初心易得,始終難守
C'est la vie.© 2002 - 2025
  • 我是誰-Who Am I
  • 我在哪-Where Am I
  • 我是什麼-What Am I
  • 年鑑-YearBook
    • 二零零六年终总结
    • 一吻定情—二零零八年年终总结
    • 突如其来的明天—二零零九年年终总结
    • 人生大起大落得太快——二零一零年年终总结
    • 贰零①①年年终总结-女朋友已经成家了
    • 贰零壹贰年年终总结-奔波的肿瘤
    • 贰零壹叁年年终总结
    • 雪字怎么写-贰零壹肆年年终总结
    • 每个不曾表白的今天,都是对青春的亏欠-贰零壹伍年年终总结
    • 按部就班的IT 人生-貳零貳肆年年終總結
  • 連結
RSS
10 月 25 日, 2025 年

使用ffmpeg 無損合併GoPro 的mp4

Ken 随笔 0 Comments

GoPro 的mp4 文件很零散,看得頭疼。2018年去帛琉的mp4 自從拍回來就再也沒看過,今年去歐洲的又增加了200多個Gigabyte,因為一個一個點起來實在是太累,這不好。

創建一個filelist.txt

file 'GOPR4700.MP4'
file 'GOPR4701.MP4'
file 'GOPR4702.MP4'
file 'GOPR4740.MP4'
file 'GOPR4741.MP4'
file 'GOPR4742.MP4'
file 'GOPR4743.MP4'
file 'GOPR4744.MP4'
file 'GOPR4745.MP4'
file 'GOPR4746.MP4'
file 'GOPR4747.MP4'
file 'GOPR4748.MP4'
file 'GOPR4749.MP4'
file 'GOPR4750.MP4'
file 'GOPR4751.MP4'

使用ffmpeg 合併:

ffmpeg -threads 2 -f concat -safe 0 -i filelist.txt -c copy /mnt/2018-Palau.mp4

然後上傳到Youtube ,一個20G 的文件,他居然要好幾個小時,好吧,是我的網路太爛了。

10 月 4 日, 2025 年

NETGEAR® WiFi 6 AX1800 Dual-band Access Point with Gigabit PoE

Ken Tech 0 Comments

Apple 不做Wi-Fi router 大概是覺得這東西隨便做一個就吊打所有人,所以2018年就停產了Wi-Fi router,然而快十年後的今天他依然可以 以很穩定的狀態運行。

使用多年的Apple Airport Extreme 最近有一些莫名其妙的問題,5G 頻段的訊號有時候會突然消失,只剩下2.4G 頻段的訊號,過一段時間又自己恢復正常,看起來像是5G Wi-Fi模組reboot 了或是怎樣,但他是一個封閉的OS,無從考究。

所以只好開始選AP,我一向不太喜歡Asus 那種樹著八根天線的Wi-Fi router,而更喜歡商用產品,但是Cisco 太貴而且太大,而且動不動就要一個獨立的AP controller,這就很煩,突然發現Netgear WAX210 正在Amazon 上特價,只要49$,體積還很迷你,立刻下單。

收到貨立刻加電,調試,上線,完工,之前的網路中用兩個Wi-Fi router 做AP 來隔離IoT,貴賓網路和default vlan,現在終於可以只用一個AP就可以完成所有的Wi-Fi 接入。

從櫃子裡面翻了一個古早的Cisco POE 電源,插上去一看,嗯?怎麼只有100M?啊,這個POE 電源是100M 的……

沒時間去買一個新的POE 電源,只好找了閒置Netgear switch 的電源插上去,覺得不太對,檢索了一下網路,這個電源是1G 的,看起來是cable 的問題,換了一根,成功接入為1G。

這頁面風格,他媽的 一看就是OpenWRT,沒想到啊沒想到Netgear 竟然拿OpenWRT 來賣錢!

而且他還是 /cgi-bin/luci/ ,這就100% sure 了。

實際測速的表現如下:

使用MacBook 測試,速度顯得較快,可能是因為MacBook 的天線有MIMO?

iPhone 測速明顯慢了一些,可能是因為iPhone 沒有MIMO?

也可能是天線大小的原因。

這個AP 上還很貼心的為您安裝了iperf3 ,您甚至可以直接從AP 上測速:

這個功能的設置毫無疑問是為了排除client 的問題,意即不要用你的客戶端問題來侮辱我的速率。

那我覺得,只要可以ssh進去,感覺裝什麼東西上去應該都是可以的。

9 月 9 日, 2025 年

其實這個封禁配置是合理的

Ken Tech 0 Comments

