Q to all candidates: what is the long-term role of traditional Linux distributions?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Q to all candidates: what is the long-term role of traditional Linux distributions?

Matthew Garrett
Debian prides itself on shipping large quantities of free software with
a strong level of stability within a release. A huge number of users
around the world rely on Debian as a solid base for their infrastructure
and derivative works, and our packaging policy makes it easier for us to
ensure that security updates hit all users rather than a subset.

But upstream development is increasingly diverging from our approach.
Many new software ecosystems are based on external code repositories
rather than relying on the distribution, and in several languages it's
expected that a project directly include its dependencies rather than
relying on external availability. A world in which users are more
concerned about immediate functionality rather than long-term interface
stability means there's an increasing amount of free software that's
somewhere between difficult and impossible to ship in Debian. Efforts
like Snap and Flatpak are even making this the case for desktop
applications, providing an alternative approach for users to obtain
auto-updated software without relying on Debian.

Given these upstream shifts, is attempting to package as much software
as possible something that actually benefits Debian and our users, or is
it something that brings us a duplication of effort? If we spent time on
building tooling to automatically identify that (say) installed Go
applications that contain dependencies with security vulnerabilities and
alert users, would that be time better spent than independendly
packaging and maintaining those dependencies ourselves? Are our current
priorities the best way to serve the free software community over the
next 10 years? Would we be better off focusing Debian as a high-quality
base for users who then largely consume software from other sources?

