source: technews
有喔！筆者上次在光線較不充足的室內用 Sony XZ1 Compact 前鏡頭自拍，發現螢幕閃了一下…覺得奇怪，怎麼按快門畫面會瞬間變白1-2秒？多試了幾次才發現，原來是靠螢幕亮白光來當閃光燈嗎？找了一些資料，發現的確現在很多新手機都使用螢幕來當前鏡頭的打光了，畢竟前鏡頭都是自拍居多，用拍照的閃光燈也許太亮了？也有些手機螢幕不是變全白，而是變膚色的畫面，應該是經過實驗證明，透過膚色的打光拍出來比較有美肌效果吧XD
2018年5月29日 星期二
2018年4月1日 星期日
2018年3月31日 星期六
2018年2月28日 星期三
2017年11月29日 星期三
[閱讀]《刻意練習》讀書概要
看了太多 Youtuber、網路文章、同事的推薦，決定找來看，實際看完覺得還好，收穫不多。我本來就相信有目標有正確方法的練習可以持續進步，但是在此之前，我認為最大的問題是...我怎麼知道我要訂什麼目標？我想要成為什麼樣的人？
新的方法突破
紅色這兩點大概是我認為再同意不過的，但也是很難滿足的條件。
2017年10月1日 星期日
Google 簡立峰：AI 科技的產業應用 - 演講紀錄
Tinder 公司擁有這些數據所以全都知道，只有我們自己不知道。因此，這些我們稱為隱私的 Data，如果不幸被偷走，就像我們弄丟身分證一樣，誰知道會不會被拿來做什麼奇怪的事情呢？
2017年9月25日 星期一
2017年8月31日 星期四
2017年7月30日 星期日
負向偏誤(Negativity bias) VS. 正向補償(Positivity offset)
太久沒更新 blog 了，決定以後不論收穫是大或小，即使自己無法 output 太多想法，只要覺得適合分享，就上來寫一下，強迫自己養成歸納與寫作的習慣吧。
今天想寫內容的主要是從人類演化的觀點來看我們現在的思考方式：為什麼我們容易有負面想法？為什麼我們比較在意壞消息與輕信負向的事物？心理學家說，這是因為負向偏誤 (negativity bias) 在作祟。
最近剛好看到兩則來源都提到類似的想法，第一則來源是從罗辑思维第298期「为什么相信阴谋论」聽來的，有興趣可以進入以下連結收看：
心理學有時候很有趣，尤其是當可以對應到自己的思考方式或生活狀況的時候特別有趣，就像十二星座算命那樣，算得準就覺得這個算命讚讚讚XD
今天想寫內容的主要是從人類演化的觀點來看我們現在的思考方式：為什麼我們容易有負面想法？為什麼我們比較在意壞消息與輕信負向的事物？心理學家說，這是因為負向偏誤 (negativity bias) 在作祟。
最近剛好看到兩則來源都提到類似的想法，第一則來源是從罗辑思维第298期「为什么相信阴谋论」聽來的，有興趣可以進入以下連結收看：
音源 https://www.youtube.com/watch?v=LdWpxBPTxP4不知道陰謀論是什麼的，這裡引述羅胖的舉例：
逐字稿 http://www.luojiji.com/thread-7255-1-1.html
什么是阴谋论呢？比如，说艾滋病毒是美国人研发出来祸害世界的武器；911事件是美国政府自导自演的；共济会正在控制世界等等。針對為什麼相信陰謀論這個議題，邏輯思維整理出三個原因：
- 輕信 (演化結果)
- 控制感 (對萬物都要有個解釋，以掌控、解決對環境的不確定性)
- 一致性 (事情的發展要符合認知、符合預期)
你可以想象一下，假如你还是一个在非洲大草原上行走的原始人。你路过一片草丛，突然听到一阵窸窸碎碎的声音——那可能是一条致命的蛇，也可能是一只在捕猎的狮子，也可能只是一阵风。你不知道，那你该怎么办？是不管三七二十一掉头就跑，还是镇定自若等看明白再说呢？邏輯思維有提到演化的部分到此，至於我的第二則來源是看了一本書《好奇心的幸福力量》，書中提到因為大腦演化的設計，我們不斷在正向與負向間尋找平衡，而我們天生就會注意到負向事物，就叫做負向偏誤 (negativity bias)。
假设我们的老祖宗有两种人：一种人，凡事都要搞个明白才行动；另一种人，很容易轻信一件事。那前一种人，早就被野兽吃掉了，没有后代留下来。而我们现代人，其实都是后一种人，也就是那些“轻易就相信一件事”的老祖宗的后代。
The negativity bias is the phenomena by which humans give more psychological weight to bad experiences than a good ones. In fact, some researchers assert that negative emotions have an impact close to 3x stronger than positive emotions.書中提到，有負向偏誤，自然也有正向補償 (positivity offset)。
當感到安全時，我們會表現出對探索新事物、尋找新體驗的輕微渴望，也希望獲得回報與刺激。如果缺乏這種補償，我們就永遠不會學習、擴展、成長或演化。我覺得負向偏誤和正向補償這兩個演化的觀點很有趣，正好反思了一下自己的近況。最近進入工作的疲乏狀態一陣子了，覺得工作上沒有太多新的事物，沒有看到什麼新奇有趣的事物能激發我的熱情，以演化的觀點來看，也許就是正向補償發揮了作用吧？工作一段時期，覺得穩定了，好像能接觸的東西都看過了，有一種成長變得緩慢的感覺。因此內心會浮現要怎麼樣才能獲得更多新刺激？怎麼樣才能加速成長？
心理學有時候很有趣，尤其是當可以對應到自己的思考方式或生活狀況的時候特別有趣，就像十二星座算命那樣，算得準就覺得這個算命讚讚讚XD
2017年6月18日 星期日
Dynamical Variable Assignment in Makefile
上星期遇到奇怪問題卡了我一天：第一次 make 成功，直接重新 make 第二次結果失敗了，第三次 make 又成功？為什麼 make 結果會不一樣？
一開始找資料發現 Makefile 針對變數指定方式的不同，會有兩種展開方式：
一種是使用
Recursively 範例：
Simply 範例：
認知升級後，馬上將 Makefile 的等號改成
後來發現問題是在 rule 中使用
執行
所以最後，我放棄在 Makefile 動態指派變數的值了，把想要執行的指令直接寫成 script 讓 Makefile 呼叫，省去不必要的麻煩。
一開始找資料發現 Makefile 針對變數指定方式的不同，會有兩種展開方式：
Two Flavors of Variables
Recursively expanded variable v.s. Simply expanded variable一種是使用
=，之後執行時都會回來改變等號左邊的變數(recursively)，而另一種使用:=，將當下的值指定給等號左邊的變數(simply)，之後不再更動。Recursively 範例：
x = foo
y = $(x) bar
x = later
echo $(y) 的輸出結果會是 later bar。Simply 範例：
x := foo
y := $(x) bar
x := later
echo $(y) 的輸出結果是 foo bar。認知升級後，馬上將 Makefile 的等號改成
:=，結果根本不是這個原因…只好繼續找資料，深追問題。後來發現問題是在 rule 中使用
$(shell ... ) 動態指派變數的話，rule 在執行前就會先展開 $(shell ... ) 了，意思是 $(shell ...) 比 rule 還早被執行。使用 $eval(…) 搭配 $(shell …) 動態執行指令
以下透過 Makefile 範例來解釋：執行
make 後會先砍掉所有 rom 檔，並建立 test.rom，確保當前目錄只有 test.rom，接著透過 find 指令查找 rom 檔，將檔名 assign 給變數 ROM。all:
@rm -rf *.rom
@touch test.rom
$(eval ROM := $(shell find ./ -name *.rom))
@echo name=$(ROM)
*.rom 時：[user][linux][~/test]% ls *.rom
ls: No match.
[user][linux][~/test]% make all
name=
*.rom 時：[user][linux][~/test]% touch existed.rom
[user][linux][~/test]% ls *.rom
existed.rom
[user][linux][~/test]% make all
name=./existed.rom
$(shell ...)先執行了！有注意到情境二的 name 是 existed.rom 而非 Makefile 中建立的 test.rom 嗎？改用 Backquote 如何？
想說好吧，不呼叫 shell 了，用另一種方式解看看。於是使用 backquote (或稱 backtick)` 執行 find 指令，例如：all:
@rm -rf *.rom
@touch test.rom
$(eval ROM := `find ./ -name *.rom`)
echo "before mv: name=$(ROM)"
mv $(ROM) newname.rom
echo "after mv: name=$(ROM)"
[user][linux][~/test]% make all
echo "before mv: name=`find ./ -name *.rom`"
before mv: name=./test.rom
mv `find ./ -name *.rom` newname.rom
echo "after mv: name=`find ./ -name *.rom`"
after mv: name=./newname.rom
所以最後，我放棄在 Makefile 動態指派變數的值了，把想要執行的指令直接寫成 script 讓 Makefile 呼叫，省去不必要的麻煩。
Reference
- The Two Flavors of Variables
https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_6.html#SEC59 - Stackoverflow
https://stackoverflow.com/questions/34935544/how-to-time-the-execution-of-a-gnu-make-rule
2017年5月30日 星期二
[閱讀] 《人魚沉睡的家》原來腦死和植物人不一樣?
《人魚沉睡的家》
這本小說是由我最喜歡的推理小說作家東野圭吾所寫，近三年才開始接觸東野圭吾的小說，喜歡他的小說中引導讀者思考的情節對話。小說中常探討一些價值觀，這些價值觀不一定有對錯，僅是因為站在不同的立場，不同的成長背景，不同的經歷，因此思考出來的結果以及選擇與人不同罷了。身為使用上帝視角來看故事的讀者，我們很幸運地可以試者去思考、去同理書中每位角色的心情與想法，或許這是身為讀者最幸福的事情了。
書名的人魚是用來描述一名年幼可愛的女孩因為發生了意外，沒有意識，躺在床上或輪椅上安詳的模樣。
讀了這本小說才認識到原來植物人與腦死是不一樣的，以下綜合小說與網路查詢資料，整理出兩者的差別。
植物人由於腦幹機能還正常，保有以下特性：
腦死判定（即腦幹反射測試）︰瞳孔對光反射消失、眼球不會轉動、對疼痛沒有任何反應、刺激支氣管時，沒有作嘔或咳嗽反射等。
為什麼要區分是不是腦死？因為現行法規下定義，腦死即代表死亡，一定要判定腦死，醫生才可以摘取器官進行器官捐贈、移植。
這本小說是由我最喜歡的推理小說作家東野圭吾所寫，近三年才開始接觸東野圭吾的小說，喜歡他的小說中引導讀者思考的情節對話。小說中常探討一些價值觀，這些價值觀不一定有對錯，僅是因為站在不同的立場，不同的成長背景，不同的經歷，因此思考出來的結果以及選擇與人不同罷了。身為使用上帝視角來看故事的讀者，我們很幸運地可以試者去思考、去同理書中每位角色的心情與想法，或許這是身為讀者最幸福的事情了。
書名的人魚是用來描述一名年幼可愛的女孩因為發生了意外，沒有意識，躺在床上或輪椅上安詳的模樣。
讀了這本小說才認識到原來植物人與腦死是不一樣的，以下綜合小說與網路查詢資料，整理出兩者的差別。
植物人 v.s. 腦死
植物人是指大腦死亡但腦幹沒死，腦死是指腦幹死亡。植物人由於腦幹機能還正常，保有以下特性：
- 生理時鐘在轉，清醒（awake）但沒有意識（awareness），眼睛張開
- 無法與他人互動
- 無意識行為
- 自發性呼吸（腦幹正常）
- 非自發性運動（還是能進食、排泄）
腦死判定（即腦幹反射測試）︰瞳孔對光反射消失、眼球不會轉動、對疼痛沒有任何反應、刺激支氣管時，沒有作嘔或咳嗽反射等。
為什麼要區分是不是腦死？因為現行法規下定義，腦死即代表死亡，一定要判定腦死，醫生才可以摘取器官進行器官捐贈、移植。
延伸思考
- 植物人有沒有可能醒過來？
- 腦死有沒有可能醒過來？
- 你是否接受器官捐贈？
- 家人是否接受器官捐贈？
延伸閱讀
2017年4月26日 星期三
Blog CSS Test
H1 Text
H2 Text
1#
2#
3#
4#
5#
5 is the normal size
6#
↓分隔線↓ 中文字型測試
Normal text
Bold text
Italic text
text block 1
text block 2
This is text block 3...test with large widthhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
and the second line
int main(void)
{
printf("This is code block...test with large widthhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh");
return 0;
}Finally, test with block quote
Written with StackEdit.
2017年4月23日 星期日
Linux Kernel Panic Analysis
前言
這篇文章主要分享在 CentOS 下，使用 crash 分析 vmcore 除錯的經驗。
上星期收到一件來自日本的客服案例：客戶的 Linux server 發生 panic 導致系統重啟。客戶將 kernel panic 產生的 vmcore 以及 server vendor – Red Hat 的反饋一起傳給我們，由於 Red Hat 反饋表示這是我們 driver 的問題，於是客戶就要求我們針對 7GB 的 vmcore 進行分析。
其實我沒有處理過 Linux kernel panic 的經驗(只有接過 Windows BSOD1 的案子)，問了公司幾位前輩，通常發生這種問題時，客戶只會給我們純文字 error log 以及問題的複現流程。但這次客戶只發生過一次 panic，也不知道如何複製問題，我唯一的資訊只有 vmcore，因此我才花了一些時間學習如何分析 vmcore。
工具準備及環境建置
這次分析需要安裝：
- crash
- vmlinux
yum install crash
vmlinux and vmcore do not match! 的錯誤。要怎麼知道 vmcore 是在哪一版的 kernel 產生的呢？可以用 strings 去抓 vmcore 的資訊：
[root@localhost ~]# strings vmcore | grep OSRELEASE
OSRELEASE=3.10.0-327.el7.x86_64
^C
[root@localhost ~]#
OSRELEASE=3.10.0-327.el7.x86_64，就可以到 debuginfo.centos.org 下載對應版本的 kernel-debuginfo 了，其中 vmlinux 就包含在 debuginfo package 裡面。由於 debuginfo 依存於 debuginfo-common ，因此這兩項都要下載並透過 rpm 安裝：
[root@localhost ~]# rpm -ivh kernel-debuginfo-common-x86_64-3.10.0-327.el7.x86_64.rpm
[root@localhost ~]# rpm -ivh kernel-debuginfo-3.10.0-327.el7.x86_64.rpm
[root@localhost ~]# find /usr/lib/debug/lib/modules/3.10.0-327.el7.x86_64/ -name vmlinux
/usr/lib/debug/lib/modules/3.10.0-327.el7.x86_64/vmlinux
[root@localhost ~]#
開始分析
執行 crash 並帶入 vmlinux 與 vmcore，會看到類似以下畫面：
[root@localhost ~]# crash /usr/lib/debug/lib/modules/3.10.0-327.el7.x86_64/vmlinux vmcore
crash 7.1.5-2.el7
Copyright (C) 2002-2016 Red Hat, Inc.
...(略)
KERNEL: /usr/lib/debug/lib/modules/3.10.0-327.el7.x86_64/vmlinux
DUMPFILE: vmcore
CPUS: 8
DATE: Mon Apr 3 04:16:14 2017
UPTIME: 47 days, 02:41:16
LOAD AVERAGE: 0.74, 0.33, 0.18
TASKS: 676
NODENAME: xxx
RELEASE: 3.10.0-327.el7.x86_64
VERSION: #1 SMP Thu Oct 29 17:29:29 EDT 2015
MACHINE: x86_64 (2594 Mhz)
MEMORY: 31.7 GB
PANIC: "Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 5"
PID: 0
COMMAND: "swapper/5"
TASK: ffff8808541f5c00 (1 of 8) [THREAD_INFO: ffff880852b98000]
CPU: 5
STATE: TASK_RUNNING (PANIC)
Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 5 。有興趣可以 google 一下 soft/hard LOCKUP 的差別。crash 內建了許多好用的指令，首先
bt 可以說是必用的指令之一。bt - backtrace
crash> bt
PID: 0 TASK: ffff8808541f5c00 CPU: 5 COMMAND: "swapper/5"
#0 [ffff88087fd459c8] machine_kexec at ffffffff81051beb
#1 [ffff88087fd45a28] crash_kexec at ffffffff810f2542
#2 [ffff88087fd45af8] panic at ffffffff8162ea73
#3 [ffff88087fd45b78] watchdog_overflow_callback at ffffffff8111b512
#4 [ffff88087fd45b88] __perf_event_overflow at ffffffff8115ed71
#5 [ffff88087fd45c00] perf_event_overflow at ffffffff8115f844
#6 [ffff88087fd45c10] intel_pmu_handle_irq at ffffffff810325a8
#7 [ffff88087fd45e60] perf_event_nmi_handler at ffffffff8163ebeb
#8 [ffff88087fd45e80] nmi_handle at ffffffff8163e339
#9 [ffff88087fd45ec8] do_nmi at ffffffff8163e4e9
#10 [ffff88087fd45ef0] end_repeat_nmi at ffffffff8163d771
[exception RIP: ioread8+66]
RIP: ffffffff81309532 RSP: ffff88087fd43e28 RFLAGS: 00000092
RAX: ffffc90013422a7e RBX: 0000000000000020 RCX: 0000000000000000
RDX: 0000000000009580 RSI: ffff88085f408a00 RDI: ffffc90013422a06
RBP: ffff88087fd43ea8 R8: 0000000000000000 R9: 0000000000000082
R10: ffff88085f403500 R11: 000e783a5cdff909 R12: 0000000000000022
R13: 000000000000000e R14: 0000000000000f50 R15: ffffffffa03fac10
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
--- <NMI exception stack> ---
#11 [ffff88087fd43e28] ioread8 at ffffffff81309532
#12 [ffff88087fd43e28] mx_interrupt at ffffffffa03f1940 [mxupcie]
#13 [ffff88087fd43eb0] handle_irq_event_percpu at ffffffff8111c2be
#14 [ffff88087fd43ef8] handle_irq_event at ffffffff8111c49d
#15 [ffff88087fd43f20] handle_fasteoi_irq at ffffffff8111f90a
#16 [ffff88087fd43f40] handle_irq at ffffffff81016ecf
#17 [ffff88087fd43f78] do_IRQ at ffffffff81647daf
--- <IRQ stack> ---
...(略)
[exception RIP: ioread8+66]，其中 RIP 是一個 instruction pointer 的暫存器，它指向了正在被執行的指令的記憶體位置。更重要的是，我發現了在 call trace #12 顯示的 mx_interrupt at ffffffffa03f1940 [mxupcie] 正好是我們 driver 的一個函式。獲得以上訊息，接著我們可以利用
dis 命令將其反組譯：dis - disassembling instruction
dis 後面接 address 或 symbol，加個-l 參數可以直接指出 source code line number。crash> dis -l ioread8+66
/usr/src/debug/kernel-3.10.0-327.el7/linux-3.10.0-327.el7.x86_64/lib/iomap.c: 73
0xffffffff81309532 <ioread8+66>: movzbl %al,%eax
crash>
crash> dis -l ffffffffa03f1940
0xffffffffa03f1940 <mx_interrupt+384>: test $0xf,%al
crash>
ioread8+66 可以指出位於 iomap.c: 73，但是反組譯 mx_interrupt 所在位置 ffffffffa03f1940 卻不知道是哪一行程式。其實原因是沒有載入 driver module 的 symbol，所以認不出來，因此只要利用 mod 指令載入 module 2就沒問題囉！crash> mod -s mxupcie /mydriver/mxupcie.ko
MODULE NAME SIZE OBJECT FILE
ffffffffa03f9120 mxupcie 69583 /mydriver/mxupcie.ko
crash> dis -l ffffffffa03f1940
/mydriver/mxpcie.c: 2485
0xffffffffa03f1940 <mx_interrupt+384>: test $0xf,%al
crash>
mxpcie.c: 2485 ，恭喜你終於可以開始對程式碼 debug 啦~!註釋
- Blue Screen of Death (BSOD) - Windows 當機，顯示藍屏畫面。Windows BSOD 預設會產生 minidump，R&D 可以透過 minidump 查詢當機的原因，個人覺得與本案例 Linux 的 vmcore 類似。有需要也可以修改 Windows 系統預設值，使當機時產生full dump，而非只有部分核心訊息的 minidump。 ↩
- 載入 module symbol 時，有意識到客戶用 Red Hat build 出來的 driver 和我在 CentOS build 出來的可能會有差異，雖然都是 Kernel 3.10，但不確定有無影響。因此我使用了 objdump 反組譯 CentOS build 出來的組合語言，比對
test $0xf,%al這一行是否指到同一行程式碼，還好結果是相同的。 ↩
訂閱：
文章 (Atom)