90 歲的老人家了 XDDD
在「Noam Chomsky Makes His First Power Point Presentation」這邊看到的:
幹壞事是進步最大的原動力
繼四月出 DynamoDB 推出的 PITR 後 (參考「Amazon DynamoDB 的 Point-In-Time Recovery」這篇),Amazon Aurora for MySQL 也宣佈支援 PITR 了:「Amazon Aurora Backtrack – Turn Back Time」。
從截圖可以看到支援到秒層級:
然後最多 72 小時,會有額外費用:
這樣又讓 DBA 少了一些事情 XD
Amazon DynamoDB 在 3/26 發出來的功能,以秒為單位的備份與還原機制:「New – Amazon DynamoDB Continuous Backups and Point-In-Time Recovery (PITR)」。
先打開這個功能:
打開後就會開始記錄,最多可以還原 35 天內的任何一個時間點的資料:
DynamoDB can back up your data with per-second granularity and restore to any single second from the time PITR was enabled up to the prior 35 days.
這時候就算改變資料或是刪除資料,實際上在系統內都是 Copy-on-write 操作,所以需要另外的空間,這部份會另外計價:
Pricing for continuous backups is detailed on the DynamoDB Pricing Pages. Pricing varies by region and is based on the current size of the table and indexes. For example, in US East (N. Virginia) you pay $0.20 per GB based on the size of the data and all local secondary indexes.
有這樣的功能通常是一開始設計時就有考慮 (讓底層的資料結構可以很方便的達成這樣的效果),現在只是把功能實作出來... 像 MySQL 之類的軟體就沒辦法弄成這樣 XDDD
最後有提到支援的地區,是用條列的而不是說所有有 Amazon DynamoDB 的區域都支援:
PITR is available in the US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), EU (Frankfurt), EU (Ireland), EU (London), and South America (Sao Paulo) Regions starting today.
比對一下,應該是巴黎與美國政府用的區域沒進去... 一個是去年年底開幕的區域,另一個是本來上新功能就偏慢的區域。
華盛頓郵報整理出來了 Facebook 的廣告所使用的 98 個個人資訊:「98 personal data points that Facebook uses to target ads to you」。
基本的個人資訊 (甚至是朋友的),以及使用什麼瀏覽器都可以預期;而 Like 或是參加的 Group 都會被計算也是意料中的事情,不過連信用卡的種類也都在內就頗特別的...
來檢視一下自己的防禦機制有哪些... 瀏覽器預設擋下第三方 cookie:
用 Ghostery 預設把所有外部元件擋下來,再用白名單開想要看的部份。用 uBlock Origin 擋下所有廣告。
另外用「Force Facebook Most Recent」強制 Facebook 轉到 Most Recent 的 Timeline 上。
不知道這樣夠不夠用...
最後來列出這 98 個條件:
看到「http://0.30000000000000004.com/」這個網站對經典的 0.1 + 0.2 問題整理了各語言的結果。這個網址名稱也很機車啊 XD
開頭的說明講述 IEEE 754 二進制表示法的問題:
Your language isn't broken, it's doing floating point math. Computers can only natively store integers, so they need some way of representing decimal numbers. This representation comes with some degree of inaccuracy. That's why, more often than not, .1 + .2 != .3.
It's actually pretty simple. When you have a base 10 system (like ours), it can only express fractions that use a prime factor of the base. The prime factors of 10 are 2 and 5. So 1/2, 1/4, 1/5, 1/8, and 1/10 can all be expressed cleanly because the denominators all use prime factors of 10. In contrast, 1/3, 1/6, and 1/7 are all repeating decimals because their denominators use a prime factor of 3 or 7. In binary (or base 2), the only prime factor is 2. So you can only express fractions cleanly which only contain 2 as a prime factor. In binary, 1/2, 1/4, 1/8 would all be expressed cleanly as decimals. While, 1/5 or 1/10 would be repeating decimals. So 0.1 and 0.2 (1/10 and 1/5) while clean decimals in a base 10 system, are repeating decimals in the base 2 system the computer is operating in. When you do math on these repeating decimals, you end up with leftovers which carry over when you convert the computer's base 2 (binary) number into a more human readable base 10 number.
這邊主要是討論 IEEE 754-1985 這個標準,後來在 IEEE 754-2008 提出了新的表示方法,支援十進位的表示法來解這個問題 (雖然還沒普及)。
在 Hacker News Daily 上看到「DEC64: Decimal Floating Point」:
公式是:
value = coefficient * 10exponent
是以 10 為底。
0 與 NaN 是特別處理:
There are 255 possible representations of zero. They are all considered to be equal.
There is a special value called nan that has a coefficient of 0 and an exponent of -128. The result of division by zero is nan. nan is also the result of operations that produce results that are too large to be represented. nan is equal to itself.
網域也註冊一段時間了,不知道為什麼被突然提起...:
Domain Name: DEC64.COM Registrar: 1 & 1 INTERNET AG Whois Server: whois.schlund.info Referral URL: http://1and1.com Name Server: NS57.1AND1.COM Name Server: NS58.1AND1.COM Status: ok Updated Date: 03-jun-2013 Creation Date: 02-jun-2009 Expiration Date: 02-jun-2014
Edward Snowden 再次丟出 NSA 內部文件,表示 NSA 付錢給 RSA 在演算法裡面放後門:「Exclusive: Secret contract tied NSA and security industry pioneer」。
RSA 的回應則是完全不想提到這筆錢是做什麼用的:「RSA Response to Media Claims Regarding NSA Relationship」。
現在一般在猜測,這個後門應該就是 RSA BSAFE 的預設偽隨機數產生器 Dual_EC_DRBG。
對於 Dual_EC_DRBG 的攻擊,2006 年的「Cryptanalysis of the Dual Elliptic Curve Pseudorandom Generator」就這樣寫:
Our experimental results and also empirical argument show that the DEC PRG is insecure. The attack does not imply solving the ECDLP for the corresponding elliptic curve. The attack is very efficient.
在 2007 年,Bruce Schneier 寫了一篇「Did NSA Put a Secret Backdoor in New Encryption Standard?」,提到這個弱點並沒有大到使得這個演算法不堪用,但看了總是不爽:
Problems with Dual_EC_DRBG were first described in early 2006. The math is complicated, but the general point is that the random numbers it produces have a small bias. The problem isn't large enough to make the algorithm unusable -- and Appendix E of the NIST standard describes an optional work-around to avoid the issue -- but it's cause for concern. Cryptographers are a conservative bunch: We don't like to use algorithms that have even a whiff of a problem.
並且建議不要用 Dual_EC_DRBG:
My recommendation, if you're in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.
現在回頭看這件事情... hmmm...
中文稱為「平方根倒數速演算法」,英文則是「Fast Inverse Square Root」。
好像是在 Twitter 還是 Facebook 上看到的 (還是是在其他管道?),仔細看中文版維基百科條目,發現中文版的資料相當完整了 (看了一下歷史記錄,是去年 2012 年 6 月的時候從英文版翻出來的)。
當時很有名的 magic hack,比查表法快:
在1990年代初(也即該演算法發明的大概時間),軟體開發時通用的平方根計算方法多是從尋找表中取得近似值,而這段代碼取近似值耗時比之更短,達到精確度要求的速度也比通常使用的浮點除法計演算法快四倍,
然後還比 CPU 指令集快 XD
由於演算法所生成的用於輸入牛頓法的首次近似值已經相當精確,此演算法所得近似值的精度已可接受,而若使用與《雷神之鎚III競技場》同為1999年發行的Pentium III中的SSE指令rsqrtss計算,則計算平方根倒數的收斂速度更慢,精度也更低。
Update:請參考 comment,看起來中文版有誤譯...
我本來以為我之前寫過,找了找沒翻到... 補記錄下來 :p