Python, Spy Files, Rights, IPv6, Energy, Indexing, Security, Documentation

Python 3.7 - Went through the list, it seems that there aren't any practically big changes. So it's all good, when version gets released.
After checking latest cx_freeze features, added "Optimize": 2 to build_exe options when using cx_freeze. Compressed option isn't available since v5.0 release.
Read Spy Files of Russia. Nothing new? I guess. It's totally normal that everything's being monitored nowadays.
On Windows I often use "! " as prefix for files which I want to be first visible in the resource manager. On Linux (ambiguous I know) with some filename sorting applications that's not that simple. Well, many symbols get ignored or sorted last. ". " works, but is often hidden. So what's the best prefix to use to get filename listed first? Practically best option seems to be "0 " which usually leads the filename to be first in the directory when sorting alphabetically by filename. And if there are other files with "0 " you can always use "0." which gets sorted before those. What about getting files last in directory? Well "~ " prefix works very well for that. Why space after the symbol? Usually files have no other meaning than making sure that the filename is there to be seen, and having the extra space just improves readability. "0 README.txt" or "!README.txt" are true classics. I often also use more clarifying names like "0 dir info.txt" or something, which makes it obvious that it describes what the directory contains. Unless there's separate docs folder in the project, which contains documentation for the whole project and it's directories, etc. And on Linux you can ignore the .txt extension / suffix, because Linux isn't file extension oriented like Windows is.
Spent quite a while explaining to group of users about security rights, principle of least privilege and so on. It seems that the current Windows 10 user rights management, where there's separate Administrator account, seems to confuse so many normal users seriously. But that's totally expected. Because that's one of the reasons why Linux has been so horribly hard to use, many claim. Duh. Yeah, I know weasel words.
Very long discussions about IPv6 and IPv4 NAT and how to maximize IPv4 address utilization and NAT efficiency using RSAP-IP. Ref: RFC2663. It seems that some people got really deeply rooted misunderstandings about NAT.
It seems quite likely that my home is going to get heated in future by data center waste heat. That's nice thought. Energy recycling should be used more often.
I've been optimizing indexing and table joins and generic 'database design' for one hobby project. Phew, so much work and so many factors to consider. Partial indexing improved update performance a lot. Yet there are just so many different ways of implementing same thing, which one is the most efficient one, is hard question. Is it better to have 'processed' flag on huge table. Or just have a little table which can be joined with the primary table which contains list of unprocessed IDs. I kind of like this approach. The worst approach is to have that processed flag, and without partial indexing in the primary table. That's something I've seen being used in production way too much. It's very inefficient way of getting the job done.
Kept wondering why people expose totally insecure services to Internet all the time. I personally always close firewall, while doing service configuration which might or is known to be insecure. After I'm done and sure, everything is okay again, I'll open the specified services for access. But most of administrators seem to ignore this step, and allow access to default configurations without authentication / access restrictions. I think it's horrible, but unfortunately totally normal. Nobody seems to care about that either.
Another thing is why all the production credentials should be included in basic documentation. As well as some information which is clearly freely parameterizable. Some people insist that should be in the documentation. But I personally strongly believe it shouldn't. Afaik, it's just silly to put it there. Nobody updates that documentation, and values can and should be changed at times.

2019-01-20