如果不小心提交github提交错了，而 --amend 也不能修改提交者的信息，可以通过尝试下面的方式 Checkout bash 1 git checkout --orphan <latest_branch> Add all the files bash 1 git add -A Commit the changes bash 1 git commit -am "commit message" Delete the branch bash 1 git branch -D main Rename the current branch to main bash 1 git branch -m main Finally, force update your repository bash 1 git push -f origin main 缺点是：所有该分支的提交记录都将被删除 Reference how to delete all commit history in github?...

deb 概述 deb包（.deb）是 Debian 和基于 Debian衍生操作系统（如Ubuntu）中使用的一种软件包的格式。deb是一种基于 Unix ar [3] (Unix archiver) 的归档文件。其中包含二进制文件、配置文件和其他软件所需的资源。deb包可用于安装、升级和卸载软件包。通常，Debian操作系统的用户使用apt（Advanced Package Tool）等软件包管理器工具来管理deb包。通过这些工具，用户可以轻松下载、安装和管理软件包，而无需手动编译、安装和解决软件包之间的依赖关系。 deb VS rpm 包的归档格式不同：deb是基于 ar 的归档模式，而RPM是基于 cpio 的归档模式 包的结构不同：deb包要求必须包含一个 DEBIAN 目录；而RPM不需要以来额外的目录结构 包的依赖机制不同： Deb使用epoch，而RPM使用build number：在Deb中，epoch是一个可选的字段，它允许呈现基准日期之前的先前版本。而在RPM中，build number表示软件包编译的次数。因此，在Deb中，为了解决版本控制问题，epoch是非常重要的，而在RPM中，则更关注build number。 Deb使用逆向依赖关系，而RPM使用依赖关系：在Deb中，依赖项是从包本身向外扩展，在解决依赖问题时可以通过逆向依赖关系进行。而在RPM中，则更喜欢使用依赖关系直接指向其他包。 Deb允许代理软件包，而RPM则不允许代理软件包：Deb中，软件包可以使用另一种软件包的代理来提供功能。在RPM中，软件包需要直接引用相关的软件包。这意味着在Deb中，对于版本控制，可以用另一种代理软件包来解决问题，而在RPM中必须直接引用包。 Deb允许多重依赖关系，RPM则不允许：Deb允许使用多个依赖项列表，以便包与不同版本的库兼容。在RPM中，需要在每个包中定义依赖项和其版本，不能使用多重依赖。 deb包的分析 deb包的结构 deb 最重要的是 控制文件 Control ，该文件记录了deb包与其安装的程序的信息。 在deb包内部包含一组模拟 Linux 文件系统的文件夹，例如 /usr, /usr/bin, /opt等等。 放置在其中一个目录中的文件将在安装期间复制到实际文件系统中的相同位置。 因此，例如将二进制文件放入 <.deb>/usr/local/bin/binaryfile 将被安装到 /usr/local/bin/binaryfile. 对于deb 包的命名是遵循着一个特定的格式： text 1 <name>_<version>-<revision>_<architecture>.deb <name> 构建的deb包名称，如nginx <version> 程序的版本号 ，如1.20 <revision> 当前 deb 包的版本号 <architecture> 表示构建出的包的操作系统架构，如，amd64、i386 如果你构建一个nginx-1.20的arm操作系统下的，那么deb包名格式则为 nginx_1.20-1_arm64.deb control文件 [2] Deb软件包（....

telnet：busybox-extras net-tools: net-tools tcpdump: tcpdump wget: wget dig nslookup: bind-tools curl: curl nmap: nmap wget ifconfig nc traceroute.. : busybox ssh: openssh-client ss iptables: iproute2 ethtool: ethtool yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 FROM alpine MAINTAINER RUN sed -i 's@http://dl-cdn.alpinelinux.org/@https://mirrors.aliyun.com/@g' /etc/apk/repositories RUN apk add --no-cache --virtual .persistent-deps \ curl \ tcpdump \ iproute2 \ bind-tools \ ethtool \ busybox-extras \ libressl \ openssh-client \ busybox CMD [ "tail", "-f" ]

D-Bus 是 Linux 系统中的一种通信机制，用于在进程之间进行通信。D-Bus 配置文件则是一种用于配置 D-Bus 的文件，其中包含有关系统总线 (system bus)，会话总线 (session bus) 和各种系统服务的详细信息。 本文将解析 D-Bus 配置文件，侧重点则为权限的配置 配置文件的基本结构 D-Bus 配置文件使用 XML 格式进行编写，具有以下基本结构： xml 1 2 3 4 5 6 7 8 9 10 11 12 <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/D-Bus/1.0/busconfig.dtd"> <busconfig> <policy group="wheel"> <!-- policy rules go here --> </policy> <policy context="default"> <!-- policy rules go here --> </policy> <include filename="other-config.xml"/> <listen>unix:path=/var/run/D-Bus/system_bus_socket</listen> </busconfig> 什么是D-Bus Policy？ D-Bus Policy是D-Bus配置文件中最重要的字段之一，用于定义D-Bus服务的访问控制策略。D-Bus Policy包含了一组规则，用于限制D-Bus服务的使用者对D-Bus服务的访问，确保D-Bus服务的安全性。...

创建型模式 工厂模式 概念说明 工厂模式 (factory pattern) 是在父类中提供一个创建对象的方法，是用于创建不同类型的对象，而无需指定对象的真实的类 工厂模式的特点： 对客户端隐藏对象创建的复杂逻辑 可以通过修改工厂类来创建对象而不影响客户端代码 提供创建对象的单一来源。 单个工厂类用以各组件保持一致性。 允许子类创建对象类型 图：工厂设计模式的示意图 Source：https://www.techcrashcourse.com/2015/10/factory-design-pattern.html 图片说明： Owl, Eagle, Sparrow 类都必须实现 Brid 接口， 该接口声明了一个名为 fly() 的方法。 每个类都将以不同的方式实现该方法。而使用工厂模式后的代码机构则为图所示，当 Owl, Eagle, Sparrow 实现了共同的接口，就可以将其对象传递给客户代码， 而无需提供额外数据。 而 “调用工厂方法的代码” 称为 “客户端代码”，这样可以做到 “不需要了解不同子类返回实际对象之间的差别”。客户端代码将所有 Brid Sanctuary 视为抽象的 Brid ，这样 ”客户端代码“ 知道所有鸟类对象都提供 fly() 方法， 但是并不关心其实现方式。 代码实现 brid.go go 1 2 3 4 5 package main type Brid interface { Fly() } Owl.go go 1 2 3 4 5 type Owl struct {} func (g *Owl) Fly() { fmt....