Scribbles for my bad memory

作者：尼尔 舒宾 （Neil Shubin)

2024-09-18 19:24:47
没有什么事情始于你认为它开始的时候。

2024-09-23 21:49:52
生物创新从来不是伴随着与之相关的巨大转变而出现的。羽毛并不是出现在飞行演化的过程中，肺和附肢也不是出现在脊椎动物登上陆地的过程中。更重要的是，如果没有这些创新，生命史上的重大变革以及其他类似的转变将不可能发生。生命史上的重大转变不必等待许多创新同时出现，而是通过给已有的结构赋予新的功能来实现的。早在很久之前，创新的前体就已经存在了。事情并非始于你认为它们开始的时候。

2024-09-25 10:23:02
如果林奈认为蝾螈是造物的底线，那么其他人则将它们视为原始的，甚至是有魔法的生物。从老普林尼到奥古斯丁，哲学家将蝾螈想象成从熔岩、地狱或火焰中诞生的生物。对奥古斯丁而言，蝾螈是有人真的因诅咒而葬身火海的切实证据。奥古斯丁的观点源于一种说法，即蝾螈能抵抗火焰或从篝火中涌出。这些超能力可能反映出它们的某些生物学特征。正如水族馆管理员和蝾螈爱好者所知，一些种类的蝾螈喜欢藏身在腐烂的原木底面。在奥古斯丁的年代，人们捡拾柴火的时候无意间捡到了这些藏着蝾螈的原木。当他们点燃原木后看到蝾螈从里面跑出来时，无疑会惊呼“这是什么邪恶的东西”。

2024-09-25 11:15:21
你可以在蛋壳上切一个洞，让光线从蛋的侧面射入，然后将蛋放在显微镜下观察里面的胚胎。胚胎开始于蛋黄顶部的一小团白色细胞。时间一天天过去，胚胎逐渐长大，出现各种可以识别的标志——头、尾、背部、翅膀和腿。这个过程感觉就像是一场精心编写的舞剧。最初，受精卵经历了一系列分裂，一个细胞变成两个，两个变成四个，四个变成八个，依此类推。随着细胞增殖，胚胎最终变成了一个细胞团。几天后，胚胎从一个空心球变成简单的细胞盘，周围的细胞负责保护和提供营养，并为胚胎发育创造合适的环境。最终，一个完整的生物体会从这个简单的细胞盘中孕育而出
注: 这不就是操作系统自举的过程吗？！

2024-09-25 16:42:51
当海鞘刚从卵中孵化出来时，它们长得像蝌蚪一样，可以自由地游动。后来它们经历了变态发育，沉入水底，附着在岩石上。如果有什么“蝌蚪”可以唤起人类的想象力，那就是海鞘的幼体了。它们自由游动的样子与成体一点儿也不像。它们有着大大的脑袋，通过前后摆动尾部来推动身体前进。在它们体内，一条神经管沿着背部延伸，还有一条结缔组织棒（脊索）从头延伸到尾；它们的头后甚至还有鳃裂。脊椎动物的假想祖先的三个基本特征，都可以在海鞘幼体中找到。

2024-09-25 16:44:07
然后，随着发育进行，这些特征又在海鞘幼体中消失了，或者至少那些从以人类为中心的观点来看重要的特征消失了。几周后，蝌蚪状的海鞘幼体游到了水底。在下降的过程中，它逐渐失去了尾巴、神经管以及几乎整条结缔组织棒，鳃裂变成了抽水装置的一部分。它附着在岩石上，在余生中将成为一台固定的“抽水机”。一条有着脊椎动物身体基础构造的小蝌蚪，会变成让人误以为是植物的东西。

2024-09-25 17:28:43
在《理想国》中，柏拉图认为不变的理念才是所有多样性背后的基础，多变的现实物体只不过是理念的实体表现。从水杯到房屋，再到柏拉图，所有物体的多样性都可以归结为形而上学的本质，从中衍生出各种实体表现形式。

2024-09-25 17:34:55

If you're tired of seeing the "Are you sure you want to continue connecting (yes/no/[fingerprint])?" prompt every time you SSH into a new server, you're not alone. This security feature, while important, can be a bit of a nuisance for system administrators and developers who frequently connect to new machines. This is especially true when they wish to run a remote command on a newly trusted machine. Let's explore how to streamline this process without completely compromising security.

Understanding the Prompt

First, it's important to understand why this prompt appears. It's a security measure designed to protect you from man-in-the-middle attacks by verifying the authenticity of the server you're connecting to. However, in controlled environments or for non-critical systems, you might want to bypass this prompt.

The Quick Fix: StrictHostKeyChecking

One simple way to avoid this prompt is by using the StrictHostKeyChecking option. You can add this to your SSH command like this:

ssh -o StrictHostKeyChecking=accept-new user@hostname

But what if you want to make this change permanent? You can add it to your SSH config file:

1. Open or create your SSH config file:

   vim ~/.ssh/config
   

2. Add the following line:

   StrictHostKeyChecking accept-new
   

This setting will automatically accept and save new host keys without prompting, while still warning you if a known host's key has changed.

Security Considerations

While this method is convenient, it's important to understand the security implications:

