From 940fc41cd6e6d124d0ad97c2a8615f365cfb0bbb Mon Sep 17 00:00:00 2001 From: Kevin Day Date: Sat, 10 Aug 2024 14:22:25 -0500 Subject: [PATCH] Update: Grammar improvements and other similar types of changes to the design page. --- fll/design.html | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/fll/design.html b/fll/design.html index 81260ad..95c401b 100644 --- a/fll/design.html +++ b/fll/design.html @@ -114,19 +114,19 @@ 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. + At this point the software, be it the source code or the binary is synonymous with spoken words. There is no product, there is only just a spoken and recorded 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 magic happens when the machine computes. This computation of the communicated idea requires hardware. It is this hardware that manifests the idea into reality. Think of this computing as synonymous with reading or listening to some language. 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. + 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, and often being 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. + Associating, or otherwise linking to, an idea is somehow treated as if the originator of the first spoken idea includes 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 when they claim linking creates a combined product 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 core principle of this project is to use legal means to make such an absurdity illegal or unlawful. 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. Linking to another library does not make a combined product despite what the United States of America current claims.

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. @@ -144,16 +144,16 @@ 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. + 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, please do not. If there is some major security issue or other such extreme problem, then API breakage can still be considered. This will, however, be strongly resisted to help ensure only a minimum amount of 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. + 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. Also conside that this is a specifications driven project. When the specification changes and adds features, then the FLL project might be expected to add new features despite the featureless goal and mindset.

- 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. + 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, then 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 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. These full blown implementations also act as an example.

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. @@ -162,13 +162,13 @@ 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. + 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. As of the 0.7.0 versions and later, they have been separated into their own projects. 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. + Keep it simple is one of the goals of the project. This project follows "keep it simple" rather than "keep it absolutely simple". This is often referred to as "Keep It Simple, Stupid", which is not to be confused with "Keep It Stupid Simple". There are many situations where complexity is not only encouraged but also necessary.

@@ -186,10 +186,10 @@ 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. + These text files are then processed either through scripts or manually and are presented in different formats. One such format is on the Kevux website. This results in a bit of redudancy and complexity, but more importantly, this 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. + 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.

-- 1.8.3.1