Ah, so you didn't install Ardour from the Ubuntu packages, but from another source? (Direct download from their site?) If you can confirm that, I'll give it a try with whatever Ardour installation source you're working with.carlv wrote: We get this:
bash: /usr/lib/ardour5/ardour-vst-scanner: No such file or directory
Sitala drum plugin
Moderators: MattKingUSA, khz
-
- Established Member
- Posts: 24
- Joined: Mon Dec 17, 2018 4:26 am
- Location: Berlin
- Contact:
Re: Sitala drum plugin
-
- Established Member
- Posts: 278
- Joined: Tue Jul 12, 2016 6:10 pm
- Has thanked: 32 times
- Been thanked: 38 times
Re: Sitala drum plugin
KXStudio repos., so as sysrqer points out the ardour-vst-scanner resides here for me: /opt/ardour/lib/ardour-vst-scanner.scottwheeler wrote:Ah, so you didn't install Ardour from the Ubuntu packages, but from another source? (Direct download from their site?) If you can confirm that, I'll give it a try with whatever Ardour installation source you're working with.
I re-wrote your code, hopefully correctly to reflect (LD_LIBRARY_PATH=/opt/ardour/lib /opt/ardour/lib/ardour-vst-scanner -f /usr/lib/lxvst/libsitala.so ) ran and got back...
LD_LIBRARY_PATH=/opt/ardour/lib /opt/ardour/lib/ardour-vst-scanner -f /usr/lib/lxvst/libsitala.so
[ERROR]: Could not open existing LXVST plugin: /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37: undefined symbol: g_output_stream_write_all_async
[WARNING]: Cannot get LinuxVST information from '/usr/lib/lxvst/libsitala.so': load failed.
- lilith
- Established Member
- Posts: 1698
- Joined: Fri May 27, 2016 11:41 pm
- Location: bLACK fOREST
- Has thanked: 117 times
- Been thanked: 57 times
- Contact:
Re: Sitala drum plugin
Thanks for supporting linux anyway and thanks for fast reply to my email .scottwheeler wrote:Hi - this is Scott, one of the guys from Decomposer that make Sitala (and I'm the one that did the Linux package).
Sitala's always worked on Linux, but packaging / testing for Linux is complex relative to other platforms simply because there are so many different Linuxes one can target. That's why for now we just released a package for the most recent Ubuntu LTS, since that had up to now been the most requested distribution.
It's possible we'll include other Linux distributions at some point down the line. Mostly it depends on how much uptake we see on Linux in general. Right now packaging for just one Linux distribution is approximately as complicated as packaging for macOS or Windows, but as of today, our Linux package has a whopping ... 23 users (compared to hundreds on the other two platforms). Shipping for a large set of distros is unlikely unless those ratios change significantly.
-
- Established Member
- Posts: 24
- Joined: Mon Dec 17, 2018 4:26 am
- Location: Berlin
- Contact:
Re: Sitala drum plugin
Hmm, as far as I can tell, Ardour isn't actually contained in the KXStudio repos (which I didn't realize until I got them set up and reinstalled ardour just to see it was being pulled from the same standard Ubuntu location). If it was there, it would show up in this file, I believe:carlv wrote: KXStudio repos., so as sysrqer points out the ardour-vst-scanner resides here for me: /opt/ardour/lib/ardour-vst-scanner.
http://ppa.launchpad.net/kxstudio-debia ... ackages.gz
-
- Established Member
- Posts: 278
- Joined: Tue Jul 12, 2016 6:10 pm
- Has thanked: 32 times
- Been thanked: 38 times
Re: Sitala drum plugin
I picked it up from here http://kxstudio.linuxaudio.org/Reposito ... plications back around 2016 or there about. It works, so haven't thought about it much since. Can't help in that regard much beyond that, unfortunately.scottwheeler wrote:Hmm, as far as I can tell, Ardour isn't actually contained in the KXStudio repos (which I didn't realize until I got them set up and reinstalled ardour just to see it was being pulled from the same standard Ubuntu location). If it was there, it would show up in this file, I believe:carlv wrote: KXStudio repos., so as sysrqer points out the ardour-vst-scanner resides here for me: /opt/ardour/lib/ardour-vst-scanner.
http://ppa.launchpad.net/kxstudio-debia ... ackages.gz
Thanks and happy sleuthing.
-
- Established Member
- Posts: 24
- Joined: Mon Dec 17, 2018 4:26 am
- Location: Berlin
- Contact:
Re: Sitala drum plugin
So, as I said, LXStudio doesn't actually ship Ardour anymore. I decided, however, to try the direct download from the Ardour page, and I did get the same error as you're getting. So I'll assume that the LXStudio packagers were just packaging the binary from the Ardour download page.carlv wrote: I picked it up from here http://kxstudio.linuxaudio.org/Reposito ... plications back around 2016 or there about. It works, so haven't thought about it much since. Can't help in that regard much beyond that, unfortunately.
The problem is this: that package contains old copies of a lot of system libraries and overrides the default system libraries with those old versions, and forces those overrides on any plugins that it loads. Sitala (and anything built with a current version of JUCE, an audio app framework -- I found other instances here in the forum of people hitting similar issues with other plugins) expects those libraries to be the current system libraries. This is pretty bad packaging practice from Ardour.
Fortunately, the version available from their website isn't any more current than the version available from the default Ubuntu repositories (that you'd get with standard `apt install ardour`), and the Ubuntu packages are created correctly, so there's really no good reason to continue to use the things from Ardour's site.
-
- Established Member
- Posts: 24
- Joined: Mon Dec 17, 2018 4:26 am
- Location: Berlin
- Contact:
Re: Sitala drum plugin
I'm not entirely sure that I would recommend this (since I don't know what assumptions Ardour makes about the old libraries), but just doing this makes things work for me:
After that Ardour runs fine, and loads Sitala without problems.
Basically that removes Ardour's overrides of the relevant system libraries (but still leaves many other ones in place -- again, their packaging process is very questionable), and gets things working for Sitala.
Code: Select all
cd /opt/Ardour-5.12.0/lib
mkdir old
mv libgio-2.0.so.0 libglib-2.0.so.0 libgobject-2.0.so.0 libharfbuzz.so.0 old/
Basically that removes Ardour's overrides of the relevant system libraries (but still leaves many other ones in place -- again, their packaging process is very questionable), and gets things working for Sitala.
-
- Established Member
- Posts: 168
- Joined: Sun Jun 07, 2015 2:15 am
- Has thanked: 9 times
- Been thanked: 28 times
Re: Sitala drum plugin
I don't think Ardour's packaging is bad or questionable, just different in its purpose. The binaries from ardour.org aim to be distro-agnostic with the expectation that plugins be distro-agnostic as well. You have chosen to package your plugin to be distro-specific, which means it will be compatible with the Ubuntu-packaged version of Ardour but perhaps not the official binary. Each approach has its justifications. However, I think you would reach more users if you packaged it for Debian Stable instead of Ubuntu 18.04. AFAIK, a *.deb file that installs properly on Debian Stable will also install on Ubuntu 18.04 along with numerous other distros. Someone should correct me if I am wrong about that.
Thank you for the plugin and your efforts to make it available for Linux users.
Thank you for the plugin and your efforts to make it available for Linux users.
-
- Established Member
- Posts: 24
- Joined: Mon Dec 17, 2018 4:26 am
- Location: Berlin
- Contact:
Re: Sitala drum plugin
It would be a little ugly, but understandable if they were shipping an application which does not load third party plugins. Then the worst that would happen is that that application wouldn't get security updates and bug fixes that were fixed in later versions of the libs it uses. But doing that for something which loads plugins is genuinely crappy.GuntherT wrote:I don't think Ardour's packaging is bad or questionable, just different in its purpose. The binaries from ardour.org aim to be distro-agnostic with the expectation that plugins be distro-agnostic as well.
Their binary isn't system agnostic because it targets older, more compatible versions of things. It's system agnostic because they ship (old, but only because their binary package is a couple years old) versions of every single library that they use. To create plugins that would be reliably loaded with those versions, they'd need to ship an SDK that you could build your plugins against, but then they wouldn't be guaranteed to work with other applications on the system. Effectively Ardour is a mini-distro.
I'm calling it "crappy" because I don't think it's reasonable to force third parties to package and test things against their mini-distro rather than the system provided and updated libraries.
You are wrong about that:However, I think you would reach more users if you packaged it for Debian Stable instead of Ubuntu 18.04. AFAIK, a *.deb file that installs properly on Debian Stable will also install on Ubuntu 18.04 along with numerous other distros. Someone should correct me if I am wrong about that.
https://unix.stackexchange.com/question ... ith-debian
It's possible that coincidentally a Debian Stable package of Sitala would work with Ubuntu 18.04, but there are no guarantees of such. Nevertheless, since in theory we have a deb packaging script that I think should work on Debian too, I'm curious enough that I'm doing a VirtualBox install of Debian Stable now to try it out.
- Linuxmusician01
- Established Member
- Posts: 1542
- Joined: Mon Feb 23, 2015 2:38 pm
- Location: Holland
- Has thanked: 773 times
- Been thanked: 142 times
Re: Sitala drum plugin
With all do respect. I'm not a developer/programmer: I know very little about it and have no experience with it. First of all I would like to thank @ScottWheeler very, very much for taking Linux seriously and porting his plugin to Linux. You're the greatest man.
In the old days (say, around 2005) I still used Windows. A friend of mine is a software developer and in his free time he made a program that manages virtual football teams for a game he played with friends. He'd sometimes ask me to install this program to test it and to show the progress he made. This program would on occasion not install on my Windows version because it would need libraries specific to the development stuff that he used. I constantly had to download and install new .net stuff or something like that. My developer friend hated that because the guys he made the software for weren't keen on installing all sorts of extra stuff for the football app. Some didn't even know how to do that.
Now what's the point of the story above? Not dependency hell. I think we're past that in Linux. Again, I don't know nothing 'bout developing software so I could be offending people here which is not my intention. I just look at things from a user perspective. The point is that some software development kits (that's what you call it, right?) support specific configurations of a system for which the software is intended. That's where the problem lies in my opinion. Systems like Windows and MacOS are - again: I ain't no professional - sort of "frozen in time" and very "predictable". They should be, and can be, very easy to make software for. Just like Android and iOS: almost all apps are compatible w/ each phone and backwards compatible w/ old ones.
But just like the .net application that my friend built back in the day, a lot of Linux software that one can download from the internet (rather than from the standard repo from your distro) is extremely hungry for the latest and greatest libraries. And as a user you get the sneakin' suspicion that for a simple little app like a football manager or a drum kit emulator/VST that's not necessary.
As a simple end-user it comes across like this: to simple little old me it looks as though development kit makers do not care about me as a user, they don't spend any time on assessing which versions of a library their stuff is really dependent. As a user I get the impression that the software in question does not rely on the new and improved things that new libraries offer. So they might as well be linked to older versions of the libs.
So why don't they? Software that depends on old libs work with the newest versions, but not the other way around...
I know that there probably is a good reason that dev kits (if that is what one calls it) are dependent of the latest stuff and even if you support old libs then the question is: how far back in time should you go with support? Ten years? One year?
Fact of the matter is that the latest version of MS Word probably still works on Windows XP. But a drum plugin won't work on a Linux distro that is a few years old. Or it won't work because of the reasons explained here concerning the packaging of Ardour.
I consider this to be one of the reasons people wont switch to Linux. I personally don't mind that much anymore because I don't care for the latest and greatest versions of applications: a version that is a few years old is good enough for me. I probably won't notice the "new" additions anyway.
It appears to me (like stated more then once: from the targeted users perspective, I ain't no pro) that in this case there's a problem w/ hard linking to old libs by one app (Ardour) and dependency on a specific distro and specific libs of a second app (Sitala). Reminds me of the .net problem my friend had...
Why are dev kits so hungry on new libs? If they weren't we wouldn't have the problems w/ Sitala (it would have worked w/ the libs that Ardour wants to use etc.).
Sorry, had to get that off my chest.
In the old days (say, around 2005) I still used Windows. A friend of mine is a software developer and in his free time he made a program that manages virtual football teams for a game he played with friends. He'd sometimes ask me to install this program to test it and to show the progress he made. This program would on occasion not install on my Windows version because it would need libraries specific to the development stuff that he used. I constantly had to download and install new .net stuff or something like that. My developer friend hated that because the guys he made the software for weren't keen on installing all sorts of extra stuff for the football app. Some didn't even know how to do that.
Now what's the point of the story above? Not dependency hell. I think we're past that in Linux. Again, I don't know nothing 'bout developing software so I could be offending people here which is not my intention. I just look at things from a user perspective. The point is that some software development kits (that's what you call it, right?) support specific configurations of a system for which the software is intended. That's where the problem lies in my opinion. Systems like Windows and MacOS are - again: I ain't no professional - sort of "frozen in time" and very "predictable". They should be, and can be, very easy to make software for. Just like Android and iOS: almost all apps are compatible w/ each phone and backwards compatible w/ old ones.
But just like the .net application that my friend built back in the day, a lot of Linux software that one can download from the internet (rather than from the standard repo from your distro) is extremely hungry for the latest and greatest libraries. And as a user you get the sneakin' suspicion that for a simple little app like a football manager or a drum kit emulator/VST that's not necessary.
As a simple end-user it comes across like this: to simple little old me it looks as though development kit makers do not care about me as a user, they don't spend any time on assessing which versions of a library their stuff is really dependent. As a user I get the impression that the software in question does not rely on the new and improved things that new libraries offer. So they might as well be linked to older versions of the libs.
So why don't they? Software that depends on old libs work with the newest versions, but not the other way around...
I know that there probably is a good reason that dev kits (if that is what one calls it) are dependent of the latest stuff and even if you support old libs then the question is: how far back in time should you go with support? Ten years? One year?
Fact of the matter is that the latest version of MS Word probably still works on Windows XP. But a drum plugin won't work on a Linux distro that is a few years old. Or it won't work because of the reasons explained here concerning the packaging of Ardour.
I consider this to be one of the reasons people wont switch to Linux. I personally don't mind that much anymore because I don't care for the latest and greatest versions of applications: a version that is a few years old is good enough for me. I probably won't notice the "new" additions anyway.
It appears to me (like stated more then once: from the targeted users perspective, I ain't no pro) that in this case there's a problem w/ hard linking to old libs by one app (Ardour) and dependency on a specific distro and specific libs of a second app (Sitala). Reminds me of the .net problem my friend had...
Why are dev kits so hungry on new libs? If they weren't we wouldn't have the problems w/ Sitala (it would have worked w/ the libs that Ardour wants to use etc.).
Sorry, had to get that off my chest.
- davephillips
- Established Member
- Posts: 592
- Joined: Sat Aug 15, 2015 1:05 pm
- Has thanked: 35 times
- Been thanked: 23 times
Re: Sitala drum plugin
Greetings,
I think that technical and non-technical users have missed the actual fact of what's happening. Like other distros Ubuntu uses libraries with versioned symbols, so if you try to run a binary-built-on-Ubuntu that requires versioned symbols later than your system supports, you are out of luck unless 1) you update your entire system or 2) you can update only the required libraries or 3) you know how to use LD_LIBRARY_PATH and can point the binary to a location with the required libs or 4) you can convince the developer to stop using versioned libraries, which would probably mean not using Ubuntu as a development environment, which given its popularity is not likely to happen.
Or 5) you can build it yourself from the source code. The resulting binary will then require whatever system versions it was built with, but at least it'll run on your local system. Alas, AFAICT the source for Sitala is not freely available.
Here's why Sitala won't run on my ancient Fedora 23 system. This is what it wants :
These are the GLIBC versions supported by my /usr/lib64/libm.so.6 :
Some background about versioning:
http://harmful.cat-v.org/software/dynam ... ed-symbols
Best regards,
dp
I think that technical and non-technical users have missed the actual fact of what's happening. Like other distros Ubuntu uses libraries with versioned symbols, so if you try to run a binary-built-on-Ubuntu that requires versioned symbols later than your system supports, you are out of luck unless 1) you update your entire system or 2) you can update only the required libraries or 3) you know how to use LD_LIBRARY_PATH and can point the binary to a location with the required libs or 4) you can convince the developer to stop using versioned libraries, which would probably mean not using Ubuntu as a development environment, which given its popularity is not likely to happen.
Or 5) you can build it yourself from the source code. The resulting binary will then require whatever system versions it was built with, but at least it'll run on your local system. Alas, AFAICT the source for Sitala is not freely available.
Here's why Sitala won't run on my ancient Fedora 23 system. This is what it wants :
Code: Select all
$ ldd sitala
./sitala: /lib64/libcurl-gnutls.so.4: no version information available (required by ./sitala)
./sitala: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by ./sitala)
...
Code: Select all
$ nm libm.so.6 | grep GLIBC
...
0000000000000000 A GLIBC_2.15
0000000000000000 A GLIBC_2.18
0000000000000000 A GLIBC_2.2.5
0000000000000000 A GLIBC_2.4
...
http://harmful.cat-v.org/software/dynam ... ed-symbols
Best regards,
dp
- raboof
- Established Member
- Posts: 1855
- Joined: Tue Apr 08, 2008 11:58 am
- Location: Deventer, NL
- Has thanked: 50 times
- Been thanked: 74 times
- Contact:
Re: Sitala drum plugin
Seconded .Linuxmusician01 wrote:With all do respect. I'm not a developer/programmer: I know very little about it and have no experience with it. First of all I would like to thank @ScottWheeler very, very much for taking Linux seriously and porting his plugin to Linux. You're the greatest man.
Thanks for spelling this out .Linuxmusician01 wrote:I don't know nothing 'bout developing software so I could be offending people here which is not my intention.
On linux, there isn't really a 'software development kit' in the way you describe - you just install the 'development files' of the libraries you want to program against, which typically are packaged in your distro's package manager.Linuxmusician01 wrote:The point is that some software development kits (that's what you call it, right?) support specific configurations of a system for which the software is intended
It is certainly not about 'not caring about the user': when publishing open source software, while most of the time the maintainer is also a user of the software, doing it 'just for yourself' is not really worth it. So putting in all the work needed to publish the software is certainly a testament that open source developers certainly care about their users. Commercial developers of course also tend to care about their customers.Linuxmusician01 wrote:As a simple end-user it comes across like this: to simple little old me it looks as though development kit makers do not care about me as a user
As I noted above, as a developer the easiest thing to do is just to build against whatever version is packaged with the distribution I am using during development. Building against specific versions is possible but cumbersome. Testing that the code also works with older versions of those libraries is possible, but "going an extra mile".Linuxmusician01 wrote:They don't spend any time on assessing which versions of a library their stuff is really dependent. As a user I get the impression that the software in question does not rely on the new and improved things that new libraries offer. So they might as well be linked to older versions of the libs. So why don't they?
Unfortunately, this is not true: this is called 'keeping backwards compatibility', so software that depends on old libraries will also work with newer versions. To split hairs, this has 2 parts: 'binary backwards compatibility' (making sure projects written for an older version can link to a newer version) and 'source backwards compatibility' (making sure projects written for an older version can compile against a newer version).Linuxmusician01 wrote:Software that depends on old libs work with the newest versions, but not the other way around...
The thing is, this is very hard - both in the sense that it takes a lot of effort, and that it is easy to get wrong.
This is part of the reason Ardour, when taken from the homepage, ships with its own version of the libraries instead of relying on the versions installed on your system. This has the advantage Ardour is not affected by compatibility problems when running on a system with unpredictable versions of those libraries. It has the disadvantage that any plugins loaded into Ardour also 'inherit' those versions of the libraries, making the plugins fail even when they were built for the libraries that ship with your distribution...
Actually you'll need Windows 7 (https://products.office.com/en-US/buy/office), but your point stands, that's also 9 years ago.Linuxmusician01 wrote:Fact of the matter is that the latest version of MS Word probably still works on Windows XP.
One thing to remember here is a plugin is a little more complicated than an application: because plugins loaded into Ardour 'inherit' the versions of the libraries shipping with Ardour, things are more complicated.Linuxmusician01 wrote:But a drum plugin won't work on a Linux distro that is a few years old.
For popular open source software, of course it is likely that this has been solved by the distribution: part of packaging is making sure a version of the software is built which works together with the versions of the libraries available in the distribution.Linuxmusician01 wrote:I consider this to be one of the reasons people wont switch to Linux. I personally don't mind that much anymore because I don't care for the latest and greatest versions of applications: a version that is a few years old is good enough for me. I probably won't notice the "new" additions anyway.
For obscure open source software, it might run, if any libraries it uses are either included (like with Ardour) or compatible with the versions on your system. If it doesn't, then you can try and build the project from source - perhaps making some adjustments to make it build against more modern versions of libraries. Building from source can be tricky, sometimes out of reach for 'regular users' - but it great that it is possible at all.
For proprietary software distributed as binaries, they are in a bit of a pickle: since the distributions won't take care of building their software, they must themselves make sure to build their software against libraries commonly found in distributions. That can be quite a challenge.
One commonly applied technique to distribute binaries that work across a number of Linuxes, already mentioned by Scott above, is by linking them statically. He is right to be careful about licensing pitfalls in this case, however: the same rules may not apply for static and dynamic linking.
Scott: I wonder if that interpretation might not be too strict: indeed the LGPL allows static linking as long as you "also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application" (https://www.gnu.org/licenses/gpl-faq.ht ... cVsDynamic). If you make sure you (also) ship your plugin in object format, it seems to me like that would be sufficient - it is not necessary to also ship the object files of the libraries you depend on, as the user can obtain/build those themselves.scottwheeler wrote:in most cases using static linkage violates the licenses of the libraries that they're using (unless they're also shipping object files to allow the application to be re-linked, which I've never seen happen).
More generally, I think the problem is that different applications are sharing the same libraries. If one application could use one set of versions of libraries and another application could use another, that would already help a lot. There have been some packaging approaches (such as the previously discussed Flatpak) that promote this idea, but I don't think any of those ever really became popular.Linuxmusician01 wrote:It appears to me (like stated more then once: from the targeted users perspective, I ain't no pro) that in this case there's a problem w/ hard linking to old libs by one app (Ardour) and dependency on a specific distro and specific libs of a second app (Sitala).
For plug-ins the problem is even more tricky. Treating plugins more like individual applications would help here, but it seems that isn't how VST works.
It would be interesting to know whether and, if so, how this is solved on Windows. They certainly used to suffer from that same problem ('DLL Hell'), but I haven't kept up. I suspect they either package libraries with their applications (Ardour-style) or link statically. Someone with more Windows experience should confirm, though.Linuxmusician01 wrote:Reminds me of the .net problem my friend had...
I hope the (slightly rambling) explanations above help understand some of the issues. As said, static linking of Sitala might already help a lot (though probably not with libc versions), and might not be as problematic license-wise as was suggested earlier.Linuxmusician01 wrote:Why are dev kits so hungry on new libs? If they weren't we wouldn't have the problems w/ Sitala (it would have worked w/ the libs that Ardour wants to use etc.).
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Re: Sitala drum plugin
@scottwheeler @raboof @all
Would it be helpful to create extra threads in the Developer's Section?
To exchange among developers about such topics as for example:
- What are the possibilities to develop software under linux (for example: dependency problems (libs) / ...)
- Advantages and disadvantages
- Software license GNU GPL
- Distribution of software / Updates / ...
- ...
That would be a help for all (future) developers to grasp and discuss such basic topics and thereby gain clarity(s) or discuss optimal way(s)?
Would it be helpful to create extra threads in the Developer's Section?
To exchange among developers about such topics as for example:
- What are the possibilities to develop software under linux (for example: dependency problems (libs) / ...)
- Advantages and disadvantages
- Software license GNU GPL
- Distribution of software / Updates / ...
- ...
That would be a help for all (future) developers to grasp and discuss such basic topics and thereby gain clarity(s) or discuss optimal way(s)?
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
- raboof
- Established Member
- Posts: 1855
- Joined: Tue Apr 08, 2008 11:58 am
- Location: Deventer, NL
- Has thanked: 50 times
- Been thanked: 74 times
- Contact:
Re: Sitala drum plugin
I think forum threads are not great for long-term knowledge storage, the wiki might be better for that.khz wrote:Would it be helpful to create extra threads in the Developer's Section?
That would be a help for all (future) developers to grasp and discuss such basic topics and thereby gain clarity(s) or discuss optimal way(s)?
If anyone wants to discuss these topics then by all means open threads there of course - and ideally summarize findings in a more long-term place .