Featureless Linux Library

The Featureless Linux Library has a specific design with a specific set of principles. This design and these principles direct and govern how, what, and in what way the projects are built, styled, released, maintained, documented, and evolved.

The FLL project is a collection of different sub-projects, standards, specifications, and programs. Each of these has its own set of rules, guidelines, and principles. All of these are primarily drive by open-source design and principles but the specific way in which this happens is dependent on the specific type of material or data as well as the intended purpose or target audience.

To better understand the core principles and even philosophy behind this FLL project one must first understand some key terminology from the perspective of what the terms do or are for rather than what the direct meaning of the words are.

The term software is understood as thought. That is to say, if you have an idea in your mind then treat this idea as software. This perspective introduces a problem, a problem of ambiguity. Software is more than an idea when it is on a computer. The general definition of software can refer to source code, binaries, or data (data encompasses both source code and binaries but for the purposes here please ignore this fact). A binary is usually created from source code.

The perspective on source code should be described first to address the problem. Source Code is an idea communicated through some language. A single idea may be expressed differently between two distinct languages and still be the same idea. However, the representation of that idea may be limited or otherwise influenced by the constraints or limitation of a language.

When the source code is compiled, interpreted, or otherwise converted into machine code, the idea behind the source code is now represented in a new language, the machine language. This resulting representation in the machine language is the binary.

At this point the software, be it the source code or the binary is synonymous with spoken words. There is no product, only just a spoken and recored idea constrained by the language it is spoken in.

The magic happens when the machine computes. This computation of the communicated idea requires hardware. It is this hardware that manifests the idea into reality. A product, therefore, may only exist in conjunction with some hardware.

The world as it currently exists is a world of restrictions and patents. Supposedly an idea is not patentable. Supposedly math cannot be patented. Yet with software effectively being a written or spoken idea, often represented in mathematical equations, is treated as patentable.

Associating, or otherwise linking, an idea is somehow treated as if the originator of the first spoken idea spoke the second idea. Take a conversation, for example. If the first person says "I like cake." and the second person says "I like candles on cake." then does that mean the first person is the one who originated the statement "I like candles on cake."? Of course not. But the legal system in the United States of America, and perhaps the world, have decided otherwise. That is to say, linking one binary to another (somehow) creates a combined product. This appears to be some sort of magical fairy dust lawyers use to convince people that what you are smelling is actually a rose rather than something bovine herders have to shovel up from time to time.

The core principle of this project is to use legal means to make such an absurdity illegal. Thus the copyrights, such as the LGPLv2.1+ license, are utilized. The goal here is not to deny a person the ability to make a product and sell it. Instead, the goal here is so that a person who makes a product can actually make and sell it. Just because a bird house has nails in it doesn't mean the originator of the nails now owns all rights to the bird house. Just because an AMD motherboard has an Nvidia graphics card connected to it does not mean AMD now owns all rights to the Nvidia graphics card.

The FLL is a set of nails, screws, gears, and clockwork all designed and intended to be taken apart and used in whatever way another person deems necessary. For convenience, this library includes fully functionaly programs as an example on how to use the project. They too can be taken apart.

The FLL project, sub-projects, and related projects are all being built in stages. These stages are not temporal based but are instead goal based. There are temporal constraints to keep development within reason and to provide cut-off points. Each of these goal posts are separated by development and stable releases. A stable release may also be referred to as a production release.

Long term stability is a flag ship goal of this project. To that extent, stable releases are to be maintained indefinitely. Ideally, this will hold true only for 1.0 releases and beyond but in practice pre-1.0 may also seek this goal. For long term stability, API breakage is not allowed with a stable release. For those people out there who blindly apply infinites to everything, stop it. If there is some major security issue or other such extreme problem then API breakage can be considered. This will, however, be strongly resisted to ensure only necessary breakage occurs. Strong resistence is not the same as never allowing.

The term "featureless" is loosely used in this project to describe the idea that a project should not constantly add features like a kid in a candy shop wanting to try every new piece of candy they find. The entire FLL project is designed so that you can do as you will so long as you do not deny another person the same. This means that you are free to add as many features as you like. In your own project. Or in your own hacked variation. This project shall attempt to maintain a discrete set of functionality specific to each stable release and the goals of that release.

Temporal constraints may result in a stable release being made without all of the intended features. These such cases should be treated on a per-situation basis. Changes to a stable release to add features that did not make it is still discouraged and should be avoided. Futhermore, there is an undescribed point in time in which if a stable release has not achieve a planned or intended feature then that feature should never be added. Time matters. For example, if version 1.0 was supposed to bake a cake and failed to get that functionality but then 10-years later (when 3d-printing evolved into 3d-baking) the version 1.0 must not have the "bake a cake" feature added. Too much time has passed. Just make a 1.2 release for baking cakes. The rule of thumb is flexibility for short term and rigidity for long term.

The FLL project has the word "library" in the name. For good reason. The primary purpose of this project is to be used as a library. The original flag ship of this project is the Featureless Make program. Notice the word "program". The FLL project does contain related programs but these are kept to a minimal. The purpose of the programs in this project are to have fully functional and usable example programs. They are not examples in the traditional sense but are instead full blown implementations.

The Featureless Make is also an exception case. I wrote a thesis regarding the GNU make system and I proposed the Featureless Make as a solution that utilizes the Featureless Settings Specification. This is the foundation that birthed the Featureless Linux Library. For this reason, the Featureless Make will always be part of the FLL project.

Many of the programs provided by the FLL are a way of extending the library in such a way that a shell script, such as GNU Bash, can utilize the library. Programs like the FSS Basic Read are examples of this.

Other programs, namely the Controller program are not intended to be directly part of this project in the long term. They exist within this project for development convenience. Eventually they will budd off into their own separate project. These separate projects will still depend on and use the FLL.

The way in which data is stored, utilized, and communicated should also follow similar design and principles. The standards and their accompanying specifications are provided by the FLL to achieve this.

Keep it simple is one of the goals of the project. But again, all of you people out there that love infinitives, stop it. This project follows "keep it simple" rather than "keep it absolutely simple". There are many situations where complexity is not only encouraged but also necessary.

An important aspect of the design and principles of the FLL project is that of communication. All aspects of the project are designed to have both explicit and implicit meaning. From the syntax and styling to the standards and protocols.

The project hosts numerous plain text files following a given FSS format. The IKI format may be used in many of these files to provide further assistance in communicating different aspects of the documentation.

These text files are then process either through scripts or manually and presented in different formats. One such format is on the Kevux website where this document might reside. This results in a bit of redudancy and complexity but achieves the goal of communication.

Idealistically the FLL project will be written in multiple programming languages. This would mean that the ideas represented by this project are communicated through different software languages. Given the complexity of this task, this is not a goal post but is instead an ideal. To that end, the design of the FLL and related projects is done in such a way to be open-ended and better allow for additional languages even if no additional language is ever used.