Ubuntu 24系统PHP 8.3安装Swoole扩展的方法

在 Ubuntu 24.04(Noble Numbat)上安装 Swoole 扩展(PHP 8.3),目前最稳定、推荐的方式有两种:

1 首选方式:使用 Ondřej Surý 的 PPA 仓库(他维护了大量 PHP 扩展的预编译包,包括 swoole 6.1.4+,已支持 PHP 8.3),安装最简单、无需编译、更新方便。

2 备选方式:用 pecl 从源码编译安装(如果 PPA 版本不满足需求,或想用最新 master 分支)。

Swoole 官方仓库已转向维护较少的 OpenSwoole 分支,但大多数项目仍使用原版 swoole(pecl/swoole 或 PPA 中的 php-swoole)。

方式一:使用 PPA 安装(强烈推荐,5 分钟搞定)

1 添加 Ondřej Surý 的 PPA(如果之前没加过):

sudo add-apt-repository ppa:ondrej/php
sudo apt update

2 安装 Swoole 扩展:

sudo apt install php8.3-swoole

这会自动安装最新可用版本(截至 2025 年底,已有 6.1.4+ 支持 PHP 8.3)。

3 启用扩展(通过PPA包安装的扩展通常自动启用,但保险起见):

sudo phpenmod swoole

或手动在 php.ini 添加。

4 验证是否安装成功:

php -m | grep swoole

如果输出:

swoole

就说明安装swoole扩展成功。

更详细检查:

php -i | grep -i swoole

看到 swoole support => enabled 及版本信息即表示安装成功。

推荐再运行一个简单脚本进行测试:

<?php
echo swoole_version() . PHP_EOL;
var_dump(extension_loaded('swoole'));
?>

执行 php test.php

5 重启 PHP 服务:

sudo systemctl restart php8.3-fpm   # Nginx + FPM 最常见
sudo systemctl restart apache2      # 如果用 Apache

方式二:用 pecl 从源码编译安装(如果需要最新版或自定义)

1 安装编译依赖(非常重要,Ubuntu 24.04 上缺这些会编译失败):

sudo apt update
sudo apt install php8.3-dev php-pear libssl-dev zlib1g-dev libcurl4-openssl-dev
sudo apt install gcc g++ make   # 基本编译工具

如果要启用协程钩子、HTTP2、MySQL 等高级功能,还可加:

sudo apt install libbrotli-dev libnghttp2-dev

2 更新 pecl 频道(避免旧缓存问题):

sudo pecl channel-update pecl.php.net

3 安装 Swoole(推荐指定稳定版,如 5.1.x 或 6.0.x,根据项目需求):

sudo pecl install swoole

或指定版本(例如最新稳定版):

sudo pecl install swoole-6.1.4

安装过程会询问是否启用各种特性(默认回车即可,大部分推荐启用):

enable sockets support? [yes] → yes
enable openssl support? [yes] → yes
enable http2 support? [yes] → yes(需 libnghttp2-dev)
enable brotli? [no] → yes(需 libbrotli-dev)
…

4 启用扩展

用 phpenmod(推荐做法):

sudo phpenmod swoole

或手动编辑 php.ini(CLI 和 FPM 分别处理):

sudo nano /etc/php/8.3/cli/php.ini
sudo nano /etc/php/8.3/fpm/php.ini

添加以下一行:

extension=swoole.so

5 验证是否安装成功:

php -m | grep swoole

如果输出:

swoole

就说明安装swoole扩展成功。

更详细检查:

php -i | grep -i swoole

看到 swoole support => enabled 及版本信息即表示安装成功。

推荐再运行一个简单脚本进行测试:

<?php
echo swoole_version() . PHP_EOL;
var_dump(extension_loaded('swoole'));
?>

执行 php test.php

6 重启 PHP 服务:

sudo systemctl restart php8.3-fpm   # Nginx + FPM 最常见
sudo systemctl restart apache2      # 如果用 Apache

