未命名
golang.org/x/net/websocket示例
1 | package main |
github.com/gorilla/websocket示例
1 | package main |
golang.org/x/net/websocket示例1 | package main |
github.com/gorilla/websocket示例1 | package main |
https://blog.csdn.net/maizi314/article/details/103979437
https://blog.csdn.net/wushang923/article/details/9226529
https://www.cnblogs.com/lonelyxmas/p/7979743.html
https://blog.csdn.net/yangyy9611/article/details/17464133
https://lindexi.oschina.io/lindexi/post/WPF-%E4%BD%BF%E7%94%A8%E5%B0%81%E8%A3%85%E7%9A%84-SharpDx-%E6%8E%A7%E4%BB%B6.html
https://blog.csdn.net/weixin_34320159/article/details/86132420
https://blog.csdn.net/wangsunjun/article/details/8894952
https://www.codeproject.com/Articles/15610/Regex-Validation-in-WPF
https://www.cnblogs.com/mantian/p/3816834.html
https://cloud.tencent.com/developer/ask/76782/answer/132738
https://blog.csdn.net/ZZZWWWPPP11199988899/article/details/77620211
https://blog.csdn.net/qq_38888555/article/details/82118505
https://blog.csdn.net/lwwl12/article/details/78472235
https://blog.walterlv.com/post/win10/2017/10/02/wpf-transparent-blur-in-windows-10.html
http://toto0668.blog.163.com/blog/static/30990252201691441716893/
https://blog.csdn.net/catshitone/article/details/78522931
导入pg源及签名
1 | sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list' |
导入TimeScalaDB 源及签名
debian版
1 | sh -c "echo 'deb [signed-by=/usr/share/keyrings/timescale.keyring] https://packagecloud.io/timescale/timescaledb/debian/ $(lsb_release -c -s) main' > /etc/apt/sources.list.d/timescaledb.list" |
1 | sh -c "echo 'deb [signed-by=/usr/share/keyrings/timescale.keyring] https://packagecloud.io/timescale/timescaledb/ubuntu/ $(lsb_release -c -s) main' > /etc/apt/sources.list.d/timescaledb.list" |
安装
1 | apt install postgresql-14 |
启动pg
1 | service postgresql start |
创建timescaledb扩展时会报一下错误
1 | FATAL: extension "timescaledb" must be preloaded |
根据提示修改配置文件
1 | echo "shared_preload_libraries = 'timescaledb'" >> /etc/postgresql/14/main/postgresql.conf |
重启pg
1 | service postgresql restart |
再次建立扩展
1 | create extension timescaledb; |
查看已安装好的扩展
1 | \dx |
大端数据格式
1 | ffmpeg -i test.mp3 -f s16be -ar 16000 -ac 1 -acodec pcm_s16be pcm16k.pcm |
小端数据格式
1 | ffmpeg -i test.mp3 -f s16le -ar 16000 -ac 1 -acodec pcm_s16le pcm16k.pcm |
说明:
Podman 是一个开源的容器运行时工具,可在大多数 Linux 平台上使用。它旨在提供与 Docker 相似的功能,但采用了更现代、更安全的架构。
| 特性 | Docker | Podman |
|---|---|---|
| 守护进程 | 需要 dockerd 守护进程以 root 权限运行 |
无需守护进程,直接与 OCI 运行时交互 |
| 运行权限 | 通常需要 root 权限 | 支持无根(rootless)模式,普通用户可直接运行 |
| 进程模型 | 复杂:dockerd -> containerd -> containerd-shim -> runc |
简洁:podman -> conmon -> runc |
| 安全性 | root 守护进程存在潜在安全风险 | 无 root 守护进程,安全性更高 |
架构对比图:
Podman 直接调用 OCI 运行时(如 runc),通过 conmon(容器监控器)管理容器进程,无需 dockerd 这类以 root 身份运行的守护进程。
Podman 的命令行接口与 Docker 高度兼容,大多数 Docker 命令可以直接替换为 podman。它支持管理和运行任何符合 OCI(开放容器倡议) 规范的容器和镜像,并能无缝使用 Docker Hub 等镜像仓库。
官网:podman.io
在 CentOS/RHEL 8 及更高版本上,Podman 通常是预装的。如需安装:
1 | sudo yum -y install podman |
编辑配置文件 /etc/containers/registries.conf:
1 | # 设置镜像搜索源 |
编辑 /etc/containers/storage.conf,确保普通用户模式性能更佳:
1 | [storage] |
Podman 命令与 Docker 命令高度相似,以下是对照表:
| 功能 | Docker 命令 | Podman 命令 |
|---|---|---|
| 创建并运行容器 | docker run |
podman run |
| 启动已停止容器 | docker start |
podman start |
| 停止运行中容器 | docker stop |
podman stop |
| 重启容器 | docker restart |
podman restart |
| 终止容器 | docker kill |
podman kill |
| 删除容器 | docker rm |
podman rm |
| 列出容器 | docker ps |
podman ps |
| 功能 | Docker 命令 | Podman 命令 |
|---|---|---|
| 拉取镜像 | docker pull |
podman pull |
| 列出镜像 | docker images |
podman images |
| 删除镜像 | docker rmi |
podman rmi |
| 构建镜像 | docker build |
podman build |
| 导出镜像 | docker save |
podman save |
| 导入镜像 | docker load |
podman load |
| 功能 | Docker 命令 | Podman 命令 |
|---|---|---|
| 进入容器 | docker exec |
podman exec |
| 查看日志 | docker logs |
podman logs |
| 检查容器 | docker inspect |
podman inspect |
| 查看进程 | docker top |
podman top |
| 复制文件 | docker cp |
podman cp |
便捷参数:许多命令支持 --latest 或 -l 参数来操作最近创建的容器,避免输入冗长的容器ID。
1 | # 拉取并运行 Apache httpd 容器 |
1 | FROM docker.io/library/centos:7 |
1 | podman build -t my-nginx:latest . |
1 | # 1. 为镜像打标签 |
Podman 的核心优势之一是支持普通用户无需 sudo 即可运行容器。
管理员需要在主机上完成以下配置:
安装必要软件:
1 | sudo yum -y install slirp4netns fuse-overlayfs shadow-utils |
配置用户子UID/GID:
Podman 要求用户在 /etc/subuid 和 /etc/subgid 文件中拥有唯一的 UID/GID 范围。
1 | # 查看现有分配 |
文件格式为:用户名:起始UID:数量
调整内核参数(允许绑定低端口):
1 | # 允许非特权用户绑定 80 及以上端口 |
普通用户 tom 登录后,可以创建个人配置文件 ~/.config/containers/ 来覆盖系统默认设置。
在 rootless 模式下挂载卷时,容器内的文件属主会映射到主机用户的子UID。使用 --userns=keep-id 选项可以让容器内的进程以与主机用户相同的 UID 运行,简化文件权限管理。
1 | # 1. 创建数据目录 |
net.ipv4.ip_unprivileged_port_start=80,可以映射 80 及以上 的端口。1 | # 映射 8080 端口(始终允许) |
如果习惯 Docker 命令,可以为 Podman 设置别名实现无缝切换:
1 | echo "alias docker=podman" >> ~/.bashrc |
现在,你可以继续使用 docker 命令,但实际上调用的是 podman。
Root 用户和普通用户拥有独立的镜像和容器存储空间,互不可见。
1 | # root 用户查看 |
利用 Podman 简洁的进程模型进行调试:
1 | # 查看容器相关进程 |
Podman 作为 Docker 的现代替代品,凭借其无需守护进程、原生支持 Rootless 模式和与 Docker CLI 高度兼容的特性,为容器运行提供了更安全、更灵活的解决方案。
迁移建议:
alias docker=podman 平滑过渡。通过掌握 Podman 的核心概念、命令和配置,你可以在享受容器技术便利的同时,构建更安全、更高效的容器化工作流。
当克隆(git clone)或拉取/推送(git pull/git push)远程仓库时,如果遇到速度极慢、频繁超时甚至失败的情况,很可能是网络连接问题。此时,为 Git 配置代理是有效的解决方案。
首先,识别你使用的 Git 远程协议:
http:// 或 https:// 开头。1 | https://github.com/user/repo.git |
git@ 或 ssh:// 开头。1 | git@github.com:user/repo.git |
代理类型:你需要知道本地代理软件提供的协议和端口,通常是 HTTP/HTTPS 代理 或 SOCKS5 代理。
此方法通过 Git 自身的配置项设置代理,适用于使用 http:// 或 https:// 地址的仓库。
1 | # 设置 HTTP/HTTPS 代理(端口 7890 为例) |
参数说明:
--global:修改全局配置文件(~/.gitconfig),对所有仓库生效。http://127.0.0.1:7890:代理地址和端口,请替换为你本地代理软件的实际设置。http.proxy 配置项同时作用于 http:// 和 https:// 协议,没有独立的 https.proxy 配置项。如果只想为某个网站(如 GitHub)使用代理,可以针对性地配置。
1 | # 为 GitHub 设置 HTTP/HTTPS 代理 |
优势:此配置仅影响对 github.com 的访问,其他仓库仍走直连,更灵活。
1 | # 查看所有 Git 配置 |
当使用 git@ 格式的地址时,Git 依赖 SSH 进行通信。此时需要配置 SSH 客户端本身,通过修改 ~/.ssh/config 文件实现。
编辑 ~/.ssh/config 文件(如果不存在则创建):
1 | nano ~/.ssh/config |
针对 HTTP/HTTPS 代理:
1 | Host github.com |
针对 SOCKS5 代理:
1 | # 方式一:明确指定协议 |
参数详解:
Host github.com:指定此配置仅对访问 github.com 生效。可替换为 gitlab.com 等。User git:SSH 连接用户,对于 Git 服务通常为 git。ProxyCommand:指定通过代理建立连接的命令。nc:netcat 命令,用于网络连接。-X connect:指定使用 HTTP CONNECT 方法(用于 HTTPS 代理)。-X 5:指定使用 SOCKS5 协议。-x 127.0.0.1:port:指定代理服务器地址和端口。%h %p:SSH 运行时自动替换为目标主机名和端口。Windows 系统通常使用 connect 工具(Git for Windows 自带)。编辑 ~/.ssh/config 文件(路径通常为 C:\Users\你的用户名\.ssh\config)。
针对 HTTP/HTTPS 代理:
1 | Host github.com |
针对 SOCKS5 代理:
1 | Host github.com |
参数说明:
connect:Git for Windows 自带的代理连接工具。-H:指定 HTTP 代理。-S:指定 SOCKS5 代理。配置完成后,测试 SSH 是否能通过代理正常连接:
1 | ssh -T git@github.com |
如果看到类似 Hi username! You've successfully authenticated... 的成功提示,则配置正确。
假设你的环境是:
GitHub 使用 SSH 协议 + SOCKS5 代理(端口 7891)。公司内网 GitLab 使用 HTTPS 协议直连。对应配置:
**SSH 配置 (~/.ssh/config)**:
1 | Host github.com |
Git 全局配置:
1 | # 为所有 HTTPS 仓库设置代理 |
可以创建 Shell 脚本或别名来快速启用/禁用代理。
1 | # 在 ~/.bashrc 或 ~/.zshrc 中添加别名 |
然后执行 source ~/.bashrc 后,即可通过 git-proxy-on 和 git-proxy-off 快速切换。
错误:Failed to connect to 127.0.0.1 port 7890: Connection refused
原因:代理服务器未运行,或端口号错误。
解决:确认本地代理软件(如 Clash、V2Ray)已启动,并检查其监听的端口号。
配置后速度反而变慢或失败
原因:代理服务器不稳定或网络延迟高。
解决:尝试更换代理节点,或对特定仓库使用直连(git config --unset)。
如何为 git:// 协议设置代理?git:// 协议使用 9418 端口,不常用且通常不支持代理。建议改用 HTTPS 或 SSH 协议。
公司内网环境注意事项
如果公司网络已提供透明代理或强制使用自己的代理,可能需要联系 IT 部门获取正确的代理地址,并可能需要配置 no_proxy 环境变量来排除内部地址。
| 场景 | 协议 | 配置位置 | 关键命令/配置 |
|---|---|---|---|
| 通用 HTTPS 仓库 | HTTP/HTTPS | Git 全局配置 | git config --global http.proxy http://127.0.0.1:7890 |
| 特定 HTTPS 仓库 | HTTP/HTTPS | Git 全局配置 | git config --global http.https://github.com.proxy ... |
| SSH 仓库 | SSH | ~/.ssh/config 文件 |
ProxyCommand nc -x 127.0.0.1:7891 %h %p |
核心步骤:
https:// 还是 git@。git config 命令。~/.ssh/config 文件。git clone 一个小仓库或 ssh -T 测试连接。进入MSYS2安装目录,例如C:\msys64,打开路径 C:\msys64\etc\pacman.d.
在该目录下找到以下文件,并分别进行修改:
将以下内容添加到文件顶部:
1 | Server = https://mirrors.tuna.tsinghua.edu.cn/msys2/msys/$arch |
1 | Server = https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/i686 |
1 | Server = https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/x86_64 |
如果需要支持 ucrt64 或 _clang_,可参考以下示例
1 | # mirrorlist.ucrt64 |
完成上述修改后,运行以下命令更新系统:
1 | pacman -Syu |
[Linux-4.4-x86_64 内核配置选项简介 金步国] (jinbuguo.com)
Systemd 是一系列工具的集合,其作用也远远不仅是启动操作系统,它还接管了后台服务、结束、状态查询,以及日志归档、设备管理、电源管理、定时任务等许多职责,并支持通过特定事件(如插入特定 USB 设备)和特定端口数据触发的 On-demand(按需)任务。
Systemd 的后台服务还有一个特殊的身份——它是系统中 PID 值为 1 的进程。
Systemd 提供了服务按需启动的能力,使得特定的服务只有在真正被请求时才启动。
在 SysV-init 时代,将每个服务项目编号依次执行启动脚本。Ubuntu 的 Upstart 解决了没有直接依赖的启动之间的并行启动。而 Systemd 通过 Socket 缓存、DBus 缓存和建立临时挂载点等方法进一步解决了启动进程之间的依赖,做到了所有系统服务并发启动。对于用户自定义的服务,Systemd 允许配置其启动依赖项目,从而确保服务按必要的顺序运行。
在 Systemd 之前的主流应用管理服务都是使用进程树来跟踪应用的继承关系的,而进程的父子关系很容易通过两次 fork 的方法脱离。
而 Systemd 则提供通过 CGroup 跟踪进程关系,弥补了这个缺漏。通过 CGroup 不仅能够实现服务之间访问隔离,限制特定应用程序对系统资源的访问配额,还能更精确地管理服务的生命周期。
Systemd 是一系列工具的集合,包括了一个专用的系统日志管理服务:Journald。这个服务的设计初衷是克服现有 Syslog 服务的日志内容易伪造和日志格式不统一等缺点,Journald 用二进制格式保存所有的日志信息,因而日志内容很难被手工伪造。Journald 还提供了一个 journalctl 命令来查看日志信息,这样就使得不同服务输出的日志具有相同的排版格式,便于数据的二次处理。
![[Systemd服务管理/IMG-20260205160657597.png]]
Systemd 可以管理所有系统资源,不同的资源统称为 Unit(单位)。
在 Systemd 的生态圈中,Unit 文件统一了过去各种不同系统资源配置格式,例如服务的启/停、定时任务、设备自动挂载、网络配置、虚拟内存配置等。而 Systemd 通过不同的文件后缀来区分这些配置文件。
Unit 文件按照 Systemd 约定,应该被放置指定的三个系统目录之一中。这三个目录是有优先级的,如下所示,越靠上的优先级越高。因此,在三个目录中有同名文件的时候,只有优先级最高的目录里的那个文件会被使用。
Systemd 默认从目录 /etc/systemd/system/ 读取配置文件。但是,里面存放的大部分文件都是符号链接,指向目录 /usr/lib/systemd/system/,真正的配置文件存放在那个目录。
Unit 是 Systemd 管理系统资源的基本单元,可以认为每个系统资源就是一个 Unit,并使用一个 Unit 文件定义。在 Unit 文件中需要包含相应服务的描述、属性以及需要运行的命令。
Target 是 Systemd 中用于指定系统资源启动组的方式,相当于 SysV-init 中的运行级别。
简单说,Target 就是一个 Unit 组,包含许多相关的 Unit 。启动某个 Target 的时候,Systemd 就会启动里面所有的 Unit。从这个意义上说,Target 这个概念类似于”状态点”,启动某个 Target 就好比启动到某种状态。
1 | [Unit] |
如下所示,Systemd 服务的 Unit 文件可以分为三个配置区段:
这部分配置的目标模块通常是特定运行目标的 .target 文件,用来使得服务在系统启动时自动运行。这个区段可以包含三种启动约束:
1 | # find /etc/systemd/system/* -type d |
| SysV-Init Level | Systemd Target | Note |
|---|---|---|
| 0 | runlevel0.target -> poweroff.target | 关闭系统 |
| 1 | runlevel1.target -> rescue.target | 单用户模式 |
| 2 | runlevel2.target -> multi-user.target | 用户定义/域特性运行级别,默认等同于级别3 |
| 3 | runlevel3.target -> multi-user.target | 多用户模式 |
| 4 | runlevel4.target -> multi-user.target | 用户定义/域特定运行级别,默认等同于级别3 |
| 5 | runlevel5.target -> graphical.target | 多用户, 图形模式 |
| 6 | runlevel6.target -> reboot.target | 重启 |
| emergency | emergency.target | 急救模式 |
通过 systemctl list-units –type=target 命令可以获取当前正在使用的运行目标
1 | # systemctl list-units --type=target |
用来 Service 的配置,只有 Service 类型的 Unit 才有这个区块。它的主要字段分为服务生命周期和服务上下文配置两个方面。
注意:如果在 ExecStart、ExecStop 等属性中使用了 Linux 命令,则必须要写出完整的绝对路径。对于 ExecStartPre 和 ExecStartPost 辅助命令,若前面有个 “-” 符号,表示忽略这些命令的出错。因为有些 “辅助” 命令本来就不一定成功,比如尝试清空一个文件,但文件可能不存在。
在 Unit 文件中,有时会需要使用到一些与运行环境有关的信息,例如节点 ID、运行服务的用户等。这些信息可以使用占位符来表示,然后在实际运行被动态地替换实际的值。
uname -r 命令输出的内容在现实中,往往有一些应用需要被复制多份运行。例如,用于同一个负载均衡器分流的多个服务实例,或者为每个 SSH 连接建立一个独立的 sshd 服务进程。
Unit 模板文件的写法与普通的服务 Unit 文件基本相同,不过 Unit 模板的文件名是以 @ 符号结尾的。通过模板启动服务实例时,需要在其文件名的 @ 字符后面附加一个参数字符串。
apache@.service 模板
1 | [Unit] |
启动 Unit 模板的服务实例
在服务启动时需要在 @ 后面放置一个用于区分服务实例的附加字符参数,通常这个参数用于监控的端口号或控制台 TTY 编译号。
1 | systemctl start apache@8080.service |
Systemd 在运行服务时,总是会先尝试找到一个完整匹配的 Unit 文件,如果没有找到,才会尝试选择匹配模板。例如上面的命令,System 首先会在约定的目录下寻找名为 apache@8080.service 的文件,如果没有找到,而文件名中包含 @ 字符,它就会尝试去掉后缀参数匹配模板文件。对于 apache@8080.service,systemd 会找到 apache@.service 模板文件,并通过这个模板文件将服务实例化。
1 | # systemctl --help |
1 | # 列出正在运行的 Unit |
1 | # 显示系统状态 |
1 | # 立即启动一个服务 |
1 | # 列出一个 Unit 的所有依赖,默认不会列出 target 类型 |
当一个新的 Unit 文件被放入 /etc/systemd/system/ 或 /usr/lib/systemd/system/ 目录中时,它是不会被自识识别的。
Target 就是一个 Unit 组,包含许多相关的 Unit 。启动某个 Target 的时候,Systemd 就会启动里面所有的 Unit。
在传统的 SysV-init 启动模式里面,有 RunLevel 的概念,跟 Target 的作用很类似。不同的是,RunLevel 是互斥的,不可能多个 RunLevel 同时启动,但是多个 Target 可以同时启动。
1 | # 查看当前系统的所有 Target |
Systemd 通过其标准日志服务 Journald 提供的配套程序 journalctl 将其管理的所有后台进程打印到 std:out(即控制台)的输出重定向到了日志文件。
Systemd 的日志文件是二进制格式的,必须使用 Journald 提供的 journalctl 来查看,默认不带任何参数时会输出系统和所有后台进程的混合日志。
默认日志最大限制为所在文件系统容量的 10%,可以修改 /etc/systemd/journald.conf 中的 SystemMaxUse 来指定该最大限制。
1 | # 查看所有日志(默认情况下 ,只保存本次启动的日志) |
1 | # 重启系统 |
1 | # 查看启动耗时 |
1 | # 显示当前主机的信息 |
1 | # 查看当前时区设置 |
1 | # 列出当前 session |
1 | $ PASSWORD=$(systemd-ask-password "Input Your Password:") |
systemd-run 可以将一个指定的操作变成后台运行的服务。它的效果似乎与直接在命令后加上表示后台运行的 & 符号很相似。然而,它让命令成为服务还意味着,它的生命周期将由 Systemd 控制。具体来说,包括以下好处: