Compare commits
1 commit
master
...
improvemen
| Author | SHA1 | Date | |
|---|---|---|---|
ef0a9577e2
|
48 changed files with 20 additions and 826 deletions
|
|
@ -10,7 +10,7 @@ steps:
|
|||
commands:
|
||||
- git submodule update --init --recursive
|
||||
- cp -rv garage/doc/book content/documentation
|
||||
- cp -rv garage/doc/api static/api
|
||||
- cp -rv garage/doc/api ./static/
|
||||
|
||||
- name: build-css
|
||||
image: node
|
||||
|
|
|
|||
1
.gitignore
vendored
1
.gitignore
vendored
|
|
@ -2,4 +2,3 @@ node_modules
|
|||
public
|
||||
content/documentation
|
||||
static/style.css
|
||||
static/api
|
||||
|
|
|
|||
0
config.toml
Normal file → Executable file
0
config.toml
Normal file → Executable file
Binary file not shown.
|
|
@ -1,192 +0,0 @@
|
|||
+++
|
||||
title='Thoughts on "Leaderless Consensus"'
|
||||
date=2023-11-30
|
||||
+++
|
||||
|
||||
*Consensus algorithms such as Raft and Paxos, which are used in many distributed databases,
|
||||
have notoriously unpredictable performance in low-quality networks that suffer from
|
||||
latency, jitter, packet loss and/or unavailable nodes, which is why Garage does not use
|
||||
them and uses only CRDTs. A new paper by Antoniadis et al., [*Leaderless Consensus*](https://www.sciencedirect.com/science/article/abs/pii/S0743731523000151),
|
||||
introduces a new category of algorithms that better tolerate the frequent
|
||||
unavailability of a subset of nodes. However, additional research and practical work is required before
|
||||
these results can be put into practice. Read for more details.*
|
||||
|
||||
<!-- more -->
|
||||
|
||||
---
|
||||
|
||||
As I have said many times when presenting Garage, we have made a point of not
|
||||
using any consensus algorithm in Garage and using only CRDTs, for several
|
||||
reasons. The first, and most important reason, is that all of the consensus
|
||||
algorithms that we know of[^1] (in particular Raft, which is very popular in
|
||||
distributed databases) suffer from unpredictable performance when nodes or the
|
||||
network are unreliable. Even in relatively stable conditions, Raft-like
|
||||
algorithms can still be much slower than CRDTs (as we have shown in some
|
||||
[benchmarks](https://garagehq.deuxfleurs.fr/documentation/design/benchmarks/#on-a-complex-simulated-network))
|
||||
because they elect a leader node and require all operations to pass through the
|
||||
leader, which can become a bottleneck. Other than performance issues, Raft is
|
||||
a complex algorithm and implementing it correctly is a challenging software
|
||||
engineering endeavor that we did not wish to undertake, preferring instead
|
||||
simplicity as a foundational principle to help us write correct software.
|
||||
|
||||
However, writing a distributed system such as Garage can be challenging when
|
||||
consensus is not available, as we can only use CRDTs (conflict-free replicated
|
||||
data types) in the code, and we cannot rely on state machine replication. This
|
||||
means that the specific semantics of CRDTs have to be taken into account
|
||||
everywhere in the code, which is often not a problem but sometimes adds some
|
||||
complexity. More importantly, this means that a whole class of features cannot
|
||||
be implemented in Garage, like those that would require some form of locking or
|
||||
exclusive access. In practice, this has been causing us issues on the
|
||||
CreateBucket endpoint, which by definition is meant to exclusively associate a
|
||||
bucket name to a newly created bucket. In current Garage versions, concurrent
|
||||
calls to CreateBucket with the same name may create several buckets and leave
|
||||
Garage in an inconsistent state.
|
||||
|
||||
This leads naturally to the following question: is it possible to implement a
|
||||
consensus algorithm that eschews the shortcomings of Raft-like algorithms in
|
||||
unreliable systems? And in particular, is it possible to implement a consensus
|
||||
algorithm that does not elect a leader, and is therefore not sensitive to
|
||||
temporary slowdowns or unavailabilities of individual nodes? A new paper by
|
||||
Antoniadis et al., [*Leaderless
|
||||
Consensus*](https://www.sciencedirect.com/science/article/abs/pii/S0743731523000151)
|
||||
[[PDF](/blog/2023-11-thoughts-on-leaderless-consensus/2023-Leaderless_consensus_JPDC.pdf)],
|
||||
suggests that the answer is *yes*. However, as with all new research, putting
|
||||
it into practice will take some time and a lot of work. I will discuss in this
|
||||
article practical questions posed by the *Leaderless Consensus* paper, and
|
||||
further steps that could be taken to advance on these issues.
|
||||
|
||||
Please note that the entire content of this article is **purely speculative**
|
||||
and does not include any *positive results*. Note also that we are not
|
||||
discussing Byzantine-tolerant systems, which seem to be the main focus of
|
||||
*Leaderless Consensus*, even though the authors also propose an algorithm for
|
||||
non-Byzantine systems (the one we are interested in).
|
||||
|
||||
## Main takeaways of *Leaderless Consensus*
|
||||
|
||||
To be able to meaningfully say that an algorithm is *leaderless*, one has to first
|
||||
determine what *leaderless* precisely means. The paper starts by offering such
|
||||
a definition, using a network model they call *synchronous-k* ("synchronous minus *k*"),
|
||||
where *n* nodes are running in synchronous steps where at most *k* nodes might be
|
||||
offline, paused, or otherwise unavailable, at each step.
|
||||
The *synchronous-k* model has a variant called *eventually synchronous-k* which seems
|
||||
to better model the behaviour of WAN links on the Internet, although I am not sure
|
||||
of the precise difference between the two. Once the *synchronous-k* network model
|
||||
is defined, a leaderless consensus algorithm is simply defined as a consensus algorithm
|
||||
that still works (i.e. it terminates, giving a decision), in a *synchronous-1* system.
|
||||
Concretely, this means that at any given time, a random node in the network may be
|
||||
disconnected (not always the same one), and the consensus algorithm will be impacted
|
||||
only minimally. In other words, we can say that a leaderless consensus algorithm
|
||||
degrades gracefully in the presence of transient node failures.
|
||||
This "graceful degradation" property, which Raft does not have,
|
||||
seems to be exactly what we are looking for in a potential consensus algorithm that
|
||||
could be added to Garage.
|
||||
|
||||
Having given this definition, the paper continues by offering concrete
|
||||
algorithms to implement leaderless consensus. Of particular interest to us, the
|
||||
paper presents in Section 5 a leaderless consensus algorithm, which they call
|
||||
OFT-Archipelago, which works in message passing systems without Byzantine
|
||||
nodes, where the only faults that can occur are message omissions (like
|
||||
messages being dropped by the network, or temporary node crashes). This is
|
||||
exactly the premise made by Garage, so this algorithm could be a good candidate
|
||||
for us. Interestingly, while leaderless consensus is formally defined as a
|
||||
consensus algorithm that works in a *synchronous-1* system (i.e. tolerating
|
||||
only one failed node at each step), Archipelago works with up to *f < n/2*
|
||||
unavailable nodes at each time steps.
|
||||
|
||||
According to the benchmarks in the leaderless consensus paper, while
|
||||
Archipelago has very good throughput (around 50kops/s), the latency of
|
||||
individual operations is generally between 1 or 2 seconds. This seems to be
|
||||
acceptable for application in Garage if used only for administrative operations
|
||||
on buckets and access keys which are relatively rare. From a theoretical point
|
||||
of view, OFT-Archipelago can terminate in 3 RTT in the optimal scenario,
|
||||
however it is not clear to me whether there is an upper bound on the
|
||||
termination time, or whether there is a probabilistic analysis of the
|
||||
termination delays that could be made. It is also not very clear to me the
|
||||
link between this algorithm and the FLP impossibility theorem: since
|
||||
Archipelago seems to do things that are forbidden by FLP, it means that the
|
||||
premise of a *synchronous-k* system is probably in fact much stronger that the
|
||||
network asynchrony assumed by FLP.
|
||||
|
||||
Among the other advantages of OFT-Archipelago is the fact that the algorithm
|
||||
seems to be very simple, much more than Raft, as it is described in the paper
|
||||
in only 42 lines of very understandable pseudocode. There is also a BFT
|
||||
variant of Archipelago, which is not of interest to us in the context of Garage
|
||||
as we are making the hypothesis that all nodes are trusted.
|
||||
|
||||
## Where to go from now?
|
||||
|
||||
Before an algorithm such as OFT-Archipelago can be added to Garage, a few fundamental
|
||||
questions need to be answered, among which:
|
||||
|
||||
- How should Archipelago interact with Garage's use of CRDT data types? Do we
|
||||
have to create a fully separate subsystem for things that are managed under
|
||||
consensus, or can we hopefully share some logic? More precisely, can we use
|
||||
a consensus algorithm simply as a total order broadcast primitive that
|
||||
becomes a mandatory passing point for all modification requests on a set of
|
||||
metadata tables, with those tables still being based on the CRDT table
|
||||
replication and synchronisation library which is currently in use in Garage?
|
||||
In this situation, nodes that come back from a crash can simply catch up on
|
||||
old changes using the Merkle tree algorithm synchronisation algorithm that we
|
||||
already have. Or must we use the consensus algorithm as the only way to
|
||||
broadcast operations and data for the tables that are managed by it? This
|
||||
would mean that we must add specific logic to handle the case of a node
|
||||
coming back from a crash, where it must either download all the log of
|
||||
operations since it was last up, or an entire snapshot of the metadata tables
|
||||
in question. I think this is mostly related to the reason we want to add
|
||||
consensus, and the exact consistency guarantees we are expecting it to
|
||||
provide to us.
|
||||
|
||||
- Can Archipelago be made correct under cluster reconfiguration scenarios? This
|
||||
is linked to the work done for task 3 of the 2023 NLnet project
|
||||
([#495](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/495),
|
||||
[#667](https://git.deuxfleurs.fr/Deuxfleurs/garage/pulls/667)), which focuses
|
||||
on making the Quorum-based algorithm for CRDT updates reliable even when the
|
||||
cluster layout is updated. I will be writing more about this topic in a
|
||||
future blog post, but in a nutshell, the NLnet task is mainly focused on
|
||||
maintaining read-after-write consistency in Garage at all times, which has
|
||||
led us to develop a relatively general framework for modeling algorithm based
|
||||
on quorums. Since Archipelago also guarantees its correctness using a
|
||||
non-empty-intersection-of-quorums property, it could benefit from the work
|
||||
that was originally made on quorums for the CRDT algorithms.
|
||||
|
||||
If we obtain satisfactory answers to these questions, the remaining work will be
|
||||
the technical implementation of Archipelago in Garage and its validation:
|
||||
|
||||
- Determine more precisely how the pipelined version of Archipelago is made,
|
||||
as its complete description is not given in the leaderless consensus paper,
|
||||
only a few basic pointers (Section 8.1 of the JPDC version).
|
||||
|
||||
- Implement Archipelago in Rust, ideally under the form of a generic reusable crate
|
||||
that could be used outside of the context of Garage.
|
||||
|
||||
- Do a benchmark of Archipelago vs. existing Raft implementations (for instance
|
||||
the async-raft crate). We should benchmark the algorithms in the following
|
||||
scenarios: stable networking, high latency and jitter, evolutive situation
|
||||
with different phases. My hypothesis is that Archipelago could be slower (in
|
||||
terms of latency, not necessarily in throughput) than Raft in the stable
|
||||
networking scenario, but the other two scenarios would force Raft to
|
||||
reconfigure often (i.e. change leaders), which could be the source of huge
|
||||
performance penalties, which Archipelago would not suffer from.
|
||||
|
||||
- Integrate Archipelago with Garage to solve the CreateBucket issue.
|
||||
|
||||
- To validate our implementation, we would want to test it using automated
|
||||
testing frameworks such as Jepsen. I've been using Jepsen for the NLnet task
|
||||
3 and I'm starting to understand quite well how it works, so this could be
|
||||
relatively easy.
|
||||
|
||||
- If we want to go further, there is always the possibility of formalizing a
|
||||
proof of our implementation, however I don't know what are the good tools to
|
||||
do this, and in all cases it would be an extreme amount of work.
|
||||
|
||||
|
||||
Please send your comments and feedback to
|
||||
[garagehq@deuxfleurs.fr](mailto:garagehq@deuxfleurs.fr) if you have any.
|
||||
|
||||
---
|
||||
|
||||
<sup id="1">1</sup>: We are concerned only with consensus algorithms in the
|
||||
context of closed, trusted systems such as distributed databases, and not in
|
||||
large trustless networks such as blockchains.
|
||||
|
||||
Written by [Alex Auvolat](https://adnab.me).
|
||||
|
|
@ -1,281 +0,0 @@
|
|||
+++
|
||||
title="Maintaining read-after-write consistency in all circumstances"
|
||||
date=2023-12-06
|
||||
+++
|
||||
|
||||
*Garage is a data storage system that is based on CRDTs internally. It does not
|
||||
use a consensus algorithm such as Raft, therefore maintaining consistency in a
|
||||
cluster has to be done by other means. Since its inception, Garage has made use
|
||||
of read and write quorums to guarantee read-after-write consistency, the only
|
||||
consistency guarantee it provides. However, as of Garage v0.9.0, this guarantee
|
||||
is not maintained when the composition of a cluster is updated and data is
|
||||
moved between storage nodes. As part of our current NLnet-funded project, we
|
||||
are developing a solution to this problem. This blog post proposes a
|
||||
high-level overview of the proposed solution.*
|
||||
|
||||
<!-- more -->
|
||||
|
||||
---
|
||||
|
||||
Garage provides mainly one consistency guarantee, read-after-write for objects, which can be described as follows:
|
||||
|
||||
**Read-after-write consistency.** *If a client A writes an object x (e.g. using
|
||||
PutObject) and receives a `HTTP 200 OK` response, and later a client B tries to
|
||||
read object x (e.g. using GetObject), then B will read the version written by
|
||||
A, or a more recent version.*
|
||||
|
||||
The consistency guarantee offered by Garage is slightly more general than this
|
||||
simplistic formulation, as it also applies to other S3 endpoints such as
|
||||
ListObjects, which are always guaranteed to reflect the latest version of
|
||||
objects inserted in a bucket. Note that Amazon calls this guarantee [*strong*
|
||||
read-after-write consistency](https://aws.amazon.com/s3/consistency/) (they
|
||||
also have it on AWS), to differentiate it from [another definition of
|
||||
read-after-write
|
||||
consistency](https://avikdas.com/2020/04/13/scalability-concepts-read-after-write-consistency.html)
|
||||
that only applies to data that is read by the same client that wrote it. Since
|
||||
that weaker form is also called
|
||||
[read-your-writes](https://jepsen.io/consistency/models/read-your-writes), I
|
||||
will always be referring to the strong version when using the term
|
||||
"read-after-write consistency".
|
||||
|
||||
In Garage, this consistency guarantee at the level of objects in the S3 API is
|
||||
in fact a reflection of read-after-write consistency in the internal metadata
|
||||
engine (which is a distributed key/value store with CRDT values). Reads and
|
||||
writes to metadata tables use quorums of 2 out of 3 nodes for each operation,
|
||||
ensuring that if operation B starts after operation A has completed, then there
|
||||
is at least one node that is handling both operation A and B. In the case where
|
||||
A is a write (an update) and B is a read, that node will have the opportunity
|
||||
to return the value written in A to the reading client B. A visual depiction
|
||||
of this process can be found in [this
|
||||
presentation](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/commit/a8b0e01f88b947bc34c05d818d51860b4d171967/doc/talks/2023-09-20-ocp/talk.pdf)
|
||||
on slide 32 (pages 57-64), and the algorithm is written down on slide 33 (page
|
||||
54).
|
||||
|
||||
Note that read-after-write guarantees [are broken and have always
|
||||
been](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/147) for metadata
|
||||
related to buckets and access keys, which might not be something we can fix due
|
||||
to different requirements on the quorums for the related metadata tables.
|
||||
|
||||
|
||||
## Current issues with read-after-write consistency
|
||||
|
||||
Maintaining read-after-write consistency depends crucially on the intersection
|
||||
of the quorums being non-empty. There is however a scenario where these quorums
|
||||
may be empty: when the set of nodes affected to storing some entries changes,
|
||||
for instance when nodes are added or removed and data is being rebalanced
|
||||
between nodes.
|
||||
|
||||
### A concrete example
|
||||
|
||||
Take the case of a partition (a subset of the data stored by Garage) which is
|
||||
stored on nodes A, B and C. At some point, a layout change occurs in the
|
||||
cluster, and after the change, nodes A, D and E are responsible for storing the
|
||||
partition. All read and write operations that were initiated before the layout
|
||||
change, or by nodes that were not yet aware of the new layout version, will be
|
||||
directed to nodes A, B and C, and will be handled by a quorum of two nodes among
|
||||
those three. However, once the new layout is introduced in the cluster, read
|
||||
and write operations will start being directed to nodes A, D and E, expecting a
|
||||
quorum of two nodes among this new set of three nodes.
|
||||
|
||||
Crucially, coordinating when operations start being directed to the new layout
|
||||
is a hard problem, and in all cases we must assume that due to some network
|
||||
asynchrony, there can still be some nodes that keep sending requests to nodes
|
||||
A, B and C for a long time even after everyone else is aware of the new layout.
|
||||
Moreover, data will be progressively moved from nodes B and C to nodes D and E,
|
||||
which can take a long time depending on the quantity of data. This creates a
|
||||
period of uncertainty as to where exactly the data is stored in the cluster.
|
||||
Overall, this basically means that this simplistic scheme gives us no way to
|
||||
guarantee the intersection-of-quorums property, which is necessary for
|
||||
read-after-write.
|
||||
|
||||
Concretely, here is a very simple scenario in which read-after-write is broken:
|
||||
|
||||
1. A write operation is directed to nodes A, B and C (the old layout), and
|
||||
receives OK responses from nodes B and C, forming a quorum, so the write
|
||||
completes successfully. The written data then arrives to node A as well.
|
||||
|
||||
2. The new layout version is introduced in the cluster.
|
||||
|
||||
3. Before nodes D and E have had the chance to retrieve the data that was
|
||||
stored on nodes B and C, a read operation for the same key is directed to
|
||||
nodes A, D and E. D and E both return an OK response with no data (a null
|
||||
value), because they is not yet up-to-date. An answer from node A is not
|
||||
received in time. The two responses from nodes D and E, that contain no
|
||||
data, still form a quorum, so the read returns a null value instead of the
|
||||
value that was written before, even though the write operation reported a
|
||||
success.
|
||||
|
||||
|
||||
### Evidencing the issue with Jepsen testing
|
||||
|
||||
The first thing that I had to do for the NLnet project was to develop a testing
|
||||
framework to show that read-after-write consistency issues could in fact arise
|
||||
in Garage when the cluster layout was updated. To make such tests, I chose to
|
||||
use the [Jepsen](https://jepsen.io/) testing framework, which helps us put
|
||||
distributed software in complex adverse scenarios and verify whether they
|
||||
respect some claimed consistency guarantees or not.
|
||||
|
||||
I will not enter into too much detail on the testing procedure, but suffice to
|
||||
say that issues were found. More precisely, I was able to show that Garage
|
||||
*did* guarantee read-after-write in a variety of adverse scenarios such as
|
||||
network partitions, node crashes and clock scrambling, but that it was unable
|
||||
to do so as soon as regular layout updates were introduced.
|
||||
|
||||
The progress of the Jepsen testing work is tracked in [PR
|
||||
#544](https://git.deuxfleurs.fr/Deuxfleurs/garage/pulls/544)
|
||||
|
||||
|
||||
## Fixing read-after-write consistency when layouts change
|
||||
|
||||
To solve this issue, we will have to keep track of several pieces of
|
||||
information in the cluster. We will also have to adapt our read/write quorums
|
||||
and our data transfer strategy during rebalancing to make sure that data can be
|
||||
found when it is requested.
|
||||
|
||||
First of all, we adapted Garage's code to be able to handle *several versions
|
||||
of the cluster layout* that can be live in the cluster at the same time, to
|
||||
keep track of multiple possible locations for data that is currently being
|
||||
transferred between nodes. When multiple cluster layout versions are live,
|
||||
write operations are directed to all of the nodes responsible for storing the
|
||||
data in all the live versions. This ensures that the nodes in the oldest live
|
||||
layout version always have an up-to-date view of the data, and that a read
|
||||
quorum among those nodes is always a safe way to ensure read-after-write
|
||||
consistency.
|
||||
|
||||
Nodes will progressively synchronize data so that the nodes in the newest live
|
||||
layout version will catch up with data stored by nodes in the older live layout
|
||||
version. Once nodes in the newer layout versions also have an up-to-date view
|
||||
of the data, read operations will progressively start using a quorum of nodes
|
||||
in the new layout version instead of the old one.
|
||||
|
||||
Once all nodes are reading from newer layout versions, the oldest live versions
|
||||
can be pruned. This means that writes will stop being directed to those nodes,
|
||||
and the nodes will delete the data they were storing. Obviously, in the (very
|
||||
common) case where some nodes are both in the old and new layout versions,
|
||||
those nodes will not delete their data and they will continue to receive
|
||||
writes.
|
||||
|
||||
### Performance impacts
|
||||
|
||||
When multiple layout versions are live, writes are sent to all nodes
|
||||
responsible for the partition of the requested key in all live layout
|
||||
versions, and will return OK only when they receive a quorum of OK responses
|
||||
for each of the live layout versions. This means that writes could be a bit
|
||||
slower when a layout change is being synchronized in the cluster. Typically if
|
||||
only one node is changing between the old and the new layout version, the write
|
||||
operation will await for 3 responses among 4 requests, instead of the classical
|
||||
2 responses among 3 requests.
|
||||
|
||||
Concerning reads, they are still sent to only three nodes. Indeed, they are
|
||||
sent to the nodes of the newest live layout version for which nodes have
|
||||
completed a sync to catch up on existing data, and they only expect a quorum of
|
||||
2 responses among the three nodes of that layout version. This way, reads
|
||||
always stay as performant as when no layout change is being processed.
|
||||
|
||||
### Ensuring that new nodes are up-to-date
|
||||
|
||||
An additional coordination mechanism is necessary for the data synchronization
|
||||
procedure, to ensure that it is not started too early and that after it
|
||||
completes, the nodes in the new layout indeed contains an up-to-date view of
|
||||
the data.
|
||||
|
||||
Indeed, imagine the following adverse scenario, which we want to avoid: a new
|
||||
layout version is introduced in the cluster, and nodes immediately start
|
||||
copying the data to the new nodes. However, some write operations that were
|
||||
initiated before the new layout was introduced (or that were handled by a node
|
||||
not yet aware of the layout) could be delayed, and the written data was not yet
|
||||
received by the old nodes when they sent their copy of everything. When the
|
||||
sync reports completion, and read operations start being directed to nodes of
|
||||
the new layout, the written data might be missing from the nodes handling the
|
||||
read, and read-after-write consistency could be violated.
|
||||
|
||||
To avoid this situation, the synchronization operation is not initiated until
|
||||
all cluster nodes have reported an "acknowledge" of the new layout version,
|
||||
indicating that they have received the new layout version, and that they are no
|
||||
longer processing write operations that were only addressed to nodes of the
|
||||
previous layout versions. This makes sure that no data will be missed by the
|
||||
sync: once the sync has started, no more data can be written only to old layout
|
||||
versions. All of the writes will also be directed to the new nodes. More
|
||||
exactly: all data that the source nodes of the sync does not yet contain when
|
||||
the sync starts, is written by a write operation that is also directed at a
|
||||
quorum of nodes among the new ones. This means that at the end of the sync, a
|
||||
read quorum among the new nodes will necessarily return an up-to-date copy of
|
||||
all of the data.
|
||||
|
||||
### Details on update trackers
|
||||
|
||||
As you can see, the previous algorithm needs to keep track of a lot of
|
||||
information in the cluster. This information is kept in three "layout update trackers",
|
||||
which keep track of the following information:
|
||||
|
||||
- The `ack` layout tracker keeps track of nodes receiving the latest layout
|
||||
versions and indicating that they are no longer processing writes addressed
|
||||
only to older layout versions. Once all nodes have acknowledged a new
|
||||
version, we know that all in-progress and future write operations that are
|
||||
made in the cluster are directed to the nodes that were added in this layout
|
||||
version as well.
|
||||
|
||||
- The `sync` layout tracker keeps track of nodes finishing a full metadata table
|
||||
sync, that was started after all nodes `ack`'ed the new layout version.
|
||||
|
||||
- The `sync_ack` layout tracker keeps track of nodes receiving the `sync`
|
||||
tracker update for all cluster nodes, and thus starting to direct reads to
|
||||
the newly synchronized layout version. This makes it possible to know when no
|
||||
more nodes are reading from an old version, at which point the corresponding
|
||||
data can be deleted.
|
||||
|
||||
In the simplest scenario, only two layout versions are live, and these trackers
|
||||
therefore can only have the values `n` (the new layout version) and `n-1` (the
|
||||
old one). However this mechanism handles the general case where several
|
||||
successive layout updates are being processed and more than two layout versions
|
||||
are live simultaneously. The layout update trackers can take as values the
|
||||
version numbers of any currently live layout version.
|
||||
|
||||
### What about dead nodes?
|
||||
|
||||
In this post I have used many times the phrases "once all nodes have
|
||||
acknowledged a new layout version", or "once all nodes have completed a sync".
|
||||
This obviously means that if some nodes are dead or unresponsive, the
|
||||
processing of the layout update can be delayed indefinitely, and nodes in the
|
||||
old layout versions will keep receiving writes and storing unnecessary data.
|
||||
This is an unfortunate fact with the method proposed here. To cover for these
|
||||
situations, the following workarounds can be made:
|
||||
|
||||
- A layout change is generally a supervised operation, meaning that a system
|
||||
administrator may manually intervene to inform the cluster that certain nodes
|
||||
are dead and that their layout tracker values should not be taken into
|
||||
account.
|
||||
|
||||
- For the `sync` update tracker, we don't actually need to wait for all of the
|
||||
synchronizations to terminate, quorums can be used instead as they should be
|
||||
sufficient to ensure that the copied data is up-to-date.
|
||||
|
||||
- For the `ack` and `sync_ack` update trackers, we can automatically increase
|
||||
them for all nodes (even dead ones) after a certain time delay, as there is
|
||||
no reason for the changes taking more than e.g. 10 minutes to propagate in
|
||||
regular conditions. We might not enable this behaviour by default, though,
|
||||
due to its possible impacts on consistency.
|
||||
|
||||
|
||||
## Current status and future work
|
||||
|
||||
The work described in this blog post is currently almost complete but it still
|
||||
needs to be ironed out. I have made a first run of Jepsen testing on the new
|
||||
code that showed that the changes seem to be fixing the issue. I will be
|
||||
running longer and more intensive runs of Jepsen testing once the code is
|
||||
finished, to make sure everything is fine. The changes will require a major
|
||||
update of Garage: this will be the v0.10.0 release, which will probably be
|
||||
finished in January or February of 2024. This update will be a very safe and
|
||||
transparent update, as only the layout data structure is changed and nothing
|
||||
related to object storage itself is touched.
|
||||
|
||||
If I had the time to do so, I would write the algorithm described in this post
|
||||
in a formal way, in the form of a scientific paper. I believe such a paper
|
||||
would be worthy of presenting at a scientific conference or journal, especially
|
||||
given the fact that it is motivated by a very concrete use case and has been
|
||||
validated quite thoroughly (with Jepsen). Unfortunately, this is not my
|
||||
highest priority at the moment.
|
||||
|
||||
---
|
||||
|
||||
Written by [Alex Auvolat](https://adnab.me).
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
+++
|
||||
title="PhD offering to work on Garage and Distributed Systems"
|
||||
date=2024-01-10
|
||||
+++
|
||||
|
||||
*Deuxfleurs and IMT Atlantique are partnering to fund a PhD student to work on
|
||||
Garage and distributed systems theory during three years. The recruitment
|
||||
process is open and we are currently looking for candidates. Applications are
|
||||
accepted until Jan 31, 2024. Read for details.*
|
||||
|
||||
<!-- more -->
|
||||
|
||||
---
|
||||
|
||||
|
||||
Deuxfleurs and IMT Atlantique are partnering to fund a PhD student to work on
|
||||
Garage and distributed systems theory, as part of the SEED PhD program, and we
|
||||
are looking for a candidate. This is a French PhD so the program duration is 3
|
||||
years, starting in September 2024, and the student is expected to already have
|
||||
a master's degree or to obtain one before September 2024. The PhD will take
|
||||
place mostly at IMT Atlantique in Nantes (France) within the STACK team, with a
|
||||
three-month stay at Deuxfleurs and a three-month stay abroad (probably in the
|
||||
US). Ideally we are looking for a candidate that already has solid Rust coding
|
||||
skills and a good understanding of distributed systems theory, however both
|
||||
skills can be learnt during the program. Dr. Alex Auvolat from Deuxfleurs will
|
||||
be supervising the student along with Dr. Daniel Balouek from IMT Atlantique.
|
||||
This is a great opportunity to improve your Rust coding skills, learn
|
||||
distributed systems theory, travel to France, meet the great people behind
|
||||
Deuxfleurs and, incidentally, obtain a diploma. Feel free to apply or pass the
|
||||
information to anyone you know who might be interested.
|
||||
|
||||
- Read the [PhD topic proposal](https://www.imt-atlantique.fr/sites/default/files/recherche/doctorat/seed/research-topics/6-consensus-algorithms.html)
|
||||
|
||||
- For more context, also read the following blog posts:
|
||||
|
||||
- [Maintaining read-after-write consistency in all circumstances](@/blog/2023-12-preserving-read-after-write-consistency/index.md)
|
||||
- [Thoughts on "Leaderless Consensus"](@/blog/2023-11-thoughts-on-leaderless-consensus/index.md)
|
||||
|
||||
- [Apply here](https://www.imt-atlantique.fr/en/research-innovation/phd/seed/application)
|
||||
|
||||
- Read about [the SEED PhD program](https://www.imt-atlantique.fr/en/research-innovation/phd/seed)
|
||||
|
||||
- Read about [the STACK team at IMT Atlantique](https://stack-research-group.gitlabpages.inria.fr/web/)
|
||||
|
||||
A webinar will be held on Friday, Jan 10, 2024, at 11:00 CET, to introduce
|
||||
the PhD subject and the context. See details at [this
|
||||
address](https://www.imt-atlantique.fr/en/research-innovation/phd/seed/events#webinars) (we are subject 6-consensus-algorithms).
|
||||
|
||||
The PhD topic is open for applications until Jan 31, 2024.
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
+++
|
||||
title="Open letter to the European Commission"
|
||||
date=2024-07-14
|
||||
+++
|
||||
|
||||
*Deuxfleurs has benefitted multiple times from European grants via the NGI project, for the developpement of Garage and Aerogramme, two pieces of software
|
||||
that we have developped for the needs of our association. Today, these grants are in peril, as the European Commission wishes to finance AI projects instead.
|
||||
We relay and sign an open letter from our friends at petites singularités, that asks that the NGI project be maintained, as it provides great assistance
|
||||
for the development of free software and commons on the Internet.*
|
||||
|
||||
<!-- more -->
|
||||
|
||||
---
|
||||
|
||||
Since 2020, Next Generation Internet (NGI) programmes, part of European
|
||||
Commission's Horizon programme, fund free software in Europe using a cascade
|
||||
funding mechanism (see for example NLnet's calls). This year, according to the
|
||||
Horizon Europe working draft detailing funding programmes for 2025, we notice
|
||||
that Next Generation Internet is not mentioned any more as part of Cluster 4.
|
||||
|
||||
NGI programmes have shown their strength and importance to support the European
|
||||
software infrastructure, as a generic funding instrument to fund digital
|
||||
commons and ensure their long-term sustainability. We find this transformation
|
||||
incomprehensible, moreover when NGI has proven efficient and ecomomical to
|
||||
support free software as a whole, from the smallest to the most established
|
||||
initiatives. This ecosystem diversity backs the strength of European
|
||||
technological innovation, and maintaining the NGI initiative to provide
|
||||
structural support to software projects at the heart of worldwide innovation is
|
||||
key to enforce the sovereignty of a European infrastructure.
|
||||
|
||||
Contrary to common perception, technical innovations often originate from
|
||||
European rather than North American programming communities, and are mostly
|
||||
initiated by small-scaled organizations.
|
||||
|
||||
Previous Cluster 4 allocated 27 millions euros to:
|
||||
|
||||
- "Human centric Internet aligned with values and principles commonly shared in Europe" ;
|
||||
|
||||
- "A flourishing internet, based on common building blocks created within NGI, that enables better control of our digital life" ;
|
||||
|
||||
- "A structured eco-system of talented contributors driving the creation of new internet commons and the evolution of existing internet commons".
|
||||
|
||||
In the name of these challenges, more than 500 projects received NGI funding in
|
||||
the first 5 years, backed by 18 organisations managing these European funding
|
||||
consortia.
|
||||
|
||||
NGI contributes to a vast ecosystem, as most of its budget is allocated to fund
|
||||
third parties by the means of open calls, to structure commons that cover the
|
||||
whole Internet scope - from hardware to application, operating systems, digital
|
||||
identities or data traffic supervision. This third-party funding is not renewed
|
||||
in the current program, leaving many projects short on resources for research
|
||||
and innovation in Europe.
|
||||
|
||||
Moreover, NGI allows exchanges and collaborations across all the Euro zone
|
||||
countries as well as "widening countries"[^1], currently both a success and and an
|
||||
ongoing progress, likewise the Erasmus programme before us. NGI also
|
||||
contributes to opening and supporting longer relationships than strict project
|
||||
funding does. It encourages to implement projects funded as pilots, backing
|
||||
collaboration, identification and reuse of common elements across projects,
|
||||
interoperability in identification systems and beyond, and setting up
|
||||
development models that mix diverse scales and types of European funding
|
||||
schemes.
|
||||
|
||||
While the USA, China or Russia deploy huge public and private resources to
|
||||
develop software and infrastructure that massively capture private consumer
|
||||
data, the EU can't afford this renunciation.
|
||||
|
||||
Free and open source software, as supported by NGI since 2020, is by design the
|
||||
opposite of potential vectors for foreign interference. It lets us keep our
|
||||
data local and favors a community-wide economy and know-how, while allowing an
|
||||
international collaboration. This is all the more essential in the current
|
||||
geopolitical context: the challenge of technological sovereignty is central,
|
||||
and free software allows to address it while acting for peace and sovereignty
|
||||
in the digital world as a whole.
|
||||
|
||||
*The list of all other collectives that have also signed the letter is available
|
||||
at the following address: <https://pad.public.cat/lettre-NCP-NGI>.*
|
||||
|
||||
---
|
||||
|
||||
[^1]: As defined by Horizon Europe, widening Member States are Bulgaria, Croatia, Cyprus, the Czech Republic, Estonia, Greece, Hungary, Latvia, Lituania, Malta, Poland, Portugal, Romania, Slovakia and Slovenia. Widening associated countries (under condition of an association agreement) include Albania, Armenia, Bosnia, Feroe Islands, Georgia, Kosovo, Moldavia, Montenegro, Morocco, North Macedonia, Serbia, Tunisia, Turkey and Ukraine. Widening overseas regions are : Guadeloupe, French Guyana, Martinique, Reunion Island, Mayotte, Saint-Martin, The Azores, Madeira, the Canary Islands.
|
||||
0
content/blog/_index.md
Normal file → Executable file
0
content/blog/_index.md
Normal file → Executable file
2
garage
2
garage
|
|
@ -1 +1 @@
|
|||
Subproject commit 070a8ad110cb75dd2df7ddc9ecbb5c814291ac89
|
||||
Subproject commit b17d59cfabbe92c509f4888cae83f6053a8cab1e
|
||||
0
package-lock.json
generated
Normal file → Executable file
0
package-lock.json
generated
Normal file → Executable file
2
package.json
Normal file → Executable file
2
package.json
Normal file → Executable file
|
|
@ -4,7 +4,7 @@
|
|||
"description": "",
|
||||
"main": "index.js",
|
||||
"scripts": {
|
||||
"start": "npx tailwindcss -i ./src/input.css -o ./public/style.css --minify --watch"
|
||||
"start": "npx tailwindcss -i ./src/input.css -o ./static/style.css --minify --watch"
|
||||
},
|
||||
"keywords": [],
|
||||
"author": "",
|
||||
|
|
|
|||
20
shell.nix
20
shell.nix
|
|
@ -1,20 +0,0 @@
|
|||
with import <nixpkgs> {};
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = "node";
|
||||
buildInputs = [
|
||||
nodejs
|
||||
zola
|
||||
];
|
||||
shellHook = ''
|
||||
export PATH="$PWD/node_modules/.bin/:$PATH"
|
||||
function build {
|
||||
rm -r content/documentation static/api
|
||||
cp -rv garage/doc/book content/documentation
|
||||
cp -rv garage/doc/api static/api
|
||||
npm install
|
||||
npx tailwindcss -i ./src/input.css -o ./static/style.css --minify
|
||||
zola build -u https://garagehq.deuxfleurs.fr
|
||||
}
|
||||
'';
|
||||
}
|
||||
0
src/input.css
Normal file → Executable file
0
src/input.css
Normal file → Executable file
0
static/icons/browserconfig.xml
Normal file → Executable file
0
static/icons/browserconfig.xml
Normal file → Executable file
0
static/icons/cpu.svg
Normal file → Executable file
0
static/icons/cpu.svg
Normal file → Executable file
|
Before Width: | Height: | Size: 4.5 KiB After Width: | Height: | Size: 4.5 KiB |
0
static/icons/disk.svg
Normal file → Executable file
0
static/icons/disk.svg
Normal file → Executable file
|
Before Width: | Height: | Size: 2.7 KiB After Width: | Height: | Size: 2.7 KiB |
0
static/icons/hardware.svg
Normal file → Executable file
0
static/icons/hardware.svg
Normal file → Executable file
|
Before Width: | Height: | Size: 2.8 KiB After Width: | Height: | Size: 2.8 KiB |
0
static/icons/mstile-150x150.png
Normal file → Executable file
0
static/icons/mstile-150x150.png
Normal file → Executable file
|
Before Width: | Height: | Size: 5.7 KiB After Width: | Height: | Size: 5.7 KiB |
0
static/icons/network.svg
Normal file → Executable file
0
static/icons/network.svg
Normal file → Executable file
|
Before Width: | Height: | Size: 3.3 KiB After Width: | Height: | Size: 3.3 KiB |
0
static/icons/ram.svg
Normal file → Executable file
0
static/icons/ram.svg
Normal file → Executable file
|
Before Width: | Height: | Size: 2.5 KiB After Width: | Height: | Size: 2.5 KiB |
6
static/icons/site.webmanifest
Normal file → Executable file
6
static/icons/site.webmanifest
Normal file → Executable file
|
|
@ -1,6 +1,6 @@
|
|||
{
|
||||
"name": "Garage",
|
||||
"short_name": "Garage",
|
||||
"name": "",
|
||||
"short_name": "",
|
||||
"icons": [
|
||||
{
|
||||
"src": "/android-chrome-192x192.png",
|
||||
|
|
@ -15,5 +15,5 @@
|
|||
],
|
||||
"theme_color": "#ffffff",
|
||||
"background_color": "#ffffff",
|
||||
"display": "browser"
|
||||
"display": "standalone"
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,121 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
version="1.1"
|
||||
id="svg2"
|
||||
xml:space="preserve"
|
||||
width="1600.5095"
|
||||
height="502.77777"
|
||||
viewBox="0 0 480.15286 150.83333"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"><metadata
|
||||
id="metadata8"><rdf:RDF><cc:Work
|
||||
rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" /></cc:Work></rdf:RDF></metadata><defs
|
||||
id="defs6"><linearGradient
|
||||
id="linearGradient1220"><stop
|
||||
id="stop1216"
|
||||
offset="0"
|
||||
style="stop-color:#98bf00;stop-opacity:1;" /><stop
|
||||
id="stop1218"
|
||||
offset="1"
|
||||
style="stop-color:#98bf00;stop-opacity:0.51" /></linearGradient><linearGradient
|
||||
x1="0"
|
||||
y1="0"
|
||||
x2="1"
|
||||
y2="0"
|
||||
gradientUnits="userSpaceOnUse"
|
||||
gradientTransform="matrix(-139.45511,-135.52185,-135.52185,139.45511,177.4727,131.75308)"
|
||||
spreadMethod="pad"
|
||||
id="linearGradient28"><stop
|
||||
style="stop-opacity:1;stop-color:#00afbc"
|
||||
offset="0"
|
||||
id="stop24" /><stop
|
||||
style="stop-opacity:1;stop-color:#205374"
|
||||
offset="1"
|
||||
id="stop26" /></linearGradient><clipPath
|
||||
clipPathUnits="userSpaceOnUse"
|
||||
id="clipPath38"><path
|
||||
d="M 0,127.984 H 415.474 V 0 H 0 Z"
|
||||
id="path36" /></clipPath><linearGradient
|
||||
xlink:href="#linearGradient1220"
|
||||
id="linearGradient947"
|
||||
gradientUnits="userSpaceOnUse"
|
||||
x1="14.915152"
|
||||
y1="14.167241"
|
||||
x2="214.11908"
|
||||
y2="111.76186"
|
||||
gradientTransform="matrix(4.4444443,0,0,-4.4444443,-33.008887,535.8)" /><clipPath
|
||||
clipPathUnits="userSpaceOnUse"
|
||||
id="clipPath38-9"><path
|
||||
d="M 0,127.984 H 415.474 V 0 H 0 Z"
|
||||
id="path36-1" /></clipPath></defs><g
|
||||
id="g10"
|
||||
transform="matrix(1.3333333,0,0,-1.3333333,-9.9026662,160.74)"><g
|
||||
id="g40"
|
||||
transform="translate(175.9982,95.8645)" /><g
|
||||
id="g44"
|
||||
transform="translate(152.1193,64.9934)" />
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<g
|
||||
id="NGI0Entrust"><title
|
||||
id="title12661">NGI Zero Entrust</title><path
|
||||
id="path7692"
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:0.999999"
|
||||
d="m 133.10651,96.933602 c -6.67899,0 -12.68988,-1.41201 -18.02988,-4.23501 -5.344,-2.822 -9.51678,-6.73803 -12.52178,-11.74702 -3.004994,-5.008 -4.507906,-10.66967 -4.507906,-16.982669 0,-6.314995 1.502912,-11.974991 4.507906,-16.983985 3.005,-5.008995 7.14794,-8.924024 12.42993,-11.747021 5.282,-2.823998 11.23084,-4.23501 17.84883,-4.23501 4.613,0 9.19693,0.698875 13.75093,2.094873 0.045,0.014 0.0912,0.02819 0.13623,0.04219 7.10399,2.201999 11.88413,8.859686 11.88413,16.29668 v 9.047022 c 0,3.581996 -2.90333,6.485889 -6.48633,6.485889 h -0.50581 c -0.064,0 -0.12704,-0.0077 -0.19204,-0.0097 -0.064,0.002 -0.12704,0.0097 -0.19204,0.0097 h -7.28306 c -3.92899,0 -7.35908,-2.964914 -7.61308,-6.884912 -0.278,-4.295996 3.12428,-7.86709 7.36128,-7.86709 0.776,0 1.34293,-0.753702 1.11093,-1.493702 -0.65799,-2.087998 -2.34102,-3.751009 -4.54702,-4.333008 -2.07399,-0.546999 -4.27598,-0.820898 -6.60498,-0.820898 -4.00699,0 -7.57381,0.864972 -10.6998,2.594971 -3.127,1.729999 -5.5704,4.143993 -7.3314,7.23999 -1.761,3.095997 -2.64067,6.617018 -2.64067,10.564014 0,4.005996 0.87967,7.557666 2.64067,10.653656 1.761,3.097 4.2191,5.49317 7.3771,7.19517 3.156,1.698 6.76804,2.54883 10.83604,2.54883 4.68099,0 8.8649,-1.26899 12.5499,-3.80699 2.341,-1.61199 5.52423,-1.58761 7.75723,0.17139 3.47999,2.741 3.2889,8.04495 -0.31509,10.45196 -1.7,1.13599 -3.53807,2.11163 -5.51206,2.92763 -4.553,1.881 -9.62316,2.82305 -15.20816,2.82305 z m -93.706345,-1.09248 c -4.022996,0 -7.284815,-3.26081 -7.284815,-7.28482 v -49.17612 c 0,-4.022993 3.261819,-7.284815 7.284815,-7.284815 4.023996,0 7.284814,3.261822 7.284814,7.284815 V 62.34029 c 0,2.842996 3.564362,4.118722 5.36836,1.921728 L 76.282148,34.757135 c 1.383999,-1.685 3.450155,-2.661768 5.631153,-2.661768 h 1.380761 c 4.023997,0 7.286133,3.261822 7.286133,7.284815 v 49.17612 c 0,4.02401 -3.262136,7.28482 -7.286133,7.28482 -4.023995,0 -7.284815,-3.26081 -7.284815,-7.28482 V 65.615095 c 0,-2.844997 -3.568118,-4.119773 -5.370117,-1.917774 L 46.503925,93.172322 c -1.382997,1.69 -3.45199,2.6688 -5.635987,2.6688 z m 136.597415,-4.4e-4 c -4.074,0 -7.37578,-3.30178 -7.37578,-7.37578 V 39.472027 c 0,-4.073996 3.30178,-7.37622 7.37578,-7.37622 4.074,0 7.37622,3.302224 7.37622,7.37622 v 48.992875 c 0,4.074 -3.30222,7.37578 -7.37622,7.37578 z" /><path
|
||||
id="path30"
|
||||
style="fill:url(#linearGradient947);fill-opacity:1;stroke:none;stroke-width:4.44444"
|
||||
d="M 79.115234 30 C 52.097457 30 30 52.101902 30 79.115234 L 30 423.66211 C 30 450.67989 52.097457 472.77734 79.115234 472.77734 L 812.60352 472.77734 C 839.61685 472.77734 861.7207 450.67544 861.7207 423.66211 L 861.7207 342.50586 C 861.7207 333.51919 865.28844 324.89711 871.64844 318.53711 L 912.07617 278.11133 C 923.36506 266.82688 923.33313 248.52428 912.01758 237.27539 L 871.7207 197.19922 C 865.3207 190.83922 861.7207 182.18238 861.7207 173.16016 L 861.7207 79.115234 C 861.7207 52.101902 839.61685 30 812.60352 30 L 79.115234 30 z M 558.57812 104.87891 C 583.40035 104.87891 605.93437 109.06578 626.16992 117.42578 C 634.94325 121.05245 643.11241 125.38861 650.66797 130.4375 C 666.68575 141.13528 667.53503 164.7084 652.06836 176.89062 C 642.14392 184.7084 627.99624 184.81679 617.5918 177.65234 C 601.21402 166.37234 582.6189 160.73242 561.81445 160.73242 C 543.73445 160.73242 527.68096 164.51388 513.6543 172.06055 C 499.61874 179.62499 488.69385 190.27462 480.86719 204.03906 C 473.04052 217.79906 469.13086 233.58423 469.13086 251.38867 C 469.13086 268.93089 473.04052 284.57984 480.86719 298.33984 C 488.69385 312.09984 499.55339 322.82869 513.45117 330.51758 C 527.3445 338.20647 543.19697 342.05078 561.00586 342.05078 C 571.35697 342.05078 581.14355 340.83345 590.36133 338.40234 C 600.16577 335.81568 607.64587 328.42453 610.57031 319.14453 C 611.60142 315.85564 609.0817 312.50586 605.63281 312.50586 C 586.8017 312.50586 571.68046 296.63435 572.91602 277.54102 C 574.0449 260.11879 589.28973 246.94141 606.75195 246.94141 L 639.12109 246.94141 C 639.40998 246.94141 639.69016 246.97549 639.97461 246.98438 C 640.2635 246.97549 640.54368 246.94141 640.82812 246.94141 L 643.07617 246.94141 C 659.00062 246.94141 671.9043 259.84758 671.9043 275.76758 L 671.9043 315.97656 C 671.9043 349.0299 650.65927 378.61958 619.08594 388.40625 C 618.88594 388.46847 618.68047 388.53153 618.48047 388.59375 C 598.24047 394.79819 577.86746 397.9043 557.36523 397.9043 C 527.9519 397.9043 501.51266 391.63314 478.03711 379.08203 C 454.56155 366.53536 436.14852 349.13527 422.79297 326.87305 C 409.43741 304.61083 402.75781 279.45534 402.75781 251.38867 C 402.75781 223.33089 409.43741 198.16793 422.79297 175.91016 C 436.14852 153.64793 454.6942 136.24339 478.44531 123.70117 C 502.17865 111.15451 528.89368 104.87891 558.57812 104.87891 z M 142.10547 109.73438 L 148.62891 109.73438 C 158.33557 109.73438 167.53107 114.08459 173.67773 121.5957 L 280.94531 252.5957 C 288.9542 262.38237 304.8125 256.71671 304.8125 244.07227 L 304.8125 142.11133 C 304.8125 124.22688 319.30501 109.73438 337.18945 109.73438 C 355.0739 109.73438 369.57227 124.22688 369.57227 142.11133 L 369.57227 360.67188 C 369.57227 378.55187 355.0739 393.04883 337.18945 393.04883 L 331.05273 393.04883 C 321.3594 393.04883 312.1765 388.70764 306.02539 381.21875 L 198.3418 250.08594 C 190.32402 240.32149 174.48242 245.9914 174.48242 258.62695 L 174.48242 360.67188 C 174.48242 378.55187 159.98991 393.04883 142.10547 393.04883 C 124.22547 393.04883 109.72852 378.55187 109.72852 360.67188 L 109.72852 142.11133 C 109.72852 124.22688 124.22547 109.73438 142.10547 109.73438 z M 749.20508 109.73633 C 767.31174 109.73633 781.98828 124.41091 781.98828 142.51758 L 781.98828 360.26367 C 781.98828 378.37034 767.31174 393.04688 749.20508 393.04688 C 731.09841 393.04688 716.42383 378.37034 716.42383 360.26367 L 716.42383 142.51758 C 716.42383 124.41091 731.09841 109.73633 749.20508 109.73633 z "
|
||||
transform="matrix(0.22500001,0,0,-0.22500001,7.4269998,120.555)" /><g
|
||||
aria-label="Z E R O"
|
||||
transform="scale(1,-1)"
|
||||
id="text56"
|
||||
style="font-weight:600;font-size:31.76px;font-family:'Montserrat SemiBold';-inkscape-font-specification:Montserrat-SemiBold;fill:#6f9aa8"><path
|
||||
d="m 261.75384,-85.665085 -13.08512,15.97528 h 13.498 v 3.4936 H 243.206 v -2.76312 l 13.08512,-15.97528 h -12.8628 v -3.4936 h 18.32552 z"
|
||||
id="path12603" /><path
|
||||
d="m 278.84063,-75.787725 v 6.12968 h 12.5452 v 3.46184 h -16.674 v -22.232 h 16.22936 v 3.46184 h -12.10056 v 5.78032 h 10.73488 v 3.39832 z"
|
||||
id="path12605" /><path
|
||||
d="m 323.74919,-66.196205 h -4.4464 l -4.54168,-6.5108 q -0.28584,0.03176 -0.85752,0.03176 h -5.01808 v 6.47904 h -4.1288 v -22.232 h 9.14688 q 2.89016,0 5.01808,0.9528 2.15968,0.9528 3.30304,2.73136 1.14336,1.77856 1.14336,4.22408 0,2.50904 -1.23864,4.31936 -1.20688,1.81032 -3.4936,2.6996 z m -4.54168,-14.32376 q 0,-2.12792 -1.39744,-3.27128 -1.39744,-1.14336 -4.09704,-1.14336 h -4.82752 v 8.86104 h 4.82752 q 2.6996,0 4.09704,-1.14336 1.39744,-1.17512 1.39744,-3.30304 z"
|
||||
id="path12607" /><path
|
||||
d="m 347.12448,-65.878605 q -3.39832,0 -6.12968,-1.46096 -2.73136,-1.49272 -4.2876,-4.09704 -1.55624,-2.63608 -1.55624,-5.8756 0,-3.23952 1.55624,-5.84384 1.55624,-2.63608 4.2876,-4.09704 2.73136,-1.49272 6.12968,-1.49272 3.39832,0 6.12968,1.49272 2.73136,1.46096 4.2876,4.06528 1.55624,2.60432 1.55624,5.8756 0,3.27128 -1.55624,5.8756 -1.55624,2.60432 -4.2876,4.09704 -2.73136,1.46096 -6.12968,1.46096 z m 0,-3.62064 q 2.2232,0 4.00176,-0.98456 1.77856,-1.01632 2.79488,-2.79488 1.01632,-1.81032 1.01632,-4.03352 0,-2.2232 -1.01632,-4.00176 -1.01632,-1.81032 -2.79488,-2.79488 -1.77856,-1.01632 -4.00176,-1.01632 -2.2232,0 -4.00176,1.01632 -1.77856,0.98456 -2.79488,2.79488 -1.01632,1.77856 -1.01632,4.00176 0,2.2232 1.01632,4.03352 1.01632,1.77856 2.79488,2.79488 1.77856,0.98456 4.00176,0.98456 z"
|
||||
id="path12609" /></g><g
|
||||
aria-label="ENTRUST"
|
||||
transform="scale(0.99994801,-1.000052)"
|
||||
id="Entrust"
|
||||
style="font-weight:bold;font-size:20.009px;font-family:'Montserrat SemiBold';-inkscape-font-specification:'Montserrat SemiBold, Bold';letter-spacing:3.55932px;fill:#6f9aa8;stroke-width:0.999947"><path
|
||||
d="m 245.81989,-41.935548 v 3.861737 h 7.90356 v 2.180981 h -10.50473 v -14.0063 h 10.2246 v 2.180981 h -7.62343 v 3.641638 h 6.76304 v 2.140963 z"
|
||||
id="path12612" /><path
|
||||
d="m 270.04847,-40.414864 v -9.484266 h 2.58116 v 14.0063 h -2.14096 l -7.72347,-9.484266 v 9.484266 h -2.58117 v -14.0063 h 2.14097 z"
|
||||
id="path12614" /><path
|
||||
d="m 285.39308,-35.89283 h -2.60117 v -11.80531 h -4.64209 v -2.20099 h 11.88535 v 2.20099 h -4.64209 z"
|
||||
id="path12616" /><path
|
||||
d="m 307.52074,-35.89283 h -2.80126 l -2.86129,-4.101845 q -0.18008,0.02001 -0.54024,0.02001 h -3.16142 v 4.081836 h -2.60117 v -14.0063 h 5.76259 q 1.82082,0 3.16142,0.60027 1.36061,0.60027 2.08094,1.720774 0.72032,1.120504 0.72032,2.661197 0,1.580711 -0.78035,2.721224 -0.76034,1.140513 -2.20099,1.700765 z m -2.86129,-9.024059 q 0,-1.340603 -0.88039,-2.060927 -0.8804,-0.720324 -2.58116,-0.720324 h -3.04137 v 5.582511 h 3.04137 q 1.70076,0 2.58116,-0.720324 0.88039,-0.740333 0.88039,-2.080936 z"
|
||||
id="path12618" /><path
|
||||
d="m 319.76395,-35.69274 q -2.90131,0 -4.52204,-1.620729 -1.62073,-1.640738 -1.62073,-4.682106 v -7.903555 h 2.60117 v 7.80351 q 0,4.121854 3.5616,4.121854 3.5416,0 3.5416,-4.121854 v -7.80351 h 2.56115 v 7.903555 q 0,3.041368 -1.62073,4.682106 -1.60072,1.620729 -4.50202,1.620729 z"
|
||||
id="path12620" /><path
|
||||
d="m 337.4296,-35.69274 q -1.62073,0 -3.14141,-0.460207 -1.50068,-0.460207 -2.38107,-1.220549 l 0.9004,-2.020909 q 0.86039,0.680306 2.10095,1.120504 1.26056,0.420189 2.52113,0.420189 1.5607,0 2.32105,-0.500225 0.78035,-0.500225 0.78035,-1.320594 0,-0.60027 -0.4402,-0.980441 -0.42019,-0.40018 -1.08049,-0.620279 -0.66029,-0.220099 -1.80081,-0.500225 -1.60072,-0.380171 -2.60117,-0.760342 -0.98044,-0.380171 -1.70076,-1.180531 -0.70032,-0.820369 -0.70032,-2.20099 0,-1.160522 0.62028,-2.100945 0.64029,-0.960432 1.90086,-1.520684 1.28057,-0.560252 3.1214,-0.560252 1.28058,0 2.52113,0.320144 1.24056,0.320144 2.14097,0.920414 l -0.82037,2.020909 q -0.92042,-0.540243 -1.92087,-0.820369 -1.00045,-0.280126 -1.94087,-0.280126 -1.54069,0 -2.30103,0.520234 -0.74034,0.520234 -0.74034,1.380621 0,0.60027 0.42019,0.980441 0.4402,0.380171 1.1005,0.60027 0.66029,0.220099 1.80081,0.500225 1.5607,0.360162 2.56115,0.760342 1.00045,0.380171 1.70076,1.180531 0.72033,0.80036 0.72033,2.160972 0,1.160522 -0.64029,2.100945 -0.62028,0.940423 -1.90085,1.500675 -1.28058,0.560252 -3.12141,0.560252 z"
|
||||
id="path12622" /><path
|
||||
d="m 354.47498,-35.89283 h -2.60117 v -11.80531 h -4.64209 v -2.20099 h 11.88535 v 2.20099 h -4.64209 z"
|
||||
id="path12624" /></g></g>
|
||||
|
||||
|
||||
|
||||
<text
|
||||
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:20.01px;font-family:'Montserrat SemiBold';-inkscape-font-specification:'Montserrat SemiBold, Bold';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;fill:#6f9aa8;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1"
|
||||
id="text2843"
|
||||
x="240.16206"
|
||||
y="-35.894695"
|
||||
transform="scale(1,-1)"><tspan
|
||||
id="tspan2841"
|
||||
x="240.16206"
|
||||
y="-35.894695" /></text></g></svg>
|
||||
|
Before Width: | Height: | Size: 14 KiB |
0
static/images/backup.png
Normal file → Executable file
0
static/images/backup.png
Normal file → Executable file
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
0
static/images/cyberduck-logo.png
Normal file → Executable file
0
static/images/cyberduck-logo.png
Normal file → Executable file
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
0
static/images/host.png
Normal file → Executable file
0
static/images/host.png
Normal file → Executable file
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
0
static/images/mastodon-logo.svg
Normal file → Executable file
0
static/images/mastodon-logo.svg
Normal file → Executable file
|
Before Width: | Height: | Size: 1.4 KiB After Width: | Height: | Size: 1.4 KiB |
0
static/images/matrix-logo.svg
Normal file → Executable file
0
static/images/matrix-logo.svg
Normal file → Executable file
|
Before Width: | Height: | Size: 3.8 KiB After Width: | Height: | Size: 3.8 KiB |
0
static/images/nextcloud-logo.svg
Normal file → Executable file
0
static/images/nextcloud-logo.svg
Normal file → Executable file
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 10 KiB |
|
|
@ -1,34 +0,0 @@
|
|||
<?xml version="1.0" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
|
||||
<!-- Created using Karbon14, part of koffice: http://www.koffice.org/karbon -->
|
||||
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="449px" height="168px">
|
||||
<defs>
|
||||
</defs>
|
||||
<g id="Layer">
|
||||
</g>
|
||||
<g id="Layer">
|
||||
<path fill="#98bf00" d="M446.602 73.8789L449.102 60.234L436.207 60.234L439.957 40.145L424.512 46.191L422.012 60.234L412.617 60.234L410.117 73.8789L419.363 73.8789L416.215 91.1719C416.066 92.125 415.816 93.5234 415.566 95.3203C415.316 97.1211 415.164 98.7188 415.164 100.07C415.215 106.316 416.715 111.465 419.664 115.516C422.613 119.66 427.41 122.109 434.109 122.859L440.555 109.566C437.105 109.117 434.508 107.766 432.66 105.469C430.809 103.117 429.91 100.168 429.91 96.5703C429.91 95.8711 430.012 94.8711 430.16 93.5234C430.309 92.1719 430.461 91.0742 430.609 90.2227L433.609 73.8789L446.602 73.8789L446.602 73.8789Z" />
|
||||
<path fill="#98bf00" d="M310.707 72.332C313.105 71.4805 315.207 71.0312 316.957 71.0312C318.855 71.0312 320.453 71.582 321.754 72.6797C323.004 73.7305 323.602 75.2812 323.602 77.4297C323.602 78.0273 323.504 78.9297 323.301 80.1797C323.102 81.3281 322.953 82.3789 322.805 83.2773L319.203 100.168C318.953 101.469 318.703 102.82 318.453 104.219C318.203 105.668 318.105 106.918 318.105 107.965C318.105 112.016 319.203 115.414 321.453 118.113C323.602 120.812 327.449 122.41 333 122.859L339.348 110.016C337.195 109.668 335.648 108.867 334.699 107.617C333.699 106.418 333.199 104.719 333.199 102.57C333.199 102.07 333.25 101.469 333.348 100.82C333.398 100.168 333.5 99.6211 333.547 99.2188L337.195 82.0273C337.496 80.5781 337.746 79.1289 337.945 77.6797C338.148 76.2812 338.246 74.8789 338.246 73.5312C338.246 68.582 336.797 64.586 333.898 61.637C330.949 58.688 326.852 57.188 321.602 57.188C318.555 57.188 315.656 57.688 312.809 58.688C310.008 59.637 306.609 61.234 302.66 63.586C302.512 62.637 302.16 61.484 301.66 60.188C301.113 58.938 300.512 57.836 299.863 56.836L286.469 62.586C287.617 64.336 288.516 66.184 289.066 68.082C289.566 69.9805 289.816 71.7812 289.816 73.4297C289.816 74.2812 289.766 75.3281 289.617 76.4805C289.516 77.6289 289.367 78.5273 289.215 79.1797L281.27 121.512L295.664 121.512L304.109 75.8281C306.16 74.2812 308.359 73.1289 310.707 72.332L310.707 72.332Z" />
|
||||
<path fill="#98bf00" d="M350.742 80.0781C349.191 84.6758 348.441 89.5742 348.441 94.7227C348.441 99.2188 349.043 103.219 350.191 106.719C351.34 110.215 352.992 113.164 355.09 115.516C357.141 117.914 359.688 119.711 362.637 120.961C365.586 122.211 368.883 122.859 372.484 122.859C376.832 122.859 381.129 122.062 385.43 120.461C389.777 118.863 393.574 116.363 396.824 113.016L391.426 100.519C388.926 103.32 386.176 105.418 383.129 106.867C380.078 108.316 377.031 109.016 374.031 109.016C370.535 109.016 367.785 107.918 365.785 105.719C363.836 103.469 362.836 100.668 362.836 97.3711L362.836 96.4219C362.836 96.0234 362.887 95.6211 362.988 95.2227C365.637 94.8711 368.633 94.4219 371.984 93.8242C375.332 93.2227 378.73 92.5234 382.18 91.7227C385.629 90.875 388.977 89.9258 392.273 88.9258C395.523 87.9258 398.422 86.875 400.871 85.8242L400.871 80.0781C400.871 76.5312 400.32 73.332 399.223 70.4805C398.074 67.734 396.574 65.332 394.625 63.285C392.676 61.285 390.324 59.785 387.676 58.785C385.078 57.738 382.23 57.188 379.18 57.188C374.73 57.188 370.582 58.188 366.836 60.137C363.035 62.086 359.789 64.785 357.141 68.2344C354.391 71.6328 352.293 75.5781 350.742 80.0781L350.742 80.0781ZM372.383 69.9805C373.934 69.1328 375.684 68.7344 377.633 68.7344C380.281 68.7344 382.48 69.582 384.227 71.332C385.977 73.0312 386.879 75.5781 386.879 79.0273C385.43 79.4766 383.727 80.0273 381.73 80.5781C379.68 81.0781 377.633 81.5781 375.531 82.0273C373.383 82.4766 371.332 82.9258 369.285 83.3281C367.234 83.6758 365.484 83.9766 363.984 84.2266C364.234 82.1289 364.688 80.1289 365.387 78.2773C366.137 76.4297 367.086 74.7812 368.234 73.3789C369.484 71.9805 370.832 70.832 372.383 69.9805L372.383 69.9805Z" fill-rule="evenodd" />
|
||||
<path fill="#000000" d="M404.172 140.453C404.172 139.203 403.969 138.055 403.57 137.055C403.172 136.055 402.621 135.207 401.973 134.457C401.27 133.758 400.473 133.207 399.523 132.856C398.574 132.508 397.523 132.309 396.422 132.309C394.973 132.309 393.625 132.606 392.375 133.156C391.125 133.707 390.027 134.508 389.078 135.504C388.125 136.504 387.379 137.656 386.828 139.004C386.277 140.356 385.977 141.805 385.977 143.402C385.977 144.652 386.176 145.75 386.578 146.801C386.926 147.801 387.477 148.652 388.176 149.352C388.828 150.101 389.676 150.648 390.625 151.051C391.574 151.399 392.625 151.598 393.773 151.598C395.176 151.598 396.523 151.301 397.773 150.75C399.023 150.199 400.121 149.398 401.07 148.402C402.02 147.449 402.77 146.25 403.32 144.902C403.871 143.551 404.172 142.055 404.172 140.453L404.172 140.453ZM390.277 140.402C390.574 139.504 390.977 138.703 391.477 138.004C392.023 137.305 392.676 136.754 393.426 136.305C394.176 135.856 394.973 135.656 395.922 135.656C397.371 135.656 398.422 136.106 399.172 137.004C399.922 137.856 400.32 139.106 400.32 140.652C400.32 141.602 400.172 142.555 399.871 143.504C399.621 144.402 399.223 145.203 398.672 145.902C398.121 146.602 397.473 147.152 396.723 147.601C395.973 148 395.125 148.199 394.223 148.199C392.773 148.199 391.727 147.75 390.977 146.902C390.227 146 389.824 144.801 389.824 143.254C389.824 142.305 389.977 141.352 390.277 140.402L390.277 140.402Z" fill-rule="evenodd" />
|
||||
<path fill="#000000" d="M434.559 132.559L431.008 132.559L429.109 143.602C429.059 143.754 429.012 144.004 429.012 144.352C429.012 144.703 429.012 144.953 429.012 145.203L428.859 145.203L422.465 132.559L419.113 132.559L415.766 151.301L419.363 151.301L421.363 140.004C421.414 139.856 421.414 139.606 421.414 139.356C421.414 139.106 421.414 138.805 421.414 138.504L421.563 138.504L428.109 151.449L431.309 151.149L434.559 132.559L434.559 132.559Z" />
|
||||
<path fill="#000000" d="M374.383 132.559L370.734 132.559L367.387 151.301L371.082 151.301L374.383 132.559L374.383 132.559Z" />
|
||||
<path fill="#000000" d="M328.949 132.559L324.703 132.559C323.902 133.906 323.051 135.457 322.102 137.106C321.152 138.754 320.254 140.453 319.355 142.152C318.453 143.852 317.656 145.5 316.906 147.102C316.156 148.699 315.555 150.101 315.105 151.301L318.953 151.301C319.105 150.949 319.254 150.5 319.453 150.051C319.652 149.602 319.855 149.102 320.105 148.652C320.305 148.199 320.504 147.75 320.703 147.301C320.902 146.852 321.102 146.453 321.254 146.102L327.75 146.102C327.801 146.551 327.801 147 327.852 147.5L328 148.949C328.051 149.398 328.102 149.852 328.152 150.301C328.199 150.75 328.199 151.098 328.199 151.449L331.898 151.149C331.898 150.449 331.848 149.648 331.75 148.699C331.699 147.75 331.551 146.75 331.398 145.703C331.25 144.652 331.098 143.504 330.898 142.351C330.75 141.203 330.551 140.055 330.301 138.906C330.102 137.754 329.898 136.656 329.648 135.555C329.398 134.508 329.199 133.508 328.949 132.559L328.949 132.559ZM326.602 138.106C326.703 138.656 326.801 139.254 326.902 139.902C327 140.504 327.102 141.106 327.152 141.652C327.25 142.203 327.301 142.601 327.352 142.953L322.703 142.953C322.953 142.504 323.203 142.004 323.453 141.453C323.754 140.902 324.051 140.305 324.352 139.703C324.703 139.106 325 138.555 325.301 138.004C325.602 137.453 325.852 136.957 326.102 136.606L326.301 136.606C326.402 137.004 326.5 137.504 326.602 138.106L326.602 138.106Z" fill-rule="evenodd" />
|
||||
<path fill="#000000" d="M357.641 135.957L358.188 132.559L345.395 132.559L344.844 135.957L349.391 135.957L346.742 151.301L350.391 151.301L353.09 135.957L357.641 135.957L357.641 135.957Z" />
|
||||
<path fill="#000000" d="M297.465 132.309C296.414 132.309 295.363 132.356 294.312 132.457C293.266 132.606 292.266 132.758 291.316 133.008L288.168 150.852C289.117 151.098 290.215 151.25 291.414 151.399C292.566 151.551 293.664 151.598 294.715 151.598C296.262 151.598 297.664 151.348 299.012 150.852C300.363 150.301 301.562 149.602 302.562 148.652C303.559 147.699 304.359 146.551 304.961 145.203C305.508 143.852 305.809 142.305 305.809 140.606C305.809 139.254 305.609 138.106 305.211 137.055C304.762 136.004 304.211 135.156 303.461 134.457C302.711 133.758 301.812 133.207 300.812 132.856C299.762 132.508 298.664 132.309 297.465 132.309L297.465 132.309ZM296.664 135.707C297.414 135.707 298.113 135.805 298.762 135.957C299.414 136.106 299.961 136.406 300.41 136.805C300.91 137.203 301.312 137.703 301.562 138.356C301.812 138.953 301.961 139.703 301.961 140.652C301.961 141.852 301.812 142.902 301.461 143.852C301.16 144.801 300.711 145.602 300.113 146.25C299.512 146.902 298.812 147.352 297.961 147.699C297.113 148.051 296.215 148.199 295.164 148.199C294.715 148.199 294.266 148.199 293.715 148.152C293.164 148.102 292.664 148.051 292.316 148L294.465 135.906C294.766 135.856 295.164 135.805 295.613 135.754C296.062 135.707 296.414 135.707 296.664 135.707L296.664 135.707Z" fill-rule="evenodd" />
|
||||
<path fill="#000000" d="M185.809 62.586C186.957 64.336 187.855 66.184 188.406 68.082C188.906 69.9805 189.156 71.7812 189.156 73.4297C189.156 74.2812 189.105 75.3281 188.957 76.4805C188.855 77.6289 188.707 78.5273 188.555 79.1797L180.609 121.512L195.004 121.512L203.449 75.8281C205.5 74.2812 207.699 73.1289 210.047 72.332C212.445 71.4805 214.547 71.0312 216.297 71.0312C218.195 71.0312 219.793 71.582 221.094 72.6797C222.344 73.7305 222.941 75.2812 222.941 77.4297C222.941 78.0273 222.844 78.9297 222.645 80.1797C222.441 81.3281 222.293 82.3789 222.145 83.2773L218.543 100.168C218.293 101.469 218.043 102.82 217.793 104.219C217.547 105.668 217.445 106.918 217.445 107.965C217.445 112.016 218.543 115.414 220.793 118.113C222.941 120.812 226.793 122.41 232.34 122.859L238.688 110.016C236.539 109.668 234.988 108.867 234.039 107.617C233.039 106.418 232.539 104.719 232.539 102.57C232.539 102.07 232.59 101.469 232.688 100.82C232.738 100.168 232.84 99.6211 232.891 99.2188L236.539 82.0273C236.836 80.5781 237.086 79.1289 237.285 77.6797C237.488 76.2812 237.586 74.8789 237.586 73.5312C237.586 68.582 236.137 64.586 233.238 61.637C230.289 58.688 226.191 57.188 220.945 57.188C217.895 57.188 214.996 57.688 212.148 58.688C209.348 59.637 205.949 61.234 202 63.586C201.852 62.637 201.5 61.484 201 60.188C200.453 58.938 199.852 57.836 199.203 56.836L185.809 62.586L185.809 62.586Z" />
|
||||
<path fill="#000000" d="M276.82 31.547L262.676 31.547L251.883 90.0234C251.43 91.9727 251.082 94.0234 250.832 96.1719C250.582 98.2695 250.434 100.219 250.434 102.019C250.434 107.816 251.531 112.566 253.781 116.262C256.031 119.961 259.828 122.16 265.176 122.859L271.672 109.566C270.625 109.066 269.723 108.516 268.875 107.918C268.023 107.367 267.324 106.617 266.773 105.769C266.176 104.918 265.727 103.918 265.477 102.719C265.227 101.519 265.074 100.019 265.074 98.2695C265.074 97.4219 265.125 96.4727 265.227 95.4727C265.375 94.4219 265.527 93.3711 265.676 92.2734L276.82 31.547L276.82 31.547Z" />
|
||||
<path fill="#000000" d="M246.434 132.559L242.785 132.559L240.387 146.25C239.887 146.801 239.285 147.25 238.535 147.652C237.785 148 236.988 148.199 236.086 148.199C235.188 148.199 234.488 148 233.988 147.601C233.438 147.152 233.188 146.453 233.188 145.402C233.188 145.203 233.238 144.902 233.289 144.504C233.34 144.152 233.34 143.801 233.387 143.504L235.387 132.559L231.688 132.559L229.738 143.453C229.691 143.902 229.641 144.352 229.59 144.801C229.539 145.25 229.539 145.602 229.539 145.953C229.539 146.953 229.691 147.801 229.988 148.551C230.289 149.301 230.691 149.852 231.191 150.301C231.738 150.75 232.34 151.098 232.988 151.301C233.688 151.5 234.387 151.598 235.137 151.598C236.988 151.598 238.637 151.051 240.137 149.898C240.137 150.148 240.137 150.449 240.188 150.75C240.188 151 240.188 151.25 240.234 151.5L243.883 151.25C243.836 151 243.836 150.75 243.836 150.449C243.785 150.199 243.785 149.898 243.785 149.551C243.785 148.949 243.836 148.301 243.883 147.652C243.934 146.953 243.984 146.301 244.133 145.703L246.434 132.559L246.434 132.559Z" />
|
||||
<path fill="#000000" d="M276.621 132.559L273.074 132.559L271.172 143.602C271.125 143.754 271.074 144.004 271.074 144.352C271.074 144.703 271.074 144.953 271.074 145.203L270.922 145.203L264.527 132.559L261.176 132.559L257.828 151.301L261.426 151.301L263.426 140.004C263.477 139.856 263.477 139.606 263.477 139.356C263.477 139.106 263.477 138.805 263.477 138.504L263.625 138.504L270.176 151.449L273.371 151.149L276.621 132.559L276.621 132.559Z" />
|
||||
<path fill="#000000" d="M214.797 134.457C214.098 133.758 213.297 133.207 212.348 132.856C211.398 132.508 210.348 132.309 209.25 132.309C207.801 132.309 206.449 132.606 205.199 133.156C203.949 133.707 202.852 134.508 201.902 135.504C200.953 136.504 200.203 137.656 199.652 139.004C199.102 140.356 198.801 141.805 198.801 143.402C198.801 144.652 199.004 145.75 199.402 146.801C199.754 147.801 200.301 148.652 201 149.352C201.652 150.101 202.5 150.648 203.449 151.051C204.398 151.399 205.449 151.598 206.598 151.598C208 151.598 209.348 151.301 210.598 150.75C211.848 150.199 212.945 149.398 213.895 148.402C214.848 147.449 215.598 146.25 216.145 144.902C216.695 143.551 216.996 142.055 216.996 140.453C216.996 139.203 216.797 138.055 216.395 137.055C215.996 136.055 215.445 135.207 214.797 134.457L214.797 134.457ZM204.301 138.004C204.852 137.305 205.5 136.754 206.25 136.305C207 135.856 207.801 135.656 208.75 135.656C210.199 135.656 211.246 136.106 211.996 137.004C212.746 137.856 213.148 139.106 213.148 140.652C213.148 141.602 212.996 142.555 212.695 143.504C212.445 144.402 212.047 145.203 211.496 145.902C210.949 146.602 210.297 147.152 209.547 147.601C208.797 148 207.949 148.199 207.051 148.199C205.602 148.199 204.551 147.75 203.801 146.902C203.051 146 202.652 144.801 202.652 143.254C202.652 142.305 202.801 141.352 203.102 140.402C203.402 139.504 203.801 138.703 204.301 138.004L204.301 138.004Z" fill-rule="evenodd" />
|
||||
<path fill="#000000" d="M188.258 132.559L177.961 132.559L174.613 151.301L178.312 151.301L179.559 144.152L186.309 144.152L186.906 140.754L180.16 140.754L181.008 135.957L187.656 135.957L188.258 132.559L188.258 132.559Z" />
|
||||
<path fill="#98bf00" d="M127.082 44.891C128.43 33.945 125.684 24.102 118.883 15.402C112.086 6.707 103.191 1.66 92.2461 0.309C81.3008 -1.039 71.4531 1.711 62.7578 8.508C54.7109 14.754 49.8125 22.801 48.0625 32.648C47.9141 33.496 47.7617 34.297 47.6641 35.145C47.5625 35.996 47.5117 36.797 47.4648 37.594C47.1133 42.191 47.5625 46.59 48.7617 50.789C50.1133 55.688 52.4609 60.285 55.8594 64.633C59.2578 68.9805 63.1563 72.3828 67.6055 74.9297C71.3516 77.0781 75.5 78.5273 80.0508 79.3281C80.8516 79.4766 81.6484 79.5781 82.5 79.7266C82.9492 79.7773 83.3984 79.8281 83.8477 79.8789C84.9492 75.4297 86.6484 71.2812 88.9961 67.531C87.4453 67.582 85.8477 67.531 84.25 67.383C84.1484 67.332 84.0977 67.332 84.0469 67.332C82.1992 67.082 80.3984 66.734 78.75 66.184C73.6016 64.535 69.2539 61.484 65.707 56.938C62.1562 52.391 60.2578 47.441 59.9062 42.043C59.8086 40.293 59.8594 38.543 60.1094 36.695C60.1094 36.645 60.1094 36.547 60.1094 36.496C61.0586 29.047 64.5078 23 70.4531 18.352C76.4531 13.703 83.1992 11.805 90.7461 12.754C98.293 13.656 104.391 17.102 109.039 23.102C113.688 29.098 115.586 35.844 114.688 43.395C114.438 45.094 114.137 46.691 113.688 48.242C117.887 46.891 122.281 46.191 126.883 46.242C126.93 45.793 127.031 45.344 127.082 44.891L127.082 44.891Z" />
|
||||
<path fill="#98bf00" d="M132.328 51.488C131.48 51.391 130.68 51.289 129.828 51.238C125.23 50.941 120.832 51.391 116.637 52.539C111.738 53.887 107.141 56.289 102.789 59.688C98.4414 63.035 95.043 66.934 92.5469 71.3828C90.3945 75.1289 88.9453 79.2773 88.0977 83.8281C92.4453 84.5742 96.4453 85.8242 100.141 87.6758C100.391 85.875 100.742 84.1758 101.242 82.5781C102.891 77.4297 105.941 73.082 110.488 69.5312C115.035 65.984 119.984 64.035 125.434 63.684C127.18 63.586 128.93 63.633 130.781 63.883C130.828 63.883 130.879 63.883 130.93 63.883C138.375 64.836 144.426 68.332 149.074 74.2812C153.77 80.2266 155.668 86.9766 154.719 94.5234C153.77 102.07 150.32 108.168 144.375 112.863C138.426 117.512 131.68 119.363 124.23 118.461C125.082 122.512 125.332 126.758 125.031 131.156C134.977 131.809 143.973 128.957 152.02 122.711C160.719 115.914 165.766 107.016 167.113 96.0703C168.465 85.125 165.715 75.2812 158.918 66.582C152.621 58.535 144.574 53.637 134.777 51.891C133.93 51.738 133.129 51.59 132.328 51.488L132.328 51.488Z" />
|
||||
<path fill="#000000" d="M128.93 78.7266C125.48 78.3281 122.434 79.1797 119.684 81.3281C116.934 83.4766 115.387 86.2266 114.984 89.625C114.535 93.0742 115.387 96.1211 117.535 98.8711C119.684 101.621 122.434 103.168 125.883 103.57C129.281 104.019 132.328 103.168 135.078 101.019C137.828 98.8711 139.375 96.1211 139.824 92.6719C140.227 89.2734 139.375 86.2266 137.227 83.4766C135.078 80.7266 132.328 79.1797 128.93 78.7266L128.93 78.7266Z" />
|
||||
<path fill="#98bf00" d="M12.8281 73.6289C13.7773 66.082 17.2266 59.938 23.2227 55.289C29.1719 50.641 35.8672 48.742 43.3164 49.691C42.4648 45.641 42.1641 41.395 42.5156 36.996C32.5703 36.344 23.5742 39.145 15.5273 45.441C6.77734 52.238 1.78125 61.137 0.433594 72.082C-0.917969 83.0273 1.78125 92.8242 8.62891 101.57C14.875 109.617 22.9219 114.516 32.7695 116.262C33.5703 116.414 34.3672 116.512 35.2188 116.664C36.0664 116.762 36.8672 116.863 37.7188 116.914C42.3164 117.215 46.7148 116.762 50.9102 115.613C55.7578 114.215 60.4062 111.816 64.7578 108.465C69.0547 105.066 72.4531 101.168 75.0039 96.7695C77.1523 93.0234 78.6016 88.875 79.4492 84.3281C75.1016 83.5781 71.1055 82.2773 67.4062 80.4766C67.1563 82.2266 66.8047 83.9258 66.3047 85.5742C64.6562 90.7227 61.6055 95.0703 57.0586 98.6211C52.5117 102.168 47.5625 104.117 42.1641 104.469C40.4141 104.566 38.6172 104.519 36.7656 104.269C36.7188 104.269 36.668 104.269 36.6172 104.219C29.1719 103.269 23.1211 99.8203 18.4727 93.8711C13.7773 87.875 11.8789 81.1289 12.8281 73.6289L12.8281 73.6289Z" />
|
||||
<path fill="#000000" d="M32.4688 67.133C29.7188 69.2305 28.1719 72.0312 27.7227 75.4805C27.3203 78.8281 28.1719 81.8789 30.3203 84.625C32.418 87.375 35.168 88.9727 38.6172 89.4258C42.0664 89.7734 45.1133 88.9258 47.8633 86.8242C50.5625 84.6758 52.1094 81.8789 52.5625 78.5273C53.0117 75.0781 52.1602 71.9805 50.0117 69.2812C47.8633 66.535 45.1133 64.984 41.6641 64.586C38.2148 64.133 35.168 64.984 32.4688 67.133L32.4688 67.133Z" />
|
||||
<path fill="#000000" d="M97.293 32.348C95.1445 29.598 92.3438 28.047 88.9453 27.648C85.4961 27.199 82.4492 28.047 79.75 30.199C77 32.297 75.4023 35.098 75.0039 38.543C74.5508 41.941 75.4531 44.992 77.6016 47.742C79.6992 50.441 82.4492 52.039 85.8984 52.488C89.2969 52.84 92.3438 51.988 95.0938 49.891C97.8438 47.742 99.3906 44.941 99.8438 41.594C100.242 38.145 99.3906 35.047 97.293 32.348L97.293 32.348Z" />
|
||||
<path fill="#98bf00" d="M85.0469 88.4258C84.5977 88.375 84.1484 88.3242 83.6992 88.2734C82.5977 92.7227 80.8984 96.8711 78.5508 100.621C80.1016 100.519 81.6992 100.57 83.3477 100.769C83.3984 100.769 83.4492 100.769 83.5 100.82C85.3477 101.019 87.0977 101.371 88.7969 101.918C93.9453 103.57 98.293 106.668 101.84 111.215C105.391 115.715 107.289 120.66 107.641 126.109C107.738 127.859 107.688 129.609 107.438 131.457C107.438 131.508 107.438 131.559 107.438 131.656C106.488 139.106 103.039 145.152 97.0938 149.801C91.0938 154.449 84.3477 156.348 76.8008 155.398C69.2539 154.449 63.1563 151 58.5078 145.051C53.8086 139.055 51.9102 132.309 52.8594 124.762C53.0625 123.062 53.4102 121.461 53.9102 119.91C49.6641 121.262 45.2656 121.91 40.6641 121.91C40.6172 122.359 40.5156 122.812 40.4648 123.262C39.1172 134.207 41.8164 144.004 48.6641 152.75C55.4609 161.445 64.3555 166.492 75.3008 167.844C86.2461 169.191 96.043 166.445 104.789 159.645C112.836 153.348 117.734 145.301 119.484 135.457C119.633 134.656 119.734 133.856 119.883 133.008C119.934 132.156 120.035 131.359 120.082 130.559C120.383 125.91 119.934 121.512 118.785 117.363C117.434 112.465 115.035 107.867 111.688 103.519C108.289 99.1719 104.391 95.7227 99.9922 93.2227C96.1953 91.0742 92.0469 89.625 87.4961 88.8242C86.6992 88.6758 85.8984 88.5234 85.0469 88.4258L85.0469 88.4258Z" />
|
||||
<path fill="#000000" d="M89.9961 120.41C87.8477 117.664 85.0977 116.113 81.6484 115.664C78.1992 115.266 75.1523 116.113 72.4531 118.262C69.7031 120.41 68.1562 123.16 67.7031 126.559C67.2539 130.008 68.1562 133.059 70.3047 135.805C72.4024 138.555 75.1523 140.106 78.6016 140.504C82.0508 140.953 85.0977 140.106 87.8477 137.953C90.5469 135.805 92.0938 133.059 92.5469 129.609C92.9453 126.211 92.0938 123.16 89.9961 120.41L89.9961 120.41Z" />
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 20 KiB |
0
static/images/peertube-logo.svg
Normal file → Executable file
0
static/images/peertube-logo.svg
Normal file → Executable file
|
Before Width: | Height: | Size: 364 B After Width: | Height: | Size: 364 B |
0
static/images/rclone-logo.svg
Normal file → Executable file
0
static/images/rclone-logo.svg
Normal file → Executable file
|
Before Width: | Height: | Size: 4.3 KiB After Width: | Height: | Size: 4.3 KiB |
0
static/images/store.png
Normal file → Executable file
0
static/images/store.png
Normal file → Executable file
|
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
0
static/js/site.js
Normal file → Executable file
0
static/js/site.js
Normal file → Executable file
0
tailwind.config.js
Normal file → Executable file
0
tailwind.config.js
Normal file → Executable file
0
templates/404.html
Normal file → Executable file
0
templates/404.html
Normal file → Executable file
0
templates/base.html
Normal file → Executable file
0
templates/base.html
Normal file → Executable file
0
templates/blog_article.html
Normal file → Executable file
0
templates/blog_article.html
Normal file → Executable file
0
templates/blog_index.html
Normal file → Executable file
0
templates/blog_index.html
Normal file → Executable file
|
|
@ -12,7 +12,6 @@ Downloads | {{ config.title }}
|
|||
<div class="h-8 w-8 bg-gradient-to-bl from-gray-50 via-gray-50 to-gray-100 -rotate-45 transform origin-top-left shadow"></div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="mx-auto max-w-7xl px-4">
|
||||
<div id="releases-container" class="py-24 space-y-20">
|
||||
<div id="docker-images" class="space-y-4">
|
||||
|
|
@ -95,6 +94,8 @@ Downloads | {{ config.title }}
|
|||
let extraBuilds = data[1].builds;
|
||||
let developmentBuilds = data[2].builds;
|
||||
|
||||
console.log(extraBuilds)
|
||||
|
||||
/** Release Builds */
|
||||
for (i = 0; i < releaseBuilds.length; i++) {
|
||||
window['build' + i] =
|
||||
|
|
@ -108,7 +109,7 @@ Downloads | {{ config.title }}
|
|||
<div id="release-builds-detail-${i}" class="flex flex-col md:flex-row items-start md:items-center space-x-0 md:space-x-2 space-y-2 md:space-y-0"></div>
|
||||
<span class="inline-block mt-4 text-sm mb-1 uppercase text-gray-600">Sources</span>
|
||||
<div id="release-builds-source-${i}" class="flex items-center space-x-2">
|
||||
<a href="https://git.deuxfleurs.fr/Deuxfleurs/garage/src/tag/${releaseBuilds[i]['version']}" download class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<a href="https://git.deuxfleurs.fr/Deuxfleurs/garage/src/tag/${releaseBuilds[i]['version']}" class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<span>Gitea</span>
|
||||
</a>
|
||||
<a href="https://git.deuxfleurs.fr/Deuxfleurs/garage/archive/${releaseBuilds[i]['version']}.zip" class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
|
|
@ -126,7 +127,7 @@ Downloads | {{ config.title }}
|
|||
for (j = 0; j < releaseBuilds[i]['builds'].length; j++) {
|
||||
window['buildDetail' + i] =
|
||||
`
|
||||
<a href="${releaseBuilds[i]['builds'][j]['url']}" download class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<a href="${releaseBuilds[i]['builds'][j]['url']}" class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<span>
|
||||
${releaseBuilds[i]['builds'][j]['platform']
|
||||
.replace('aarch64-unknown-linux-musl', 'linux/arm64')
|
||||
|
|
@ -153,7 +154,7 @@ Downloads | {{ config.title }}
|
|||
<div id="extra-builds-detail-${i}" class="flex flex-col md:flex-row items-start md:items-center space-x-0 md:space-x-2 space-y-2 md:space-y-0"></div>
|
||||
<span class="inline-block mt-4 text-sm mb-1 uppercase text-gray-600">Sources</span>
|
||||
<div id="extra-builds-source-${i}" class="flex items-center pt-4 space-x-2">
|
||||
<a href="https://git.deuxfleurs.fr/Deuxfleurs/garage/src/tag/${extraBuilds[i]['version']}" download class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<a href="https://git.deuxfleurs.fr/Deuxfleurs/garage/src/tag/${extraBuilds[i]['version']}" class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<span>Gitea</span>
|
||||
</a>
|
||||
<a href="https://git.deuxfleurs.fr/Deuxfleurs/garage/archive/${extraBuilds[i]['version']}.zip" class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
|
|
@ -171,7 +172,7 @@ Downloads | {{ config.title }}
|
|||
for (j = 0; j < extraBuilds[i]['builds'].length; j++) {
|
||||
window['buildDetail' + i] =
|
||||
`
|
||||
<a href="${extraBuilds[i]['builds'][j]['url']}" download class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<a href="${extraBuilds[i]['builds'][j]['url']}" class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<span>
|
||||
${extraBuilds[i]['builds'][j]['platform']
|
||||
.replace('aarch64-unknown-linux-musl', 'linux/arm64')
|
||||
|
|
@ -198,7 +199,7 @@ Downloads | {{ config.title }}
|
|||
<div id="development-builds-detail-${i}" class="flex flex-col md:flex-row items-start md:items-center space-x-0 md:space-x-2 space-y-2 md:space-y-0"></div>
|
||||
<span class="inline-block mt-4 text-sm mb-1 uppercase text-gray-600">Sources</span>
|
||||
<div id="development-builds-source-${i}" class="flex items-center pt-4 space-x-2">
|
||||
<a href="https://git.deuxfleurs.fr/Deuxfleurs/garage/src/tag/${developmentBuilds[i]['version']}" download class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<a href="https://git.deuxfleurs.fr/Deuxfleurs/garage/src/tag/${developmentBuilds[i]['version']}" class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<span>Gitea</span>
|
||||
</a>
|
||||
<a href="https://git.deuxfleurs.fr/Deuxfleurs/garage/archive/${developmentBuilds[i]['version']}.zip" class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
|
|
@ -216,7 +217,7 @@ Downloads | {{ config.title }}
|
|||
for (j = 0; j < developmentBuilds[i]['builds'].length; j++) {
|
||||
window['buildDetail' + i] =
|
||||
`
|
||||
<a href="${developmentBuilds[i]['builds'][j]['url']}" download class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<a href="${developmentBuilds[i]['builds'][j]['url']}" class="inline-block p-1.5 text-garage-gray font-bold bg-gray-300 hover:bg-orange-300 rounded border-b-2 border-gray-400 hover:border-orange-400 transition-all duration-300">
|
||||
<span>
|
||||
${developmentBuilds[i]['builds'][j]['platform']
|
||||
.replace('aarch64-unknown-linux-musl', 'linux/arm64')
|
||||
|
|
|
|||
26
templates/index.html
Normal file → Executable file
26
templates/index.html
Normal file → Executable file
|
|
@ -28,7 +28,6 @@
|
|||
<span class="inline text-sm md:text-base">Get Started</span>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
<div class="max-w-7xl mx-auto grid grid-cols-1 md:grid-cols-3 gap-x-32 py-12">
|
||||
<a href="{{config.base_url}}/documentation/connect/websites/" class="group flex flex-col items-center justify-center p-2">
|
||||
<img src="{{ get_url(path='images/host.png') }}" class="transform group-hover:translate-y-2 transition duration-500">
|
||||
|
|
@ -217,28 +216,15 @@
|
|||
<div class="w-full flex flex-col items-center justify-center shadow-inner">
|
||||
<div class="px-8 py-24 space-y-8 text-garage-gray max-w-4xl mx-auto">
|
||||
<h2 class="text-2xl text-garage-orange font-semibold">Sponsors and funding</h2>
|
||||
<p>Garage has received funding from <a class="text-garage-orange underline" href="https://pointer.ngi.eu/" target="_blank">NGI POINTER</a> (3 full-time employees for one year, in 2021-2022),
|
||||
and from <a class="text-garage-orange underline" href="https://nlnet.nl/entrust/" target="_blank">NLnet / NGI0 Entrust</a> (1 full-time employee for one year, in 2023-2024).
|
||||
</p>
|
||||
<p>If you want to participate in funding Garage development,
|
||||
<p>The <a class="text-garage-orange underline" href="https://deuxfleurs.fr/" target="_blank">Deuxfleurs association</a>
|
||||
has received a grant from <a class="text-garage-orange underline" href="https://pointer.ngi.eu/" target="_blank">NGI POINTER</a>,
|
||||
to fund 3 people working on Garage full-time for a year : from October 2021 to September 2022.</p>
|
||||
<p>If you want to fund Garage development past its initial grant,
|
||||
either through donation or support contract,
|
||||
please <a class="text-garage-orange underline" href="mailto:{{config.extra.social.email}}">get in touch with us</a>.
|
||||
</p>
|
||||
<p>
|
||||
<img src="{{ get_url(path='images/ngi-pointer-eu.png') }}" class="w-2/3 mx-auto" alt="NGI Pointers">
|
||||
</p>
|
||||
<p class="flex flex-row justify-around">
|
||||
<img src="{{ get_url(path='images/nlnet.svg') }}" class="w-1/3" alt="NLnet logo">
|
||||
<img src="{{ get_url(path='images/NGI0Entrust_tag.svg') }}" class="w-1/3" alt="NGI0 Entrust logo">
|
||||
</p>
|
||||
please <a class="text-garage-orange underline" href="mailto:{{config.extra.social.email}}">get in touch with us</a></p>
|
||||
<img src="{{ get_url(path='images/ngi-pointer-eu.png') }}" class="w-2/3 mx-auto" alt="NGI Pointers">
|
||||
<p class="italic">This project has received funding from the European Union's Horizon 2021 research and innovation programme
|
||||
within the framework of the NGI-POINTER Project funded under grant agreement N° 871528.</p>
|
||||
<p class="italic">This project has received funding from the NGI0
|
||||
Entrust Fund, a fund established by NLnet with financial support from the
|
||||
European Commission's Next Generation Internet programme, under the aegis of DG
|
||||
Communications Networks, Content and Technology under grant agreement No
|
||||
101069594.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
|
|
|||
0
templates/macros.html
Normal file → Executable file
0
templates/macros.html
Normal file → Executable file
|
|
@ -1,14 +0,0 @@
|
|||
<div class="max-w-4xl mx-auto">
|
||||
<div class="bg-teal-100 border-t-4 border-teal-500 rounded-b text-teal-900 px-4 py-3 shadow-md" role="alert">
|
||||
<div class="flex">
|
||||
<div class="py-1"><svg class="fill-current h-6 w-6 text-teal-500 mr-4" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 20"><path d="M2.93 17.07A10 10 0 1 1 17.07 2.93 10 10 0 0 1 2.93 17.07zm12.73-1.41A8 8 0 1 0 4.34 4.34a8 8 0 0 0 11.32 11.32zM9 11V9h2v6H9v-4zm0-6h2v2H9V5z"/></svg></div>
|
||||
<div>
|
||||
<p class="font-bold">Garage pre-1.0 community survey</p>
|
||||
<p class="text-sm"> As part of our plans for the release of Garage v1.0, we are launching a survey to gather feedback from Garage users and potential users on all fronts, in order to improve Garage's reliability, user experience, and suitability for various application domains.</p>
|
||||
<p>
|
||||
<a href="https://pad.deuxfleurs.fr/form/#/2/form/view/bGZkUeZ5wxOuTSlP3nRJeTbCQlwdqUpF3ggN6vGqRds/" class="text-garage-orange font-bold hover:underline">Answer the survey here</a>
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
0
templates/robots.txt
Normal file → Executable file
0
templates/robots.txt
Normal file → Executable file
0
templates/shortcodes/katex.html
Normal file → Executable file
0
templates/shortcodes/katex.html
Normal file → Executable file
0
templates/shortcodes/mermaid.html
Normal file → Executable file
0
templates/shortcodes/mermaid.html
Normal file → Executable file
0
templates/shortcodes/vimeo.html
Normal file → Executable file
0
templates/shortcodes/vimeo.html
Normal file → Executable file
0
templates/shortcodes/youtube.html
Normal file → Executable file
0
templates/shortcodes/youtube.html
Normal file → Executable file
Loading…
Reference in a new issue