注意事项与常见问题

  • 依赖缺失:编译失败最常见原因是缺少 php8.3-dev 或 libssl-dev。
  • 内存/CPU:编译 Swoole 需要 1-2GB 内存,低配 VPS 可能卡住或失败。
  • OpenSwoole vs Swoole:如果你项目明确需要 OpenSwoole(更活跃的分支),改用 pecl install openswoole 或 PPA 中的 php8.3-openswoole(如果有)。
  • 生产环境:Swoole 常用于常驻进程,建议用 Supervisor 或 systemd 管理服务,不要直接用 php-fpm。
  • 性能调优:安装后可在 php.ini 添加:

swoole.use_shortname = On    ; 允许 \co、\go 等短名(可选)

参考

官方文档安装Swoole

布鲁克定律(Brook’s Law):为已经延期的软件项目增加人手只会让项目延期得更厉害

如果一个项目出现了延期,只是简单地增加人手很可能会带来灾难性的后果。对编程效率、软件开发方法、技术架构等因素进行评审总是会带来更好的结果。如果没有,那说明霍夫施塔特定律也在起作用。

霍夫施塔特定律(Hofstadter’s Law)由 Douglas Hofstadter 提出,并以他的名字命名。这个定律指出:即使你考虑到了霍夫施塔特定律,项目的实际完成时间总是比预期的要长。

这个“定律”是关于准确预估完成复杂任务所需时间的难度。这个定律具有递归性,反映了预估复杂项目的难度,尽管你可能已经做出了最大的努力,而且也知道任务的复杂性。

这就是为什么在进行项目预估时必须要有一个缓冲区。

软件开发后期,添加人力只会使项目开发得更慢。

这个定律表明,在许多情况下,试图通过增加人力来加速已延期项目的交付,将会使项目交付得更晚。布鲁克斯也明白,这是一种过度简化。但一般的论据是,新资源的时间增加和通信开销,会在短期内使开发速度减慢。而且,许多任务是密不可分的,换句话说,这样可以使更多的资源之间能轻易分配,这也意味着潜在的速度增长也更低。

谚语:十个女人不能在一个月内生一个孩子。与布鲁克斯法则同出一辙,特别是某些不可分割或者并行的工作。

这也是《人月神话》的中心主题。

参考

https://cloud.tencent.com/developer/article/1421055?from=article.detail.1525574

https://github.com/nusr/hacker-laws-zh

https://en.m.wikipedia.org/wiki/Brooks%27s_law

怎么判断当前使用的ssh命令是否是OpenSSH的?

要判断当前系统中使用的 ssh 命令是否是 OpenSSH 实现(OpenSSH 是 SSH 协议的最常见开源版本,在 Linux、macOS 等系统默认使用),可以采用以下方法。这些方法基于命令输出或文件检查,适用于大多数 Unix-like 系统(如 Ubuntu、macOS)。如果您使用 Windows,可能需调整为 PowerShell 或检查 PuTTY 等工具。

方法 1: 使用版本检查命令(推荐,最简单)

运行以下命令:

ssh -V

预期输出:

  • 如果是 OpenSSH,会显示类似:

OpenSSH_9.6p1, OpenSSL 3.0.13 30 Jan 2024

开头以 “OpenSSH_” 表示是 OpenSSH 版本(数字如 9.6p1 因系统而异)。

  • 如果不是 OpenSSH(如 Dropbear 或其他实现),输出可能不同,例如:

Dropbear: Dropbear ssh-2024.85

方法 2: 检查命令路径和链接

运行:

which ssh

输出路径如 /usr/bin/ssh(Ubuntu 默认)。

然后检查文件类型:

ls -l /usr/bin/ssh  # 替换为实际路径

如果是符号链接指向 OpenSSH 二进制(如 /usr/bin/ssh -> /usr/sbin/openssh-ssh),则可能是 OpenSSH。

或使用:

file /usr/bin/ssh

输出中包含 “ELF executable” 和架构信息,但不直接确认;结合版本检查使用。

方法 3: 检查安装包(适用于 Ubuntu/Debian 系统)

运行:

dpkg -S $(which ssh)

如果输出包含 “openssh-client” 或类似包名,则是 OpenSSH。

