I wonder what it would take to have shopkeepers, cashiers, and others who regularly encounter customers in close proximity to wear masks (aka respirators.) The 2018 Cambridge pandemic study had found that these people categorically become superspreaders during an epidemic, and by having them either vaccinated (not an option for now) or isolated, we can reduce the number of infections by 40%.
I understand that the capacity to mass produce masks is limited here in the States, and the leaders have promoted policies, or public orders accordingly, so I’m not advocating that everyone wear masks, but I think it’d be a good idea to have these potential superspreaders to wear them.
The upcoming standard is called IEEE 802.11ax and it will be available starting in the fall of 2019.
The latest standard we’ve been using is called 802.11ac, and although we haven’t heard Wi-FI 5, the new standard will be widely promoted as Wi-Fi 6 (as the 6th generation).
The new Wi-Fi 6, 802.11ax uses both 2.4 GHz & 5 GHz and has features such as multi-user, multiple-input, multiple-output (MU-MIMO), Orthogonal Frequency Division Multiple Access (OFDMA) — allows more devices to simultaneously operate on the same channel — throughput of 9 to 10 gigabits per second in optimal conditions. It also supports WPA3.
For reference: Wi-Fi 5, 802.11ac (only uses 5 GHz) Wi-Fi 4, 802.11n (uses both 2.4 GHz & 5 GHz)
While monitoring the logs, I’ve encountered an interesting URL being examined by Googlebot. It’s a type of pattern I’ve been seeing for last several months and decided to make a comment about it today. There’s a very little doubt that Googlebot is partially driven by machine learning algorithm, and for some reason it’s querying a date of May 14, 2143 on this instance. It’s targetting a Read the Bible in a Year service area I’ve created for my church few years ago at https://kumcabq.org/dailyreading. Apparently, Googlebot has figured out that it could traverse through time and started to query what seems to be arbitrary dates. Here are some dates it has queried in the wee hours of August 12, 2019, in the descending order of query times:
Okay, on the second look, it is actually traversing through one day at a time for years 1865, 2132, 2125, 2026, 2034, 2069, 2025, 2033, and so on. The log has many more dates. It almost looks like an artificial intelligence trying to figure out what correlation, if any, is there between the date and the Bible passages presented on the page. This seems to have gone on for a while. This is just taking up unnecessary bandwidth… not sure what to do — slap the Googlebot’s hand when it gets to this page again, or maybe take the page down?
With the need to have multiple sessions via terminal multiplexer, I’ve recently switched back to using GNU Screen rather than tmux. In this transition, I’ve noticed the following:
$ printf '%b\n' '\ue0b0\ue0b1\ue0b2\ue0b3\ue0b4'
Screenshot
Unicode characters don’t appear correctly. So I had to add the following to ~/.bashrc and restart my bash session to get it to display the unicode characters and symbols properly again.
export LC_ALL=en_US.utf-8
Now, it shows up fine.
Screenshot
This may be helpful to those who make use of special Unicode symbols, which are often non-standard, via NerdTree, Airline or Powerline VIM or Neovim plugins. This may be applicable to Nerd Font users as well.
I usually connect to a single server via PuTTY, and have three (horizontally) split sessions for logs, and another PuTTY window for sysadmin, and maybe one for coding (with multiple sessions via byobu), and possibly another one for reference. This doesn’t seem to be possible with tmux as backend for byobu.
This may be because, tmux, in spite of all the praises it receives for speed, features, and whatnot, doesn’t support multiple concurrent, but distinct sessions via byobu. I haven’t researched this deep enough to conclusively say that there is absolutely no way to do this, but I’ve found simply switching over to screen to be much easier solution for now.
Even after a complete update of the system (via yum in this case) the number of updates available indicator on the status line on byobu doesn’t get updated. This happens regardless of terminal multiplexer you’re using (either screen, or tmux.) This indicator seems to be cached under /dev/shm/byobu-mhan-CQCSeDjp/cache.screen folder, and a very short-lived, temporary workaround seems to be simply emptying out the folder. More permanent solution would be to fix the script itself (/usr/libexec/byobu/updates_available). On line 66, the following yum command is executed:
yum list updates -q | grep -vc "Updated Packages"
That is supposed to return the number of updates available, but it only works properly when it’s under under sudo on this system. It fails with an error message when it is run with user account, which byobu assumes when this script is run:
Cannot upload enabled repos report, is this client registered?
This seems to be a message related to RH subscription manager, which is typically installed as a plugin to yum. We can run without plugins to see if it still complains:
No complaint here. And return of 0 is promising. That 1! below has been an eyesore, so for now, this will be a good enough of a fix for me. This may disable some repos that were added as plugins, and I will have to double check that some other time. Adding –noplugins to line 66 in /usr/libexec/byobu/updates_available.
Whenever I use PuTTY (on Windows) to connect to my CentOS box, I always get the message immediately after the authentication:
Couldn't get a file descriptor referring to the console
I decided not to ignore the message today, and figured out that setfont in my .bash_profile was causing it. I recall putting that in when I used to work from home more often and connect directly on console. Just nuke or comment out the line, and all is at peace.