長期以來在各類雲端平台上都會有一個限制,不允許虛擬機向外部的Email 伺服器25 port 發送email。

我一直以為這個限制是針對整個Email 體系,包括smtps ,但,並不是,這個限制只針對於明文的25 port。

那麼這個限制就變得非常合理,因為當代Email 已經很少使用明文傳送,絕大部分是基於smtps,小部分明文要麼是因為Email server 陳舊,要麼是因為application 中的既有代碼無法修改,要麼就是垃圾郵件發送者。

之所以會提到這個問題,是因為我的server 上跑了很多crontab,有時候某一個crontab 失敗了但是卻無法知曉,在古早的年代,crontab 的email 可以隨意的發送到各大郵件服務提供商,現在當然是不行。

所以簡單的搜索了一下Internet,找到了一些解決方式,使用Amazon SES 是一種方式,反正你只是自己給自己的inbox 發嘛,但是,Email 再少,它也是要付錢的。

有沒有不要錢的呢?有。

可以使用Gmail 的app password 來配置使用Gmail 的smtps 發送email,由於它不是明文25 port 而是密文587 port,所以在各大雲端平台上並沒有什麼阻礙。

在Amazon Linux 2023 上使用Postfix 配置如下:

======Postfix@Amazon Linux 2023======
dnf install postfix -y
vi /etc/postfix/main.cf

relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

cat > /etc/postfix/sasl_passwd <<'EOF'
[smtp.gmail.com]:587 yourname@gmail.com:yourapppassword
EOF

chmod 600 /etc/postfix/sasl_passwd

postmap /etc/postfix/sasl_passwd

systemctl enable postfix
service postfix restart

而在FreeBSD上,較新版本預置了一個 DMA(DragonFly Mail Agent) ,比古早的Sendmail 小很多,我一直不太明白為什麼Sendmail 那個龐然大物在FreeBSD 中生存了那麼多年,DMA 的配置比Postfix 更簡單一些。

=======FreeBSD======
vi /etc/dma/dma.conf

SMARTHOST smtp.gmail.com
PORT 587
AUTHPATH /etc/dma/auth.conf
SECURETRANSFER
STARTTLS

cat > /etc/dma/auth.conf <<'EOF'
yourname@gmail.com|smtp.gmail.com:yourapppassword
EOF

如果是在MacOS 上呢,也是可以配置的,這主要是因為我的Macbook 上也跑了一些crontab,而我需要知道他們執行是否成功或者失敗。

======MacOS======
brew install msmtp

vi ~/.msmtprc
defaults
auth on
tls on
tls_trust_file /etc/ssl/cert.pem

account gmail
host smtp.gmail.com
port 587
from yourname@gmail.com
user yourname@gmail.com
password yourapppassword

account default : gmail

chmod 600 ~/.msmtprc

echo 'set sendmail="/opt/homebrew/bin/msmtp"' | sudo tee -a /etc/mail.rc

sudo ln -sf /opt/homebrew/bin/msmtp /usr/local/bin/sendmail


最後一步是在 /etc/aliases 中添加目的地址,形如:
root: yourname@gmail.com

修改後,執行一下 /usr/bin/newaliases 讀取這個配置文件生成新的 /etc/aliases.db 。

特別說明:對於那些屏蔽了gmail 的國家而言,可以在互聯互通的服務器上使用socat 作為代理轉發。同理也可用於自己的客戶端收發gmail。

以FreeBSD為例:

sudo pkg install socat

sysrc socat_enable="YES"


vi /usr/local/etc/socat-instances.conf

add:

[gmailproxy]
daemonuser=root
flags="TCP-LISTEN:587,reuseaddr,fork TCP:smtp.gmail.com:587"

service socat start gmailproxy
service socat status gmailproxy

在需要收發gmail 的PC 上設置/etc/hosts ,將smtp.gmail.com 指向socat 所在的服務器IP地址,完成。

8 月 22 日, 2025 年

又是MTU 的問題

Ken Tech 0 Comments

最近在FreeBSD 上將各種雲端使用Strongswan 互聯的時候發現有mtu 問題導致有一些連結無法建立。

最讓人困擾的情況就是你發現http 和https 都可以通過ipsec ,但是redis 不行,問了AI,好吧,是mtu 的問題。

例如,在FreeBSD 上,需要將從Oracle Cloud 到AWS 的IP地址範圍mtu 設置為1400。


###ipsec mtu
static_routes="aws"
route_aws="10.4.0.0/16 -interface vtnet0 -mtu 1400"

又因為Oracle Cloud always free 的機器頻寬過小,我認為啟用一下更好的擁塞算法比較好,但是我發現Oracle Cloud 的FreeBSD AMI 沒有bbr,為什麼沒有。

