Simple tests.
parent
080a2ee5bb
commit
209cc4686f
|
|
@ -6,8 +6,9 @@
|
|||
<script src="/highlight.pack.js"></script>
|
||||
<script>hljs.initHighlightingOnLoad();</script>
|
||||
|
||||
|
||||
<a href="/">
|
||||
<img src="/baguette.png" alt="Baguette" class="banner" />
|
||||
</a>
|
||||
|
||||
<pre aria-hidden="true"><code>
|
||||
____ _ _
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
+++
|
||||
+++
|
||||
|
||||
[BaguetteOS](/baguette/)
|
||||
[BaguetteOS](/)
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -6,10 +6,18 @@ paginate_by = 5
|
|||
|
||||
Hello! Here a few links to our <red>currently expanding</red> documentation.
|
||||
|
||||
- [BaguetteOS: the French operating system.][baguetteos]
|
||||
- BaguetteOS: the French operating system. [All-in-one-page][allinonebaguetteos]
|
||||
- [Overview][baguette-overview]
|
||||
- [Technical choices][baguette-technical-choices]
|
||||
- [Why slotting matters][baguette-slotting]
|
||||
- [Our tooling][baguette-our-tooling]
|
||||
- [Our projects, beyond the OS.][projects]
|
||||
- [Rant 'bout software.][rant]
|
||||
|
||||
[baguetteos]: /baguette
|
||||
[allinonebaguetteos]: /baguette
|
||||
[baguette-our-tooling]: /baguette/our-tooling
|
||||
[baguette-overview]: /baguette/overview
|
||||
[baguette-slotting]: /baguette/slotting
|
||||
[baguette-technical-choices]: /baguette/technical-choices
|
||||
[projects]: /projects
|
||||
[rant]: /handbook/rant
|
||||
|
|
|
|||
|
|
@ -122,6 +122,7 @@ BaguetteOS does not suffer from cumbersome historical decisions: no overly engin
|
|||
Online documentation and man pages are written in Markdown (thanks to `zola` and [scdoc][scdoc]).
|
||||
Every tool has a man page: no man page = no integration in base.
|
||||
|
||||
<a name="inspiration"></a>
|
||||
## Inspiration
|
||||
|
||||
- [CRUX][crux], [alpine][alpine]: simple-to-understand Linux systems
|
||||
|
|
@ -131,6 +132,7 @@ Every tool has a man page: no man page = no integration in base.
|
|||
- [suckless][suckless] and [cat-v][cat-v]: documentation and tools, all about simplicity, code readability and re-usability
|
||||
- [morpheus][morpheus]: OS based on statically compiled tools
|
||||
|
||||
<a name="why-not-x"></a>
|
||||
## Why not use another system?
|
||||
|
||||
An operating system is mostly a kernel handling the hardware and a bunch of small programs (named `coreutils`) doing basic tasks (copy a file, list the content of a directory, print the date, etc.).
|
||||
|
|
|
|||
|
|
@ -16,7 +16,12 @@ paginate_by = 5
|
|||
<a name="slotting"></a>
|
||||
# Slotting: providing software the right way
|
||||
|
||||
The usual way to provide software is to package it into a distribution, then provide it as *the* OS version of the software.
|
||||
> Packages can support having multiple versions installed simultaneously.
|
||||
> This is useful for libraries which may have changed interfaces between versions.
|
||||
> For example, the python compiler can be installed in both versions 2.7 and 3.5 in parallel.
|
||||
> This feature is called slotting.
|
||||
|
||||
The usual way to provide a software is to package it into a distribution, then provide it as *the* OS version of the software.
|
||||
In the long run, software and libraries change, which is no big deal since maintainers verify the consistency of the different versions provided by the OS.
|
||||
Maintainers' job is to verify that all programs have the right library versions under their OS.
|
||||
|
||||
|
|
|
|||
|
|
@ -38,6 +38,14 @@ title = "Projets"
|
|||
14. dnsmanager
|
||||
|
||||
|
||||
Test to create tables.
|
||||
|
||||
| Tables | Are | Cool |
|
||||
| ------------- |:-------------:| :-----|
|
||||
| col 3 is | right-aligned | $1600 |
|
||||
| col 2 is | centered | $12 |
|
||||
| zebra stripes | are neat | $1 |
|
||||
|
||||
# Nous contacter
|
||||
|
||||
N'hésitez pas à venir discuter avec nous sur [notre outil de communication][mattermost].
|
||||
|
|
|
|||
|
|
@ -7,6 +7,8 @@ title = "Projects"
|
|||
Here is a list of our currently developping projects.
|
||||
This list will grow up following our wildest dreams.
|
||||
|
||||
First, the [specification file format][local-specfileformat] used in a few of our projects.
|
||||
|
||||
1. [service][local-service]: start, stop, configure services<br />
|
||||
2. `packaging`
|
||||
3. `package`
|
||||
|
|
@ -31,12 +33,6 @@ This list will grow up following our wildest dreams.
|
|||
|
||||
|
||||
|
||||
| Tables | Are | Cool |
|
||||
| ------------- |:-------------:| :-----|
|
||||
| col 3 is | right-aligned | $1600 |
|
||||
| col 2 is | centered | $12 |
|
||||
| zebra stripes | are neat | $1 |
|
||||
|
||||
### Not under active development, nor ever started (but still awesome)
|
||||
|
||||
1. firewalld: because your firewall should be a simple service provided seemlessly by your OS
|
||||
|
|
@ -44,6 +40,7 @@ This list will grow up following our wildest dreams.
|
|||
- should replace QML but with a lot of similarities (they got a lot of things right!)
|
||||
|
||||
|
||||
[local-specfileformat]: /projects/specification-file-format/
|
||||
[local-dnsmanager]: /projects/dnsmanager
|
||||
[local-service]: /projects/service
|
||||
[netlibre]: https://netlib.re
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ It can:
|
|||
|
||||
`service` lacks simple scripts for managing databases, has no backup integration and needs more templates.
|
||||
|
||||
## TODO: logging
|
||||
### TODO: logging
|
||||
|
||||
Currently, logging is simply a pair of files created in `/var/log` for each service.
|
||||
|
||||
|
|
@ -30,12 +30,12 @@ The naming convention is:
|
|||
/var/log/$servicename.$environment.{err,log}
|
||||
```
|
||||
|
||||
## TODO: databases
|
||||
### TODO: databases
|
||||
|
||||
Currently, these is only support for `postgresql`.
|
||||
Currently, there is only support for `postgresql`.
|
||||
|
||||
|
||||
## TODO: backup
|
||||
### TODO: backup
|
||||
|
||||
There is currently on back-up system.
|
||||
A simple `backup` tool should be developed, allowing users to provide back-up endpoints.
|
||||
|
|
@ -46,7 +46,7 @@ Here is a quick overview of what we have in mind:
|
|||
# backup add ssh:example.com:/srv/backup
|
||||
```
|
||||
|
||||
## TODO: templates
|
||||
### TODO: templates
|
||||
|
||||
Templates should be added for these services:
|
||||
- php-fpm
|
||||
|
|
|
|||
|
|
@ -62,6 +62,8 @@ software-url: %{url}/my-software-v0.2.tar.gz
|
|||
<a name="examples"></a>
|
||||
# Real-life examples
|
||||
|
||||
The specification file format is used in practice in [packaging][packaging] and [service][service].
|
||||
|
||||
<a name="example-packaging"></a>
|
||||
## In `packaging`
|
||||
|
||||
|
|
@ -181,7 +183,26 @@ the-property: the value
|
|||
a-list: value, value, value
|
||||
```
|
||||
|
||||
`code blocks` allow to insert `shell scripting`, because sometimes we <u>do</u> want to tell instructions and it is not available in YAML or JSON.
|
||||
`code blocks` allow a strict visual separation between variable declaration and `shell scripting`.
|
||||
|
||||
```YAML
|
||||
# Without code blocks
|
||||
# Is any of these a block of code?
|
||||
a: b
|
||||
something: |
|
||||
blah -x
|
||||
blah -a
|
||||
```
|
||||
|
||||
```YAML
|
||||
# With code blocks
|
||||
# Is any of these a block of code?
|
||||
a: b # This one could be
|
||||
@xxx
|
||||
# There, no doubt.
|
||||
blah -x
|
||||
blah -a
|
||||
```
|
||||
|
||||
Finally, `sections` allow a more concise configuration by factoring simple patterns.
|
||||
|
||||
|
|
@ -202,8 +223,6 @@ list-of-directories:
|
|||
|
||||
The `spec` file format can be read line-by-line, which is very simple to implement.
|
||||
|
||||
The specification file format is used in practice in [packaging][packaging] and [service][service].
|
||||
|
||||
[Back to top](#top)
|
||||
|
||||
[service]: https://git.baguette.netlib.re/Baguette/service
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
Subproject commit cb45a6fe0168a947992c0bef24fc7ddbaec7f9f3
|
||||
Subproject commit 898078b75b56906d1c6164738c3bb36ed53073bc
|
||||
Loading…
Reference in New Issue