加州法院認為 Uber 與 Lyft 的司機是員工

先前在其他地區已經有很多判例了,這次會特別記錄下來是因為加州是 UberLyft 的總部:「Uber and Lyft ordered by California judge to classify drivers as employees」。

裡面有提到了去年九月加州政府通過了法案 (California Assembly Bill 5,簡稱 AB 5),把 ABC Test 放進法律,取代了之前的 Borello test,用來判斷聘顧關係 (是否為員工,或是獨立的合約關係):

Under the ABC test, a worker is considered an employee and not an independent contractor, unless the hiring entity satisfies all three of the following conditions:

  • The worker is free from the control and direction of the hiring entity in connection with the performance of the work, both under the contract for the performance of the work and in fact;
  • The worker performs work that is outside the usual course of the hiring entity’s business; and
  • The worker is customarily engaged in an independently established trade, occupation, or business of the same nature as that involved in the work performed.

現在需要這三點都成立才會認定為獨立的合約聘顧關係,雖然還有上訴的機會,但翻盤的機率應該不高,記得這個法案當初就是針對 Uber 跟 Lyft...

微軟開源 1983 年版的 GW-BASIC

微軟用 MIT License 放出 1983 年版的 GW-BASIC:「Microsoft Open-Sources GW-BASIC」。

這次放出來程式看起來是 x86 assembly,不過放出來的版本好像也不能算是「原始」的版本,而是從 "master implementation" 轉譯出來的版本:

This source was ‘translated’?

Each of the assembly source files contains a header stating This translation created 10-Feb-83 by Version 4.3

Since the Instruction Set Architecture (ISA) of the early processors used in home and personal computers weren’t spectacularly different from one another, Microsoft was able to generate a substantial amount of the code for a port from the sources of a master implementation. (Alas, sorry, we’re unable to open-source the ISA translator.)

主要還是 PR,然後帶一些考古價值...

C++ 與組語的速度...

Hacker News Daily 上看到「Why is this C++ code faster than my hand-written assembly for testing the Collatz conjecture?」覺得很有趣...

作者寫了一段 assembly,但跑起來比用 C++ 同義的版本慢多了。目前最高分的答案給了很清楚的解釋...

    mov rbx, 2
    xor rdx, rdx
    div rbx

上面這段 code 是作者寫的組語版本,用到 div 指令,這是非常慢的指令:

On Intel Haswell, div r64 is 36 uops, with a latency of 32-96 cycles, and a throughput of one per 21-74 cycles.

相較於 C++ 的版本,用到的是 shr (logical shift right,以位元方式往右平移,最高位補零),速度快太多:

shr rax, 1 does the same unsigned division: It's 1 uop, with 1c latency, and can run 2 per clock cycle.

這是用到無號整數透過 shr 平移一格剛好是除以二的特性,因為速度的關係,這個用法到現在還是很常被拿來用,但對於平常沒在寫 assembly 的人就會有上面的誤解 XDDD

解譯機械碼的 Panopticon

Panopticon 看起來頗不錯,可以直接解機械碼轉成 assembly,再把 flow 畫出來讓人理解:

不過還不知道遇到 dynamic self-decoding 的程式會怎麼處理,另外我記得好像有些商用的 solution 已經有提供了,不知道相比起來如何。

Google 推出 BinDiff 分析惡意軟體

看到 Google 推出 BinDiff 時以為是某種對 binary 檔案產生類似 diff 結果的軟體 (像是 bsdiff 這樣的東西),仔細看才發現是跟資安有關的東西:「BinDiff now available for free」。

可以用在只有 binary 的情況下,快速找出有哪些 assembly code 有差異,進而讓人可以更快的分析。資安分析可以透過這個工具加速。相同的,也可以透過這個工具看出 vendor patch 實際上修了什麼東西:

BinDiff is a comparison tool for binary files that helps to quickly find differences and similarities in disassembled code. It is used by security researchers and engineers across the globe to identify and isolate fixes for vulnerabilities in vendor-supplied patches and to analyze multiple versions of the same binary.

而另外一個用途則是快速分類,把相同的 malware 集合起來,降低重複分析的時間:

Another common use case is to transfer analysis results from one binary to another, helping to prevent duplicate analyses of, for example, malware binaries.

目前支援的 assembly 指令集包括了這些:

Compare binary files for x86, MIPS, ARM/AArch64, PowerPC, and other architectures.

從原始文章可以看到還有 flowchart 分析:

不過這是配合其他 Hex-Rays IDA 的 Professional 版本產生的結果分析,官網報價一套是 USD$1129。

To use it, you also need the commercial Hex-Rays IDA Pro disassembler, 6.8 or later.

128bytes 組合語言的 3D 綜合展示...

原始程式碼在「Wolf128.asm」這邊,依照說明,是跑在 Windows XP SP3 + DOSBox。在「Dissecting the 128-byte raycaster」這邊的「Assembly code analysis」這段有程式碼的解說。

如同引用的文章一開始說的,這結合了滑鼠控制、材質貼圖、Ray casting 以及動畫效果的程式,而只有 128bytes!

我上面這一段文字用 UTF-8 表示都已經超過 128bytes 了... ~_~

了解 C 語言的數字資料型態...

在「Deep C: Understanding the Design of C Integer Types」這篇文章裡面以 C99 為參考文件,說明 C 語言的資料型態 (尤其是數字的部份)。


To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine’s hardware does it rather than by a general abstract rule.

以 target machine 為主要考量的特性與 C 語言被認為是 portable assembly language 的想法還蠻同調的... (What is a portable assembly language?)

所以寫 Portable C code 的人會比較辛苦,需要查規格書的資料,確保各平台都能夠正確被編譯... 而到最後演變成沒什麼人在管 "portable" 這件事情,反正 Autotools 開下去針對不能跑的平台用不同的 code XD