或者:

apt list --installed | grep openssh

看到 “openssh-client” 或 “openssh-server” 表示已安装 OpenSSH。

方法 4: 检查帮助或手册

运行:

ssh --help

OpenSSH 的帮助输出会列出特定选项(如 -V, -vvv),与其他实现(如 lsh 或 Tectia)不同。

常见注意事项

  • 多实现共存:如果系统有多个 SSH(如通过 Homebrew 在 macOS 安装),使用 which ssh 确认当前 PATH 中的是哪个。
  • 如果不是 OpenSSH:可能是 Dropbear(轻量级,用于嵌入式系统)、PuTTY(Windows GUI 工具)或其他商业实现(如 Tectia)。这些通常不支持所有 OpenSSH 选项。
  • 测试连接:运行 ssh -vvv user@host(详细模式),日志中会显示”OpenSSH”,如果是该实现。
  • 如果命令不存在,安装 OpenSSH:Ubuntu 上运行 sudo apt install openssh-client
  • Windows 11企业版自带OpenSSH。

The ~/.ssh/config File: Make Your SSH Life 10× Easier (and Safer)

If you SSH into multiple machines every day and you’re still typing long commands like

ssh -i ~/.ssh/special_key -p 2222 [email protected]

…then you are suffering needlessly.

The ~/.ssh/config file is the single best way to stop that pain. It’s a per-user OpenSSH client configuration file (usually at /home/yourname/.ssh/config or ~/.ssh/config on macOS/Linux), and it lets you centralize all your connection logic so you rarely need flags anymore.

What it actually does (the good parts)
1 Host aliases / nicknames
Turn ugly connection strings into one nice short name.

Host prod-db
    HostName 10.88.12.45
    User admin
    Port 2222
    IdentityFile ~/.ssh/prod_rsa

After that, you just type:

ssh prod-db

2 Common options you almost always want

  • User — default username
  • Port — non-22 ports
  • IdentityFile — which key to offer (and only that key if you pair it with IdentitiesOnly yes)
  • ProxyJump — jump hosts / bastions (the modern replacement for ProxyCommand)

Example with a bastion:

Host internal-server
    HostName 192.168.77.22
    User deploy
    ProxyJump bastion.corp.example.com

3 Wildcards & patterns for groups of hosts
Very powerful once you have 10+ machines with similar setup.

Host *.staging.example.com
    User staging
    IdentityFile ~/.ssh/staging_key
    ServerAliveInterval 30

Host prod-*
    IdentitiesOnly yes
    IdentityFile ~/.ssh/prod_ed25519

4 Security & hardening tricks (things people usually learn the hard way)

Host untrusted-host
    StrictHostKeyChecking accept-new
    UserKnownHostsFile /dev/null     # only for throwaway/testing hosts!

Host *
    # Good defaults everyone should consider
    ServerAliveInterval 60
    ServerAliveCountMax 3
    Compression yes                # sometimes helps a lot on slow links
    ForwardAgent no                # safer default nowadays

Quick example people actually use

# ~/.ssh/config

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 5
    AddKeysToAgent yes
    UseKeychain yes               # macOS only, keeps passphrase in keychain

Host jump
    HostName jump.corp.example.com
    User jumpuser

Host *.internal
    ProxyJump jump
    User app
    IdentityFile ~/.ssh/internal_ed25519

Host laptop
    HostName 192.168.1.88
    User pi
    Port 8822

Important gotchas / pro tips
1 Permissions must be 600: chmod 600 ~/.ssh/config
OpenSSH will silently ignore the file if it’s too permissive — very common source of “why isn’t my config working?” pain.

2 User-level ~/.ssh/config overrides /etc/ssh/ssh_config

3 The file is not shell script — no variables, no conditionals (except the limited Match blocks in newer OpenSSH versions)

4 You can split config into multiple files with Include (OpenSSH ≥7.3):