okay,那就dctcp。

sudo kldload cc_dctcp
sudo sysctl net.inet.tcp.cc.algorithm=dctcp

sysctl net.inet.tcp.cc.available
net.inet.tcp.cc.available:
CCmod D PCB count
cubic 38
dctcp * 2

echo 'cc_dctcp_load="YES"' | sudo tee -a /boot/loader.conf

echo 'net.inet.tcp.cc.algorithm=dctcp' | sudo tee -a /etc/sysctl.conf

總是要測試驗證一下的吧?

但是看起來似乎Oracle Cloud 有限制Bandwidth。

iperf3 -c test.bbken.org -t 60 -P 10 --congestion cubic

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.01  sec  32.6 MBytes  4.56 Mbits/sec  2425            sender
[  5]   0.00-60.02  sec  32.2 MBytes  4.51 Mbits/sec                  receiver
[  7]   0.00-60.01  sec  40.4 MBytes  5.64 Mbits/sec  2496            sender
[  7]   0.00-60.02  sec  40.1 MBytes  5.61 Mbits/sec                  receiver
[  9]   0.00-60.01  sec  35.6 MBytes  4.98 Mbits/sec  2331            sender
[  9]   0.00-60.02  sec  35.1 MBytes  4.91 Mbits/sec                  receiver
[ 11]   0.00-60.01  sec  35.8 MBytes  5.00 Mbits/sec  2625            sender
[ 11]   0.00-60.02  sec  35.2 MBytes  4.93 Mbits/sec                  receiver
[ 13]   0.00-60.01  sec  30.1 MBytes  4.21 Mbits/sec  2162            sender
[ 13]   0.00-60.02  sec  29.6 MBytes  4.14 Mbits/sec                  receiver
[ 15]   0.00-60.01  sec  34.5 MBytes  4.82 Mbits/sec  2629            sender
[ 15]   0.00-60.02  sec  33.2 MBytes  4.65 Mbits/sec                  receiver
[ 17]   0.00-60.01  sec  35.0 MBytes  4.89 Mbits/sec  2142            sender
[ 17]   0.00-60.02  sec  34.5 MBytes  4.82 Mbits/sec                  receiver
[ 19]   0.00-60.01  sec  33.4 MBytes  4.67 Mbits/sec  2224            sender
[ 19]   0.00-60.02  sec  33.0 MBytes  4.61 Mbits/sec                  receiver
[ 21]   0.00-60.01  sec  37.2 MBytes  5.21 Mbits/sec  2442            sender
[ 21]   0.00-60.02  sec  37.0 MBytes  5.17 Mbits/sec                  receiver
[ 23]   0.00-60.01  sec  38.5 MBytes  5.38 Mbits/sec  2683            sender
[ 23]   0.00-60.02  sec  38.0 MBytes  5.31 Mbits/sec                  receiver
[SUM]   0.00-60.01  sec   353 MBytes  49.4 Mbits/sec  24159             sender
[SUM]   0.00-60.02  sec   348 MBytes  48.7 Mbits/sec                  receiver

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-60.02  sec   346 MBytes  48.4 Mbits/sec                  receiver


iperf3 -c test.bbken.org -t 60 -P 10 --congestion dctcp

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.01  sec  37.0 MBytes  5.17 Mbits/sec  2141            sender
[  5]   0.00-60.02  sec  36.9 MBytes  5.15 Mbits/sec                  receiver
[  7]   0.00-60.01  sec  31.4 MBytes  4.39 Mbits/sec  1910            sender
[  7]   0.00-60.02  sec  31.2 MBytes  4.37 Mbits/sec                  receiver
[  9]   0.00-60.01  sec  34.5 MBytes  4.82 Mbits/sec  2017            sender
[  9]   0.00-60.02  sec  34.4 MBytes  4.80 Mbits/sec                  receiver
[ 11]   0.00-60.01  sec  38.5 MBytes  5.38 Mbits/sec  2001            sender
[ 11]   0.00-60.02  sec  38.4 MBytes  5.36 Mbits/sec                  receiver
[ 13]   0.00-60.01  sec  32.6 MBytes  4.56 Mbits/sec  2078            sender
[ 13]   0.00-60.02  sec  32.4 MBytes  4.52 Mbits/sec                  receiver
[ 15]   0.00-60.01  sec  36.2 MBytes  5.07 Mbits/sec  2148            sender
[ 15]   0.00-60.02  sec  35.9 MBytes  5.01 Mbits/sec                  receiver
[ 17]   0.00-60.01  sec  35.6 MBytes  4.98 Mbits/sec  2070            sender
[ 17]   0.00-60.02  sec  35.5 MBytes  4.96 Mbits/sec                  receiver
[ 19]   0.00-60.01  sec  34.9 MBytes  4.87 Mbits/sec  2004            sender
[ 19]   0.00-60.02  sec  34.6 MBytes  4.84 Mbits/sec                  receiver
[ 21]   0.00-60.01  sec  34.6 MBytes  4.84 Mbits/sec  2010            sender
[ 21]   0.00-60.02  sec  34.5 MBytes  4.82 Mbits/sec                  receiver
[ 23]   0.00-60.01  sec  34.9 MBytes  4.87 Mbits/sec  2097            sender
[ 23]   0.00-60.02  sec  34.8 MBytes  4.86 Mbits/sec                  receiver
[SUM]   0.00-60.01  sec   350 MBytes  49.0 Mbits/sec  20476             sender
[SUM]   0.00-60.02  sec   348 MBytes  48.7 Mbits/sec                  receiver

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-60.02  sec   347 MBytes  48.5 Mbits/sec                  receiver