• It automatically accepts keys from new, unknown hosts.
• It still protects you from potential man-in-the-middle attacks on known hosts.
• It assumes you trust your network and the new hosts you're connecting to.

When to Use This Method

This approach is best suited for:

• Environments where you frequently connect to new, trusted hosts.

• Controlled, secure networks.

• Scenarios where the convenience outweighs the risk of not manually verifying each new host.

IF statement won't work directly in standard SQL scripts outside of a stored procedure or function in MySQL. Thus, we will have to use a different approach using CREATE PROCEDURE to encapsulate the logic. Here’s an example that you can reference to create a stored procedure to safely make the changes:

DELIMITER //

CREATE PROCEDURE AdjustFilesTable()
BEGIN
    -- Change FileExt from char(4) to char(5) if it exists
    IF (SELECT COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS 
        WHERE TABLE_NAME = 'Files' AND COLUMN_NAME = 'FileExt') > 0 THEN
        SET @sql = 'ALTER TABLE Files CHANGE COLUMN FileExt FileExt CHAR(5) NOT NULL';
        PREPARE stmt FROM @sql;
        EXECUTE stmt;
        DEALLOCATE PREPARE stmt;
    END IF;

    -- Rename CreateAt to CreatedAt if it exists
    IF (SELECT COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS 
        WHERE TABLE_NAME = 'Files' AND COLUMN_NAME = 'CreateAt') > 0 THEN
        SET @sql = 'ALTER TABLE Files CHANGE COLUMN CreateAt CreatedAt BIGINT DEFAULT NULL';
        PREPARE stmt FROM @sql;
        EXECUTE stmt;
        DEALLOCATE PREPARE stmt;
    END IF;

    -- Rename UpdateAt to UpdatedAt if it exists
    IF (SELECT COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS 
        WHERE TABLE_NAME = 'Files' AND COLUMN_NAME = 'UpdateAt') > 0 THEN
        SET @sql = 'ALTER TABLE Files CHANGE COLUMN UpdateAt UpdatedAt BIGINT DEFAULT NULL';
        PREPARE stmt FROM @sql;
        EXECUTE stmt;
        DEALLOCATE PREPARE stmt;
    END IF;
END //

DELIMITER ;

-- Call the procedure to adjust the table
CALL AdjustFilesTable();

-- Optionally, drop the procedure afterwards
DROP PROCEDURE IF EXISTS AdjustFilesTable;

Explanation:

1. Stored Procedure Creation: We create a stored procedure named AdjustFilesTable that contains the logic to adjust the table.
2. Conditional Logic: Inside the procedure, we use IF statements to check for the existence of each column before attempting to alter it.
3. Dynamic SQL Execution: We prepare, execute, and deallocate the statements as needed.
4. Calling the Procedure: After creating the procedure, we call it to perform the adjustments.
5. Cleanup: Optionally, you can drop the procedure afterward to prevent clutter.

Note:

• Make sure you have the necessary permissions to create procedures in your MySQL environment.

通常 A 机器和 B 机器已经在 ~/.ssh/config 中定义并建立了信任关系，因此我们可以直接使用主机别名，而不需要使用 user@B_machine 的方式。

sync_files.sh 脚本

#!/bin/bash

# 定义源和目标目录
SOURCE_DIR="/data/files/"
DEST_DIR="B_machine:~/backups/A_machine/data/files"

# 执行 rsync 命令
rsync -av --exclude='tmp/' "$SOURCE_DIR" "$DEST_DIR"

1. 确保脚本有执行权限：

   chmod +x sync_files.sh
   

2. 使用 cron 设置每五分钟执行一次该脚本：

   crontab -e
   

   添加：

   */5 * * * * /path/to/sync_files.sh
   

在 Linux 系统上，/var/log/journal 目录通常用来存储系统日志。如果这个目录占用了过多的空间，可以通过以下几种方法来管理和限制日志的大小：

1. 修改 journald 配置

你可以通过修改 journald 的配置文件来设置日志的最大大小和保留时间：

1. 打开终端。

2. 编辑 journald 配置文件：

   sudo nano /etc/systemd/journald.conf
   

3. 在文件中添加或修改以下配置项：

   [Journal]
   SystemMaxUse=500M
   SystemKeepFree=100M
   SystemMaxFileSize=50M
   SystemMaxFiles=10
   

   这些选项的含义如下：

   • SystemMaxUse：限制日志的总大小。
   • SystemKeepFree：保留的磁盘空间。
   • SystemMaxFileSize：每个日志文件的最大大小。
   • SystemMaxFiles：最大日志文件数。

4. 保存文件并退出编辑器。

5. 重新启动 journald 服务以应用更改：

   sudo systemctl restart systemd-journald
   

2. 清理现有日志

如果你想立即释放一些空间，可以手动清理旧的日志文件：

sudo journalctl --vacuum-size=500M

这条命令会将日志文件的总大小限制在 500MB。

3. 定期清理日志

你可以使用 cron 任务来定期清理日志。例如，可以设置一个每天执行的任务来保持日志的大小在一个合理的范围内。

1. 打开 cron 编辑器：

   crontab -e
   

2. 添加以下行以每天清理日志：

   0 0 * * * /usr/bin/journalctl --vacuum-time=7d
   

   这样设置后，系统将每天清理超过 7 天的日志。