Overall, everything works pretty well for me (user for multiple years), except all apps which are too bound too Google Play Services as microG is not stubbing/implementing all APIs.
So all apps with premium subscription you can only handle through in-app purchase, usually won't work.
I've heard that some banking apps are not working correctly either as not "secured" enough device, in my personal experience, they all worked, it's really a case-by-case logics here.
For the upgrade, OTA upgrade around every month, and it has always worked smoothly
Something I have been wondering with Flatpak is about Ram usage. As sharing dynamic libraries allow loading it into RAM only once, while if I use Signal, Chromium and different others Flatpaks, all libs will be loaded multiple times (often with their own version). So maybe disk is cheap but RAM may be more limited, which looks kind of a limit in the generalization of this method of distribution. (You could tell me it's the same with containers)
Am I right to think that? Has someone measured that difference on their workstation?
Interesting not really, someone in my family made some research about its past and return to the XVIIth century. From there, we can only make assumptions.
Currently, we are running multiple containers from different apps on the same host. These containers are running with unprivileged users and reduced capabilities but in the same network. It will probably change in the future for a higher level of isolation.
Remind me "The Three Stigmata of Palmer Eldritch" from Philip K. Dick. Selected (clever) people are sent as settlers on Mars, but everybody know it's crappy as hell and that people are surviving thanks to drugs which allow them to remind theirselves what Earth's like. People try to get crazy on Earth to fail tests and avoid being sent there.
Docker stats is not a solution since you can't configure it, it's a good effort but is not sufficient. Docker stats over hundredths of containers generates too much load, you can't configure anything. An external project is welcomed to fulfill this lack.
I don't want to say anything wrong on this and I don't have the knowledge on this, but it's possible than the OS is doing a lot of work on this to avoid cutting connections. Do you have any details on this?
That's because when you connect to your SSH, it forked and there is one process which is handling your connection, then when you restart the daemon, it only restarts the master, no harm done to the existing connections.
The less I rely on the operating system environment, the best it is. Go provides static binaries, easy to deploy. I don't want to get hooked to systemd. (even more if my server can handle the use case with a few lines of code.)
You're right, but in some cases, for example a 'git push' to deploy an application, we don't want the SSH connection to be cut when upgrading our SSH server, this is not an option. If the server crashes the current connections will be lost, but it should be the only scenario when this occures.
1. When the parent process has finished handling its connections, it just exits. The children are then considered as 'orphans' and are automatically attached to the init process. When you run your service as a daemon, that's exactly what you want, so you don't have a huge stack of processes.
2. I used syscall.ForkExec(os.Args[0], os.Args […]), but I could changed the string array os.Args by anything I want to change the arguments.
3. It could be a way to do it, it would also work, but it is not the choice we have done.
4. It may look a bit weird, but it's part of the language, you get used to it really quickly ;-)
Actually, we are not only using this for HTTP services, but also for our SSH server (the one I've introduced last week). This method was mandatory for us!
The 'manners' package only enables graceful shutdown in a HTTP server, there is still work to be done to restart it gracefully, that's what I'm trying to show in the article.
By sensitive data, we meant part of the identity of all our users (there is quite often user@host at the end of the public keys sent by our users), and the second point is linked to the internal commands.
In the `command="ssh-handler" ssh-rsa....` the command doesn't receive the SSH public key as argument, so we would have to provide additional information like:
`command="ssh-handler <user_id|username|key_id>" ssh-rsa....`
So yes, if we have a way to avoid having a copy of that on all our servers able to authenticate users, we take it!
So all apps with premium subscription you can only handle through in-app purchase, usually won't work.
I've heard that some banking apps are not working correctly either as not "secured" enough device, in my personal experience, they all worked, it's really a case-by-case logics here.
For the upgrade, OTA upgrade around every month, and it has always worked smoothly