- One of the biggest problems with an API is the mis-use or misunderstanding of the meaning and purpose of one. The term itself is not the most accurate and is also not ideal. A more appropriate term would be a Library Interface or a Software Interface. + One of the biggest problems with an API is the misuse or misunderstanding of the meaning and purpose of one. + The term itself is not the most accurate and is also not ideal. + A more appropriate term would be a Library Interface or a Software Interface.

@@ -268,7 +181,11 @@

- The API term is commonly mis-represented as Services or Protocols (such as "Web API"). An API instructs a programmer how to use a dependency when programming some software that utilizes said dependency. An API is a Specification of some Implementation of a Standard be it a formally defined standard or an informally defined standard. An API may be an Implementation of a Standard or a part of an Implementation of a Standard. An API is, in effect, documentation. + The API term is commonly mis-represented as Services or Protocols (such as "Web API"). + An API instructs a programmer how to use a dependency when programming some software that utilizes said dependency. + An API is a Specification of some Implementation of a Standard be it a formally defined standard or an informally defined standard. + An API may be an Implementation of a Standard or a part of an Implementation of a Standard. + An API is, in effect, documentation.

@@ -279,7 +196,10 @@

- The ABI term refers to an Application Binary Interface and represents the compiled implementation of some API. An ABI may not always exist for some API, such as for pure scripting languages. An ABI is neither a Specification nor a Standard. An ABI is an Implementation of an API making it an Implementation of a Standard or Specification. + The ABI term refers to an Application Binary Interface and represents the compiled implementation of some API. + An ABI may not always exist for some API, such as for pure scripting languages. + An ABI is neither a Specification nor a Standard. + An ABI is an Implementation of an API making it an Implementation of a Standard or Specification.

