This guide provides amendments to the original scripts by Paddy Landau, so as to provide the option for using BTRFS as the root file system. These changes have been collated into a modified version. Please note, the modified scripts still depend on the ancillary scripts provided with the original script.
In addition to the tweaks to support BTRFS, this guide also includes some tweaks for issues related to slow boot times and partitioning.
Poverty: A problem of complexity? Poverty is a global problem that affects our civilisation on a large scale. However, what is poverty? This is an important question, since very often the very definition of a problem guides the process of finding solutions and informs the type of the solutions that are considered.
For the problem of poverty, there are many definitions. Very often these definitions tend to focus on income and money.
We have become increasingly aware that we are living in an interconnected and interdependent world. This is generally related back to the field of study of “Complex Systems” and includes terms such as: complex adaptive systems, emergence, chaos, non-equilibrium systems, network effects, and so on.
An interesting formulation that helps to identify, in soft terms, the nature of complex systems is VUCA, that is systems that exhibit the following properties:
In this post we consider the situation of a long running engineering project and see how taking a hypothetical, but explicitly, model driven approach could help to guide the undertaking to completion.
Firstly, what is a “project”?
This may seem like a obvious question, but the definition is important, because all too often in organisations the colloquial understanding is something like:
A project is a catch all for stuff related to that thing that somebody somewhere wants and that is going to need a bunch of people and time.
Monolithic undertakings tend to fail. This may seem like a harsh statement, but there are many ways for systems to fail:
a system could be built that simply doesn’t meet the requirements of the sponsor. a system could logically solve a problem, but exhibits behaviour that is outside of operational tolerance once deployed in a realistic context. a system could simply remain in development indefinitely and never finish. When the “surface area” of the system is large it simply becomes more difficult to avoid all of these failure modes simultaneously.
When taking a model driven approach to software development, one of the problems that arises is that of how to synchronise the model with the reified implementation.
Why is this a problem? Put more bluntly:
How do we know that the final software accurately implements the model.
Providing a bit more context, while software modelling is not new e.g. UML, MDA, EMF and other TLA approaches, we are focusing on using conventional software languages and tools.
Development of large scale distributed systems is complex. Many of our software systems essentially follow this distributed system pattern, and are therefore complex undertakings.
Complexity takes time. It takes time to evolve in nature, and it takes time to introduce in software. Complexity also introduces risk. This risk can generally be sufficiently mitigated with the inclusion of additional complexity so as to reduce the likelihood of systems failures – but then even more time is required.
Resources are limited. This is in many ways one of the defining realisations of our current age. We have limited oil, limited land, limited water etc.
In general system design this is no different. For computationally backed systems we have limited execution cores, limited volatile memory, limited network bandwidth. The realisation for software engineering is that the systems being built can not be built with the mindset of unlimited resource, but rather with the view that resources are bounded.
Systems can be described in terms of their boundaries and the information that passes across those boundaries. But at some point the system needs to perform activities. In the parlance of the ‘actor model’ we might describe the activities as behaviours that are invoked when a message is received.
However, this doesn’t really help one to get a handle on the causal cascade that could be triggered as a result of this message.
One of the challenges when taking a model driven approach to system development is that we naturally create models of varying levels of complexity but then we need to be able to relate one model to another.
That is, not only do we want to be able to evaluate the model against the reified system, but we also want to evaluate models at higher levels of abstraction with those at lower levels of abstraction.