Or as an alternative DPF https://github.com/DISTRHO/DPF which at least supports JACK and LV2 (the pull request for it for JUCE has gone unmerged for years :( and no additional license restrictions
First of all, thanks for getting in touch with your users!
Hope you'll be able to extrapolate some useful info from it :)
My basic suggestion would be to keep it simple, so stay with the GNOME apps where you can.
Also it might make sense to make a distinction between what people feel is a good choice of software and which of those should be included in the default install.
IMHO stuff like and IDE, e-mail client, IRC client, messaging client, office suite and screen recording don't have to be included in the default install as long as it's easy enough for everyone to add them later (or customize during install).
Regarding specific items:
- Terminal: gnome-terminal, but if possible look into make the tabs a bit less tall and fix the search dialog so it can be closed by pressing escape
- File manager/photo viewer: nautilus, but look into fixing the preview (spacebar) so that it allows opening the preview window once and then allow navigating through all files in the chosen directory using the arrow keys
- Calendar: gnome-calender, but make sure you use gnome 3.24 or later so it support dark mode
- Screenshots: gnome-screenshot, but please fix it so it's possible to take multiple screenshots in succession. Right one has to close and open it to do so.
- Video player: Technically mpv, maybe with the gnome-mpv GUI. Though mpv might be too difficult to use for some users?
- Music player: Imho none of them is really good enough :( Elementary's noise might be at some point
Hmm that's a pity even though it shouldn't come as a surprise for anyone who's actively using/involved with fleet.
I like the simplicity and flexibility of fleet (basically distributed SystemD) a lot. Don't necessarily want to switch to a bigger scheduler like Kubernetes. Anyone have any suggestions for/experiences with an alternative simpler scheduler (like Nomad or an alternative solution like the autopilot stuff from Joyent)?
We are considering switching to the normal logstash-output-es plugin together with a AWS v4 auth signing proxy to make the setup more portable/less tied to AWS.
I have a basic signing proxy setup working based on nginx/openresty. If you're interested just let me know.
We ran into the access control limitations as well. They are caused by the fact that for some reason AWS ES only supports resource based policies which is imho the wrong way around to manage your policies.
We did get it to work in a useable manner by having the ES policy apply to a role (i.e. the principal is a role).
If you than apply that role to your instances it will work for with instance profile based auth.
Even though using Alpine as the base image for a container is a lot beter/cleaner than other base image imho we shouldn't rely on distro package management inside containers.
Not only does running a package manager inside the container mean you'll need to satisfy its dependencies in your image you also increase the image's attack surface compared to an image without a package manager.
Ideally we'd have a simple way of installing stuff into images from the outside so you can always start `FROM scratch` and add the minimum deps you need to run your app.
Adding stuff could be as simple as extracting tars with the tar's contents following the Filesystem Hierarchy Standard. Each tar could be a layer so it matches well with how Docker images work as well.
Since it isn't possible to extend the Dockerfile syntax I started prototyping a static binary written in Go to add to `scratch` to do this. It worked better than I expected :)
Only thing I couldn't find was a distro that packaged it's packages this way and it would obviously suck to create another packaging standard.
But still, I see no reason to use it over LV2 or even LADSPA.