diff --git a/documents/standards/control/documents/packet_request.txt b/documents/standards/control/documents/packet_request.txt new file mode 100644 index 0000000..6f7e8c3 --- /dev/null +++ b/documents/standards/control/documents/packet_request.txt @@ -0,0 +1,38 @@ +# fss-0002 +# +# license: open-standard-license-1.0-or-later +# version 2024/07/02 +# + +Packet Request: + The Control program sends packets and receives packet responses from the Controller program over the Controller program's Control socket. + This documentation describes the request packets sent by this program. + + The purpose of these request packets are to ask the Controller program to perform a requested action. + + The communications to/from the Controller program utilize the FSS-000F (Simple Packet). + This Simple Packet is expected to contain within it the FSS-000E (Payload) format. + + The Payload contains within it a Header and a Payload. + Note the potential confusion here between the Payload when referring to the Packet format and the Payload referring to the Content within the Payload Packet. + To avoid this, henceforth "Payload Packet" refers to the FSS-000E (Payload) used within the FSS-000F (Simple Packet). + The "Payload Header" refers to either the Object ("header:") or Content within the Payload Packet representing the header. + The "Payload Object" refers to the Object within the Payload Packet (ie: "payload:"). + The "Payload Content" refers to the Content within the Payload Packet. + + The FSS-000E (Payload Packet) is very flexible in what it allows within the Header of the Payload Packet. + The Control program is more restrictive and supports only a subset of the possibilities (which this is explicitly allowed by the Specification). + + The Control program only supports the following Payload Packet header Objects for the request\: + - type: Allows only a single type header Object and may only be one of: "controller", "error", or "init". + - length: Allows only a single length header Object and must properly describe the length of the entire Payload Packet as per the referenced Specifications. + - action: Allows only a single action header Object and whose first Content must only be one of: "freeze", "kexec", "kill", "pause", "reboot", "reload", "rerun", "restart", "resume", "shutdown", "start", "stop", and "thaw". + + The number of Content associated with a action are specific to the requirements of that action. + + The Payload Content is not used and should always be of length 0. + + The Payload Content represents the rule being started in FSS-0001 (Extended) format, such as "service sshd". + + For example, given the command: "control start service sshd in 5 minutes". + The "action" Object would be "start service sshd in 5 minutes". diff --git a/documents/standards/control/documents/packet_response.txt b/documents/standards/control/documents/packet_response.txt new file mode 100644 index 0000000..8c12c48 --- /dev/null +++ b/documents/standards/control/documents/packet_response.txt @@ -0,0 +1,53 @@ +# fss-0002 +# +# license: open-standard-license-1.0-or-later +# version 2024/07/02 +# + +Packet Response: + The control program sends packets and receives packet responses from the controller program over the controller program's control socket. + This documentation describes the expected response packets and how these response packets are handled. + + The communications to/from the controller program utilize the FSS-000F (Simple Packet). + This Simple Packet is expected to contain within it the FSS-000E (Payload) format. + + The Payload contains within it a Header and a Payload. + Note the potential confusion here between the Payload when referring to the Packet format and the Payload referring to the Content within the Payload Packet. + The "Payload Header" refers to either the Object ("header:") or Content within the Payload Packet representing the header. + The "Payload Object" refers to the Object within the Payload Packet (ie: "payload:"). + The "Payload Content" refers to the Content within the Payload Packet. + + The Payload Packet (FSS-000E) is very flexible in what it allows within the Header of the Payload Packet. + The Control program is more restrictive and supports only a subset of the possibilities (which this is explicitly allowed by the Specification). + + The Control program only supports the following Payload Packet header Objects for the response\: + - status: Allows only a single status header Object. + - type: Allows only a single type header Object and may only be one of: "controller", "error", or "init". + - action: Allows only a single action header Object and must only be one of: "freeze", "kexec", "kill", "pause", "reboot", "reload", "rerun", "restart", "resume", "shutdown", "start", "stop", and "thaw". + - length: Allows only a single length header Object and must properly describe the length of the entire Payload Packet as per the referenced Specifications. + + The "error" type response Payload Packet is treated as an error response. + For any error responses that are associated with an action, then the action header is provided (otherwise it is not expected and is ignored). + For any error responses the Payload Content may be empty but when it is not, then the Payload Content is a single string representing a message further describing the error or the reason for the error. + These error responses represents errors in attempting to perform some action. + These responses are not used for actions that return an error as the result of a proper execution or performing of that action. + + The "controller" type response Payload Packet represents a response regarding the result of performing a requested action. + There must always be an "action" designating the action this response is in regards to. + Only the following are (currently) supported as a status\: + - F_busy: When unable to perform the action as because the service is too busy or the + - F_done: When successfully performed the action but the action does not return success or failure. + - F_failure: When successfully performed the action and the action returned some sort of failure or error. + - F_success: When successfully performed the action and the action returned some sort of success. + + When using the -R/--return parameter, the program prints specially formatted messages to help make the output more scriptable. + + The form is "response [type] [action] [status]". + Examples\: + - A response that designates the action failed might look like: "response controller my_action F_failure". + - A response that designates the controller ran out of memory, preventing the action from being run: "response error my_action F_memory_not". + - A response that designates the controller ran successfully: "response controller my_action F_success". + + When the control program fails to function due to some error, there will be no specially formatted message printed. + When the controller program fails before it can perform the requested action, then a "response error [action] [status]" formatted message is printed. + When the controller program successfully performs the action but the result of that action is an error, then a "response controller [action] F_failure" formatted message is printed. diff --git a/documents/standards/control/documents/readme.build.txt b/documents/standards/control/documents/readme.build.txt new file mode 100644 index 0000000..53c235d --- /dev/null +++ b/documents/standards/control/documents/readme.build.txt @@ -0,0 +1,335 @@ +# fss-0002 iki-0000 +# +# license: cc-by-sa-4.0 +# version 2024/07/10 +# +# This file (assumed to be named readme.build.txt) can be more easily read using the following iki_read commands: +# iki_read readme.build.txt +Q -w -rr FLL FLL FSS FSS -WW character "'" "'" code '"' '"' +# +# To read the "Build Readme Documentation" section of this file, use this command sequence: +# fss_basic_list_read readme.build.txt +Q -cn "Build Readme Documentation" | iki_read +Q -w -rr FLL FLL FSS FSS -WW character "'" "'" code '"' '"' +# + +Build Readme Documentation: + The bold:"Featureless Make", or code:"fake", is a build system opposing the bold:"GNU Make" build (and install) system. + See the code:"fake" project for further details regarding that build system. + + Use the code:"make" operation from the code:"fake" program to build this project\: + code:"fake" + + If the project has already been built before, alternative consider performing both a code:"clean" and an explicit code:"make" operation\: + code:"fake clean make" + + After building, either run the helper file:"install.sh" script or manually install the build files. + + Install Example\: + code:"./install.sh" + + Manual Install Example\: + code:"cp -vR build/documentation/* /usr/share/" + code:"cp -vR build/includes/* /usr/include/" + code:"cp -vR build/libaries/shared/* /usr/lib/" + code:"cp -vR build/programs/shared/* /usr/bin/" + code:"cp -vR build/settings/* /etc/" + + Build Tree Structure Example (using an early code:"controller-0.7.4" project structure)\: + block:" + build/ + âââ documentation + âÂ Â âââ man + âÂ Â âââ man1 + âÂ Â âÂ Â âââ controller.1 + âÂ Â âââ man5 + âÂ Â âââ controller-actions.5 + âÂ Â âââ controller-entry.5 + âÂ Â âââ controller-exit.5 + âÂ Â âââ controller-packet.5 + âÂ Â âââ controller-rule.5 + âââ documents + âââ includes + âÂ Â âââ program + âÂ Â âââ controller + âÂ Â âââ controller + âÂ Â âÂ Â âââ controller.h + âÂ Â âÂ Â âââ string.h + âÂ Â âââ init + âÂ Â âÂ Â âââ init.h + âÂ Â âÂ Â âââ string.h + âÂ Â âââ main + âÂ Â âââ common + âÂ Â âÂ Â âââ define + âÂ Â âÂ Â âÂ Â âââ control.h + âÂ Â âÂ Â âÂ Â âââ entry.h + âÂ Â âÂ Â âÂ Â âââ rule.h + âÂ Â âÂ Â âÂ Â âââ thread.h + âÂ Â âÂ Â âââ define.h + âÂ Â âÂ Â âââ enumeration + âÂ Â âÂ Â âÂ Â âââ control.h + âÂ Â âÂ Â âÂ Â âââ entry.h + âÂ Â âÂ Â âÂ Â âââ instance.h + âÂ Â âÂ Â âÂ Â âââ process.h + âÂ Â âÂ Â âÂ Â âââ rule.h + âÂ Â âÂ Â âÂ Â âââ thread.h + âÂ Â âÂ Â âââ enumeration.h + âÂ Â âÂ Â âââ print.h + âÂ Â âÂ Â âââ string + âÂ Â âÂ Â âÂ Â âââ general.h + âÂ Â âÂ Â âÂ Â âââ rule.h + âÂ Â âÂ Â âââ string.h + âÂ Â âÂ Â âââ type + âÂ Â âÂ Â âÂ Â âââ cache.h + âÂ Â âÂ Â âÂ Â âââ control.h + âÂ Â âÂ Â âÂ Â âââ defs.h + âÂ Â âÂ Â âÂ Â âââ entry.h + âÂ Â âÂ Â âÂ Â âââ execute.h + âÂ Â âÂ Â âÂ Â âââ instance.h + âÂ Â âÂ Â âÂ Â âââ interrupt.h + âÂ Â âÂ Â âÂ Â âââ lock.h + âÂ Â âÂ Â âÂ Â âââ process.h + âÂ Â âÂ Â âÂ Â âââ rule.h + âÂ Â âÂ Â âÂ Â âââ thread.h + âÂ Â âÂ Â âââ type.h + âÂ Â âââ common.h + âÂ Â âââ controller.h + âÂ Â âââ convert.h + âÂ Â âââ entry + âÂ Â âÂ Â âââ action.h + âÂ Â âÂ Â âââ preprocess.h + âÂ Â âÂ Â âââ process.h + âÂ Â âÂ Â âââ setting.h + âÂ Â âââ entry.h + âÂ Â âââ file.h + âÂ Â âââ instance + âÂ Â âÂ Â âââ prepare.h + âÂ Â âÂ Â âââ wait.h + âÂ Â âââ instance.h + âÂ Â âââ lock.h + âÂ Â âââ path.h + âÂ Â âââ perform.h + âÂ Â âââ print + âÂ Â âÂ Â âââ data.h + âÂ Â âÂ Â âââ debug + âÂ Â âÂ Â âÂ Â âââ perform + âÂ Â âÂ Â âÂ Â âÂ Â âââ control.h + âÂ Â âÂ Â âÂ Â âÂ Â âââ pid.h + âÂ Â âÂ Â âÂ Â âââ rule + âÂ Â âÂ Â âÂ Â âââ action.h + âÂ Â âÂ Â âÂ Â âââ execute.h + âÂ Â âÂ Â âââ debug.h + âÂ Â âÂ Â âââ error + âÂ Â âÂ Â âÂ Â âââ entry + âÂ Â âÂ Â âÂ Â âÂ Â âââ action.h + âÂ Â âÂ Â âÂ Â âÂ Â âââ item.h + âÂ Â âÂ Â âÂ Â âÂ Â âââ setting.h + âÂ Â âÂ Â âÂ Â âââ entry.h + âÂ Â âÂ Â âÂ Â âââ lock.h + âÂ Â âÂ Â âÂ Â âââ perform + âÂ Â âÂ Â âÂ Â âÂ Â âââ pid.h + âÂ Â âÂ Â âÂ Â âââ rule + âÂ Â âÂ Â âÂ Â âÂ Â âââ action.h + âÂ Â âÂ Â âÂ Â âÂ Â âââ item.h + âÂ Â âÂ Â âÂ Â âÂ Â âââ setting.h + âÂ Â âÂ Â âÂ Â âââ rule.h + âÂ Â âÂ Â âââ error.h + âÂ Â âÂ Â âââ lock.h + âÂ Â âÂ Â âââ message + âÂ Â âÂ Â âÂ Â âââ entry + âÂ Â âÂ Â âÂ Â âÂ Â âââ action.h + âÂ Â âÂ Â âÂ Â âÂ Â âââ item.h + âÂ Â âÂ Â âÂ Â âââ entry.h + âÂ Â âÂ Â âââ message.h + âÂ Â âÂ Â âââ output + âÂ Â âÂ Â âÂ Â âââ entry + âÂ Â âÂ Â âÂ Â âÂ Â âââ setting.h + âÂ Â âÂ Â âÂ Â âââ rule + âÂ Â âÂ Â âÂ Â âââ execute.h + âÂ Â âÂ Â âÂ Â âââ setting.h + âÂ Â âÂ Â âÂ Â âââ validate.h + âÂ Â âÂ Â âââ verbose.h + âÂ Â âÂ Â âââ warning + âÂ Â âÂ Â âÂ Â âââ entry + âÂ Â âÂ Â âÂ Â âÂ Â âââ action.h + âÂ Â âÂ Â âÂ Â âÂ Â âââ item.h + âÂ Â âÂ Â âÂ Â âÂ Â âââ setting.h + âÂ Â âÂ Â âÂ Â âââ rule + âÂ Â âÂ Â âÂ Â âââ action.h + âÂ Â âÂ Â âÂ Â âââ item.h + âÂ Â âÂ Â âÂ Â âââ setting.h + âÂ Â âÂ Â âââ warning.h + âÂ Â âââ process.h + âÂ Â âââ rule + âÂ Â âÂ Â âââ action.h + âÂ Â âÂ Â âââ execute.h + âÂ Â âÂ Â âââ expand.h + âÂ Â âÂ Â âââ instance.h + âÂ Â âÂ Â âââ is.h + âÂ Â âÂ Â âââ item.h + âÂ Â âÂ Â âââ parameter.h + âÂ Â âÂ Â âââ read.h + âÂ Â âÂ Â âââ setting.h + âÂ Â âÂ Â âââ wait.h + âÂ Â âââ rule.h + âÂ Â âââ signal.h + âÂ Â âââ status.h + âÂ Â âââ thread + âÂ Â âÂ Â âââ cleanup.h + âÂ Â âÂ Â âââ control.h + âÂ Â âÂ Â âââ entry.h + âÂ Â âÂ Â âââ instance.h + âÂ Â âÂ Â âââ is.h + âÂ Â âÂ Â âââ rule.h + âÂ Â âÂ Â âââ signal.h + âÂ Â âââ thread.h + âÂ Â âââ time.h + âÂ Â âââ validate.h + âââ libraries + âÂ Â âââ script + âÂ Â âââ shared + âÂ Â âÂ Â âââ libcontroller.so -> libcontroller.so.0 + âÂ Â âÂ Â âââ libcontroller.so.0 -> libcontroller.so.0.7 + âÂ Â âÂ Â âââ libcontroller.so.0.7 -> libcontroller.so.0.7.4 + âÂ Â âÂ Â âââ libcontroller.so.0.7.4 + âÂ Â âââ static + âââ objects + âÂ Â âââ script + âÂ Â âââ shared + âÂ Â âââ static + âââ programs + âÂ Â âââ script + âÂ Â âââ shared + âÂ Â âÂ Â âââ controller + âÂ Â âÂ Â âââ init + âÂ Â âââ static + âââ settings + âÂ Â âââ controller + âÂ Â âââ entries + âÂ Â âÂ Â âââ default.entry + âÂ Â âÂ Â âââ maintenance.entry + âÂ Â âââ example + âÂ Â âÂ Â âââ cgroup_example + âÂ Â âÂ Â âÂ Â âââ entries + âÂ Â âÂ Â âÂ Â âÂ Â âââ chromium.entry + âÂ Â âÂ Â âÂ Â âÂ Â âââ eclipse.entry + âÂ Â âÂ Â âÂ Â âÂ Â âââ firefox.entry + âÂ Â âÂ Â âÂ Â âÂ Â âââ setup_cgroups.entry + âÂ Â âÂ Â âÂ Â âââ rules + âÂ Â âÂ Â âÂ Â âââ program + âÂ Â âÂ Â âÂ Â âÂ Â âââ chromium.rule + âÂ Â âÂ Â âÂ Â âÂ Â âââ eclipse.rule + âÂ Â âÂ Â âÂ Â âÂ Â âââ firefox.rule + âÂ Â âÂ Â âÂ Â âââ setup + âÂ Â âÂ Â âÂ Â âââ cgroups.rule + âÂ Â âÂ Â âââ entries + âÂ Â âÂ Â âÂ Â âââ asynchronous.entry + âÂ Â âÂ Â âÂ Â âââ asynchronous-serial.entry + âÂ Â âÂ Â âÂ Â âââ delay-program.entry + âÂ Â âÂ Â âÂ Â âââ delay-service.entry + âÂ Â âÂ Â âÂ Â âââ environment.entry + âÂ Â âÂ Â âÂ Â âââ htop-alternate.entry + âÂ Â âÂ Â âÂ Â âââ htop-command.entry + âÂ Â âÂ Â âÂ Â âââ htop.entry + âÂ Â âÂ Â âÂ Â âââ iki.entry + âÂ Â âÂ Â âÂ Â âââ serial-alternate.entry + âÂ Â âÂ Â âÂ Â âââ serial.entry + âÂ Â âÂ Â âÂ Â âââ sshd.entry + âÂ Â âÂ Â âÂ Â âââ test.entry + âÂ Â âÂ Â âÂ Â âââ up.entry + âÂ Â âÂ Â âÂ Â âââ utility.entry + âÂ Â âÂ Â âââ exits + âÂ Â âÂ Â âÂ Â âââ htop-alternate.exit + âÂ Â âÂ Â âÂ Â âââ serial.exit + âÂ Â âÂ Â âÂ Â âââ sshd.exit + âÂ Â âÂ Â âââ rules + âÂ Â âÂ Â âââ asynchronous + âÂ Â âÂ Â âÂ Â âââ sleep_10.rule + âÂ Â âÂ Â âÂ Â âââ sleep_1.rule + âÂ Â âÂ Â âÂ Â âââ sleep_2.rule + âÂ Â âÂ Â âÂ Â âââ sleep_3.rule + âÂ Â âÂ Â âÂ Â âââ sleep_5.rule + âÂ Â âÂ Â âÂ Â âââ sleep_8.rule + âÂ Â âÂ Â âââ command + âÂ Â âÂ Â âÂ Â âââ htop.rule + âÂ Â âÂ Â âÂ Â âââ multiple.rule + âÂ Â âÂ Â âââ delay + âÂ Â âÂ Â âÂ Â âââ long.rule + âÂ Â âÂ Â âÂ Â âââ short.rule + âÂ Â âÂ Â âââ environment + âÂ Â âÂ Â âÂ Â âââ default.rule + âÂ Â âÂ Â âÂ Â âââ empty.rule + âÂ Â âÂ Â âÂ Â âââ exported.rule + âÂ Â âÂ Â âÂ Â âââ exporting.rule + âÂ Â âÂ Â âÂ Â âââ fake-nothing.rule + âÂ Â âÂ Â âÂ Â âââ fake-something.rule + âÂ Â âÂ Â âââ maintenance + âÂ Â âÂ Â âÂ Â âââ boom.rule + âÂ Â âÂ Â âââ print + âÂ Â âÂ Â âÂ Â âââ newline.rule + âÂ Â âÂ Â âââ script + âÂ Â âÂ Â âÂ Â âââ create_socket_path.rule + âÂ Â âÂ Â âÂ Â âââ fail.rule + âÂ Â âÂ Â âÂ Â âââ iki.rule + âÂ Â âÂ Â âÂ Â âââ php.rule + âÂ Â âÂ Â âÂ Â âââ python.rule + âÂ Â âÂ Â âÂ Â âââ require_me.rule + âÂ Â âÂ Â âÂ Â âââ succeed.rule + âÂ Â âÂ Â âââ serial + âÂ Â âÂ Â âÂ Â âââ s_1.rule + âÂ Â âÂ Â âÂ Â âââ s_2.rule + âÂ Â âÂ Â âÂ Â âââ s_3.rule + âÂ Â âÂ Â âÂ Â âââ s_4.rule + âÂ Â âÂ Â âÂ Â âââ s_5.rule + âÂ Â âÂ Â âÂ Â âââ s_6.rule + âÂ Â âÂ Â âââ service + âÂ Â âÂ Â âÂ Â âââ sshd.rule + âÂ Â âÂ Â âââ utility + âÂ Â âÂ Â âââ sleeper_1.rule + âÂ Â âÂ Â âââ sleeper_2.rule + âÂ Â âÂ Â âââ sleeper_3.rule + âÂ Â âââ rules + âÂ Â âââ boot + âÂ Â âÂ Â âââ devices.rule + âÂ Â âÂ Â âââ file_system.rule + âÂ Â âÂ Â âââ modules.rule + âÂ Â âÂ Â âââ proc.rule + âÂ Â âÂ Â âââ root.rule + âÂ Â âââ maintenance + âÂ Â âÂ Â âââ console.rule + âÂ Â âââ net + âÂ Â âÂ Â âââ all.rule + âÂ Â âÂ Â âââ loopback.rule + âÂ Â âââ service + âÂ Â âÂ Â âââ dbus.rule + âÂ Â âÂ Â âââ logger.rule + âÂ Â âÂ Â âââ mouse.rule + âÂ Â âââ task + âÂ Â âÂ Â âââ clock.rule + âÂ Â âÂ Â âââ keyboard.rule + âÂ Â âÂ Â âââ ntpdate.rule + âÂ Â âââ terminal + âÂ Â âââ four.rule + âÂ Â âââ one.rule + âÂ Â âââ three.rule + âÂ Â âââ two.rule + âââ stage + âââ library_shared-settings.built + âââ program_shared-settings.controller.built + âââ program_shared-settings.init.built + âââ skeleton-settings.built + âââ skeleton-settings.controller.built + âââ skeleton-settings.init.built + âââ sources_documentation-settings.built + âââ sources_documentation-settings.controller.built + âââ sources_documentation-settings.init.built + âââ sources_headers-settings.built + âââ sources_headers-settings.controller.built + âââ sources_headers-settings.init.built + âââ sources_script-settings.built + âââ sources_script-settings.controller.built + âââ sources_script-settings.init.built + âââ sources_settings-settings.built + âââ sources_settings-settings.controller.built + âââ sources_settings-settings.init.built + " + + See: FLL:"Featureless Linux Library" code:"fake" project documents and specifications for further details on how to use the bold:"Featureless Make" system. + See: FLL:"Featureless Linux Library" project documentation and specifications for how to configure the bold:"Featureless Make" FSS:"Featureless Settings Specification" files. diff --git a/documents/standards/control/documents/readme.txt b/documents/standards/control/documents/readme.txt new file mode 100644 index 0000000..5a97291 --- /dev/null +++ b/documents/standards/control/documents/readme.txt @@ -0,0 +1,27 @@ +# fss-0002 iki-0000 +# +# license: cc-by-sa-4.0 +# version 2024/07/10 +# +# This file (assumed to be named readme.build.txt) can be more easily read using the following iki_read commands: +# iki_read readme.txt +Q -w -r FLL FLL +# +# To read the "Readme Documentation" section of this file, use this command sequence: +# fss_basic_list_read readme.txt +Q -cn "Readme Documentation" | iki_read +Q -w -r FLL FLL +# + +Readme Documentation: + The Control program utilizes the FLL:"Featureless Linux Library" and is designed to be used for bold:"Linux" systems. + + This project follows many of the FLL:"Featureless Linux Library" project practices and the documentation provided by that project should be consulted for further details in this regard. + + The purpose of this project is to provide a tool to communicate with the Controller program. + This can also interact with the bold:"init" program that is an alternative build variation of the Controller program. + + This project follows bold:"Specification Driven Development" and details of the configuration files are defined in the directory:"specifications/" and in the directory:"documents/". + + To facilitate building of this project, these build systems are provided\: + - The bold:"Featureless Make", which is a level 3 project provided by FLL:"Featureless Linux Library". + + See: file:"data/build/dependencies" for specific dependencies of this project. + See: file:"documents/readme.build.txt" for bold:"Featureless Make" compiling and notes on installing. diff --git a/documents/standards/control/documents/settings.txt b/documents/standards/control/documents/settings.txt new file mode 100644 index 0000000..9a14391 --- /dev/null +++ b/documents/standards/control/documents/settings.txt @@ -0,0 +1,65 @@ +# fss-0002 +# +# license: open-standard-license-1.0-or-later +# version 2024/07/02 +# + +Settings Documentation: + This describes intent and purposes of the control settings file. + + The settings file provides default or system-wide settings. + The system-wide settings file is loaded by default but a custom settings file may be alternatively specified. + Using this avoids the need to add additional paramters to the command line when calling the control program. + + When this file is not specified any hardcoded defaults compiled into the program are used. + + The location of the settings file is compile time specific and should be changed depending on the particular design of the system. + The default path for the control settings file is something like "/etc/control/settings". + + - name_socket\: + This represents the file name used to construct the full socket path. + The file name represents the name of the file but any file extensions, such as ".suffix", should likely use "path_socket_suffix" to specify the file extension. + + When not defined the compiled in default is used. + The default socket path directory is generally "default" but this could be changed during compile time. + + This is required to not be empty so when the Object "path_socket" is defined without any Content, then an error is expected to be thrown. + + This is used along with the "path_socket", "path_socket_prefix", and the "path_socket_suffix" to construct the socket file. + + - path_socket\: + This represents the directory path to the socket file provided by the controller or init service. + This directory path is separate from the file name part so that the name can be more dynamically constructed without having to specify a full directory path each time. + + When not defined the compiled in default is used. + The default socket path directory is generally "/var/run/controller" but this could be changed during compile time. + + When the Object "path_socket" is defined without any Content, then no path is added (resulting in the socket relative to the callers current working directory). + + This is used along with the "path_socket_prefix", the "path_socket_suffix", and the "name_socket" to construct the socket file. + A full socket path might look something like "/var/run/controller/controller-default.socket". + + It is common for the controller program to be compiled as an init program. + In this case it may be common for the full socket path to instead be something more like "/var/run/init/init-default.socket". + + - path_socket_prefix\: + This represents a prefix used to construct the full socket path. + This prefix is prepended to the socket file name. + + When not defined the compiled in default is used. + The default path prefix is generally "controller-" but this could be changed during compile time. + + When the Object "path_socket_prefix" is defined without any Content, then no prefix is prepended. + + This is used along with the "path_socket", the "path_socket_suffix", and the "name_socket" to construct the socket file. + + - path_socket_suffix\: + This represents a suffix used to construct the full socket path. + This suffix is appended to the socket file name. + + When not defined the compiled in default is used. + The default path suffix is generally ".socket" but this could be changed during compile time. + + When the Object "path_socket_suffix" is defined without any Content, then no suffix is appended. + + This is used along with the "path_socket", the "path_socket_prefix", and the "name_socket" to construct the socket file. diff --git a/documents/standards/control/documents/source_design.txt b/documents/standards/control/documents/source_design.txt new file mode 100644 index 0000000..bd48b3b --- /dev/null +++ b/documents/standards/control/documents/source_design.txt @@ -0,0 +1,82 @@ +# fss-0002 iki-0000 +# +# license cc-by-sa-4.0 +# version 2025/08/26 +# +# This file (assumed to be named source_design.txt) can be more easily read using the following iki_read commands: +# iki_read source_design.txt +Q -w -rrr API API FLL FLL FSS FSS -WW character "'" "'" code '"' '"' +# +# To read the "Intent and Design of Source Code" section of this file, use this command sequence: +# fss_basic_list_read source_design.txt +Q -cn "Intent and Design of Source Code" | iki_read +Q -w -rrr API API FLL FLL FSS FSS -WW character "'" "'" code '"' '"' +# + +Intent and Design of Source Code: + This project follows the bold:"Intent and Design of Source Code" of the FLL:"Featureless Linux Library". + The italic:"Intent and Design of Featureless Linux Library" section is a copy of the FLL:"Featureless Linux Library" intend and design text. + +Intent and Design of Featureless Linux Library: + The FLL:"Featureless Linux Library", and many of the related projects, follow specific designs on how the source code, the API:"Application Programming Interface", the ABI:"Application Binary Interface", and the numerous specifications are intended to be operated and used. + + The biggest and most important of these is that this project is designed and intended to be used and optionally modified in an open-source and free manner. + + There are several principles in which the FLL:"Featureless Linux Library" is designed around to help achieve this\: + 1. All software can be a library; the distinction between an executable program and a library is not real and is a falsehood. + 2. Proper use and understanding of terminology. + 3. All functions can be added, removed, and modified at will; the behavior and functions can be changed in any manner. + 4. Separation of a specification from its implementation. + 5. The ability to combine, merge, separate, mix, and unmix any of the source code into different forms. + 6. Leave the actual configuration setup to th users combining or distributing the software. + 7. The software should ideally be functional examples where anything being present itself can potentially be fully used. + + The first principle is easily achieved in languages like C and C++. + Use the dynamic linker and link the programs, aka executables, as a library and make the actual program more or less a shim. + This does not mean programs cannot have additional changes and behavior. + + The second principle can be solved by closely observing actual meanings of technological terms and through the avoidance of "buzz" terms. + The terminology that has been historically established in the computer software field has seen some erosion. + One such example is with the API:"Application Programming Interface", which has been misused to represent request messages, like with REST:"Representational State Transfer" which is a protocol and rather than an API:"Application Programming Interface". + The second principle strongly supports the first by recognizing what is really happening verses what is an artificial or conceptual distinction. + A program, or executable, is ultimately no different from a library. + The distinction between the two is ultimately conceptual. + There are many libraries that can be executed like a program and there are programs that can be linked to by a library. + + The third principle is solved through how the source code is structured. + In the case of C code, nearly every aspect has an code:"ifdef" (or similar) wrapping that allows for customization. + The files themselves are broken up into context and purpose. + This should allow for the dynamic cherry-picking style enable or disabling certain functions. + Alternative versions of functions, that may or may not operate differently, can be enabled or disabled in a similar manner. + Major groups of changes can be performed by swapping in or out different source files. + The ability to completely omit massive amounts of functionality can be accomplished through various combinations therein. + There are even pre-built "disable" files to help facilitate mass changes. + There are also guides on generating and using stand alone builds. + Something similar will likely have to be followed as appropriate for languages other than C and C++. + + The fourth principle is achieved first by following the second principle and then by establishing differences between what a library is and what a specification is. + A specification has its own license, independent of the license of the source code, and also helps facilitate the distinction between a library and the specification. + A library can follow the specification or can deviate from the specification, by design. + When this deviation occurs should be properly documented or communicated. + Following the specification, be it in full, in part, or even minimally, is all allowed but should be properly communicated. + Whether any aspect of a specification needs to or needs to not be followed is entirely situational and such decisions should be made by the individuals or entities building and distributing such software (be it in binary or in source form). + This is not to say that the license can be violated. + Be aware, however, that it is the code or the specification that can be changed, not the license itself. + + The fifth principle is achieved through numerous means. + The Featureless Make and related specifications provide a means to tweak and customize how the library is built. + The separation of the installation logic from the build logic is a major player here. + The source code does not impose, for the most part, any sort of restrictions on how the software is to be installed once compiled. + This is left to the distributor or the end-user. + Linking dynamically or statically is entirely optional. + Linking in one big library or many smaller pieces is entirely optional. + Excluding or including individual snippets or functions is configurable, such as how the stand alone builds are designed. + + The sixth principle is achieved by providing a standard build structure for compiling that does not particularly relate to the system setup. + Many of the designs from the fifth principle help make the sixth principle possible, such as the Featureless Make build system. + The build system setup is laid out based on how the files are built rather than how they might be installed. + + The seventh principle is achieved in several different ways. + The example bootstrap scripts are themselves used to help build or initialize projects if the Featureless Make software is not yet present. + Stand alone builds are functional examples that present how one might construct a stand alone project. + These stand alone builds are themselves formally released as convenience releases for individuals only desiring one program and not any other parts of the FLL:"Featureless Linux Library",. + The stand alone builds also present ways to mass disable unneeded functionality from the FLL:"Featureless Linux Library" dependencies. + The Featureless Make itself provides build examples that can simultaneously be used as manual runtime tests. + The FSS Read, FSS Write, IKI Read, IKI Write programs provide functional examples on how to implement and use the FLL:"Featureless Linux Library" and follow the FSS:"Featureless Settings Specifications" while simultaneously providing a tool to process the associated specification. diff --git a/documents/standards/control/specifications/settings.txt b/documents/standards/control/specifications/settings.txt new file mode 100644 index 0000000..d824231 --- /dev/null +++ b/documents/standards/control/specifications/settings.txt @@ -0,0 +1,26 @@ +# fss-0002 iki-0000 +# +# license: open-standard-license-1.0-or-later +# version 2024/07/02 +# +# This file (assumed to be named settings.txt) can be more easily read using the following iki_read commands: +# iki_read settings.txt +Q -w -W code '"' '"' +# +# To read the "Entry Specification" section of this file, use this command sequence: +# fss_basic_list_read settings.txt +Q -cn "Settings Specification" | iki_read +Q -w -W code '"' '"' +# + +Settings Specification: + The control settings "settings" file follows the FSS-0001 (Extended) format. + + Each Object represents a settings property name. + There is only a distinct set of setting property names (see below). + + Each Content represents the values associated with that property. + Additional restrictions are applied to each Content depending on each specific Object name (see below). + + Object Names and their respective Content purpose/restrictions\: + - name_socket: Must only be a single valid filename, without the directory. + - path_socket: Must only be a single valid directory. + - path_socket_prefix: Zero or one string representing a file name. + - path_socket_suffix: Zero or one string representing a file name. diff --git a/documents/standards/controller/documents/controlfile.txt b/documents/standards/controller/documents/controlfile.txt new file mode 100644 index 0000000..614e92d --- /dev/null +++ b/documents/standards/controller/documents/controlfile.txt @@ -0,0 +1,31 @@ +# fss-0002 iki-0000 +# +# license: open-standard-license-1.0-or-later +# version 2025/11/21 +# +# This file (assumed to be named controlfile.txt) can be more easily read using the following iki_read commands: +# iki_read controlfile.txt +Q -w -WW code '"' '"' file '"' '"' +# +# To read the "Control File Documentation" section of this file, use this command sequence: +# fss_basic_list_read controlfile.txt +Q -cn "Control File Documentation" | iki_read +Q -w -WW code '"' '"' file '"' '"' +# + +Control File Documentation: + + A control file is intended to be used by controller programs similar to how the code:"fakefile" is used by the bold:"Featureless Make" program. + + A control file consists of the file:"entry.txt", file:"exit.txt", and file:"rule.txt" all merged into a single file. + The goal of of a control file is to collapse the directory hierarchy structure into a single file. + This imposes no new Objects or other structures. + + Any modifications, or deviations, from this standard that add additional things beyond the bold:"Entry", bold:"Exit", and bold:"Rule" are encouraged to follow the naming prefix pattern. + The naming pattern is the simple standard name, like code:"entry", code:"exit", or code:"rule" followed by a forward slash (unicode:"U+002F") as a prefix. + Then all Object names would then have that prefix. + + For example, if there is an bold:"Entry" named code:"main", then the control file representation would be code:"entry/main". + + A bold:"Rule", in addition, also has the directory path part appended (where only a forward slash (unicode:"U+002F") is allowed to represent a directory separation) followed by a forward slash (unicode:"U+002F") as part of the prefix. + + For example, if there is an bold:"Rule" named code:"one" from a directory named code:"terminal" with a bold:"Script", then the control file representation would be code:"rule/terminal/one/script". + + Due to the use of a forward slash (unicode:"U+002F"), bold:"Item" names for an bold:"Entry" or a bold:"Rule" should avoid using a forward slash (unicode:"U+002F"). diff --git a/documents/standards/controller/documents/entry.txt b/documents/standards/controller/documents/entry.txt index 5292125..1b7a881 100644 --- a/documents/standards/controller/documents/entry.txt +++ b/documents/standards/controller/documents/entry.txt @@ -1,10 +1,10 @@ # fss-0002 iki-0000 # # license: open-standard-license-1.0-or-later -# version 2024/07/10 +# version 2025/11/12 # # This file (assumed to be named entry.txt) can be more easily read using the following iki_read commands: -# iki_read entry.txt +Q -r PID PID -w -WW code '"' '"' +# iki_read entry.txt +Q -r PID PID -w -W code '"' '"' # # To read the "Entry Documentation" section of this file, use this command sequence: # fss_basic_list_read entry.txt +Q -cn "Entry Documentation" | iki_read +Q -r PID PID -w -W code '"' '"' diff --git a/documents/standards/controller/documents/initfile.txt b/documents/standards/controller/documents/initfile.txt new file mode 100644 index 0000000..816eef5 --- /dev/null +++ b/documents/standards/controller/documents/initfile.txt @@ -0,0 +1,16 @@ +# fss-0002 iki-0000 +# +# license: open-standard-license-1.0-or-later +# version 2025/11/17 +# +# This file (assumed to be named initfile.txt) can be more easily read using the following iki_read commands: +# iki_read initfile.txt +Q -w -W file '"' '"' +# +# To read the "Init File Documentation" section of this file, use this command sequence: +# fss_basic_list_read initfile.txt +Q -cn "Init File Documentation" | iki_read +Q -w -W file '"' '"' +# + +Init File Documentation: + + An init file is the init program specific version of the file:"controlfile". + The init program should use an file:"initfile" instead of a file:"controlfile", if supported. diff --git a/documents/standards/controller/documents/readme.build.txt b/documents/standards/controller/documents/readme.build.txt index bf994f8..d415138 100644 --- a/documents/standards/controller/documents/readme.build.txt +++ b/documents/standards/controller/documents/readme.build.txt @@ -32,7 +32,7 @@ Build Readme Documentation: code:"cp -vR build/programs/shared/* /usr/bin/" code:"cp -vR build/settings/* /etc/" - Build Tree Structure Example (using an early code:"controller-0.7.0" project structure)\: + Build Tree Structure Example (using an early code:"controller-0.7.4" project structure)\: block:" build/ âââ documentation @@ -187,8 +187,8 @@ Build Readme Documentation: âÂ Â âââ shared âÂ Â âÂ Â âââ libcontroller.so -> libcontroller.so.0 âÂ Â âÂ Â âââ libcontroller.so.0 -> libcontroller.so.0.7 - âÂ Â âÂ Â âââ libcontroller.so.0.7 -> libcontroller.so.0.7.0 - âÂ Â âÂ Â âââ libcontroller.so.0.7.0 + âÂ Â âÂ Â âââ libcontroller.so.0.7 -> libcontroller.so.0.7.4 + âÂ Â âÂ Â âââ libcontroller.so.0.7.4 âÂ Â âââ static âââ objects âÂ Â âââ script diff --git a/documents/standards/controller/documents/source_design.txt b/documents/standards/controller/documents/source_design.txt new file mode 100644 index 0000000..bd48b3b --- /dev/null +++ b/documents/standards/controller/documents/source_design.txt @@ -0,0 +1,82 @@ +# fss-0002 iki-0000 +# +# license cc-by-sa-4.0 +# version 2025/08/26 +# +# This file (assumed to be named source_design.txt) can be more easily read using the following iki_read commands: +# iki_read source_design.txt +Q -w -rrr API API FLL FLL FSS FSS -WW character "'" "'" code '"' '"' +# +# To read the "Intent and Design of Source Code" section of this file, use this command sequence: +# fss_basic_list_read source_design.txt +Q -cn "Intent and Design of Source Code" | iki_read +Q -w -rrr API API FLL FLL FSS FSS -WW character "'" "'" code '"' '"' +# + +Intent and Design of Source Code: + This project follows the bold:"Intent and Design of Source Code" of the FLL:"Featureless Linux Library". + The italic:"Intent and Design of Featureless Linux Library" section is a copy of the FLL:"Featureless Linux Library" intend and design text. + +Intent and Design of Featureless Linux Library: + The FLL:"Featureless Linux Library", and many of the related projects, follow specific designs on how the source code, the API:"Application Programming Interface", the ABI:"Application Binary Interface", and the numerous specifications are intended to be operated and used. + + The biggest and most important of these is that this project is designed and intended to be used and optionally modified in an open-source and free manner. + + There are several principles in which the FLL:"Featureless Linux Library" is designed around to help achieve this\: + 1. All software can be a library; the distinction between an executable program and a library is not real and is a falsehood. + 2. Proper use and understanding of terminology. + 3. All functions can be added, removed, and modified at will; the behavior and functions can be changed in any manner. + 4. Separation of a specification from its implementation. + 5. The ability to combine, merge, separate, mix, and unmix any of the source code into different forms. + 6. Leave the actual configuration setup to th users combining or distributing the software. + 7. The software should ideally be functional examples where anything being present itself can potentially be fully used. + + The first principle is easily achieved in languages like C and C++. + Use the dynamic linker and link the programs, aka executables, as a library and make the actual program more or less a shim. + This does not mean programs cannot have additional changes and behavior. + + The second principle can be solved by closely observing actual meanings of technological terms and through the avoidance of "buzz" terms. + The terminology that has been historically established in the computer software field has seen some erosion. + One such example is with the API:"Application Programming Interface", which has been misused to represent request messages, like with REST:"Representational State Transfer" which is a protocol and rather than an API:"Application Programming Interface". + The second principle strongly supports the first by recognizing what is really happening verses what is an artificial or conceptual distinction. + A program, or executable, is ultimately no different from a library. + The distinction between the two is ultimately conceptual. + There are many libraries that can be executed like a program and there are programs that can be linked to by a library. + + The third principle is solved through how the source code is structured. + In the case of C code, nearly every aspect has an code:"ifdef" (or similar) wrapping that allows for customization. + The files themselves are broken up into context and purpose. + This should allow for the dynamic cherry-picking style enable or disabling certain functions. + Alternative versions of functions, that may or may not operate differently, can be enabled or disabled in a similar manner. + Major groups of changes can be performed by swapping in or out different source files. + The ability to completely omit massive amounts of functionality can be accomplished through various combinations therein. + There are even pre-built "disable" files to help facilitate mass changes. + There are also guides on generating and using stand alone builds. + Something similar will likely have to be followed as appropriate for languages other than C and C++. + + The fourth principle is achieved first by following the second principle and then by establishing differences between what a library is and what a specification is. + A specification has its own license, independent of the license of the source code, and also helps facilitate the distinction between a library and the specification. + A library can follow the specification or can deviate from the specification, by design. + When this deviation occurs should be properly documented or communicated. + Following the specification, be it in full, in part, or even minimally, is all allowed but should be properly communicated. + Whether any aspect of a specification needs to or needs to not be followed is entirely situational and such decisions should be made by the individuals or entities building and distributing such software (be it in binary or in source form). + This is not to say that the license can be violated. + Be aware, however, that it is the code or the specification that can be changed, not the license itself. + + The fifth principle is achieved through numerous means. + The Featureless Make and related specifications provide a means to tweak and customize how the library is built. + The separation of the installation logic from the build logic is a major player here. + The source code does not impose, for the most part, any sort of restrictions on how the software is to be installed once compiled. + This is left to the distributor or the end-user. + Linking dynamically or statically is entirely optional. + Linking in one big library or many smaller pieces is entirely optional. + Excluding or including individual snippets or functions is configurable, such as how the stand alone builds are designed. + + The sixth principle is achieved by providing a standard build structure for compiling that does not particularly relate to the system setup. + Many of the designs from the fifth principle help make the sixth principle possible, such as the Featureless Make build system. + The build system setup is laid out based on how the files are built rather than how they might be installed. + + The seventh principle is achieved in several different ways. + The example bootstrap scripts are themselves used to help build or initialize projects if the Featureless Make software is not yet present. + Stand alone builds are functional examples that present how one might construct a stand alone project. + These stand alone builds are themselves formally released as convenience releases for individuals only desiring one program and not any other parts of the FLL:"Featureless Linux Library",. + The stand alone builds also present ways to mass disable unneeded functionality from the FLL:"Featureless Linux Library" dependencies. + The Featureless Make itself provides build examples that can simultaneously be used as manual runtime tests. + The FSS Read, FSS Write, IKI Read, IKI Write programs provide functional examples on how to implement and use the FLL:"Featureless Linux Library" and follow the FSS:"Featureless Settings Specifications" while simultaneously providing a tool to process the associated specification. diff --git a/documents/standards/controller/specifications/controlfile.txt b/documents/standards/controller/specifications/controlfile.txt new file mode 100644 index 0000000..3feecbd --- /dev/null +++ b/documents/standards/controller/specifications/controlfile.txt @@ -0,0 +1,38 @@ +# fss-0002 iki-0000 +# +# license: open-standard-license-1.0-or-later +# version 2025/11/21 +# +# This file (assumed to be named controlfile.txt) can be more easily read using the following iki_read commands: +# iki_read controlfile.txt +Q -w -WW code '"' '"' file '"' '"' +# +# To read the "Controlfile Specification" section of this file, use this command sequence: +# fss_basic_list_read controlfile.txt +Q -cn "Controlfile Specification" | iki_read +Q -w -WW code '"' '"' file '"' '"' +# + +Controlfile Specification: + A control file follows the code:"FSS-0005 (Somewhat Basic List)" and the code:"FSS-000D (Basic Rule)" format with bold:"IKI-0000 (Unrestricted)" format. + + A control file name is expected to have the exact name of file:"controlfile". + The file:"controlfile" is all lower case and has no file extension. + + A control file consists of the file:"entry.txt", file:"exit.txt", and file:"rule.txt" all merged into a single file. + All of the specifications apply, except for the name of the Objects. + The names of the Objects are as follows. + + For file:"entry.txt": + - The code:"main" is now called code:"entry/main". + - The code:"settings" is now called code:"entry/settings". + + For file:"exit.txt": + - The code:"main" is now called code:"exit/main". + - The code:"settings" is now called code:"exit/settings". + + For file:"rule.txt" (whose bold:"Rule" with a name of code:"my_rule" is under the path code:"directory"): + - The code:"command" is now called code:"rule/directory/my_rule/command". + - The code:"script" is now called code:"rule/directory/my_rule/script". + - The code:"service" is now called code:"rule/directory/my_rule/service". + - The code:"settings" is now called code:"rule/directory/my_rule/settings". + - The code:"utility" is now called code:"rule/directory/my_rule/utility". + + Any additional specifications brought in are be expected to follow the same pattern for combining. diff --git a/documents/standards/controller/specifications/initfile.txt b/documents/standards/controller/specifications/initfile.txt new file mode 100644 index 0000000..00707ed --- /dev/null +++ b/documents/standards/controller/specifications/initfile.txt @@ -0,0 +1,17 @@ +# fss-0002 iki-0000 +# +# license: open-standard-license-1.0-or-later +# version 2025/11/17 +# +# This file (assumed to be named initfile.txt) can be more easily read using the following iki_read commands: +# iki_read initfile.txt +Q -w -W file '"' '"' +# +# To read the "Init File Specification" section of this file, use this command sequence: +# fss_basic_list_read initfile.txt +Q -cn "Init File Specification" | iki_read +Q -w -W file '"' '"' +# + +Init File Specification: + An init file is identical to a control file in all but name. + + An Initfile file name is expected to have the exact name of file:"initfile". + The file:"initfile" is all lower case and has no file extension. diff --git a/documents/standards/fake/documents/fakefile.txt b/documents/standards/fake/documents/fakefile.txt index aa57bae..5e9699c 100644 --- a/documents/standards/fake/documents/fakefile.txt +++ b/documents/standards/fake/documents/fakefile.txt @@ -1,6 +1,6 @@ # fss-0002 iki-0000 # -# license: open-standard-license-1.0-or-later +# license open-standard-license-1.0-or-later # version 2024/07/30 # # This file (assumed to be named fakefile.txt) can be more easily read using the following iki_read commands: diff --git a/documents/standards/fake/documents/settings.txt b/documents/standards/fake/documents/settings.txt index e764d32..4ec88bc 100644 --- a/documents/standards/fake/documents/settings.txt +++ b/documents/standards/fake/documents/settings.txt @@ -1,7 +1,7 @@ # fss-0002 iki-0000 # -# license: open-standard-license-1.0-or-later -# version 2024/07/30 +# license open-standard-license-1.0-or-later +# version 2025/03/07 # # This file (assumed to be named settings.txt) can be more easily read using the following iki_read commands: # iki_read settings.txt +Q -w -rrr ASCII ASCII FLL FLL GCC GCC -WW character "'" "'" code '"' '"' @@ -23,6 +23,66 @@ Settings Documentation: The programs code:"gcc" and code:"clang" are known to work. Many of the parameters in the bold:"settings" file can be changed if not using GCC:"GNU Compiler Collection", but there may be certain hard-coded functionality that may need to be changed. + - code:"build_compiler_arguments"\: + This represents arguments passed directly to the code:"build_compiler". + These arguments are placed immediately after the code:"build_compiler" program. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive". + + - code:"build_compiler_arguments_shared"\: + This represents arguments passed directly to the code:"build_compiler" for shared. + These arguments are placed immediately after the code:"build_compiler" program. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive". + + - code:"build_compiler_arguments_static"\: + This represents arguments passed directly to the code:"build_compiler for static". + These arguments are placed immediately after the code:"build_compiler" program. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive". + + - code:"build_compiler_arguments_library"\: + This represents arguments passed directly to the code:"build_compiler" when building libraries. + These arguments are placed immediately after the code:"build_compiler_arguments" parameters. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive". + + - code:"build_compiler_arguments_library_shared"\: + This represents arguments passed directly to the code:"build_compiler" when building libraries that are shared. + These arguments are placed immediately after the code:"build_compiler_arguments_library" parameters. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive". + + - code:"build_compiler_arguments_library_static"\: + This represents arguments passed directly to the code:"build_compiler" when building libraries that are static. + These arguments are placed immediately after the code:"build_compiler_arguments_library" parameters. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive". + + - code:"build_compiler_arguments_object"\: + This represents arguments passed directly to the code:"build_compiler" when building objects. + These arguments are placed immediately after the code:"build_compiler_arguments" parameters. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive" + + - code:"build_compiler_arguments_object_shared"\: + This represents arguments passed directly to the code:"build_compiler" when building objects that are shared. + These arguments are placed immediately after the code:"build_compiler_arguments_object" parameters. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive" + + - code:"build_compiler_arguments_object_static"\: + This represents arguments passed directly to the code:"build_compiler" when building objects that are static. + These arguments are placed immediately after the code:"build_compiler_arguments_object" parameters. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive" + + - code:"build_compiler_arguments_program"\: + This represents arguments passed directly to the code:"build_compiler" when building programs. + These arguments are placed immediately after the code:"build_compiler_arguments" parameters. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive". + + - code:"build_compiler_arguments_program_shared"\: + This represents arguments passed directly to the code:"build_compiler" when building programs that are shared. + These arguments are placed immediately after the code:"build_compiler_arguments_program" parameters. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive". + + - code:"build_compiler_arguments_program_static"\: + This represents arguments passed directly to the code:"build_compiler" when building programs that are static. + These arguments are placed immediately after the code:"build_compiler_arguments_program" parameters. + This is useful for some languages, such as code:"go" which might need to operate like code:"go build" or code:"go build -buildmode=archive". + - code:"build_indexer"\: This represents the name of the indexer program to use, such as code:"ar". An indexer is often called a linker. @@ -36,9 +96,15 @@ Settings Documentation: - code:"build_language"\: The programming language to build with. - The languages code:"c" and code:"c++" are supported (with code:"bash" as a consideration for support). - The code:"bash" language is not currently implemented and needs some consideration because there is nothing to compile. - The code:"bash" language will likely build a set of individual scripts, and perhaps script dependencies, into a single Bash script. + The languages code:"c", code:"c++", code:"go", and code:"shell" are the commonly known and supported languages. + The code:"shell" language is for shell languages such as code:"bash" or code:"zsh" and might not need special handling because there is nothing to compile. + The code:"shell" language might be implemented to build a set of individual scripts, and perhaps script dependencies, into a single script. + Individual implementations may restrict this to a select number of languages such as the commonly known and supported languages mentioned. + Languages not in the commonly known and supported languages are generally treated as compiled languages but the user must take care to properly configure it. + + - code:"build_language_path"\: + A path relative to the sources directory reprsenting the sources. + This defaults to a path based on the code:"build_language" when not defined. - code:"build_libraries"\: A collection of libraries to be linked against. @@ -58,49 +124,126 @@ Settings Documentation: These are applied to only static builds. - code:"build_objects_library"\: - A collection of object files to be compile with when building libraries. + A collection of object files to be compile with when building objects for libraries. These are intended to represent already compiled object files. These paths are relative to the code:"path_object_script", code:"path_object_shared", or code:"path_object_static". The order of these may matter if the compiler (such as GCC:"GNU Compiler Collection" or a linker via GCC:"GNU Compiler Collection") is order sensitive. - code:"build_objects_library_shared"\: - A collection of object files to be compile with when building shared libraries. + A collection of object files to be compile with when building objects for shared libraries. These are intended to represent already compiled object files. These paths are relative to the code:"path_object_shared". The order of these may matter if the compiler (such as GCC:"GNU Compiler Collection" or a linker via GCC:"GNU Compiler Collection") is order sensitive. These are applied to only shared builds. - code:"build_objects_library_static"\: - A collection of object files to be compile with when building static libraries. + A collection of object files to be compile with when building objects for static libraries. These are intended to represent already compiled object files. These paths are relative to the code:"path_object_static". The order of these may matter if the compiler (such as GCC:"GNU Compiler Collection" or a linker via GCC:"GNU Compiler Collection") is order sensitive. These are applied to only static builds. - code:"build_objects_program"\: - A collection of object files to be compile with when building programs. + A collection of object files to be compile with when building objects for programs. These are intended to represent already compiled object files. These paths are relative to the code:"path_object_script", code:"path_object_shared", or code:"path_object_static". The order of these may matter if the compiler (such as GCC:"GNU Compiler Collection" or a linker via GCC:"GNU Compiler Collection") is order sensitive. - code:"build_objects_program_shared"\: - A collection of object files to be compile with when building shared programs. + A collection of object files to be compile with when building objects for shared programs. These are intended to represent already compiled object files. These paths are relative to the code:"path_object_shared". The order of these may matter if the compiler (such as GCC:"GNU Compiler Collection" or a linker via GCC:"GNU Compiler Collection") is order sensitive. These are applied to only shared builds. - code:"build_objects_program_static"\: - A collection of object files to be compile with when building static programs. + A collection of object files to be compile with when building objects for static programs. These are intended to represent already compiled object files. These paths are relative to the code:"path_object_static". The order of these may matter if the compiler (such as GCC:"GNU Compiler Collection" or a linker via GCC:"GNU Compiler Collection") is order sensitive. These are applied to only static builds. - code:"build_name"\: - The name of the build, which often represent the project name. + The name of the build, which often represents the project name. If program sources are specified, then this will be used as the program name. If library sources are specified, then this will be used in the library name, such as code:"libX.so" where code:"X" would be the code:"build_name" value. + If script sources are specified, then this will be used as the script name. + This is required even if one of the more specific types, such as code:"build_name_library_shared", is specified. + + - code:"build_name_library"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the library name involving objects, such as code:"libX.so" where code:"X" would be the code:"build_name_library" value. + + - code:"build_name_library_shared"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the library name for shared builds involving objects. + These are applied to only to shared builds. + + - code:"build_name_library_static"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the library name for static builds involving objects. + These are applied to only to static builds. + + - code:"build_name_object"\: + The name of the build, which often represents the project name. + If library sources are specified, then this is a variation of code:"build_name" used specifically for the program name involving objects. + If program sources are specified, then this is a variation of code:"build_name" used specifically for the library name involving objects. + + - code:"build_name_object_library"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the library name involving objects, such as code:"libX.so" where code:"X" would be the code:"build_name_library" value. + + - code:"build_name_object_library_shared"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the library name for shared builds involving objects. + These are applied to only to shared builds. + + - code:"build_name_object_library_static"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the library name for static builds involving objects. + These are applied to only to static builds. + + - code:"build_name_object_program"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the program name involving objects. + + - code:"build_name_object_program_shared"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the program name for shared builds involving objects. + These are applied to only to shared builds. + + - code:"build_name_object_program_static"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the program name for static builds involving objects. + These are applied to only to static builds. + + - code:"build_name_object_shared"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the program name for shared builds involving objects. + These are applied to only to shared builds. + + - code:"build_name_object_static"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the program name for static builds involving objects. + These are applied to only to static builds. + + - code:"build_name_program"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the program name. + + - code:"build_name_program_shared"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the program name for shared builds. + These are applied to only to shared builds. + + - code:"build_name_program_static"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the program name for static builds. + These are applied to only to static builds. + + - code:"build_name_script"\: + The name of the build, which often represents the project name. + This is a variation of code:"build_name" used specifically for the script name. - code:"build_script"\: When code:"yes", the build process will build any scripts, such as a Bash script. @@ -157,7 +300,7 @@ Settings Documentation: The built objects do not get linked and therefore no linker arguments apply. The built object files are named using the same name as the file with the file extension changed to the code:".o" extension. May include a relative sub-path to each individual source file (such as: code:"level_0/a.c level_0/b.c"). - This is different from code:"build_sources_object" in that multiple files are supported and multiple object files are created. + Multiple files are supported and multiple object files are created. - code:"build_sources_object_shared"\: A collection of source files used for generating an object file with the same name as each source file. @@ -165,7 +308,7 @@ Settings Documentation: The built objects do not get linked and therefore no linker arguments apply. The built object files are named using the same name as the file with the file extension changed to the code:".o" extension. May include a relative sub-path to each individual source file (such as: code:"level_0/a.c level_0/b.c"). - This is different from code:"build_sources_object" in that multiple files are supported and multiple object files are created. + Multiple files are supported and multiple object files are created. These are applied to only shared builds. - code:"build_sources_object_static"\: @@ -174,7 +317,7 @@ Settings Documentation: The built objects do not get linked and therefore no linker arguments apply. The built object files are named using the same name as the file with the file extension changed to the code:".o" extension. May include a relative sub-path to each individual source file (such as: code:"level_0/a.c level_0/b.c"). - This is different from code:"build_sources_object" in that multiple files are supported and multiple object files are created. + Multiple files are supported and multiple object files are created. These are applied to only static builds. - code:"build_sources_program"\: diff --git a/documents/standards/fake/specifications/defines.txt b/documents/standards/fake/specifications/defines.txt index e2c8412..9e7d660 100644 --- a/documents/standards/fake/specifications/defines.txt +++ b/documents/standards/fake/specifications/defines.txt @@ -1,6 +1,6 @@ # fss-0002 iki-0000 # -# license: open-standard-license-1.0-or-later +# license open-standard-license-1.0-or-later # version 2024/03/23 # # This file (assumed to be named defines.txt) can be more easily read using the following iki_read commands: diff --git a/documents/standards/fake/specifications/dependencies.txt b/documents/standards/fake/specifications/dependencies.txt index abb9ed7..e6fbf9f 100644 --- a/documents/standards/fake/specifications/dependencies.txt +++ b/documents/standards/fake/specifications/dependencies.txt @@ -1,6 +1,6 @@ # fss-0002 iki-0000 # -# license: open-standard-license-1.0-or-later +# license open-standard-license-1.0-or-later # version 2024/03/23 # # This file (assumed to be named dependencies.txt) can be more easily read using the following iki_read commands: diff --git a/documents/standards/fake/specifications/fakefile.txt b/documents/standards/fake/specifications/fakefile.txt index 7a8134e..e25796d 100644 --- a/documents/standards/fake/specifications/fakefile.txt +++ b/documents/standards/fake/specifications/fakefile.txt @@ -1,6 +1,6 @@ # fss-0002 iki-0000 # -# license: open-standard-license-1.0-or-later +# license open-standard-license-1.0-or-later # version 2024/07/30 # # This file (assumed to be named fakefile.txt) can be more easily read using the following iki_read commands: diff --git a/documents/standards/fake/specifications/settings.txt b/documents/standards/fake/specifications/settings.txt index 9a94ef2..f0d029c 100644 --- a/documents/standards/fake/specifications/settings.txt +++ b/documents/standards/fake/specifications/settings.txt @@ -1,7 +1,7 @@ # fss-0002 iki-0000 # -# license: open-standard-license-1.0-or-later -# version 2024/07/30 +# license open-standard-license-1.0-or-later +# version 2025/03/07 # # This file (assumed to be named settings.txt) can be more easily read using the following iki_read commands: # iki_read settings.txt +Q -w -WW character "'" "'" code '"' '"' @@ -21,13 +21,41 @@ Settings Specification: bold:"Object" names and their respective bold:"Content" purpose/restrictions\: - code:"build_compiler": Only one bold:"Content", which must only be a valid filename. + - code:"build_compiler_arguments": Must be zero or more parameters. + - code:"build_compiler_arguments_shared": Must be zero or more parameters. + - code:"build_compiler_arguments_static": Must be zero or more parameters. + - code:"build_compiler_arguments_library": Must be zero or more parameters. + - code:"build_compiler_arguments_library_shared": Must be zero or more parameters. + - code:"build_compiler_arguments_library_static": Must be zero or more parameters. + - code:"build_compiler_arguments_object": Must be zero or more parameters. + - code:"build_compiler_arguments_object_shared": Must be zero or more parameters. + - code:"build_compiler_arguments_object_static": Must be zero or more parameters. + - code:"build_compiler_arguments_program": Must be zero or more parameters. + - code:"build_compiler_arguments_program_shared": Must be zero or more parameters. + - code:"build_compiler_arguments_program_static": Must be zero or more parameters. - code:"build_indexer": Only one bold:"Content", which must only be a valid filename. - code:"build_indexer_arguments": Zero or more arguments supported by the indexer specified in code:"build_indexer". - - code:"build_language": Must only be one of: code:"bash", code:"c", or code:"c++". + - code:"build_language": May be any language but is generally only a known or supported language, such as: code:"c", code:"c++", or code:"go". - code:"build_libraries": Must only contain any number of valid library include arguments that are valid for the compiler defined in "build_compiler" bold:"Object". - code:"build_libraries_shared": Must only contain any number of valid library include arguments that are valid for the compiler defined in "build_compiler" bold:"Object". - code:"build_libraries_static": Must only contain any number of valid library include arguments that are valid for the compiler defined in "build_compiler" bold:"Object". - - code:"build_name": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name": Must only contain characters allowed in a filename (no slashes allowed) (required). + - code:"build_name_library": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_library_shared": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_library_static": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_object": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_object_library": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_object_library_shared": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_object_library_static": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_object_program": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_object_program_shared": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_object_program_static": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_object_shared": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_object_static": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_program": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_program_shared": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_program_static": Must only contain characters allowed in a filename (no slashes allowed). + - code:"build_name_script": Must only contain characters allowed in a filename (no slashes allowed). - code:"build_objects_library": Must only contain any number of valid object file names relative to the appropriate code:"path_object_*" path. - code:"build_objects_library_shared": Must only contain any number of valid object file names relative to the code:"path_object_shared" path. - code:"build_objects_library_static": Must only contain any number of valid object file names relative to the code:"path_object_static" path. @@ -114,6 +142,6 @@ Settings Specification: - code:"version_minor_prefix": Must be zero or more valid filename characters (no slashes allowed). - code:"version_nano": Must only be a single value containing valid filename characters (no slashes allowed). - code:"version_nano_prefix": Must be zero or more valid filename characters (no slashes allowed). - - code:"version_target": Must only be one of: code:"major", code:"minor", code:"micro", or code:"nano". + - code:"version_target": Must only be one of: code:"major", code:"minor", code:"micro", or code:"nano" (no slashes allowed). All bold:"Object" names support having a code:"-" and a code:"mode" name, such as code:"build_libraries-individual" for a mode called code:"individual", except for the code:"modes" and the code:"modes_default" bold:"Object" names. diff --git a/documents/standards/fll/specifications/time.txt b/documents/standards/fll/specifications/time.txt index 625116e..4416dab 100644 --- a/documents/standards/fll/specifications/time.txt +++ b/documents/standards/fll/specifications/time.txt @@ -1,7 +1,7 @@ # fss-0002 iki-0000 # # license open-standard-license-1.0-or-later -# version 2024/11/23 +# version 2025/03/22 # # This file (assumed to be named time.txt) can be more easily read using the following iki_read commands: # iki_read time.txt +Q -r UTC UTC -w -WW character "'" "'" code '"' '"' @@ -56,15 +56,15 @@ Time Specification: code:`time:"12345"`. code:`time:"2022:12345"`. code:`epochtime:"12345"`. - code:`epochtime:"2022:12345"`. + code:`epochtime:"2022::12345"`. The bold:"EKI" could be used to designate the standard unit bold:"time" and bold:"epochtime" along with a more explicit base time like the following\: code:`day:time:"12345"`. code:`day:time:"100:12345"`. code:`year:time:"2022:12345"`. code:`day:epochtime:"12345"`. - code:`day:epochtime:"100:12345"`. - code:`year:epochtime:"2022:12345"`. + code:`day:epochtime:"100::12345"`. + code:`year:epochtime:"2022::12345"`. In the previous examples for bold:"EKI" show code:"day" along with code:"epochtime". For code:`day:epochtime:"100:12345"`, this means that the timestamp starts 100 days after the bold:"UNIX Epoch" year. diff --git a/documents/standards/utf8/documents/about.txt b/documents/standards/utf8/documents/about.txt new file mode 100644 index 0000000..0f4e7ba --- /dev/null +++ b/documents/standards/utf8/documents/about.txt @@ -0,0 +1,35 @@ +# fss-0002 +# +# license cc-by-sa-4.0 +# version 2024/07/02 +# + +About utf8 Documentation: + The utf8 program is intended to provide simple support for identifying UTF-8 character sequences with regard to its Unicode codepoint designation. + Unicode codepoints may also be converted into their binary UTF-8 character sequence equivalents. + + Basic support for identifying and validating is provided. + + This is not intended to be an advanced UTF-8 processing program. + While this is an open option for future development, it is beyond the scope, time, and knowledge of the author (Kevin Day). + + There is basic support for identifying character widths and combining characters. + +Printing a Complete Binary String: + The +q/++quiet must be used to suppress message output (this does not suppress output of processed data). + + The +n/++no_color must be used to suppress printing the color context that is used for invalid sequences. + + The -B/--to_binary must be used to print the binary string. + + The -F/--to_file may optionally be used (and is recommended to be used) to send the output to a file rather than to the screen. + + The -s/--strip_invalid must not be used as the binary string may contain invalid data that must be preserved for proper binary equivalence. + + The -S/--separate must not be used to ensure the data is not separated by multiple lines. + + The -H/--headers must not be used to ensure the processing headers are not printed. + + The -v/--verify must no be used as this suppressed data output. + + The -C/--to_codepoint must not be used as this prints Unicode codepoints rather than the binary string. diff --git a/documents/standards/utf8/documents/output.txt b/documents/standards/utf8/documents/output.txt new file mode 100644 index 0000000..b571122 --- /dev/null +++ b/documents/standards/utf8/documents/output.txt @@ -0,0 +1,24 @@ +# fss-0002 +# +# license cc-by-sa-4.0 +# version 2024/07/02 +# + +Output Documentation: + This program either outputs a binary string representing UTF-8 character sequences or a string representing Unicode codepoints. + + When printing in binary string output, suppressing color, and suppressing any output messages, the output should only be an exact representation of the data. + Ideally, what this means is that the a binary program, such as /bin/bash can be used as input and this programs binary string output (with appropriate additional parameters) should be capable of printing output that is identical to the original input binary. + + In the case of Unicode codepoints, each codepoint is represented with the ASCII character 'U' followed by the ASCII character '+' followed by four to 6 hexidecimal digits. + Unicode number equivalents are not supported nor are ever intended to be supported to ensure simplicity in the design. + This makes the Unicode sequence output scriptable and usable as a data store. + + Any time any processed data fails to properly represent a valid Unicode sequence that sequence is printed exactly as is (when printing codepoints) or is printed as-is (when printing binary strings). + The invalid data is printed with a context, such as the error color context. + The color context may be suppressed by appropriate parameters. + The printing of invalid data may be suppressed by the appropraite parameters. + When printing from a binary string to a Unicode codepoint, invalid data is printed as '0x' followed by the hexidecimal digit representation (all lower case). + + When printing combining or width, the private use area is considered unknown but is not considered an error. + Anything else that is unknown is considered an error. diff --git a/documents/standards/utf8/specifications/output.txt b/documents/standards/utf8/specifications/output.txt new file mode 100644 index 0000000..3db7614 --- /dev/null +++ b/documents/standards/utf8/specifications/output.txt @@ -0,0 +1,50 @@ +# fss-0002 +# +# license open-standard-license-1.0-or-later +# version 2024/07/02 +# + +Output Specification: + The following output to modes are supported\: + - binary: Print the binary character sequences. + - codepoint: Print the Unicode codepoints. + - combining: Print whether or not the character is a combining character. + - width: Print the width of the character. + +Output to Binary: + The output is printed as raw UTF-8 character sequences without any special formatting. + May contain error data representing invalid characters (or codepoints). + Invalid characters (or codepoints) may be designated as an error using a context, such as a color context of "error". + All character codes, valid or not, may be printed as-is. + May not be combined with any other 'Output to' modes. + +Output to Codepoint: + Only upper case ASCII characters 'U', '+', '0' through '9', and 'A' through 'F' are allowed. + Always begins with 'U' and then '+'. + Is always separated by a single space (ASCII character 0x20) (optionally except for the final codepoint in a set which may be terminated by a new line or the end of a file). + May not contain non-ASCII values for designating characters (or codepoints) (which includes not allowing non-ASCII digits). + May not be combined with any other 'Output to' modes. + +Output to Combining: + A single character is used to represent combining, not-combinging, or unknown. + Is always separated by a single space (ASCII character 0x20) (optionally except for the final character in a set which may be terminated by a new line or the end of a file). + The upper case ASCII character 'C' is used to represent a combining character. + The upper case ASCII character 'N' is used to represent a non-combining character. + The ASCII '?' is used to represent either an invalid or an unknown character. + Invalid characters (or codepoints) may be designated as an error using a context, such as a color context of "error". + May not contain non-ASCII values for designating characters (or codepoints) (which includes not allowing non-ASCII digits). + May only be combined with 'Output to Width' mode. + +Output to Width: + A single character is used to represent width or unknown. + Is always separated by a single space (ASCII character 0x20) (optionally except for the final character in a set which may be terminated by a new line or the end of a file). + The ASCII character '0' is used to represent a 0-width character (generally this means a non-graph character). + The ASCII character '1' is used to represent a 1-width character. + The ASCII character '2' is used to represent a 2-width character. + The ASCII '?' is used to represent either an invalid or an unknown character. + Invalid characters (or codepoints) may be designated as an error using a context, such as a color context of "error". + May not contain non-ASCII values for designating characters (or codepoints) (which includes not allowing non-ASCII digits). + May only be combined with 'Output to Combining' mode. + +Output to Combining and Width: + When 'Output to Combining' is used with 'Output to Width', this operates exactly as 'Output to Width', except that when a valid combining character is detected, the ASCII 'C' character is used instead of the width. diff --git a/fll.html b/fll.html index 5974ceb..a2882ed 100644 --- a/fll.html +++ b/fll.html @@ -8,7 +8,7 @@ - + @@ -87,7 +87,10 @@