--
Matthew Garrett | [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Q to all candidates: what is the long-term role of traditional Linux distributions?

Jose Miguel Parrella
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 4/2/19 3:22 PM, Matthew Garrett wrote:

> Given these upstream shifts, is attempting to package as much
> software as possible something that actually benefits Debian and
> our users, or is it something that brings us a duplication of
> effort? If we spent time on building tooling to automatically
> identify that (say) installed Go applications that contain
> dependencies with security vulnerabilities and alert users, would
> that be time better spent than independendly packaging and
> maintaining those dependencies ourselves? Are our current
> priorities the best way to serve the free software community over
> the next 10 years? Would we be better off focusing Debian as a
> high-quality base for users who then largely consume software from
> other sources?

+1 to all of Matthew's questions, and I would add a few more from a
people standpoint:

How do you think motivations and incentives have changed, are changing
or will change for contributors to Debian in a world where distros no
longer mean what they used to?

If tools, policies and/or processes weren't a source of frustration
for contributors, do you think they would still disengage from the
project because they want to package software/be the subject matter
expert for said software?

Do you think Debian should focus more on the derivatives as users
rather than individual end users only? And if so, connecting to the
first Q, how would you manage new people being attracted to the
project and some current contributors feeling de-energized about it?

These are essentially the same question and I'm not expecting
candidates to pretend they can control people's feelings. I'm glad
Matthew brought this topic up and that we're having all of these
conversations as part of the campaign.

Thanks,
Jose
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOgvunu4OG37MZCTgwDJCqYjUt98FAlykGWsACgkQwDJCqYjU
t9/rEw//Wbd2wOSeZOakxOS+IDysegbHmingTt+JyFcDIvO1E44fVt95UkN+qd/D
g5Rt3CtFE8PU9o+laBSLx7wtYr7gL/eoCHbHL2dQP/7Rfg0ONoufcWWSl4dr68Gq
BsEmXoJ8Wlf1ObE3LtvPdmvpWBH/YTJDAa5F6VewweKyKZ5E1PKbuihj1Fs/KF9h
yx7cfgO8GTi1eYEfyPoFiQ8JbxDGgD1AoQ4S2dVa/YD71D5sfnPwlkIp8WQu/9pW
4x+dunT8fwYzNbtgZSeaXLT1MOCDmVHx+1deADl8QLIiCIpbfcn68AQSLDyG+kh6
8p7pCPfj0cjsBAtSu/gOIDOpn53DKZI/UxGlinuDqEv0W12GurIWKxypUCSZt9/d
0ed9B+r9XuwPGjLVDvuR2n/TOgBUW+JsRSpuYMmgaESnYMfTIGhzqcpdaB0csWTG
Kj3G9vLsMvoVFZprQ7JQwbZAob2O8Nbe21n1aPdubb8VwTzhLG9kGvPFz4eDeZL0
rgB1PsVfPl7kabFGjvv3RVrOUZJumj/Z+y53oYNcMOqAGmprmo/YoxTSmdi9wy3e
CSCOJ9l800cIUd0aQsJaCP/RED4dZoZYDqfhxcnGHtTyaIxcn0uUvFa3p5FAei5T
ygXFFdL2ToAw0bRkIeLXYPtpOjN6t8j7DpAQBp3hsVJ8l1/r/AY=
=/0Wf
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Q to all candidates: what is the long-term role of traditional Linux distributions?

Sam Hartman-3
In reply to this post by Matthew Garrett

When people hear I'm from Debian, this is the second most common
question I get.
The first is about systemd and gives me a great opportunity to talk
about how  Debian works and about how we're a community facing tough
challenges together.

Here's the answer I give on this issue for Debian of today.

Debian is great at giving you all the parts of what you need to do that
aren't your primary focus.  Even if you're a Python developer, you're
going to want some not Python stuff.  Even if you install everything you
can out of pip, some day you'll run across a dependency that's not
really a Python dependency.  (My classic example of ruby-sass has gotten
more complex because of libsass and its python bindings, but the point
is still very much true).
The free software ecosystem crosses language boundaries.
And Debian provides you with a great consistent interface for
approaching a lot of the common dependencies that are outside your core
focus.
Yet Debian also supports the tools for other repositories when you
choose that.

And that's a great answer as far as it goes.  I truly believe it; I have
lived it regularly and will continue doing so.

However, I think this is an area where someone spending some real time
developing a Debian vision and helping us move in that direction can
help.

I think packaging free software even from languages that have their own
system is valuable in a lot of ways.  First, we have a way of expressing
dependencies that cross language boundaries well.  We have a consistent
approach to validating licensing that seems better than a number of
other repositories in terms of respecting the DFSG and/or more generally
the four freedoms.

Especially for big packages, what we do is valuable.  I've run with the
upstream packaging of gitlab, and I know I'm looking forward to using
our packaging.  Our consistency, our approach to stability and security
updates really are valuable to a lot of users.  I know I want a
docker.io in Debian.  Our wordpress packaging has saved me a lot of
effort.  Yeah, you get stuck with something old, but if that works for
you, I've found that our packaging is a lot easier to leave stable than
the upstream.  The upstream forces upgrades at times that are not
convenient for me and forces me into situations where I have to spend
effort I don't have.  The Debian packaging still requires security
updates, but I have more confidence they can be applied without breaking
things or changing other behavior.

And yet people are spending a lot of time curating modules from
languages that have their own repositories.  Yes, I'm sure this work has
value.  I think we should do a better job of letting people know that we
recognize the value and articulating to ourselves and our users what
that value is.
However, it's a lot of effort, and we should understand we'll never
package all that is out there.  We should encourage people spending this
effort to evaluate whether it is the best use of their time.

More than that, I think we need to find a better way to interact with
these technologies.

For example I'm disappointed that flatpak is constructed in such a way
that you can't use debian packages to help satisfy application
dependencies even if you are using a deb-based flatpak runtime.  (The
debs would install into /usr which is reserved entirely for the
runtime).  I think that having a container system that would allow
people to use debs both on the runtime and application side could
significantly leverage our repository in those environments.  You might
well still want to build the primary app from upstream sources with no
packaging, but I think we should try to find a role in both the runtime
side of things as well as the dependencies that are not included in the
runtime that a given app needs.
(I'm aware of the technical issues to what I propose and am sure there
are lots of politics too)

I think we should also look at how we can interact better with these
other package managers.  I doubt we want packages in Debian main that
depend on random ruby gems or go packages pulled from an external
repository.  However perhaps we want that to be possible for third
parties.

Where it's not already possible perhaps we want to work with language
specific repositories to express dependencies that don't come from their
language in distribution terms.

Several of the language-specific installers are already good at allowing
system modules of the appropriate version to satisfy dependencies.

In general, I think this is an area where we need some focus.

And it's with a fair bit of regret that I realize I probably cannot
provide that focus in my first term as DPL if elected.
I think that the emphasis on communication and decision making I plan to
focus on will give us necessary skills as a project to approach this
sort of work.  I think that focusing on removing some of our internal
workflow challenges will help us make changes.
But realistically I think there's only so much one person can do in one
year.  I think this is important--critically important even in in a long
enough horizon--and yet beyond where I think I can personally spend my
energy right now.
It sucks; I think that the emotional, political and technical aspects of
this are interesting and challenging.  And yet I look at what I wrote in
my platform and what I've talked about already, and I don't want to
change my priorities.

I would be eager to find some way to help empower others to work on
this.  I don't have an explicit plan in that area and note I've already
talked about a lot of ways I'd work with people and there's a lot of
already existing teams and finite time.

--Sam

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Q to all candidates: what is the long-term role of traditional Linux distributions?

Jonathan Carter (highvoltage)-2
In reply to this post by Matthew Garrett
Hi Matthew

On 2019/04/03 00:22, Matthew Garrett wrote:
> Given these upstream shifts, is attempting to package as much software
> as possible something that actually benefits Debian and our users, or is
> it something that brings us a duplication of effort?

I'm not quite convinced that these upstream shifts are as pronounced as
you make it out to be. Packaging software in Debian is both beneficial
to its users, and a duplication of effort. Some things are a
double-edged sword and you have to weigh up the positives and the
negatives. I don't think it's a valid "or" question.

> If we spent time on building tooling to automatically identify that (say) installed Go
> applications that contain dependencies with security vulnerabilities and
> alert users, would that be time better spent than independendly
> packaging and maintaining those dependencies ourselves?

I think it's up to people who use hacky distribution methods to try to
solve the problems that they create, not us.

> Are our current priorities the best way to serve the free software
> community over the next 10 years?

Do you mind being more clear about which priorities you're referring to?

Regardless, the answer is likely to be no. I think there will be too
much change over the next ten years for any project to have the luxury
of having the same exact priorities over such a period.

As for our official priorities in terms of our social contract, I hope
that those priorities will be the same in 10 years from now.

> Would we be better off focusing Debian as a high-quality base for users
> who then largely consume software from other sources?

I don't think so. However, I do think we can do a lot more to make it
easier for users to consume software from 3rd party sources. There has
been some good discussions on this topic on this list recently, and its
clear that it's not going to be a problem that you can fix by just
throwing random quick and convenient ideas at it. Flatpacks, Snaps and
AppImages are a reasonable stopgap but they don't come close to solving
all the problems that they try to address and also cause new problems.
Personally I would rather us focus on bringing Debian's distribution
methods to the point where it's second to none. Based on the discussions
we've had on this list recently, it certainly seems possible to get
there, even if it may take some time.

Debian as it exists now is already very usable as a high quality base
that can be used to consume 3rd party sources, so if that aspect had
more attention and focus, what would you like to see better in Debian as
a base system?

-Jonathan

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

Re: Q to all candidates: what is the long-term role of traditional Linux distributions?

Ian Jackson-2
In reply to this post by Sam Hartman-3
Sam Hartman writes ("Re: Q to all candidates: what is the long-term role of traditional Linux distributions?"):
> Debian is great at giving you all the parts of what you need to do that
> aren't your primary focus.

This is a great answer.

> I think packaging free software even from languages that have their own
> system is valuable in a lot of ways.  First, we have a way of expressing
> dependencies that cross language boundaries well.  We have a consistent
> approach to validating licensing that seems better than a number of
> other repositories in terms of respecting the DFSG and/or more generally
> the four freedoms.

We have had a lot of discussions in Debian about language-specific
package managers, and we seem to have some heartache or something on
this topic.  Personally I have a somewhat different take.

Compared to (say) NPM or crates.io,

 * Debian has a much better answer to the problem of upstream malware
   (including the risk of random hostiles taking over packages).

 * Debian provides clear Freeness guarantees.

 * Debian provides much longer-term stability.

 * Using Debian packages means a much lower risk of random shit going
   wrong simply because the set of online services, public keys,
   etc. you are relying on is much smaller and more cohesive.

 * Debian also, sometimes serendipitously, provides a filter which
   means that if you're lucky you don't have to wade through as much
   crap to find a thing to do what you wanted.

Serious failures due to language-specific package managers - which
place far too much trust in their ill-curated or not-at-all-curated
archives - have become so common that they are not even news any more.

The worst language-specific package managers encourage really poor
practices.  Read this excellent article where someone familiar with
incident analysis and remediation tries to look at recent NPM failure
from the pov of Serious People Trying To Stop Bad Shit:
  https://www.hillelwayne.com/post/stamping-on-eventstream/

(Additionally, Debian provides a standardised format so you don't need
to learn language-specific tools and so that software from different
languages can be integrated.  Our packaging tooling makes that easy.)


So IMO the benefits of Debian are all *really valuable*.  But they are
also *work*.  Ie, those benefits are the result of the hard work of
our language-specific packaging teams.

When that work is not done, indeed, users have to fall back on random
upstream stuff.  


I am all for making it easier for language-specific packaging teams to
do their curation work.

But I don't think it is a problem *for Debian* that there are systems
which look more convenient until you discover that are a tyre fire and
now you are on fire too.  I don't think we should emulate them.


One thing that would make this a lot easier would be if we could draw
more users into this curation more easily.  Of course curation is a
task requring authority, so will have to depend on status or review.

But it would be nice if, say, after I have done my own techopolitical
review of some thing I found on crates.io, I as a DD could push some
button to say "I approve of this thing with its current
maintainership" and it would be automatically shoveled into sid.

As it is, I would have to learn a lot about not just Rust but also
Debian Rust packaging, and join the Rust packaging team, and so on.

I wouldn't mind promising to keep an eye on the updates on crates.io
and saying yay/nay to them.  Provided that saying yay or is very
simple and doesn't involve wrestling a pile of strange machinery.

In a recent project of mine that was too big a yak to add to my herd,
which means that Debian missed the opportunity to capture the value of
my review work.

I think that this problem could and therefore should be solved in a
way which generalises to multiple language-specific package managers.


> And yet people are spending a lot of time curating modules from
> languages that have their own repositories.  Yes, I'm sure this work has
> value.  I think we should do a better job of letting people know that we
> recognize the value and articulating to ourselves and our users what
> that value is.

I agree that we need to do more promotion of this aspect of Debian's
value.


Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Q to all candidates: what is the long-term role of traditional Linux distributions?

Jonathan Dowland
In reply to this post by Matthew Garrett
Thanks for asking these questions. I'm *really* interested to see how
all the candidates respond (if they do)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Re: Q to all candidates: what is the long-term role of traditional Linux distributions?

Joerg Jaspert
In reply to this post by Matthew Garrett
On 15361 March 1977, Matthew Garrett wrote:

> But upstream development is increasingly diverging from our approach.

I think that depends a bit in which area you look.

> Many new software ecosystems are based on external code repositories
> rather than relying on the distribution, and in several languages it's
> expected that a project directly include its dependencies rather than
> relying on external availability.

But those software ecosystems also need a stable base that works and
allows them to ignore those mundane basics.

> Given these upstream shifts, is attempting to package as much software
> as possible something that actually benefits Debian and our users, or is
> it something that brings us a duplication of effort?

We don't need every single possible bit of software packaged. That's
neither a useful nor an attainable goal.

We need as much groundwork packaged that you can use any of the existing
and new coming stuff in an easy, yet still secure, way. And that you can
do it on an otherwise stable platform. Which is something Debian does
provide pretty nicely (ok, except for releasing way too often and fast,
which is a major downside of us).

> If we spent time on building tooling to automatically identify that
> (say) installed Go applications that contain dependencies with
> security vulnerabilities and alert users, would that be time better
> spent than independendly packaging and maintaining those dependencies
> ourselves?

It may be. As I wrote elsewhere I imagine a Debian that has a Magic
Archive (Hey, I got a free magic card there) and is *THE* answer to
everything package related, so that anyone in any language environment
(nodejs? ruby? python? perl? java? haskell? whatever) who ever goes "And
now, how do my users get the crap I wrote?" goes "OH, sure, Debian, I
just fill out this $somethingseomething and any user anywhere can
*easily* get at it, perfectly integrated in their system with all
dependencies magically resolved".

Lucky, for me, even with the magic card, I have been vague enough that
it fits even here. I do want Debian to be the platform chosen to build
other stuff upon. In whichever environment the people building are. Go,
Ruby, NodeJS, whatever. A startup that scales up tons of containers and
throws them away even faster than their humans. A big business that
thinks a new released Linux Distribution every 10 years is the best.
Someting in between that can deal with 5 years. Users at home that have
featuritis and can't wait for the next tiny dot version to finally
install.

Now, packaging it all is an effort we really can't sustain. And it
really doesn't make sense to have packages where the metadata is larger
than the code. So yes, better tooling will be part of the answer.

Our advantage, and something that we should try to keep and extend on is
our unification and consistency. Say, I want a perl module Foo::Bar, I
get it with one command and a predictable name and location and general
behaviour. Want a golang something module (just assume its packaged), I
get it with the same command and a predictable name. And so on.[1]

> Are our current priorities the best way to serve the free software
> community over the next 10 years?

No idea how the world will look in 10 years, but if we keep the users as
part of our priority, and adapt according to their needs, we shouldn't
be far off. And yeah, now someone asks to define users, especially with
what I wrote some lines up.

> Would we be better off focusing Debian as a high-quality base for
> users who then largely consume software from other sources?

I think we should not have just one focus and concentrate on that alone.
We should have multiple and continue to try to weight them against each
other as good as possible.


Footnotes:
[1] Sure, right now this requires the "needs to be packaged" part.

--
bye, Joerg

Reply | Threaded
Open this post in threaded view
|

Re: Q to all candidates: what is the long-term role of traditional Linux distributions?

Raphael Hertzog-3
In reply to this post by Matthew Garrett
Hi,

I'm not a candidate but the topic resonates with me and I want to share my
thoughts also because I am in the position to do or fund some work related
to all this.

In Kali, we have software that are close to impossible to package because
they have plenty of dependencies and sometimes even require specific
(non-current) versions of said dependencies. For ruby applications, we
tend to package them crudely by embedding a "bundle" of all the
dependencies but that's not very nice. Some applications are also poorly
coded and we want to avoid side-effects on the system or other
applications due to bad behaviour of some application executed as root.

Our current idea is to try to deliver such applications in containers
that would be installed in the (host) Kali system and managed from there
as well.

On Tue, 02 Apr 2019, Matthew Garrett wrote:
> Given these upstream shifts, is attempting to package as much software
> as possible something that actually benefits Debian and our users, or is
> it something that brings us a duplication of effort?

We definitely add value when we package something. But we should embrace
the change in the ways to deliver software... when it's not possible to
package something cleanly, we should still make it possible for us to
deliver said software to the user, e.g. as a containerized application (but
maybe others have better ideas of how to deliver hard to package
applications).

Instead of maintaining the source package, we will maintain the rules to
build the container from the real packages (for the base system) and from
the upstream sources (for the application) and from third-party
language-specific package managers (for dependencies).

Exactly like we did for packages, we would build an ecosystem around those
containerized applications including policies, common rules, linters, etc.

A containerized application would still be integrated on the host system
(e.g. the application would show up in the menus, etc.) and we would
provide the glue required to upgrade those apps over time (e.g. dump the data
from the old container, import them into the new container).

> If we spent time on
> building tooling to automatically identify that (say) installed Go
> applications that contain dependencies with security vulnerabilities and
> alert users, would that be time better spent than independendly
> packaging and maintaining those dependencies ourselves?

Packaging and maintaining the dependencies has value. But it's not always
possible to use those packaged versions and in that case, it would be nice
if we could let users know of the vulnerabilities that they are exposed to
by using some outdated software in their containerized applications. We
have most of the data in the security tracker already. It would require
some supplementary work but it's clearly something achievable.

> Are our current priorities the best way to serve the free software
> community over the next 10 years? Would we be better off focusing Debian
> as a high-quality base for users who then largely consume software from
> other sources?

I'm not sure that we have "priorities". But we have grown around the
central role of package maintainers and that's what most contributors are
currently familiar with. And I'm not sure that we have to trade being a
good base against maintaining many packages, we should be able to do both.

But I would definitely love to make Debian the base used by all upstreams
when they decide to ship their application as a flatpak or as a snap. And
they would do so because we have all the building blocks readily
available, nice tooling to make this easy, good documentation to help
them, etc.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Reply | Threaded
Open this post in threaded view
|

Re: Q to all candidates: what is the long-term role of traditional Linux distributions?

Martin Michlmayr
In reply to this post by Matthew Garrett
* Matthew Garrett <[hidden email]> [2019-04-02 23:22]:
> But upstream development is increasingly diverging from our approach.
...

You do a great job of explaining how upstream and the world around us
has changed in many ways.

While I'm not sure that all changes have been for the best, it's
important to recognize that things have changed and to ask what the
role of a distribution should be in today's world.  Can we still
provide value by sitting inbetween developer and user, or are we just
adding a delay without any benefits?

> Given these upstream shifts, is attempting to package as much
> software as possible something that actually benefits Debian and our
> users, or is it something that brings us a duplication of effort?

Clearly there is some benefit, but increasingly we're also adding
friction.  Maybe we can do more work upstream directly, and also find
ways to get things into Debian more quickly.

> If we spent time on building tooling to automatically identify that
> (say) installed Go applications that contain dependencies with
> security vulnerabilities and alert users

That would certainly be worthwhile in any case.

> Are our current priorities the best way to serve the free software
> community over the next 10 years? Would we be better off focusing
> Debian as a high-quality base for users who then largely consume
> software from other sources?

I don't know the answers, but these are *exactly* the kind of
questions that we, as a community (and together with other
distributions), have to ask and find answers for.

As DPL, I would facilitate discussion about Debian's role in today's
world and empower people like you to lead such discussions and to ask
how we can successfully adapt.

--
Martin Michlmayr
https://www.cyrius.com/

Reply | Threaded
Open this post in threaded view
|

Re: Q to all candidates: what is the long-term role of traditional Linux distributions?

Martin Michlmayr
In reply to this post by Jose Miguel Parrella
* Jose Miguel Parrella <[hidden email]> [2019-04-02 19:24]:
> How do you think motivations and incentives have changed, are
> changing or will change for contributors to Debian in a world where
> distros no longer mean what they used to?

If we can answer questions like those Matthew raised and figure out
what the role of a distro should be and where we can actually add
value and position ourselves in this changing world, the motivation
and incentives to contribute will return.

> If tools, policies and/or processes weren't a source of frustration
> for contributors, do you think they would still disengage from the
> project because they want to package software/be the subject matter
> expert for said software?

I think a lot of it is that we're not seen to solve exciting problems.
How can we start solving exciting problems that exist today?  It's not
as if everything has been solved.

> Do you think Debian should focus more on the derivatives as users
> rather than individual end users only? And if so, connecting to the
> first Q, how would you manage new people being attracted to the
> project and some current contributors feeling de-energized about it?

In my opinion, there's a lot of value in focusing on end-users.  While
derivatives are important for Debian, Debian itself should be
attractive for many as an OS and not just as building blocks for
other solutions.

--
Martin Michlmayr
https://www.cyrius.com/