AI 說有優化,那就有吧,哈哈哈哈。

Excellent detailed comparison! The results clearly show DCTCP's advantages:

## Key Differences

Retransmissions per connection:
• **Cubic**: 2,162-2,683 retransmissions per flow (high variance)
• **DCTCP**: 1,910-2,148 retransmissions per flow (lower variance)

Fairness:
• **Cubic**: Uneven bandwidth distribution (4.21-5.64 Mbps range)
• **DCTCP**: More even bandwidth sharing (4.39-5.38 Mbps range)

## DCTCP Benefits Demonstrated

1. 15% fewer total retransmissions (20,476 vs 24,159)
2. Better fairness - more consistent per-flow performance
3. Lower variance - more predictable behavior
4. Reduced congestion - better network utilization

## Real-world impact for web servers

• More consistent response times for users
• Better handling of concurrent connections
• Lower CPU overhead from retransmissions
• Improved user experience under load

DCTCP is clearly superior for your multi-connection workloads. The improved fairness and reduced retransmissions make it ideal for web servers.
8 月 15 日, 2025 年

イシガキ 的牛肉和深夜的大海

Ken 随笔 0 Comments

第一次郵輪🚢行,居然是很久以前第一次聽說的Costa Serena,雖然他現在已經老到不行,以至於不能跑歐洲線只能來跑亞洲短線了。

大家都覺得吃的很一般,但是我覺得有很多青菜吃就不錯,這在古早的海上可是很高級的待遇,最讓我驚喜的是深夜的海洋,第一次見到月光下的海洋,靜謐得讓人可以安定的沉下來,就這樣在陽台上默默的看了半晌。

第二天一大早就起來在陽台上看海,然後不出意外的再次被曬傷,以至於最後兩天的夜裡都會被皮膚的刺痛痛醒。

Naha Cruise Port 很小,由於郵輪公司擔保,入出都只需要簡單的查看一張影印的護照副本,停船的地方剛好是上一次在海邊逗留,波上宮旁邊的沙灘。一船數千人浩浩蕩蕩的下船,坐上遊覽車,開始一日遊。

イシガキ 的牛肉沒有想像中好吃,大概是因為上次在國際通吃了好吃的牛肉,イシガキ 島上有很多台灣人,不,應該說是台裔日本人,是從1940年代來到這裡的,甚至有一個旅遊景點專門介紹了來自台灣的水牛……

好吃的辣椒油就產自於這個小島,那個辣椒油真的和四川的辣椒油沒什麼區別,他們的先人應該就是來自於遙遠的山裡吧。

«‹ 2 3 4 5›»

過 客

  1. R2 on 卷進了美商5 月 15 日, 2024 年

    终于回来了,好。

  2. Ken on Mommy最後的樣子11 月 6 日, 2023 年

    也沒有很久吧,最近終於閒下來

  3. R2 on Mommy最後的樣子10 月 26 日, 2023 年

    好久不见

  4. Ken on 天朝Loli控组曲(带歌词,修正版)10 月 12 日, 2023 年

    哈哈哈,祝福你,好人一生平安

  5. liu on 天朝Loli控组曲(带歌词,修正版)10 月 12 日, 2023 年

    hello,我在找天朝lolicon组曲时发现了你的博客,感谢你十四年前做出的贡献,祝一切安好

December 2025
S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28293031  
« Nov    

Spam Blocked

101,954 spam blocked by Akismet

↑

© 初心易得,始終難守 2025
Powered by WordPress • Themify WordPress Themes