- The Featureless Linux Library is a collection of standards, specifications, and software for providing a suite of Linux focused functionality. One of the main goal is to play on the word "feature" and provide a featureless library. That is, a library that is not always changing and being rewritten breaking API and ABI to introduce features. How this is achieved and to what extend this is achieved and followed is to be described in the documentation and specifications. + The Featureless Linux Library is a collection of standards, specifications, and software for providing a suite of Linux focused functionality. + One of the main goal is to play on the word "feature" and provide a featureless library. + That is, a library that is not always changing and being rewritten breaking API and ABI to introduce features. + How this is achieved and to what extend this is achieved and followed is to be described in the documentation and specifications.

The projects can be found in five locations. @@ -100,10 +103,13 @@

Kevux GIT Repository

- The source code contains the plain text documentation describing the projects and specifications describing the standards. This website will be updated to present this material. + The source code contains the plain text documentation describing the projects and specifications describing the standards. + This website will be updated to present this material.

- In addition to being a library, the FLL also provides several programs. Some programs, such as Featureless Make (a build system similar to GNU Make), are forever part of the FLL. Other programs, such as the Controller program, will eventually bud off into their own project space. + In addition to being a library, the FLL also provides several programs. + Some programs, such as Featureless Make (a build system similar to GNU Make), are forever part of the FLL. + Other programs, such as the Controller program, will eventually bud off into their own project space.