Include ~/.ssh/config.d/*.conf

Once you start using it properly, going back to flag-heavy SSH feels like using vi without a .vimrc. Highly recommended.

What are your favorite ~/.ssh/config tricks?

~/.ssh/config 文件的作用

~/.ssh/config 文件是 OpenSSH 客户端的配置文件,位于用户主目录下的 .ssh 子目录中(例如 /home/username/.ssh/config)。它允许用户自定义 SSH 连接的行为,而无需每次连接时手动指定选项。该文件的作用主要包括简化 SSH 操作、提升安全性和管理多个主机的连接配置。

主要作用

  • 简化命令:通过定义主机别名(Host),可以将复杂的连接参数封装起来。例如,将一个远程服务器的 IP、端口、用户名等预设为一个短名称,以后只需用 ssh alias 即可连接,而无需输入 ssh -p 2222 [email protected]
  • 自定义连接参数:支持设置各种 SSH 选项,如:

端口(Port):指定非标准端口。

用户名(User):默认登录用户。

密钥文件(IdentityFile):指定私钥路径,避免每次手动加载。

代理跳板(ProxyJump):配置跳板机连接。

其他高级选项:如 KeepAlive、Compression 等,用于优化连接稳定性或性能。

  • 提升安全性:可以限制特定主机的认证方式(如 IdentitiesOnly yes,只使用指定密钥),或禁用不安全的选项(如 StrictHostKeyChecking no,但不推荐)。
  • 主机匹配:支持通配符(如 Host *.example.com),对多个相似主机应用同一配置。

文件格式示例

文件是纯文本,使用键值对格式(不区分大小写)。示例:

Host myserver
    HostName 192.168.1.100
    User myuser
    Port 2222
    IdentityFile ~/.ssh/my_private_key

注意事项

  • 文件权限应为 600(chmod 600 ~/.ssh/config),以确保安全。
  • 如果文件不存在,可以手动创建。
  • 系统级配置在 /etc/ssh/ssh_config,但用户级 ~/.ssh/config 优先级更高。
  • 适用于 ssh、scp、sftp 等命令。

SEO技术之前端技术选型

前端页面使用静态页面(SSG)方式部署,是SEO最友好的。

前端页面使用服务器端渲染(SSR)方式呈现给搜索引擎,SEO次优。

如果你的前端主应用必须是使用Vue.js或React.js等框架开发的单页应用(SPA),但还有其他的营销相关页面 (落地页、关于页、wiki、博客等),请单独部署这些页面!理想情况下,营销页面应该是包含尽可能少js代码的静态HTML,并用静态页面(SSG)方式部署。

奥卡姆剃刀 (Occam’s Razor)又叫简约法则:如无必要,勿增实体

奥卡姆剃刀 (Occam’s Razor):如无必要,勿增实体。——奥卡姆的威廉 (William of Ockham)

奥卡姆剃刀指出,在几种可能的解决方案之中,最有可能的解决方案便是概念和假设最少的那个。因为这个解决方案最为简单,只解决了问题,并且没有引入额外的复杂度和可能的负面后果。

参见:

例子:

也就是说,在多个能够解决同一个问题的方法中,最简单有效的那种方法是最好的。

奥卡姆剃刀(英语:Ockham’s Razor、拉丁语:Lex Parsimoniae,意为“简约法则”)是由14世纪方济会修士奥卡姆的威廉(William of Occam,约1287年至1347年,英格兰萨里郡奥卡姆 (Ockham)人氏)提出的逻辑学法则,他在《箴言书注》2卷15题说“切勿浪费多余功夫去做本可以较少功夫完成之事”。换言之,如果关于同一个问题有许多种理论,每一种都能作出同样准确的预言,那么应该挑选其中使用假定最少的。尽管越复杂的方法通常能做出越好的预言,但是在不考虑预言能力(即结果大致相同)的情况下,假设越少越好。

所罗门诺夫的归纳推理理论是奥卡姆剃刀的数学公式化:在所有能够完美描述已有观测的可计算理论中,较短的可计算理论在估计下一次观测结果的概率时具有较大权重。

在自然科学中,奥卡姆剃刀被作为启发法技巧来使用,更多地作为帮助科学家发展理论模型的工具,而不是在已经发表的理论之间充当裁判角色。在科学方法中,奥卡姆剃刀并没有被当做逻辑上不可辩驳的定理或者科学结论。在科学方法中对简单性的偏好,是基于可证伪性的标准。对于某个现象的所有可接受的解释,都存在无数个可能的、更为复杂的变体:因为你可以把任何解释中的错误归结于特例假设,从而避免该错误的发生。所以,较简单的理论比复杂的理论更好,因为它们更加可检验。

客观剃刀理论

通用图灵机的最小指令集所需要的长度,在不同的形式中是大致相同的,而且其柯氏复杂度比大部分实际的理论小。马库斯·胡特在对剃刀的规范化中,利用这一恒常性定义了“自然”图灵机,用来排除那些过于复杂的指令集。将通用程序的描述作为“假设”,将证据的表示作为“程序数据”,可以在策梅洛-弗兰克尔集合论中证明:“模型的普适概率的对数之和加上模型输入的数据的概率的对数之和应为极小”。可以将它解释为让由两个部分组成符号串达到最短,包括模型的符号和数据的符号,这样我们就得到了最小描述长度定律。

将柯氏复杂性和奥卡姆剃刀的概念结合起来的可能结论之一是,一个理想的数据压缩器也会是一个科学解释/公式的产生器。已经有人尝试将已知的定律从简单性和压缩性的法则中重新推导出来。

对于居尔根·施密德胡贝尔来说,奥卡姆剃刀的恰当数学理论已经存在了,就是所罗门诺夫的归纳推断理论及其扩展。

反剃刀

康德为了对抗奥卡姆剃刀产生的影响,创建了他自己的反剃刀:“存在的多样性不应被粗暴地忽视”。

这么看来,奥卡姆剃刀过于实用主义了。

参考

https://github.com/nusr/hacker-laws-zh

https://en.wikipedia.org/wiki/Occam’s_razor

https://zh.wikipedia.org/wiki/%E5%A5%A5%E5%8D%A1%E5%A7%86%E5%89%83%E5%88%80

Unix哲学 (The Unix Philosophy):软件组件应该很小,并专注于做一件特定的事情

Unix 哲学指软件组件应该很小,并专注于做一件特定的事情。将小而简单以及定义良好的单元组合在一起,而不是使用大而复杂的多用途程序,可以更轻松地构建系统。

像微服务架构这种现代实践可以认为是这种哲学的应用,其中每个服务很小,集中于做一件特定的事情,由简单的构建块组成复杂的行为。

另外,盖尔定律 (Gall’s Law)也说了:一个复杂系统势必是从一个简单系统发展而来的。

Unix哲学是一套基于Unix操作系统顶级开发者们的经验提出的软件开发的准则和哲学。

McIlroy:A Quarter Century of Unix

UNIX 哲学由 Doug McIlroy 在1978年的《Bell System Technical Journal 》中发表。道格拉斯·麦克罗伊是Unix系统上管道机制的发明者,也是Unix文化的缔造者之一。他归纳的Unix哲学如下:程序应该只关注一个目标,并尽可能把它做好。让程序能够互相协同工作。应该让程序处理文本数据流,因为这是一个通用的接口。

更加简化的版本是:做一件事,做好它。虽然只有第三条是特指Unix系统的,但Unix开发者们常常同时强调这三个信条。

Pike:Notes on Programming in C

罗勃·派克在他的《Notes on Programming in C》中提到了以下格言。虽然这些规则是关于程序设计的,但作为Unix哲学丝毫不为过:

  • 规则一:你永远不会知道你的程序会在什么地方耗费时间。程序的瓶颈常常出现在意想不到的地方,因此在你确信找到瓶颈后再动手优化代码吧。过早优化是万恶之源
  • 规则二:测试代码。只有在你详细测试了代码,并且发现一部分代码耗费了绝大部分的运行时间时再对程序作速度优化。
  • 规则三:功能全面的算法(fancy algorithm)在处理小规模问题时效率很低,这是因为算法时间效率中的常量很大,而问题往往规模很小。除非你知道你遇到的常常是复杂的情况,否则就让代码丑陋但是简单而高效吧。(即使问题规模确实很大,也首先尝试第二条规则。)根据问题的规模选择对应算法,例如排序算法,在待排序的元素个数很少(两位数)时,使用冒泡排序算法,在待排序的元素个数很多时,使用快速排序算法
  • 规则四:功能全面的算法比简单的算法更容易产生Bug,更难实现。尽量使用简单的算法和数据结构。
  • 规则五:数据决定一切。如果选择的数据结构能很好的管理数据,算法部分往往不言自明。记住,数据结构,而非算法,才是编程的关键。精心设计的数据结构能达到使用简单算法就解决问题的目的。程序=精心设计的数据结构+尽量简单的算法
  • 规则六:没有第六条规则。

Pike的第一、二条规则重申了高德纳的著名格言:“过早的优化是一切罪恶的根源。” Pike的第三、四条规则被肯·汤普逊改述成:“疑惑不定之时最适合穷举。”事实上,这两条规则也是KISS原则的具体表现。则五在之前Fred Brooks的人月神话中也被提及。Jon Bentley的《Programming Pearls》中也有一章阐述了相同的设计哲学。此规则作为“如果你的数据结构很好,那么控制它的算法就无关痛痒了”的例子常常被简化成“简约地写代码,聪明地用数据”。第六条规则当然只是Pike针对蒙提·派森之小品Bruces sketch的幽默发挥而已了。

Mike Gancarz的《UNIX哲学》

1994年,X窗口系统开发组的成员Mike Gancarz根据他自己的Unix系统经验以及和其他领域使用Unix系统的资深程序员们的讨论结果,写成了The UNIX Philosophy,提出了9条训格之言:

一:小即是美。

二:让程序只做好一件事。

三:尽可能早地创建原型。

四:可移植性比效率更重要。现在应该是“可读性比效率更重要”

五:数据应该保存为文本文件。

六:尽可能地榨取软件的全部价值。

七:使用shell脚本来提高效率和可移植性。

八:避免使用可定制性低下的用户界面。

九:所有程序都是数据的过滤器。输入数据->程序->输出数据

此外还有十条原则则并不为所有人认同,甚至还是争论的焦点(如宏内核和微内核之争):

一:应该允许用户定制操作环境。安卓系统和苹果系统,有自己品牌的手机厂家会选择安卓系统,懂技术的极客也许喜欢安卓系统,普通用户喜欢苹果系统

二:让操作系统核心小而轻。

三:使用小写字母并尽量简短。

四:节约纸张,保护树林。

五:沉默是金。

六:并行地思考。人无法做到并行。在高性能服务器端,Go语言很流行,因为它可以方便地编写并发和(或)并行程序;有些轻量级的场景并不需要并发和(或)并行程序,此时使用Python、JavaScript等语言即可

七:部分加部分大于整体。

八:寻找问题的帕雷托法则。

九:程序随需求而增长(更糟就是更好)。软件是应该随着需求而进化

十:层级地思考。

糟糕的更好

Richard P. Gabriel 提议Unix的一个关键优势是他称作“糟糕的更好”的设计哲学。在“糟糕的更好”的设计风格下,接口和实现的简单性比系统的任何其他属性都更重要,包括准确性、一致性和完整性。Gabriel主张这种设计风格拥有关键的进化优势,尽管他也怀疑一些结果的质量。

参考

https://github.com/nusr/hacker-laws-zh

https://en.wikipedia.org/wiki/Unix_philosophy

https://zh.wikipedia.org/wiki/Unix%E5%93%B2%E5%AD%A6

Spotify 模型 (The Spotify Model):团队围绕功能而非技术进行组织

Spotify 模型是团队和组织结构的一种方法,已被 Spotify 实验室推广开来。在此模型中,团队围绕功能而非技术进行组织。

Spotify 模型还普及了部落、行会以及章节的概念,这些是组织结构的其他组成部分。

参考

https://github.com/nusr/hacker-laws-zh

https://engineering.atspotify.com/2014/03/27/spotify-engineering-culture-part-1