Year: 2016

  • 辯論活動有沒有辦法搬到小巨蛋舉辦?

    辯論活動有沒有辦法搬到小巨蛋舉辦?

    王公德瀛日前在 FB 上宣示想要把辯論活動搬進小巨蛋當中 – 到底有沒有辦法實現呢? 要讓夢實現,我們就應該腳踏實地的來算一遍看看。不過在開始算之前,先定義一下什麼叫作進入小巨蛋,進入小巨蛋就是要在台北小巨蛋的主場館活動場地內舉辦辯論相關的活動 ─ 總不可能只是在小巨蛋主場館外面擺擺攤子就算了吧? 釐清了進入小巨蛋是指到主場館活動場地內舉辦活動後,我們可以開始算費用了。根據台北小巨蛋「臺北小巨蛋場館場地收費標準表(104年10月23日備查)」的標準,主場館活動場地租用費用如下: 我們假設辯論活動辦在暑假,不用佈置與拆台日,只需要租用活動日就好,而且每場只用 08:00 ~ 24:00,且 門票收入不達 525000 元。在這樣的狀況下,一場活動要花費如下: 場地使用費 525, 000 元 + 水電空調費 89, 760 元 + 清潔費 31, 500 元。 共計 646, 260 元整。 竟然在小巨蛋辦個辯論活動要64萬6千2百60元啊。假設月薪5萬好了,也要不吃不喝一年才能租個場地而已,如果一個人來辦的話,確實有些吃力。 不過,如果我們把矛頭指向現有的各個大學高中辯論比賽的話,說不定合併幾個就能夠辦了! 馬上來算算,辯論比賽產業 (誤) 能夠收取到多少的報名費跟保證金。比賽列表來自「2016 辯論盃賽資訊」,手動整理之後,整理成列表如下: 登登!出乎意料的,整個盃賽報名費加保證金的狀況下,共有219萬2800元的收入,不含保證金的話,共有136萬2000元的收入呢! 也就是說,如果參加辯論比賽的隊伍們,想要在小巨蛋舉辦辯論活動的話,其實可以整併幾個辯論盃賽,然後舉辦一個在台北小巨蛋的辯論活動呢! 太棒了!這樣有生之年看到辯論活動在小巨蛋舉辦的機會又上升了不少呢!

  • 手動更新 facebook 預覽連結的圖片

    手動更新 facebook 預覽連結的圖片

    有時候網站的 og image 還沒有設定好,就不小心把連結放到 facebook 上去分享,結果發現預覽連結的圖片是錯的,這時候要怎麼辦呢? 這時候請移駕到 facebook 的 「Sharing Debugger」 Sharing Debugger 網址:https://developers.facebook.com/tools/debug/sharing/ Sharing Debugger 是 facebook 提供給使用者用來針對分享連結除錯的一個工具。目前這個版本進去的畫面是長這樣: 我的經驗是,這個網頁畫面已經改版兩三次的,不過大方向是一樣的,就是把你要修正的網址輸入到中間的地方,然後按下除錯,就可以看到存放在 facebook 有關這個連結的相關訊息。 如果你的網址沒有被 facebook 擷取過,會出現這樣的訊息: 按下 Fetch new Information,facebook 就會去擷取這個網站的相關分享訊息。 所以,到底怎麼更新那個預覽圖片? 上面可以看到,這個連結的預覽圖片是錯的,假如我已經在網站這邊設定好了,直接貼到 facebook 的話,會看到預覽圖片還是舊的。這時候就要到 sharing debugger,然後按下 Scrape Again,手動讓 facebook 重新擷取連結資料。 按完之後,就會看到新的圖片了,如果還是沒有,請多按幾次 Scrape Again,還是沒有的話,先確認一下自己網站的 open graph 設定吧!

  • gdb 錦囊妙計

    gdb 錦囊妙計

    Wonderful / Amazing TUI in gdb (but what name?)   很少人知道,但是非常有用的  – TUI (Text User Interface) 這個東西可以讓原本很難用的 gdb 變得非常好用 (應該說比較直觀),開啟之後會將畫面切分為二,上層顯示 source code,下層輸入 gdb 指令。以下是 TUI 的相關示範。   輸入 ctrl x + a 開啟 TUI,再次輸入 ctrl x + a 可以關閉 TUI。 TUI mode 中的上下左右鍵移動的是 TUI。 輸入 ctrl + p 可以回到前一個指令,ctrl + n 可以到後一個指令。 如果因為 printf 等輸出弄爛了整著介面,可以按 ctrl…

  • 致勝高應大社團預算審查會二讀三步驟

    致勝高應大社團預算審查會二讀三步驟

    前言 作為一個參加五次高應大預算審查會二讀的學生,我想我有必要將我看到的缺失列出來,讓大家參考一下。好讓我們能夠省下雙方的時間,不要為了一些枝微末節的事情浪費時間。 我認為預算審查對於社團而言,其實只是像是 Code review 而已,只要你能夠用常人能夠理解的方式解釋預算的編列,通常不會去刁鑽什麼東西。但是很多時候,我們連好好的解釋預算編列都沒有辦法。你可以說預算是活動執秘編列的,關我社長什麼事情,但是請記得,這最後還是你社團的活動,既然你要來開會了,就請先看過你的預算書。 請以後送出預算前,打開這篇文章,照著以下三步驟檢查你的預算。真的,做完之後,省下來的時間你我都能做更好的利用。 利益揭露:一次當秘書旁聽、兩次當社長被審查、兩次當議員開會審查。   第一步:前後一致 很多社團會把活動預算分給不同的執秘去打,這是沒有問題的,但是請再送出前,檢查相關的預算科目估的價格有沒有「前後一致」。 什麼叫作前後一致?就是你的第一份活動跟第二份活動的預算,假設都有估上相同的科目,請不要有相差太多的價格。 舉個例子,今天看到一個狀況是前一個活動預算表,獎狀紙是 100 元 2 份,下一個活動的預算表,獎狀紙卻是 70 元 2 份。這就是前後不一致。這個在審查的時候看到一定會問,很浪費時間的。 第2步:查價、多舉證 請,務必,不要用想、猜、大概、可能、應該、學姊說、以前都是、這種方式來估一個科目的價格。每個東西都有它「合理正常」的範圍,審查的人不是沒有當過社團人員,你估一張海報 500 元,這我一定會問你,因為旁邊的影印店 A2 輸出一張也才 80 元左右,A0 輸出一張 200 多有找。 或是印一張獎狀估 30 元,這根本就是騙人的嗎 Q_Q,打個電話到影印店問一下, 就會有答案了:一面彩色 5 元。真的,我們可以把時間省下來做更有意義的事情。 然後多舉證,把你自己放在審預算的角色上,去批判你的預算表,想想看那邊是一看就怪的地方,然後把價格查好,如果是合理的預算編列,你可以在我們問你之前,就先跟我們說明。 第3步:拆拆拆 拆,把你的預算拆開來。根據心理學實測,人們對於數字龐大的單項預算,會出現有想要刁難的傾向。例如說一筆 8000 元的場地佈置費,我一定會問你這裏面要做什麼?或是獎金一筆 6000 元,我一定會問你怎麼分配獎金。 請把他拆成「獎金 – 第1名 3000 一筆」、「獎金 – 第2名 2000 一筆」、「獎金…

  • 無法 build Linux kernel samples/bpf

    小結 總之,遇到問題記得先看 README.md / README.rst / README。   解決方式 在 linux/samples/bpf 這個資料夾裏面無法 build 出 sample 來 ➜ bpf git:(master) ✗ make make -C ../../ $PWD/ make[1]: Entering directory ‘linux’ CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh DESCEND objtool LD linux/samples/bpf/built-in.o HOSTCC linux/samples/bpf/test_verifier.o HOSTCC linux/samples/bpf/libbpf.o HOSTLD linux/samples/bpf/test_verifier HOSTCC linux/samples/bpf/test_maps.o…

  • Archlinux – sar (sysstat) 使用疑難雜症解決

    如何在 Archlinux 安裝 sar (sysstat) sudo pacman -S sysstat ➜  sar -d Cannot open /var/log/sa/sa07: No such file or directory Please check if data collecting is enabled 在 systemctl 啟動 sysstat sudo systemctl start sysstat 開機時自動開啟 sysstat sudo systemctl enable sysstat ➜  sar -d Requested activities not available in file /var/log/sa/sa07 sysstat 沒有去擷取相關的資料,把他打開來。 > sudo nano /etc/conf.d/sysstat…

  • 全身防水配備一覽表 (可雨中騎機車)

    全身防水配備一覽表 (可雨中騎機車)

    今天終於做到,除了鞋子以外都是防水的狀態了! 從公司騎機車回家的路上剛好傾盆大雨,測試了這些配備的防水能力。而實際騎車回來的結果是滿順利的,所有東西都防水成功,裏面衣服褲子沒有溼掉。 日期:2016/9/7日,19:00 ~ 20:00 前鎮區雨量 17mm,出發時間 19:30。 1. 後背包 Overboard Premium Waterproof Backpack 20L Black 官方網址:http://www.over-board.co.uk/waterproof-backpack-20ltr-black.html 購入價格:2385 購入地點:台北百岳 防水等級:IP66 實際使用狀況:包包內放有筆電、透氣衣服、雜務等等,回到家打開的時候,只有開口潮溼而已,裏面完全沒有溼掉。電腦還能開機打 Blog,放置的衣服是乾的。 2. 手機 Samsung Galaxy S7 官方網址:http://www.samsung.com/tw/consumer/mobile-phones/smart-phone/galaxy-s/galaxy-s7/ 防水等級:IP67 實際使用狀況:放在防水外套的袋子中,裏面積水,拿出來後還是可以用。這台手機我曾經拿去水冷過,完全沒有問題。相關的影片可以看這這個,放到海水都沒有問題了。 3. 防水外套 Arc’teryx Beta SL Jacket Women’s 官方網址:http://www.arcteryx.com/product.aspx?language=EN&gender=womens&model=Beta-SL-Jacket-W 購入價格:4050 購入地點:高雄百岳 防水等級:340NR GORE-TEX® Paclite® 2L 實際使用狀況:女版是因為這件在出清特價,然後只有女版的 S / XS 號,不過試穿了一下 S 號還不錯,看在這個價格就有 Gore-Tex 的狀況,買女版來穿也是沒有問題的。可能是因為騎機車的關係,水會從袖口的地方流進來,回到家脫下來看,袖子下半部是溼掉的狀況。還有就是兩側的口袋幾乎沒啥防水能力,打開來可以把水倒出來……,騎車的時候裏面只有穿一件 Uniqlo 的透氣衣服,並沒有溼掉。…

  • 在 Archlinux 編譯含有 debug symbols 的 glibc

    改用 git/chroot 來編譯 (2019/09/27 更新) 取得 glibc PKGBUILD git clone git://git.archlinux.org/svntogit/packages.git cd packages/glib/trunk 編輯 PKGBUILD,把 options 修改成 (!strip debug staticlibs) 後存檔 在 clean chroot 編譯 mkdir ~/chroot export CHROOT=$HOME/chroot mkarchroot $CHROOT/root base-devel arch-nspawn $CHROOT/root pacman -Syu makechrootpkg -c -r $CHROOT pacman -U <.pkg.tar.xz> 採用 ABS (Arch Build System) 方式去編譯 安裝 abs 套件 (pacman -S abs) 用…

  • Pipeline Speak, Part 2: The Second Part of the Sandy Bridge Pipeline 中文翻譯

    Pipeline Speak, Part 2: The Second Part of the Sandy Bridge Pipeline 中文翻譯

    原文:https://software.intel.com/en-us/blogs/2011/12/01/pipeline-speak-part-2-the-second-part-of-the-sandy-bridge-pipeline 管線後端 The Back-End 管線的後端負責執行從前端產生的微指令。為了要讓後端的資源能夠有效的被利用,後端使用自己的 bookkeeping system 來追蹤每一個微指令,其所需資料 [data requires] 以及執行狀態 [exectes status]。然後它將以任何順序來執行微指令 ─ 根據微指令的所需資料什麼時候全部準備完成以及是否有可用的執行資源。微指令的 bookkeeping 以及排程可以說非常的複雜,而且需要許多專用的隊列結構。當有些隊列結構已經滿了,也就是後端不能在從前端接收新的微指令 ─ 在 Sandy Bridge 最佳化方法中,我們稱這種情況做 ” back-end bound pipeline slots”。 後端持續在追蹤的執行資源 [ execution resources] 稱做執行單元 [execution units]。每個 microarchitecture 可能會有稍微不同的 Layout 以及不同的可用執行單元。這些執行單元是在處理上處理特定功能的邏輯組件,像是加法、除法、邏輯位移、從記憶體讀取等。當微指令使用完執行單元以及所有資料都已經讀取或儲存完畢,我們稱他們已經 “退休” [retired] ─ 這表示微指令已經完成在管線該做的工作。這些微指令絕對不會再被顯式的被轉換回指令 [instructions]。而一個指令被 “退休” 則代表所有的其產生的微指令都已經 “退休”,不過這只是個抽象化的表達方式來說明管線後端是如何處理微指令而已。   了解一點處理器的微架構,包括管線的基礎知識,在效能分析上可以說非常的有幫助。特別是在 Intel Sandy Birdge 架構,因為,第一次在 x86 處理器上,performance events 可以從一個內聚的方法…

  • Pipeline Speak: Learning More About Intel  Microarchitechture Codename Sandy Bridge 中文翻譯

    Pipeline Speak: Learning More About Intel Microarchitechture Codename Sandy Bridge 中文翻譯

    中文翻譯前言 為了理解 perf 的輸出意義[1],必須要了解 CPU Microarchitecture。如果你用 perf stat -d gzip file1 這個方式來輸出,你會發現到輸出中有加粗這個部份: ➜ /tmp perf stat -d gzip files Performance counter stats for ‘gzip files’: 6990.942695 task-clock:u (msec) # 0.996 CPUs utilized 0 context-switches:u # 0.000 K/sec 0 cpu-migrations:u # 0.000 K/sec 112 page-faults:u # 0.016 K/sec 22,653,310,816 cycles:u # 3.240 GHz (33.32%) 9,561,514,420 stalled-cycles-frontend:u #…