Many of these files also include checksums to help provide integrity (under Hash) and authenticity (under Sign). @@ -118,16 +124,20 @@

- The current stable release series of FLL is 0.6. The latest version of the stable release series is 0.6.15. + The current stable release series of the FLL project is 0.8. + The latest version of the stable release series is 0.8.0. + Some of the programs that are external to the FLL project might still be on a 0.7 development release.

- There are two different ways in which the project is released. The bare release and the pre-packaged release. + There are two different ways in which the project is released. The bare release and the prepackaged release.

- A bare release is the original project structure exactly as it appears in the Git source code repositories. The project is designed and intended to be hacked. As a result, the project must be converted into a package. There are different default supported package structures like monolithic, level, and individual. + A bare release is the original project structure exactly as it appears in the Git source code repositories. + The project is designed and intended to be hacked. As a result, the project must be converted into a package. + There are different default supported package structures like monolithic, level, and individual.

- A pre-packaged release is the project packaged into a monolithic structure. The programs are also pre-packaged to expect to link against a monolithic FLL package. + A prepackaged release is the project packaged into a monolithic structure. The programs are also prepackaged to expect to link against a monolithic FLL package.

@@ -141,124 +151,54 @@ - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + +

FLL 0.6.15	SHA256	GPG	FLL 0.8.0	SHA256	GPG
Byte Dump 0.6.15	SHA256	GPG	Byte Dump 0.8.0	SHA256	GPG
Control 0.6.15	SHA256	GPG	Fake 0.8.0	SHA256	GPG
Controller 0.6.15	SHA256	GPG	FSS Identify 0.8.0	SHA256	GPG
Fake 0.6.15	SHA256	GPG	FSS Read 0.8.0	SHA256	GPG
Firewall 0.6.15	SHA256	GPG	FSS Write 0.8.0	SHA256	GPG
FSS Basic List Read 0.6.15	SHA256	GPG	IKI Read 0.8.0	SHA256	GPG
FSS Basic List Write 0.6.15	SHA256	GPG	IKI Write 0.8.0	SHA256	GPG
FSS Basic Read 0.6.15	SHA256	GPG	Status Code 0.8.0	SHA256	GPG
FSS Basic Write 0.6.15	SHA256	GPG
FSS Embedded List Read 0.6.15	SHA256	GPG
FSS Embedded List Write 0.6.15	SHA256	GPG
FSS Extended List Read 0.6.15	SHA256	GPG
FSS Extended List Write 0.6.15	SHA256	GPG
FSS Extended Read 0.6.15	SHA256	GPG
FSS Extended Write 0.6.15	SHA256	GPG
FSS Identify 0.6.15	SHA256	GPG
FSS Payload Read 0.6.15	SHA256	GPG
FSS Payload Write 0.6.15	SHA256	GPG
FSS Status Code 0.6.15	SHA256	GPG
IKI Read 0.6.15	SHA256	GPG
IKI Write 0.6.15	SHA256	GPG
Status Code 0.6.15	SHA256	GPG
Utf8 0.6.15	SHA256	GPG	Utf8 0.8.0	SHA256	GPG

