世界一直前進著
續前篇，東西推上 cloud 之後就是換新設備了。新的 Server 更省電效能也更厲害：
RAM 本來打算買 32 GB 的，不知怎的回到家才發現買了 16 GB，再出去換也太麻煩。既然價單沒錯就罷了，反正之前都在用 16 GB 所以照著用也沒差吧。
説起來現在的散熱器得另購啊，以前都會送一個的。不過今次散熱決定用風冷了，買了個 NH-P1。望著佔了整整半個機箱的散熱「塔」，讓我覺得自己完全跟時代脱節了呢。
而且風扇也好講究，買一個要價 HKD 200，不過幸好這個散熱有送，沒有的話我會決定不裝了，反正這個散熱塔直接用機箱自帶的應該很夠。
這個機箱有外置的風速調整呢，哎呀時隔十年的發展就表現在這些細微的地方，沒有的話沒差，有的話會覺得很不錯。然後就是各種各樣的很不錯疊加在一起後變成不得了的感覺。
（機箱氣流大概是這個樣子）
現在室温是 20.8℃，能將温度壓至 26℃ 真的好厲害啊。這樣夏天的話應該會是 40℃ 左右吧。
新 Server 弄了兩天算是弄好了，因為架構改變了，後來幾天就是設計新的備份方案。
寫了個 script 將 blog 的 database 自動 upload 到 backblaze b2 上面，源碼看似簡單，其實花了我兩天時間才弄出來的。由其是簽名的部份弄了好久對面都説 invalid（backblaze b2），後來發現用 AWS 的 S3 有給提示，結果用 AWS 調試完才接回去 backblaze 那邊。
這個 blog 的 db dump 出來後就只有 3 MB 呢，所以 b2 上的 10GB 免費可以備份 3000 次，不過免費的東西是完全不能信任的，所以經加密過才上載。
然後 blog 的 assets 佔了 2GB（大部份都是圖片），這就不用 b2 了。直接每天 archive 到 web 上面，由這邊的伺服器定期下載後再推到 NAS 裏面去。
這是要我重寫嗎？沒記錯 event-based 跟 async-based 好像合不來；總之先將 redis 的 adapter 弄成 async……暫且過關了。不過 async 噴錯的話 domain 好像會爆炸，而且 nodejs 一直沒有 domain 的替代方案，我是不太想換成 async-based 啦。
還是説捨棄 domain 直接容許閃退？k8s 的話閃退也能只動復活，不過閃退了的話其他 session 會一起陪葬，所以還是不行啊。
只能退回早期版本了？要重寫的話那我不如不要 nodejs，改用 go 或者 .Net 算了。
……
但就算這個不用 async，也難以保證其他 library 的 dependency 沒有用 async 吧？也就是説 domain 根本上就是壞得差不多了。
呀好麻煩，這個問題擱置，先捲回早期版本。這個問題不重要！
其他比較首要的問題就是以前 core 沒有的東西現在有了，所以得將替代的 library 去掉並用 core 的 api 來做。例如 bcrypt，雖然現在也沒有 bcrypt，不過可以用 pbkdf2 取代了。
還有就是 mkdirp 呢，真是搞不懂當初這麼基本的 api core 會沒有啊。
想著想著其實連 mongoose 也可以不要，當初是經驗不足，從 MySQL migrate 過來的時候沿用了 relational 的設計，現在覺得完全沒必要呢。
好，慢慢來吧。這會有得忙了。
| 配置 | 舊 | 新 |
| CPU | i5-4590S | i5-12600K |
| RAM | 16 GB | 16 GB |
| Storage | 128G SSD, 2TB HDD, 500G HDD | 2x2TB SSD M2 |
説起來現在的散熱器得另購啊，以前都會送一個的。不過今次散熱決定用風冷了，買了個 NH-P1。望著佔了整整半個機箱的散熱「塔」，讓我覺得自己完全跟時代脱節了呢。
而且風扇也好講究，買一個要價 HKD 200，不過幸好這個散熱有送，沒有的話我會決定不裝了，反正這個散熱塔直接用機箱自帶的應該很夠。
這個機箱有外置的風速調整呢，哎呀時隔十年的發展就表現在這些細微的地方，沒有的話沒差，有的話會覺得很不錯。然後就是各種各樣的很不錯疊加在一起後變成不得了的感覺。
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +26.0°C (high = +80.0°C, crit = +100.0°C)
Core 0: +22.0°C (high = +80.0°C, crit = +100.0°C)
Core 4: +24.0°C (high = +80.0°C, crit = +100.0°C)
Core 8: +22.0°C (high = +80.0°C, crit = +100.0°C)
Core 12: +24.0°C (high = +80.0°C, crit = +100.0°C)
Core 16: +25.0°C (high = +80.0°C, crit = +100.0°C)
Core 20: +25.0°C (high = +80.0°C, crit = +100.0°C)
Core 28: +26.0°C (high = +80.0°C, crit = +100.0°C)
Core 29: +26.0°C (high = +80.0°C, crit = +100.0°C)
Core 30: +26.0°C (high = +80.0°C, crit = +100.0°C)
Core 31: +27.0°C (high = +80.0°C, crit = +100.0°C)
新 Server 弄了兩天算是弄好了，因為架構改變了，後來幾天就是設計新的備份方案。
寫了個 script 將 blog 的 database 自動 upload 到 backblaze b2 上面，源碼看似簡單，其實花了我兩天時間才弄出來的。由其是簽名的部份弄了好久對面都説 invalid（backblaze b2），後來發現用 AWS 的 S3 有給提示，結果用 AWS 調試完才接回去 backblaze 那邊。
這個 blog 的 db dump 出來後就只有 3 MB 呢，所以 b2 上的 10GB 免費可以備份 3000 次，不過免費的東西是完全不能信任的，所以經加密過才上載。
然後 blog 的 assets 佔了 2GB（大部份都是圖片），這就不用 b2 了。直接每天 archive 到 web 上面，由這邊的伺服器定期下載後再推到 NAS 裏面去。
源碼好像過時了
現在正在維護 blog 的源碼，發現 Redis 的新 module 直接換成了 async-based 的 approach，這邊的源碼一直都是 event-based，更新之後 blog 就壞掉了。這是要我重寫嗎？沒記錯 event-based 跟 async-based 好像合不來；總之先將 redis 的 adapter 弄成 async……暫且過關了。不過 async 噴錯的話 domain 好像會爆炸，而且 nodejs 一直沒有 domain 的替代方案，我是不太想換成 async-based 啦。
還是説捨棄 domain 直接容許閃退？k8s 的話閃退也能只動復活，不過閃退了的話其他 session 會一起陪葬，所以還是不行啊。
只能退回早期版本了？要重寫的話那我不如不要 nodejs，改用 go 或者 .Net 算了。
……
但就算這個不用 async，也難以保證其他 library 的 dependency 沒有用 async 吧？也就是説 domain 根本上就是壞得差不多了。
呀好麻煩，這個問題擱置，先捲回早期版本。這個問題不重要！
其他比較首要的問題就是以前 core 沒有的東西現在有了，所以得將替代的 library 去掉並用 core 的 api 來做。例如 bcrypt，雖然現在也沒有 bcrypt，不過可以用 pbkdf2 取代了。
還有就是 mkdirp 呢，真是搞不懂當初這麼基本的 api core 會沒有啊。
想著想著其實連 mongoose 也可以不要，當初是經驗不足，從 MySQL migrate 過來的時候沿用了 relational 的設計，現在覺得完全沒必要呢。
好，慢慢來吧。這會有得忙了。
Sun Apr 03 2022 03:36:11 GMT+0000 (Coordinated Universal Time)
Last modified: Sun Apr 03 2022 03:36:19 GMT+0000 (Coordinated Universal Time)
Comments
No comments here.
Do you even comment?
website:
Not a valid website
Invalid email format
Please enter your email
*Name:
Please enter a name
Submit
抱歉，Google Recaptcha 服務被牆掉了，所以不能回覆了