- 更新:2022-04-06 21:35:50
- 首发:2022-04-06 17:14:02
- 服务器配置
- 6734
修改$Profile
文件(notepad.exe $Profile
),添加
$OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = New-Object System.Text.UTF8Encoding
说明:上述操作修改了输出编码为UTF-8
,兼容了大部分的程序输出的中文。
修改$Profile
文件(notepad.exe $Profile
),添加
$OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = New-Object System.Text.UTF8Encoding
说明:上述操作修改了输出编码为UTF-8
,兼容了大部分的程序输出的中文。
由于RedHat停止了CentOS8的支持,同时RedHat允许开发者注册16个正版RHEL系统,我决定将部分 CentOS 8 服务器更新到 RHEL 8。以下两篇文章是官方发布的与之密切相关的内容:
CentOS Project shifts focus to CentOS Stream
New Year, new Red Hat Enterprise Linux programs: Easier ways to access RHEL
注意,因参考本文操作导致的任何损失与鄙人无关,专业用户请直接访问官方升级说明(请注意官方源无法使用,因此部分sed命令需要修改):https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/converting_from_an_rpm-based_linux_distribution_to_rhel/index 。
一直以来我的客户都在使用正版RHEL系统,购买了即时的订阅,只有部分预算有限的客户使用了CentOS系统,但无论如何他们对于安全、稳定性或技术支持即时性的要求都很高。
能够得到官方的技术支持是我们更加看重的。
目前不支持从CentOS Stream转换/升级到RHEL8,不排除将来也不支持,如果后续有升级需求将不得不重装系统。同理,已经升级到CentOS Stream
的用户就别折腾了,必须重装。(只是因为更新到vault源更新过软件,cat /etc/system-release
却得到CentOS Stream release 8
,说明实际已经升级到CentOS Stream了,是不可以升级到RHEL 8的。)
温馨提示:如果需要迁移大量数据,一定要使用专业工具并请专业的公司提供技术支持,同时做好迁移审计工作。以下方案仅供参考。
MySQL导入数据库导致中文乱码属于常见问题。一般用客户端工具导入不容易出现此问题,但是有点大又不是特别大(10G-100G)的数据通过命令导入就比较容易遇到这个问题。而网上的答案几乎都是经验性的结论,答主大多知其然不知其所以然。
注:命令导入,即source xxx.sql
。
在MySQL定时备份程序中我有提到一个基于Docker快速生成SSL证书的方式。该文章整理了该方案的详细教程。
基于Let's Encrypt
免费SSL证书。
编译程序的时候可能出现aarch64-linux-gnu-gcc: internal compiler error: Killed (program cc1)
类似的报错。这是由于内存不足引起的。可以通过开启Swap分区解决。开启swap
,即使用一部分硬盘作为虚拟内存,解决内存容量不足的情况。
在ubuntu 20.04 LTS版本中,可以通过sudo apt install python
安装python2,但是无法通过sudo apt install python-pip
安装pip2,提示E: Unable to locate package python-pip
。
无法找到python-pip安装包的原因是,Python 2.7的支持周期已于2020年1月1日结束。因为不再维护Python 2.7,pip 21.0已于2021年1月停止对Python 2.7的支持。
如果通过pypa.io
的默认get-pip.py
脚本进行安装,也将遇到This script does not work on Python 2.7 The minimum supported Python version is 3.6.
提示。
由于CentOS8默认安装了podman,因此在CentOS8中安装docker会导致冲突引发如下异常。
Error:
Problem 1: problem with installed package podman-2.0.5-5.module_el8.3.0+512+b3b58dca.x86_64
- package podman-2.0.5-5.module_el8.3.0+512+b3b58dca.x86_64 requires runc >= 1.0.0-57, but none of the providers can be installed
- package containerd.io-1.4.3-3.1.el8.x86_64 conflicts with runc provided by runc-1.0.0-68.rc92.module_el8.3.0+475+c50ce30b.x86_64
- package containerd.io-1.4.3-3.1.el8.x86_64 obsoletes runc provided by runc-1.0.0-68.rc92.module_el8.3.0+475+c50ce30b.x86_64
- cannot install the best candidate for the job
- package runc-1.0.0-64.rc10.module_el8.3.0+479+69e2ae26.x86_64 is filtered out by modular filtering
Problem 2: problem with installed package buildah-1.15.1-2.module_el8.3.0+475+c50ce30b.x86_64
- package buildah-1.15.1-2.module_el8.3.0+475+c50ce30b.x86_64 requires runc >= 1.0.0-26, but none of the providers can be installed
- package docker-ce-3:20.10.1-3.el8.x86_64 requires containerd.io >= 1.4.1, but none of the providers can be installed
- package containerd.io-1.4.3-3.1.el8.x86_64 conflicts with runc provided by runc-1.0.0-68.rc92.module_el8.3.0+475+c50ce30b.x86_64
- package containerd.io-1.4.3-3.1.el8.x86_64 obsoletes runc provided by runc-1.0.0-68.rc92.module_el8.3.0+475+c50ce30b.x86_64
- package containerd.io-1.4.1-3.1.el8.x86_64 conflicts with runc provided by runc-1.0.0-68.rc92.module_el8.3.0+475+c50ce30b.x86_64
- package containerd.io-1.4.1-3.1.el8.x86_64 obsoletes runc provided by runc-1.0.0-68.rc92.module_el8.3.0+475+c50ce30b.x86_64
- package containerd.io-1.4.3-3.el8.x86_64 conflicts with runc provided by runc-1.0.0-68.rc92.module_el8.3.0+475+c50ce30b.x86_64
- package containerd.io-1.4.3-3.el8.x86_64 obsoletes runc provided by runc-1.0.0-68.rc92.module_el8.3.0+475+c50ce30b.x86_64
- cannot install the best candidate for the job
- package runc-1.0.0-56.rc5.dev.git2abd837.module_el8.3.0+569+1bada2e4.x86_64 is filtered out by modular filtering
- package runc-1.0.0-64.rc10.module_el8.3.0+479+69e2ae26.x86_64 is filtered out by modular filtering
在部分场景中却不得不使用docker,因为podman是新东西,即便命令和docker及其相似,也因为生态原因,各类API还无法完全兼容。例如《【视频教程】Electron自动编译及自动更新、分发》就对这个情况进行过说明,在使用Electron 应用分发系统的时候,由于使用了开源项目dockerode对docker进行控制,因此需要卸载podman
改用docker
。
为了实现Electron的自动更新,曾撰文《Electron 应用分发系统(Electron自动更新)》,不少小伙伴反应说不知道正确的操作姿势。仔细想来,这个部署确实不简单,因此特意录制此视频。
视频从头开始讲解了如何搭建一个Electron官方示例,配置并实现push
到git仓库后服务器端自动编译、自动上传编译后的文件到七牛对象存储、客户端捕获更新信息并且后台静默更新的配置全过程。
需要特别留意的是,每次发布新版本之前都需要修改package.json
里面的version
版本号,否则自动更新分发会失效。
感谢回复! Clang 在生成时沿用了 GCC 的版本号标识,我是不是可以理解为Clang 18.1.4生成时使用的就是GCC4.8,所以我后续使用gcc 9.4
gcov
就会有不兼容的问题抱歉,这块我也不太清楚,尝试寻求AI的帮助吧。
我在这个过程中遇到了各种问题- -,现在在UDC core: g_serial: couldn't find an available UDC卡住了,请问大佬有什么解决方案吗,还是说我前置的设置就错了呢,> 这个需求很特殊。是可以的,但是比较困难,需要修改驱动配置。
好思路呀!!
关于hex编辑器,网上没找到特别好用的(小白没办法),最后在vscode上扩展一搜hex,第一个安装一下就可以用vscode进行hex编译了