@@ -278,105 +218,70 @@ - Byte Dump 0.6.15 (Stand Alone) - SHA256 - GPG + Byte Dump 0.8.0 (Stand Alone) + SHA256 + GPG - Controller 0.6.15 (Stand Alone) - SHA256 - GPG + Fake 0.8.0 (Stand Alone) + SHA256 + GPG - Fake 0.6.15 (Stand Alone) - SHA256 - GPG + FSS Identify 0.8.0 (Stand Alone) + SHA256 + GPG - Firewall 0.6.15 (Stand Alone) - SHA256 - GPG + FSS Read 0.8.0 (Stand Alone) + SHA256 + GPG - FSS Identify 0.6.15 (Stand Alone) - SHA256 - GPG + FSS Write 0.8.0 (Stand Alone) + SHA256 + GPG - FSS Basic Read 0.6.15 (Stand Alone) - SHA256 - GPG + IKI Read 0.8.0 (Stand Alone) + SHA256 + GPG - FSS Basic Write 0.6.15 (Stand Alone) - SHA256 - GPG + IKI Write 0.8.0 (Stand Alone) + SHA256 + GPG - FSS Extended Read 0.6.15 (Stand Alone) - SHA256 - GPG + Status Code 0.8.0 (Stand Alone) + SHA256 + GPG - FSS Extended Write 0.6.15 (Stand Alone) - SHA256 - GPG - - - FSS Payload Read 0.6.15 (Stand Alone) - SHA256 - GPG - - - FSS Payload Write 0.6.15 (Stand Alone) - SHA256 - GPG - - - FSS Status Code 0.6.15 (Stand Alone) - SHA256 - GPG - - - IKI Read 0.6.15 (Stand Alone) - SHA256 - GPG - - - IKI Write 0.6.15 (Stand Alone) - SHA256 - GPG - - - Status Code 0.6.15 (Stand Alone) - SHA256 - GPG - - - Utf8 0.6.15 (Stand Alone) - SHA256 - GPG + Utf8 0.8.0 (Stand Alone) + SHA256 + GPG

- The pre-packaged releases may also be found on the following external websites: + The prepackaged releases may also be found on the following external websites:

FLL: Sourceforge, Monolithic: https://sourceforge.net/projects/fll/files/FLL-0.6/0.6.15/monolithic/
FLL: Sourceforge, Level: https://sourceforge.net/projects/fll/files/FLL-0.6/0.6.15/level/
FLL: Sourceforge, Individual: https://sourceforge.net/projects/fll/files/FLL-0.6/0.6.15/individual/
FLL: Sourceforge, Programs: https://sourceforge.net/projects/fll/files/FLL-0.6/0.6.15/program/
FLL: Sourceforge, Stand Alone: https://sourceforge.net/projects/fll/files/FLL-0.6/0.6.15/stand_alone/
FLL: Sourceforge, Monolithic: https://sourceforge.net/projects/fll/files/FLL-0.8/0.8.0/monolithic/
FLL: Sourceforge, Level: https://sourceforge.net/projects/fll/files/FLL-0.8/0.8.0/level/
FLL: Sourceforge, Individual: https://sourceforge.net/projects/fll/files/FLL-0.8/0.8.0/individual/
FLL: Sourceforge, Programs: https://sourceforge.net/projects/fll/files/FLL-0.8/0.8.0/program/
FLL: Sourceforge, Stand Alone: https://sourceforge.net/projects/fll/files/FLL-0.8/0.8.0/stand_alone/

The bare releases may be found on the following websites:

FLL: GitHub1: https://github.com/thekevinday/fll/releases/tag/0.6.15
FLL: GitLab: https://gitlab.com/kevuxer/fll/-/releases/0.6.15
FLL: Codeberg: https://codeberg.org/kevuxer/fll/releases/tag/0.6.15
FLL: GitHub1: https://github.com/thekevinday/fll/releases/tag/0.8.0
FLL: GitLab: https://gitlab.com/kevuxer/fll/-/releases/0.8.0
FLL: Codeberg: https://codeberg.org/kevuxer/fll/releases/tag/0.8.0

@@ -395,97 +300,33 @@

- The current development release series of FLL is 0.7. The latest version of the development release series is 0.7.3. + The is currently no development release series of the FLL project. + There are projects dependent on the stable release series of the FLL project. + The latest version of these development projects is 0.7.4.

- A bare release is the original project structure exactly as it appears in the Git source code repositories. The project is designed and intended to be hacked. As a result, the project must be converted into a package. There are different default supported package structures like monolithic, level, and individual. + A bare release is the original project structure exactly as it appears in the Git source code repositories. + The project is designed and intended to be hacked. + As a result, the project must be converted into a package. + There are different default supported package structures like monolithic, level, and individual.

