Recent comments on posts in the blog:
Just in case you encounter the same problem when setting up Debian 9.
After setting up everything based on this guide, which I used since wheezy, thanks for that by the way :), I noticed that my server wasn't coming back online after rebooting.
Problem: eth0 doesn't exist anymore... so no network if I setup a non-existing nic.
Solution: Either disable the new naming schema in GRUB_CMDLINE_LINUX="net.ifnames=0" or check your predictable device name by running udev and look for eth0 (since the rescue system is still a debian 8 based OS). I just dumped it to a file then searched for eth0 with vi. To dump everything just run: udevadm info -e > /tmp/udev.log then look for the predictable name in this order: ID_NET_NAME_FROM_DATABASE ID_NET_NAME_ONBOARD ID_NET_NAME_SLOT ID_NET_NAME_PATH ID_NET_NAME_MAC
In my case it is an onboard device and the name it got is enp1s0. After adding that to GRUB_CMD_LINE and in /etc/network/interfaces I could finally get into my dropbear and unlock the system. Took me two days to figure that out. Maybe it safes someone a lot of time...
Using microg/nogapps for around 4-5 years now and also very happy!
Signature spoofing allows microg to replace google play service by giving microg the same signature. Google implemented a forced dependency model in Android which gives app suppliers the power to create a dependency on a company instead of a library. This makes conditional sale possible and easy. If I am correct, the signature spoofing patch only allows microg+blankstore and not other apps to replace google play service. Personnally I think it would even be better if you had the freedom to redefine all dependencies yourself and get rid of the possibility of conditional sale entirely. It is up to the user to decide what company to use and not the supplier. There is no extra danger from malicious actors with the patch unless you download an app with a microg signature and give that app the signature spoofing permission. I think this risk is equal or less to the risk of downloading an app which has a Google signature. Cyanogen's argument is solely based on the idea that google play services should not be replaced by another app, even if it is disabled by default and the user has to explicitly enable it a couple of times. End of cyanogen argument. Since then I am avoiding cyanogenmod when possible. Very happy with Omnirom right now.
apt-get install fdroidserver gplaycli
Apart from the security problems that most non-system package installers impose on their users, there is another severe problem: Uncertainty about software freedom.
When I use apt with official repositories from Debian, I can be confident, that all stuff is free software and license incompatibilies are unlikely. When using npm, pip, and friends, I faced many problems in the past: Very often compressed, minified, combined (JS) files with totally insufficient information about their authors and respective licenses. Or convenience copies of other programs or parts of other programs with minor or not-so-minor changes without clear indication, what this software was and by whom, and what the changes were and by whom.
npm can let you do a lot of horrible things, like the ones you mention. node.js runs perfectly well without npm ! Especially if you're using the debian packages (which are, granted, in a bad state).
Also node-webkit is some sort of ugly experiment. A bit less ugly is https://github.com/atom/electron though you still have to carry and compile chromium from source, which isn't pretty.
Christian, mine was just a rage post, because I needed to vent the frustration. Your comment was actually informative and well written! May I quote it as an addendum?
Sure. I just want to note that my comment here was a bit more polemic than I intended to, but I could identify with your frustration on this issue so much that I couldn't help myself.