Ubuntu 22.04 desktop version comes pre-installed with Snap. However, I find it inconvenient to use and the Snap directory in the Home folder is quite distracting. So, I tried uninstalling it but encountered several issues.
The MySQL binary log contains “events” that describe database changes such as table creation operations or changes to table data. It is the oplog of mysql, and we can subscribe the log to follow all the actions.
We meet an error log on nginx: worker_connections are not enough, reusing connections. To resolve this issue, here is my working solution according to the references:
This is a python version to translate W. Randolph Franklin's work. And recorded for further usage.
Here are some scripts to initialize your python environment to mirror your repo.
Ubuntu 自 18.04 开始使用 timesyncd 作为默认的 ntp client。当然如果有必要也可以安装较多包来部署一个自己的 ntp server。
本文只介绍如何配置 timesyncd。
After a recent macOS upgrade, some ssh access was strangely blocked. I turned on verbose logs to check the problem.
Usually we use data[44:] to eliminate the header information of wav files, and then assume the rest data is PCM. This may not always be true. For the wav header of a PCMWAVEFORMAT, we can usually understand that a structure Read more…
After my CentOS 7 upgrade, I rebooted it. It gets stuck and shows a prompt like this:
grub >
It is an annoying start.
Suppose we want to create a "lazy" data attributes ( "instance variables" in Smalltalk, or "data members" in C++) in a Python Class. We may required to use getattr to customize attribute access.
It is becoming pretty slow in SSH to a CentOS server.
Trying to print a verbose log:
$ ssh -vvvv my-host .... debug3: send packet: type 21 debug2: set_newkeys: mode 1 debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug1: SSH2_MSG_NEWKEYS received debug2: set_newkeys: mode 0 debug1: rekey in after 134217728 blocks debug1: Will attempt key: /Users/user/.ssh/id_rsa RSA SHA256:XXXXX/gNY explicit debug2: pubkey_prepare: done debug3: send packet: type 5 debug3: receive packet: type 7 debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512> debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 ..... <<<-- long long long silence here debug3: receive packet: type 51 <<<-- and then continue to access the server debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password debug3: preferred publickey,keyboard-interactive,password