- A pre-packaged release is the project packaged into a monolithic structure. The programs are also pre-packaged to expect to link against a monolithic FLL package. + A prepackaged release is the project packaged into a monolithic structure. + The programs are also prepackaged to expect to link against a monolithic FLL package.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

FLL Pre-packaged Source Files
Package	Hash	Sign
FLL 0.7.3	SHA256	GPG
Byte Dump 0.7.3	SHA256	GPG
Example 0.7.3	SHA256	GPG
Fake 0.7.3	SHA256	GPG
Firewall 0.7.3	SHA256	GPG
FSS Identify 0.7.3	SHA256	GPG
FSS Read 0.7.3	SHA256	GPG
FSS Write 0.7.3	SHA256	GPG
IKI Read 0.7.3	SHA256	GPG
IKI Write 0.7.3	SHA256	GPG
Status Code 0.7.3	SHA256	GPG
Utf8 0.7.3	SHA256	GPG

- There are also stand alone sources and related files for some of the programs: + There are also custom stand_alone builds that require copying in the FLL 0.8.0 source code. + These stand_alone builds are usually described and documented using the data/build/stand_alone/fakefile file. + The are often operated using a command like: fake -U build/stand_alone/. + These stand_alone builds are available for both the bare releases and the prepackaged releases.

- - +

+ @@ -495,109 +336,63 @@ - - - + + + - - - + + + - - - + + + - - - - - - - - + + +

Additional Projects Utilizing FLL
Package
Byte Dump 0.7.3 (Stand Alone)	SHA256	GPG	Control 0.8.0	SHA256	GPG
Example 0.7.3 (Stand Alone)	SHA256	GPG	Controller 0.8.0	SHA256	GPG
Fake 0.7.3 (Stand Alone)	SHA256	GPG	(Kevux) Firewall 0.8.0	SHA256	GPG
Firewall 0.7.3 (Stand Alone)	SHA256	GPG
Utf8 0.7.3 (Stand Alone)	SHA256	GPG	(Kevux) Tools 0.8.0	SHA256	GPG

- Additional projects utilizing FLL are also available: -

- - - - - - - - - - - - - - - - - - - - - - - - - - -

Additional Projects Utilizing FLL
Package	Hash	Sign
Control 0.7.3	SHA256	GPG
Controller 0.7.3	SHA256	GPG
Kevux-Tools 0.7.3	SHA256	GPG

- The pre-packaged releases may also be found on the following external websites: -

FLL: Sourceforge, Monolithic: https://sourceforge.net/projects/fll/files/FLL-0.7/0.7.3/monolithic/
FLL: Sourceforge, Level: https://sourceforge.net/projects/fll/files/FLL-0.7/0.7.3/level/
FLL: Sourceforge, Individual: https://sourceforge.net/projects/fll/files/FLL-0.7/0.7.3/individual/
FLL: Sourceforge, Programs: https://sourceforge.net/projects/fll/files/FLL-0.7/0.7.3/program/
FLL: Sourceforge, Stand Alone: https://sourceforge.net/projects/fll/files/FLL-0.7/0.7.3/stand_alone/

- The bare releases may be found on the following websites: + The Control releases may also be found in the following external websites:

FLL: GitHub1: https://github.com/thekevinday/fll/releases/tag/0.7.3
FLL: GitLab: https://gitlab.com/kevuxer/fll/-/releases/0.7.3
FLL: Codeberg: https://codeberg.org/kevuxer/fll/releases/tag/0.7.3
Control: Sourceforge: https://sourceforge.net/projects/fll-control/files/0.7/0.7.4/
Control: GitHub1: https://github.com/thekevinday/control/releases/tag/0.7.4
Control: GitLab: https://gitlab.com/kevuxer/control/-/releases/0.7.4
Control: Codeberg: https://codeberg.org/kevuxer/control/releases/tag/0.7.4

- The Control releases may be found in the following external websites: + The Controller releases may also be found in the following external websites:

Control: Sourceforge: https://sourceforge.net/projects/fll-control/files/0.7/0.7.3/
Control: GitHub1: https://github.com/thekevinday/control/releases/tag/0.7.3
Control: GitLab: https://gitlab.com/kevuxer/control/-/releases/0.7.3
Control: Codeberg: https://codeberg.org/kevuxer/control/releases/tag/0.7.3
Controller: Sourceforge: https://sourceforge.net/projects/fll-controller/files/0.7/0.7.4/
Controller: GitHub1: https://github.com/thekevinday/controller/releases/tag/0.7.4
Controller: GitLab: https://gitlab.com/kevuxer/controller/-/releases/0.7.4
Controller: Codeberg: https://codeberg.org/kevuxer/controller/releases/tag/0.7.4

- The Controller releases may be found in the following external websites: + The (Kevux) Firewall releases may also be found in the following external websites:

Controller: Sourceforge: https://sourceforge.net/projects/fll-controller/files/0.7/0.7.3/
Controller: GitHub1: https://github.com/thekevinday/controller/releases/tag/0.7.3
Controller: GitLab: https://gitlab.com/kevuxer/controller/-/releases/0.7.3
Controller: Codeberg: https://codeberg.org/kevuxer/controller/releases/tag/0.7.3
(Kevux) Tools: Sourceforge: https://sourceforge.net/projects/kevux-firewall/files/0.7/0.7.4/
(Kevux) Tools: GitHub1: https://github.com/thekevinday/kevux-firewall/releases/tag/0.7.4
(Kevux) Tools: GitLab: https://gitlab.com/kevuxer/kevux-firewall/-/releases/0.7.4
(Kevux) Tools: Codeberg: https://codeberg.org/kevuxer/kevux-firewall/releases/tag/0.7.4

- The Kevux-Tools releases may be found in the following external websites: + The (Kevux) Tools releases may also be found in the following external websites:

Kevux-Tools: Sourceforge: https://sourceforge.net/projects/kevux-tools/files/0.7/0.7.3/
Kevux-Tools: GitHub1: https://github.com/thekevinday/kevux-tools/releases/tag/0.7.3
Kevux-Tools: GitLab: https://gitlab.com/kevuxer/kevux-tools/-/releases/0.7.3
Kevux-Tools: Codeberg: https://codeberg.org/kevuxer/kevux-tools/releases/tag/0.7.3
(Kevux) Tools: Sourceforge: https://sourceforge.net/projects/kevux-tools/files/0.7/0.7.4/
(Kevux) Tools: GitHub1: https://github.com/thekevinday/kevux-tools/releases/tag/0.7.4
(Kevux) Tools: GitLab: https://gitlab.com/kevuxer/kevux-tools/-/releases/0.7.4
(Kevux) Tools: Codeberg: https://codeberg.org/kevuxer/kevux-tools/releases/tag/0.7.4

diff --git a/fll/specifications/fss/fss-0000.html b/fll/specifications/fss/fss-0000.html index e6b3ab9..82c384e 100644 --- a/fll/specifications/fss/fss-0000.html +++ b/fll/specifications/fss/fss-0000.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-0001.html b/fll/specifications/fss/fss-0001.html index c829a5a..8561d60 100644 --- a/fll/specifications/fss/fss-0001.html +++ b/fll/specifications/fss/fss-0001.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-0002.html b/fll/specifications/fss/fss-0002.html index 3abf380..dfaf98b 100644 --- a/fll/specifications/fss/fss-0002.html +++ b/fll/specifications/fss/fss-0002.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-0003.html b/fll/specifications/fss/fss-0003.html index ad11347..68a4d9e 100644 --- a/fll/specifications/fss/fss-0003.html +++ b/fll/specifications/fss/fss-0003.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-0004.html b/fll/specifications/fss/fss-0004.html index f4d097e..cb95e45 100644 --- a/fll/specifications/fss/fss-0004.html +++ b/fll/specifications/fss/fss-0004.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-0005.html b/fll/specifications/fss/fss-0005.html index a23c378..2b9eff0 100644 --- a/fll/specifications/fss/fss-0005.html +++ b/fll/specifications/fss/fss-0005.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-0006.html b/fll/specifications/fss/fss-0006.html index d84ccee..cab6603 100644 --- a/fll/specifications/fss/fss-0006.html +++ b/fll/specifications/fss/fss-0006.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-0007.html b/fll/specifications/fss/fss-0007.html index 3b0a5b0..4530c8a 100644 --- a/fll/specifications/fss/fss-0007.html +++ b/fll/specifications/fss/fss-0007.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-0008.html b/fll/specifications/fss/fss-0008.html index 937f44f..8866538 100644 --- a/fll/specifications/fss/fss-0008.html +++ b/fll/specifications/fss/fss-0008.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-0009.html b/fll/specifications/fss/fss-0009.html index 568169a..3dc25f3 100644 --- a/fll/specifications/fss/fss-0009.html +++ b/fll/specifications/fss/fss-0009.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-000a.html b/fll/specifications/fss/fss-000a.html index 2c6d13d..2afc70f 100644 --- a/fll/specifications/fss/fss-000a.html +++ b/fll/specifications/fss/fss-000a.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-000b.html b/fll/specifications/fss/fss-000b.html index 3b10662..f9b7178 100644 --- a/fll/specifications/fss/fss-000b.html +++ b/fll/specifications/fss/fss-000b.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-000c.html b/fll/specifications/fss/fss-000c.html index 8a7a673..13e0819 100644 --- a/fll/specifications/fss/fss-000c.html +++ b/fll/specifications/fss/fss-000c.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-000d.html b/fll/specifications/fss/fss-000d.html index 40a3e66..4b47e2f 100644 --- a/fll/specifications/fss/fss-000d.html +++ b/fll/specifications/fss/fss-000d.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-000e.html b/fll/specifications/fss/fss-000e.html index 3ac921d..dd8e53c 100644 --- a/fll/specifications/fss/fss-000e.html +++ b/fll/specifications/fss/fss-000e.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-000f.html b/fll/specifications/fss/fss-000f.html index 264d07c..ea49fb7 100644 --- a/fll/specifications/fss/fss-000f.html +++ b/fll/specifications/fss/fss-000f.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/fss/fss-0010.html b/fll/specifications/fss/fss-0010.html index 19b15f2..35aee9b 100644 --- a/fll/specifications/fss/fss-0010.html +++ b/fll/specifications/fss/fss-0010.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/iki/iki-0000.html b/fll/specifications/iki/iki-0000.html index d326761..9e47fab 100644 --- a/fll/specifications/iki/iki-0000.html +++ b/fll/specifications/iki/iki-0000.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/iki/iki-0001.html b/fll/specifications/iki/iki-0001.html index 1e75138..7c8e4dd 100644 --- a/fll/specifications/iki/iki-0001.html +++ b/fll/specifications/iki/iki-0001.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/iki/iki-0002.html b/fll/specifications/iki/iki-0002.html index f187129..78a9bf6 100644 --- a/fll/specifications/iki/iki-0002.html +++ b/fll/specifications/iki/iki-0002.html @@ -8,7 +8,7 @@ - + diff --git a/fll/specifications/other/time.html b/fll/specifications/other/time.html index 479b2e8..83a0133 100644 --- a/fll/specifications/other/time.html +++ b/fll/specifications/other/time.html @@ -8,7 +8,7 @@ - + diff --git a/licenses.html b/licenses.html index fe1c6a1..82943a3 100644 --- a/licenses.html +++ b/licenses.html @@ -99,7 +99,7 @@ Everything else on this website that is source code, including HTML markup, CSS, and Javascript, is under LGPLv2.1+ license.

- Â© 2022-2025 Kevin Day + Â© 2022-2026 Kevin Day

2025 / 11 / 22 - FLL 0.6.15 and FLL 0.7.3 Releases

2026 / 01 / 01 - FLL 0.8.0 Release

- The Featureless Linux Library stable version 0.6.15 and development version 0.7.3 are released. -

- The stable version 0.6.15 has a small number of security fixes and a few minor bug fixes. -

- The development version 0.7.3 is the final planned development release for the 0.7.x release series. - The API is considered stable and ready to use for a 0.8.x stable release. - The month of December 2025 will be used for testing and final preparations for an official 0.8.0 stable release in January 2026. -

- The controller project has a new feature where a controlfile (or an initfile for the init program) is supported. - This makes the behavior more similar to a fakefile or similar configuration patterns. -

- The firewall program is being relocated into its own project and therefore repository. - The 0.7.3 is the last Featureless Linux Library release that will contain it. -

- Expect to see a great deal of development in the controller, control, firewall, and the kevux-tools projects for the year 2026. - There will not be 0.8.0 releases of these projects at the same time as the 0.8.0 Featureless Linux Library release in January 2026. - These projects are simply not ready yet for that and a stable Featureless Linux Library release truly needs to be in place before these projects can be properly completed. -

- The development version 0.9.x versions will likely be focused on networking, better error handling (including error recoverability), some standard formats like HTML and JSON, more configuration via environment variables, and more advanced string matching (including regular expressions). -

- Continue readingâ¦ + The Featureless Linux Library stable version 0.8.0 is released.

- -

2025 / 08 / 09 - RP500 Lap Top

- I have decided to make a Lap Top computer. - I've really enjoyed laptops like the Purism laptops and the System76 laptops. - A laptop eventually has some problem, such as a dead battery or a damaged case, and replacements become hard to find. - The Raspberry Pi 500 Keyboard along with the Raspberry Pi Monitor together provide a Lap Top alternative to laptops that can better stand the test of time. -

- The Raspberry Pi 500 Keyboard computer is approximately $100 dollars. - The Raspberry Pi Monitor is approximately $100 dollars. - With the selection of additional parts, this can make for a relatively inexpensive laptop alternative. - Add a decent power source. - Add a USB. - And tada! - I have the basics for a laptop alternative, dubbed a Lap Top (with an emphasis on the space between the two words). -

- This is all well and good but to make it really useful and usable there needs to be additional tweaks and accessories to get the most portability out of this. - The Raspberry Pi 500 Keyboard computer also needs some modifications to make it work correctly. -

- There are also some problems with this project. - The more obvious being the cabling and extra parts. - Not having a good complete case or carrying bag is also another concern. + I'm starting the year off with the 0.8.0 stable release.
+ This release marks a major milestone for the FLL project.
+ Expect to see a lot more development in the programs and software that utilizes this stable release all year long.
+ This release represents approximately three years of off and on programming while simultaneously using the software in its developmental state.

- This article presents my particular approach, design, modifications, success, and failures in the creation and usage of my very own RP 500 Lap Top. -

- Continue readingâ¦ -

2025 / 07 / 04 - FLL 0.6.14 and FLL 0.7.2 Releases

- -

- The Featureless Linux Library stable version 0.6.14 and development version 0.7.2 are released. -

- This is a special 4th of July release to celebrate liberty in open-source. - Open-Source Software and the Internet should be free, open, and unregulated to allow for peace and prosperity. - And the 4th of July is a good symbol of that. + The official release date is intended to be some time after the UTC (time zone 0) reaches January 1, 2026.
+ This is being done explicitly because the project and its source code is available to the whole world and I am trying to make all of my times based on UTC.
+ Following UTC to make released and represent dates and times makes more sense than using some local or regional time zone.

- The stable version 0.6.14 has only a few minor changes. -

- The scripts are updated to a new practice. - The clean up changes are usually not mentioned but this one is notable. - The behavior of using echo with a pipe is replaced with using <<<. - The grep commands have been made more consistent. -

- Continue readingâ¦ -

- -

2025 / 06 / 26 - The LCG AI

- The Lossy Computer Generator (LCG) is a new term that I have created to classify the specific type of Artificial Intelligence (AI) that has currently become popular. -

- The word "Lossy" represents how parts of the original data is lost and reproduction of the original data is not likely to be identical. -

- The words "computer generation" plays on how data, as with Computer Graphics (CG), is generated by the computer. -

- LCG includes the currently popular forms of AI known as Large Language Models (LLMs), Small Language Models (SLMs), and Neural Networks. -

- A Neural Network is a form of AI that has been around as far back as the late 1700s. - Types of Neural Networks used today are: LLMs and SLMs. -

- A LLM is what people are now casually calling AI. - A very simplified description of how an LLM works is that it copies the data into memory and remaps it into a modified form. - Restoring the mapped data requires re-creating the original data at run time, similar to how MP3 works. - This process is therefore lossy. -

- A SLM is a simplified version of an LLM that attempts to use fewer parameters and should require far less power (wattage). + The most significant changes from the previous stable releases, the 0.6.x versions are:

- Continue readingâ¦ -

2025 / 04 / 30 - FLL 0.6.13 and FLL 0.7.1 Releases

- The Featureless Linux Library stable version 0.6.13 and development version 0.7.1 are released. -

- The stable version 0.6.13 has primarily seen improvements in the IKI Read program. - Several program parameters have had their behavior changed due to consistency problems with other programs. -

- The --total parameter now prints the total number of IKI Variables. - The --whole parameter now prints the total number of lines rather than the total number of IKI Variables. - The --whole parameter may now be specified along with the --at parameter. - The --total parameter has had several of its restrictions removed. - The --substitute parameter short syntax is changed to now be -S to make the program more consistent with other programs where the -s is the short syntax for the --select parameter. - The IKI Read program does not have a --select parameter. - The order in which --name, --at, and --line parameters has been clarified.

- The IKI related and Time related specifications have been updated to address concerns and points of confusion. - Additional documentation regarding the backslashes similar to how the FSS backslashes are handled. - The Time specification has incorrect examples that are now fixed. - The language in the Time specification has been changed to better allow for more flexibility in its application. -

- I have found some notable bugs where the f_signal_close, uid_t, and gid_t are assigning the wrong number when representing closed or unused. - These need to be -1 rather than 0. + A complete log of changes can be done by comparing the 0.6.0 tag to the 0.8.0 tag.
+ For example: git log --graph --decorate --pretty=oneline --abbrev-commit --abbrev=12 0.6.0...0.8.0.

- Continue readingâ¦ + Continue readingâ¦

2025 / 01 / 08 - FLL 0.7.0 Release

Year 2025 News

- The Featureless Linux Library development version 0.7.0 is released. -

- This is a development release. - The 0.7 development code has gone too long without a formal release tag. - This development branch has seen development as far back as August 3, 2022 and much of the 0.6 includes a lot of back ported code from 0.7. - This release represents a starting point for many planned changes and updates throughout the year. -

- This development code has some design changes that makes the project a little more versatile and extensible but at a cost of slightly larger code. - Many of the programs now have a more consistent and modular design that allows for housing multiple related projects in the same code base. - Several of the projects have been renamed and simplified into shorter names, such as f_string_range_t now being f_range_t. - A new program called EKI, also known as Extended IKI, that handles the EKI specifications is now available. -

- Not everything is implemented or complete, but this is not strictly required for a development release. - Most of the library, and the related programs, are tested and confirmed to be working. - Projects like Controller and Control are not yet complete. -

- Continue readingâ¦ + The news for the year 2025 remains available.

diff --git a/news/2025.html b/news/2025.html index 3f88dd0..f9d6bb3 100644 --- a/news/2025.html +++ b/news/2025.html @@ -28,6 +28,7 @@ + diff --git a/news/2025/2025_06_26-the_lcg_ai.html b/news/2025/2025_06_26-the_lcg_ai.html index 78a93b5..a3ab67d 100644 --- a/news/2025/2025_06_26-the_lcg_ai.html +++ b/news/2025/2025_06_26-the_lcg_ai.html @@ -8,7 +8,7 @@ - + diff --git a/news/2026.html b/news/2026.html new file mode 100644 index 0000000..e2e399c --- /dev/null +++ b/news/2026.html @@ -0,0 +1,156 @@ + + + + Kevux Systems and Software - News - 2026 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ +

Year 2026 News

+ +

2026 / 01 / 01 - FLL 0.8.0 Release

+ +

+ The Featureless Linux Library stable version 0.8.0 is released. +

+ +

+ I'm starting the year off with the 0.8.0 stable release.
+ This release marks a major milestone for the FLL project.
+ Expect to see a lot more development in the programs and software that utilizes this stable release all year long.
+ This release represents approximately three years of off and on programming while simultaneously using the software in its developmental state. +

+ +

+ The official release date is intended to be some time after the UTC (time zone 0) reaches January 1, 2026.
+ This is being done explicitly because the project and its source code is available to the whole world and I am trying to make all of my times based on UTC.
+ Following UTC to make released and represent dates and times makes more sense than using some local or regional time zone. +

+ +

+ The most significant changes from the previous stable releases, the 0.6.x versions are: +

+ +

Many programs have been merged into a single program using a shared code base.
The programs now follow a new signal threading and interrupt process.
This interrupt process is extended down to all of the different level project to better allow for the use of call backs and interrupt handling.
Several of the different level projects have been flattened down to a lower level.
The memory allocation logic has been changed to utilize more general structures, reducing the need for as many delete and destroy functions.
The console handling code supports additional features for disabling and enabling as well as the ability to more easily mimic common POSIX style parameters.
More functionality is added to better facilitate writing network oriented code.
More functionality is added for process and scheduler interaction.
A new example project is provided to help make learning how to write programs using this project easier.
Unicode 15.0 is now supported.
Experimental support for using ZSH for many of the projects scripts.
Provide new standard structure for programs data, especially with regard to printing.
Many of the programs now follow a new structure design that separates, call backs, caches, and other data via different structures.
Many static strings are now more centrally stored and some are in an array to better allow for different written languages to more easily replace strings where possible.
The FSS and IKI standards and specifications now support the use of back ticks.
The control program has been move out of the FLL project and into its own separate project.
The controller program has been move out of the FLL project and into its own separate project.
The firewall program has been move out of the FLL project and into its own separate project.
This has been tested to compile and run on Android (using something like Termux).
This has been tested to compile and run on the Pinephone (using PostmarketOS).
The Go programming language is now supported in the build settings files.
Introduction of the Open Standard License 1.0 for the standards and the related specifications.
Add fll.c.tags file.
Explicitly define IFS in scripts to prevent misuse.
Add a lot of status codes for various purposes and uses.
Implement new debug printing methods in programs that prints the source code file and line number instead of just a function name.
Switch to using newer initializer style of { .a = b }.
Provide more build settings defaults, such as defaulting build_language to c.
A new level 0 project, f_abstruse.
A new level 0 project, f_compare.
A new level 0 project, f_network.
A new level 0 project, f_parse.
A new level 0 project, f_process.
A new level 0 project, f_random.
A new level 0 project, f_rip.
A new level 0 project, f_schedule.
A new level 0 project, f_time.
A new level 1 project, fl_path (relocated from level 2).
A new level 1 project, fl_status_string (relocated from level 2).

+ +

+ A complete log of changes can be done by comparing the 0.6.0 tag to the 0.8.0 tag.
+ For example: git log --graph --decorate --pretty=oneline --abbrev-commit --abbrev=12 0.6.0...0.8.0. +

+ +

+ Continue readingâ¦ +

+ + diff --git a/news/2026/2026_01_01-fll_0_8_0_release.html b/news/2026/2026_01_01-fll_0_8_0_release.html new file mode 100644 index 0000000..d44bd33 --- /dev/null +++ b/news/2026/2026_01_01-fll_0_8_0_release.html @@ -0,0 +1,212 @@ + + + + News - 2026/01/01 - FLL 0.8.0 Release + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ +

2026 / 01 / 01 - FLL 0.8.0 Release

+ +

+ The Featureless Linux Library stable version 0.8.0 is released. +

+ +

+ The most significant changes from the previous stable releases, the 0.6.x versions are: +

+ +

Many programs have been merged into a single program using a shared code base.
The programs now follow a new signal threading and interrupt process.
This interrupt process is extended down to all of the different level project to better allow for the use of call backs and interrupt handling.
Several of the different level projects have been flattened down to a lower level.
The memory allocation logic has been changed to utilize more general structures, reducing the need for as many delete and destroy functions.
The console handling code supports additional features for disabling and enabling as well as the ability to more easily mimic common POSIX style parameters.
More functionality is added to better facilitate writing network oriented code.
More functionality is added for process and scheduler interaction.
A new example project is provided to help make learning how to write programs using this project easier.
Unicode 15.0 is now supported.
Experimental support for using ZSH for many of the projects scripts.
Provide new standard structure for programs data, especially with regard to printing.
Many of the programs now follow a new structure design that separates, call backs, caches, and other data via different structures.
Many static strings are now more centrally stored and some are in an array to better allow for different written languages to more easily replace strings where possible.
The FSS and IKI standards and specifications now support the use of back ticks.
The control program has been move out of the FLL project and into its own separate project.
The controller program has been move out of the FLL project and into its own separate project.
The firewall program has been move out of the FLL project and into its own separate project.
This has been tested to compile and run on Android (using something like Termux).
This has been tested to compile and run on the Pinephone (using PostmarketOS).
The Go programming language is now supported in the build settings files.
Introduction of the Open Standard License 1.0 for the standards and the related specifications.
Add fll.c.tags file.
Explicitly define IFS in scripts to prevent misuse.
Add a lot of status codes for various purposes and uses.
Implement new debug printing methods in programs that prints the source code file and line number instead of just a function name.
Switch to using newer initializer style of { .a = b }.
Provide more build settings defaults, such as defaulting build_language to c.
A new level 0 project, f_abstruse.
A new level 0 project, f_compare.
A new level 0 project, f_network.
A new level 0 project, f_parse.
A new level 0 project, f_process.
A new level 0 project, f_random.
A new level 0 project, f_rip.
A new level 0 project, f_schedule.
A new level 0 project, f_time.
A new level 1 project, fl_path (relocated from level 2).
A new level 1 project, fl_status_string (relocated from level 2).

+ +

+ A complete log of changes can be done by comparing the 0.6.0 tag to the 0.8.0 tag.
+ For example: git log --graph --decorate --pretty=oneline --abbrev-commit --abbrev=12 0.6.0...0.8.0. +

+ +

Migration from 0.6.x

+ +

+ The migration from the previous 0.6 stable release series to the 0.8 stable release series is straight forward.
+ Just build and install the new releases. +

+ +

+ There may be problems when using older versions of the 0.6 Featureless Make when compiling the new 0.8 stable release.
+ If this happens then just use the bootstrap.sh script to build and install the FLL and the respective programs. +

+ +

Future Plans

+ +

+ The stable 0.8 release sets the foundation that is needed to begin focusing on writing various programs and functionality.
+ There is expected to be a lot of work on existing programs like the controller program.
+ New programs, like furl, are expected to be developed.
+ Stale programs, like firewall, are expected to be updated and refreshed to work with the latest firewall networking functionality.
+ There is expected to be a notable amount of networking related programs and functionality to be written.
+ The networking functionality shall be implemented in individual programs but might eventually get merged into the 0.9 development branch. +

+ +

Kevux Website

+ +

+ Along with this release comes some changes to the Kevux website. +

+ +

+ The Projects and the Documentation pages have been re-organized.
+ Many of the programs are moved out of the Documentation and into the Projects pages.
+ The top-level of the Projects pages now has only simple listing of the programs and their pages. +

+ +

+ There may be future work in the Projects and the Documentation pages, but for now many of the new pages are sparse. +

+ +

+ Kevin Day +

+ + diff --git a/projects.html b/projects.html index b5d1ce4..82267d8 100644 --- a/projects.html +++ b/projects.html @@ -8,7 +8,7 @@ - + @@ -53,75 +53,48 @@

Projects

+ Listing

- Byte Dump +

FLL

+ Byte Dump

- Control + Control

- Controller + Controller

- Featureless Make + Featureless Make

- Firewall + FSS Identify

- FSS Basic List Read + FSS Read

- FSS Basic List Write + FSS Write

- FSS Basic Read + IKI Read

- FSS Basic Write + IKI Write

- FSS Embedded List Read + Status Code

- FSS Embedded List Write + UTF8

- FSS Extended List Read +

Kevux

+ Firewall

- FSS Extended List Write -

- FSS Extended Read -

- FSS Extended Write -

- FSS Identify -

- FSS Payload Read -

- FSS Payload Write -

- FSS Status Code -

- IKI Read -

- IKI Write -

- Status Code -

- UTF8 + Tools

â¦ @@ -136,385 +109,381 @@

Projects

Programs

- The Featureless Linux Library is a major project and has several sub-parts, including several programs. The FLL is broken up into multiple sub-projects that are libraries themselves or programs. This page describes those programs from FLL as well as any other programs and projects associated with Kevux Systems or Kevin Day. -

- Of particular note is that most, if not all, of the Kevux Systems programs are written to provide an API (and its respective ABI). This allows the programs themselves to be used as a library. -

- The programs themselves follow FLL design principles on making the interface human-friendly. Software should be a tool for humans, and not a tool for machines. -

- -

Byte Dump

- This tool is a nifty way to get a UTF-8 friendly hexdump alternative.
- The output is intended to honor some of the feel of hexdump but do so in an FLL way. -

- -

Control

- This project is not complete and development is planned for the FLL 0.7 development series.
-
- The goal of this is to communicate with the "Controller" program, such as starting or stopping services. -

- -

Controller

- This project is not complete and development is planned for the FLL 0.7 development series. -

- The goal of this is to provide task and service management similar to sysvinit, initng, and systemd.
- This is designed to be used for booting the system as if it were /sbin/init. -

- This should be controllable from user-space via the "Control" program. -

- -

Featureless Make

- The Featureless Make is the original program and goal of the FLL.
- The GNU Make, Autoconf, and all those build processes are unnecessarily complex. -

- A major problem with these build systems is that they try to manage installation as well as compilation.
- A build system should be just that a build system.
- Trying to handle how the built package gets installed should be done by system administrators or distributors.
- By avoiding this, the code becomes simpler, more "featureless", easier to maintain, and easier to hack. -

- The Featureless Make, also called Fake, provides two primary ways to compile C, C++, and possibly other compiled languages: -

Using the "build" command.
Using the "make" command.

- The build command is as simple as it can be and follows a Featureless Settings Specification (FSS).
- The make command (and its respective fakefile) provides a more advanced interface for handling complex build processes or compiling languages other than C/C++. -

- The build command (and subsequently the make command) currently provide some hard coded program settings, such as the indexer "ar" runs ar rcs.
- Eventually such things will be expanded into an FSS setting and made customizable. -

- Both the build and make commands support a small subset of make and autoconf functionality to make transitioning easier or make it easy to work alongside make and autoconf. -

- To help with understanding and using the Featureless Make program, fully functional example build settings and fakefiles are created for the program bzip (specifically version 1.0.8): -

- There is also a fakefile pre-configured to run GNU Make within itself to compile the Linux kernel fom source: -

https://sourceforge.net/p/fll/git/ci/development/tree/level_3/fake/data/build/fakefile-example-linux_using_make

- Bzip2 may be found here: -

https://sourceware.org/bzip2/

- -

Firewall

- This is one of the earliest proof of concept and functional example of the FLL library.
- Now it is currently outdated, but it still remains operational as an iptables wrapper.
- This program is actively used on the Turtle Kevux distribution.
- This requires iptables to be installed and executable. -

- -

FSS Identify

- This is a program reading a file and determining what Featureless Settings Specification.
- This only detects files that provide an FSS header. -

- -

FSS Basic Read

- This is a program implementing the Featureless Settings Specification FSS-0000 (Basic).
- This performs read operations related to the FSS-0000 (Basic) standard. -

- -

FSS Basic Write

- This is a program implementing the Featureless Settings Specification FSS-0000 (Basic).
- This performs write operations related to the FSS-0002 (Basic) standard. -

- -

FSS Basic List Read

- This is a program implementing the Featureless Settings Specification FSS-0002 (Basic List).
- This performs read operations related to the FSS-0002 (Basic List) standard. -

- -

FSS Basic List Write

- This is a program implementing the Featureless Settings Specification FSS-0002 (Basic List).
- This performs write operations related to the FSS-0002 (Basic List) standard. -

- -

FSS Embedded List Read

- This is a program implementing the Featureless Settings Specification FSS-0008 (Embedded List).
- This performs read operations related to the FSS-0008 (Embedded List) standard. -

- -

FSS Embedded List Write

- This is a program implementing the Featureless Settings Specification FSS-0008 (Embedded List).
- This performs write operations related to the FSS-0008 (Embedded List) standard. -

- -

FSS Extended Read

- This is a program implementing the Featureless Settings Specification FSS-0001 (Extended).
- This performs read operations related to the FSS-0001 (Extended) standard. -

- -

FSS Extended Write

- This is a program implementing the Featureless Settings Specification FSS-0001 (Extended).
- This performs write operations related to the FSS-0001 (Extended) standard. -

- -

FSS Extended List Read

- This is a program implementing the Featureless Settings Specification FSS-0003 (Extended List).
- This performs read operations related to the FSS-0003 (Extended List) standard. -

- -

FSS Extended List Write

- This is a program implementing the Featureless Settings Specification FSS-0003 (Extended List).
- This performs write operations related to the FSS-0003 (Extended List) standard. -

- -

FSS Payload Read

- This is a program implementing the Featureless Settings Specification FSS-000E (Payload).
- This performs read operations related to the FSS-000E (Payload) standard.
-

- The FSS-000E (Payload) is focused on network communication and is intended to be used inside a network packet.
- This program can be used to manually read a network packet or data from the network. -

- -

FSS Payload Write

- This is a program implementing the Featureless Settings Specification FSS-000E (Payload).
- This performs write operations related to the FSS-000E (Payload) standard.
-

- The FSS-000E (Payload) is focused on network communication and is intended to be used inside a network packet.
- This program can be used to manually write the payload portion of a network packet. -

- -

FSS Status Code

- This program is designed to interpret status codes returned by any FSS program.
- The status codes are converted to or from a code and a label. -

- This program handles more status codes that the status_code program. -

- -

Status Code

- This program is designed to interpret status codes returned by any FLL based program.
- The status codes are converted to or from a code and a label. -

- This program specifically handles only the core status codes provided by the FLL.
- Other programs that utilize custom status codes should provide their own implementation of this program, such as is done with the FSS Status Code program. -

- -

IKI Read

- Similar to the FSS Read programs, this is a program implementing the Featureless Settings Specification iki-0000 (Unrestricted).
- This performs read operations related to the iki-0000 (Unrestricted) standard.
-

- The IKI settings specification plays on how it is simpler than a Wiki syntax.
- The IKI could be used for anything from e-mails and text-messages to word-processors.
- The goal with IKI is to be very easily readably by a human, such as: iki:"example" or url:"https://sourceforge.net/projects/fll/". -

- This program is a swiss army knife for reading files that contain IKI syntax. -

- -

IKI Write

- Similar to the FSS Write programs, this is a program implementing the Featureless Settings Specification iki-0000 (Unrestricted).
- This performs write operations related to the iki-0000 (Unrestricted) standard.
-

- This program is a swiss army knife for writing files that contain IKI syntax. -

- -

UTF8

- A tool to convert one or more UTF-8 characters from the codepoint representation to a binary representation and back. -

- This program can convert complete files into a text file of UTF-8 bytecode values.
- This program can convert complete files into a text file of space separated codepoint values. -

+ The Featureless Linux Library (FLL) is a major project and has several sub-parts, including several programs.
+ The FLL is broken up into multiple sub-projects that are libraries themselves or programs.
+ All of the programs also operate as a library, unless compiled in special ways, such as with stand alone builds. +

+ +

+ This page describes those programs from FLL as well as any other programs and projects associated with Kevux Systems or Kevin Day. +

+ +

+ Of particular note is that most, if not all, of the Kevux Systems programs are written to provide an API (and its respective ABI).
+ This allows the programs themselves to be used as a library. +

+ +

+ The programs themselves follow FLL design principles on making the interface human-friendly and human-first.
+ Software should be a tool for humans, and not a tool for machines. +

+ +

Listing

+ +

+ The following are all of the projects and their respective documentation. +

+ +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Project	Description
Byte Dump	+ + This project provides the Byte Dump program. + + + + The Byte Dump program provides a way to get a UTF-8 friendly `hexdump` alternative. + + + + The output is intended to honor some of the feel of `hexdump`, but in an FLL way. + +
Control	+ + This project provides the Control program. + + + + The Control program provides a to communicate with the `controller` program, such as starting or stopping services. + + + + This project is not complete and development is on going for the FLL `0.8` stable series. + +
Controller	+ + This project provides the Controller and Init programs. + + + + The Controller program provides a way to manage programs, scripts, tasks, and services. + + + + The Init program provides similart functionality to the `sysvinit`, `initng`, and `systemd` programs. + This Init program is designed to be used for booting the system as if it were `/sbin/init`. + + + + Both the Controller and Init programs that are operating as some sort of service should be controllable from via the `control` program. + + + + This project is not complete and development is on going for the FLL `0.8` stable series. + +
Featureless Make	+ + This is the original project and goal of the FLL. + The GNU Make, Autoconf, and all those build processes are unnecessarily complex. + + + + A major problem with these other build systems is that they try to manage installation as well as compilation. + A build system should be just that, a build system. + Trying to handle how the built package gets installed should be done by system administrators or distributors. + By avoiding this, the code becomes simpler, more "featureless", easier to maintain, easier to hack, and easier to keep using over the years. + + + + Projects should only describe what API in which they are compatible with and should not be tied down to any specific project or version. + + + + This project provides the Featureless Make program. + + + + The Featureless Make is the program called `fake`. + This program provides two primary ways to compile C, C++, Go, and possibly other languages: + + + + Using the `build` command. + Using the `make` command. + + + + The `build` command is as simple as it can be and follows a Featureless Settings Specification (FSS). + The `make` command (and its respective `fakefile`) provides a more advanced interface for handling complex build processes or compiling languages other than C/C++. + + + + The `build` command (and subsequently the make command) currently provide some hard coded program settings, such as the indexer `ar` runs `ar rcs`. + Eventually such things will be expanded into an FSS setting and made customizable. + + + + Both the `build` and `make` commands support a small subset of `make` and `autoconf` functionality to make transitioning easier or make it easy to work alongside `make` and `autoconf`. + + + + To help with understanding and using the Featureless Make program, fully functional example build `settings` and `fakefile` are created for the program `bzip` (specifically version `1.0.8`): + + + + https://sourceforge.net/p/fll/git/ci/development/tree/level_3/fake/data/projects/bzip2/1.0.8/fakefile + https://sourceforge.net/p/fll/git/ci/development/tree/level_3/fake/data/projects/bzip2/1.0.8/settings-bzip2 + https://sourceforge.net/p/fll/git/ci/development/tree/level_3/fake/data/projects/bzip2/1.0.8/settings-bzip2recover + + + + There is also a `fakefile` pre-configured to run GNU Make within itself to compile the Linux kernel fom source: + + + + https://sourceforge.net/p/fll/git/ci/development/tree/level_3/fake/data/build/fakefile-example-linux_using_make + + + + The Bzip2 source code may be found here: + + + + https://sourceware.org/bzip2/ + +
FSS Identify	+ + This project provides the FSS Identify program. + + + + The FSS Identify program is designed to read a file and determine what Featureless Settings Specification (FSS) is being used by that file. + + + + The `fss_identify` program only detects files that provide an FSS header. + +
FSS Read	+ + This project provides several FSS Read programs. + + + + The FSS Read programs each suppoert various FSS: + + + + `FSS-0000 (Basic)` + `FSS-0001 (Extended)` + `FSS-0002 (Basic List)` + `FSS-0003 (Extended List)` + `FSS-0008 (Embedded List)` + `FSS-000E (Payload)` + + + + This performs read operations related to the mentioned standards. + +
FSS Write	+ + This project provides several FSS Write programs. + + + + The FSS Write programs each support various FSS: + + + + `FSS-0000 (Basic)` + `FSS-0001 (Extended)` + `FSS-0002 (Basic List)` + `FSS-0003 (Extended List)` + `FSS-0008 (Embedded List)` + `FSS-000E (Payload)` + + + + This performs write operations related to the mentioned standards. + +
IKI Read	+ + This project provides EKI Read and IKI Read programs. + + + + These EKI Read and IKI Read programs support various standards: + + + + `IKI-0000 (Unrestricted)` + `EKI-0000 (Unrestricted)` + + + + This performs read operations related to the mentioned standards. + + + + The IKI and EKI settings specifications are simpler than the common Wiki standards. + These can be used for anything from e-mails and text-messages to word-processors. + The goal with IKI is to be very easily readably by a human, such as: `iki:"example"` or `url:"https://sourceforge.net/projects/fll/"`. + + + + The EKI settings specification, also known as Extended IKI settings specification, is a variation of the IKI format that supports multiple objects. + The goal with EKI is to allow for multiple objects to be associated with one value, such as: `eki:bold:"example"` or `external:url:"https://sourceforge.net/projects/fll/"`. + +
IKI Write	+ This project provides EKI Write and IKI Write programs. + + + + These EKI Write and IKI Write programs support various standards: + + + + `IKI-0000 (Unrestricted)` + `EKI-0000 (Unrestricted)` + + + + This performs write operations related to the mentioned standards. + + + + The IKI and EKI standards are simpler than the common Wiki standards. + These can be used for anything, from text-messages to word-processors. + The goal of these standards is to be very easily readably by a human, such as: `iki:"example"` or `url:"https://sourceforge.net/projects/fll/"`. + + + + The EKI standard, also known as Extended IKI, is a variation of the IKI format that supports multiple objects. + The goal with EKI is to allow for multiple objects to be associated with one value, such as: `eki:bold:"example"` or `external:url:"https://sourceforge.net/projects/fll/"`. + +
(Kevux) Firewall	+ + This project provides the Firewall program. + + + + The Firewall program is one of the earliest proof of concepts and functional examples of the FLL. + Now this program is currently outdated, but it still remains operational as an `iptables` wrapper. + This program is actively used on the Turtle Kevux distribution. + + + This requires `iptables` to be installed and executable. + +
(Kevux) Tools	+ + This project provides a suite of various programs for operating a Kevux distribution, such as the Turtle Kevux distribution. + + + + Some of these tools might replace existing common ones, like the `rm` program. + Other tools are for testing out functionality and design, such as the `tacocat` program. + +
Status Code	+ + This project provides the FSS Status Code and the Status Code programs. + + + + The Status Code program is designed to interpret status codes returned by any FLL based program and specifically handles only core status codes. + The status codes are converted to or from a code and a label. + + + + The FSS Status Code program is designed to interpret status codes returned by any FLL based program alond with the FSS specific status codes. + + + + Other programs that utilize custom status codes should provide their own implementation of this program, such as is done with the `fss_status_code` program. + +
UTF8	+ + This project provides the UTF8 program. + + + + The UTF8 program is a tool to convert one or more UTF-8 characters from the codepoint representation to a binary representation and back. + + + + This program can convert complete files into a text file of UTF-8 bytecode values. + This program can convert complete files into a text file of space separated codepoint values. + +

Short	Long	Description
`-h`	`--help`	Print the help message.
`+C`	`++copyright`	Print the copyright.
`+d`	`++dark`	Output using colors that show up better on dark backgrounds.
`+l`	`++light`	Output using colors that show up better on light backgrounds.
`+n`	`++no_color`	Do not print using color.
`+Q`	`++quiet`	Decrease verbosity, silencing most output.
`+E`	`++error`	Decrease verbosity, using only error output.
`+N`	`++normal`	Set verbosity to normal.
`+V`	`++verbose`	Increase verbosity beyond normal output.
`+D`	`++debug`	Enable debugging, significantly increasing verbosity beyond normal output.
`+v`	`++version`	Print only the version number.

Short	Long	Description
`-c`	`--cgroup`	Specify a custom control group file path, such as `/sys/fs/cgroup/`.
`-d`	`--daemon`	Run in daemon only mode (do not process the entry).
`-I`	`--init`	The program will run as an init replacement.
`-i`	`--interruptible`	Designate that this program can be interrupted by a signal.
`-p`	`--pid`	Specify a custom pid file path, such as `controller/run/default.pid`.
`-s`	`--settings`	Specify a custom settings path, such as `controller/`.
`-S`	`--simulate`	Run as a simulation.
`-k`	`--socket`	Specify a custom socket file path, such as `controller/run/default.socket`.
`-U`	`--uninterruptible`	Designate that this program cannot be interrupted by a signal.
`-v`	`--validate`	Validate the settings (entry and rules) without running (does not simulate).

Short	Long	Description
`-h`	`--help`	Print the help message.
`+C`	`++copyright`	Print the copyright.
`+d`	`++dark`	Output using colors that show up better on dark backgrounds.
`+l`	`++light`	Output using colors that show up better on light backgrounds.
`+n`	`++no_color`	Do not print using color.
`+Q`	`++quiet`	Decrease verbosity, silencing most output.
`+E`	`++error`	Decrease verbosity, using only error output.
`+N`	`++normal`	Set verbosity to normal.
`+V`	`++verbose`	Increase verbosity beyond normal output.
`+D`	`++debug`	Enable debugging, significantly increasing verbosity beyond normal output.
`+v`	`++version`	Print only the version number.

Short	Long	Description
`-a`	`--at`	Select Object at this numeric index.
`-c`	`--content`	Print the Content (default).
`-C`	`--columns`	Print the total number of columns.
`-D`	`--delimit`	Designate how to handle applying delimits.
`-d`	`--depth`	Select Object at this numeric depth.
`-e`	`--empty`	Include empty Content when processing.
`-l`	`--line`	Print only the Content at the given line.
`-n`	`--name`	Select Object with this name.
`-o`	`--object`	Print the Object.
`-p`	`--pipe`	Print using the special pipe format.
`-O`	`--original`	Print with the original quotes and escapes.
`-s`	`--select`	Select sub-Content at this index.
`-t`	`--total`	Print the total number of lines.
`-T`	`--trim`	Trim Object names on select or print.
`-A`	`--as`	Designate the supported format to read as.

Short	Long	Description
`-c`	`--content`	The Content to write.
`-E`	`--content_end`	Write the end of Content characters.
`-N`	`--content_next`	Write the next Content characters (separates multi-Content apart).
`-d`	`--double`	Use double quotes (default).
`-f`	`--file`	Specify a file to send data to.
`-g`	`--grave`	Use graves to quote.
`-I`	`--ignore`	Ignore a given range within a Content.
`-o`	`--object`	The Object to write.
`-O`	`--object_open`	Write the open Object characters.
`-p`	`--partial`	Do not file end of Object/Content character.
`-P`	`--prepend`	Prepend the given white space characters to the start of each multi-line Content.
`-s`	`--single`	Use single quotes.
`-T`	`--trim`	Trim Object names.

Short	Long	Description
`-a`	`--at`	Select variable at this numeric index.
`-n`	`--name`	Select variables with this name.
`-s`	`--select`	Select Vocabulay (aka: Object) at this index.
`-c`	`--content`	Print the variable value (aka: content) (default).
`-l`	`--line`	Print only the variables at the given line within the file.
`-L`	`--literal`	Print the entire variable (aka: object, content, and syntax).
`-o`	`--object`	Print the variable name (aka: object).
`-t`	`--total`	Print the total number of variables.
`-w`	`--whole`	Print all of the data instead of just the IKI variable data.
`-R`	`--reassign`	Re-assign the variable for the given name and matching content value with the given string.
`-r`	`--replace`	Simple substitution, replacing the variable for the given name with the given string.
`-s`	`--substitute`	Substitute the variable for the given name and matching content value with the given string.
`-W`	`--wrap`	Prepend and append strings for the given name.

Short	Long	Description
`-A`	`--accessed`	Remove by file last accessed date and time.
`-b`	`--block`	Remove by file type of block.
`-C`	`--changed`	Remove by file changed on date and time.
`-c`	`--character`	Remove by file type of character.
`-O`	`--different`	Remove by file owner by a user different from the current calling user.
`-d`	`--directory`	Remove by file type of directory.
`-e`	`--empty`	Remove directory by a specific empty or not empty state.
`-o`	`--fifo`	Remove by file type of FIFO.
`-F`	`--follow`	Remove the file being pointed to rather than the symbolic link itself.
`-f`	`--force`	Ignore non-existent files and never prompt.
`-g`	`--group`	Remove by file group ID or name.
`-l`	`--link`	Remove by file type of link.
`-m`	`--mode`	Remove by file mode.
`-p`	`--prompt`	Prompt before removing.
`-r`	`--recurse`	Traverse into directories when removing.
`-R`	`--regular`	Remove by file type of regular.
`-s`	`--same`	Remove by file owner by the current calling user.
`-S`	`--simulate`	Simulate removal rather than actually removing.
`-k`	`--socket`	Remove by file type of socket.
`-Y`	`--stay`	Remove the symbolic link itself rather than the file being pointed to.
`-t`	`--tree`	Remove entire specified directory tree.
`-U`	`--updated`	Remove by file last updated date and time.
`-u`	`--user`	Remove by file user ID or name.
	`--allow_root`	Allow removal of the root directory '/'.
	`--local`	Designate dates are in local time, unless the time zone is specified.
	`--remember`	Remember paths of files already deleted so as to not potentially error out on already removed path.
	`--unknown`	Remove by file type of unknown.
	`--utc`	Designate dates are in UTC, unless the time zone is specified.

Short	Long	Description
`-a`	`--as`	Designate a different name to send the file as.
`-H`	`--headers`	Print the headers on send or on receive.
`-I`	`--interval`	Specify a custom poll interval in milliseconds to use.
`-M`	`--max_buffer`	Specify a maximum buffer size to allow (in bytes) when receiving packets.
`-r`	`--receive`	Specify an address or socket file to listen to and a file to write to.
`-R`	`--resolve`	Specify a custom DNS resolution methodology.
`-s`	`--send`	Specify an address or socket file send transmit to and a file to read from.