XPS 15 剁手记录

2条回复

（拖了很久几乎坑掉的一篇日志）

感谢AI 酱和缺梦等老司机的安利与指导，最终于今年三月底购买了 XPS 15 9550。次月，又蛊惑同学购买了一台。

两台机子都是在 eBay 上购买的官方翻新版（manufacturer refurbished），经由顺丰转运，送至澳门。我这台是 i7 16G 512G FHD，总花销 8736.69 元 （1299.99 USD / 8482.69 CNY + 254.00 CNY 运费，港澳无关税）。同学的是 i5 8G 256G UHD，大概七千元。

配置

XPS 15 系列不同型号的机子不少，Dell 官网共列出了八款。主要就是 CPU（i3/i5/i7）、内存（8G/16G/32G)、硬盘（不同容量的 HDD、SSD 及其组合）、电池（56Wh/84Wh）、屏幕（1080P 非触屏/4k 触屏）的不同组合。

我入的是 i7 16G 512G FHD 这款，以下描述针对此型号，不清楚其他型号是否有所不同：

  • 机子带了一个 USB Type-C 口，Nexus 5X 终于有得连原装充电器以外的设备了；
  • USB 口支持关机充电，但默认关闭，需要在 BIOS 里开启；
  • 带 TPM 1.2，使用 BitLocker 全盘加密非常方便；
  • GTX 960M 带 Fallout 4 使用「中」画质，通常跑在 30~50 fps 的范围内。

其他能方便地查到的配置细节就不提了（

购买渠道

在 Dell 国内官网购买似乎是最贵的，淘宝买官方翻新版会便宜很多。自行从 eBay 海淘可能会更便宜。下面是此时（2016年5月29日）我入的这个型号（i7 16G 512G FHD）在不同渠道购买的大致价格： 继续阅读 →

简单的 BT Tracker 连接检测

发表回复

RT @kgen: 大家 BT 下载的时候，不要开着 VPN，发达国家的版权投诉猛如虎。版权方会主动放出一些正版的 BT 种子，然后收集所有连接来源 IP，投诉或索赔。

这对于 VPN 提供商来说也是一个很头疼的问题。现在的 BT 客户端为了避免被封，已经经进化出了各种加密、混淆手段，直接检测 P2P 流量很困难。不过，大多数时候，客户端都在下载是都会同时连接一些 BitTorrent tracker 服务器。这些服务器数量有限且地址、端口号相对固定，可以非常容易地收集，并直接通过 IP 地址和端口号判断而不必对流量内容进行深度检测。探测到了就扔炸弹。是一个简单易行的判断用户是否正在使用 BT 的方法。

这个方法已在某家梯子站上部署了有一段时间了。鉴于它误报率（false postive rate）低但漏报率（false negtive rate）高，检测到的「处罚」会比较严厉——发现连接就立即挂断这条 VPN 连接。效果似乎还不错，仅有的几次投诉经过排查，发现都是在这套机制的某些环节失效时发生的。

当时为了方便操作，写了几个脚本。现在重新整理了一下，放在了 GitHub 上。这个脚本主要用于从 BT 种子文件里收集 trackers 的地址，然后解析域名得到对应的 IP 地址、协议和端口号。脚本本身并不进行检测等操作，只是为了方便配置防火墙而写。

示例

先在各处收集一些 BT 种子，这些种子文件中通常会包含一个或多个的 trackers。可使用./trackers.py torrent获得 trackers 的 URL 列表，重复的地址会被自动剔除： 继续阅读 →

Cubieboard 更新至主线内核

2条回复

Allwinner 此前一直在使用它自己 fork 的 kernel 和 U-Boot。
现在，他们正在努力将这些代码并入主线。

我在用的 Arch Linux，众所周知，是一个比较激进的发新版本。它已经开始送主线内核linux-armv7啦。

毫无悬念地，更新后就无法启动了。原因似乎是它没有更新 U-Boot。
参照这篇 Mainline U-Boot 编译最新的主线版 U-Boot 然后写入 SD 卡就好了。

需要注意的是，boot.cmd内容需要根据 Arch Linux 的安排有所更改：

setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10
load mmc 0:1 0x43000000 dtbs/${fdtfile}
load mmc 0:1 0x42000000 zImage
bootz 0x42000000 - 0x43000000

（不同之处也就是使用bootz来载入zImage；fdtfile位于dtbs/下）

另外注意似乎还有一些驱动不太完善，比如无法使用 NAND，具体请参考 Linux mainlining effort。

HSTS Preloading – 让你的域名「嵌入」主流浏览器，一同发行

34条回复

有点标题党的味道，但确实有这种效果，比如我现在用的这个域名sorz.org目前可以在 Chromium 和 Firefox 的源代码中找到。理论上，它也会出现在 Safari 和新版的 IE 里[1]。

当然「听起来好像很厉害」只是个副作用，其目的还是为了确保安全。

TL;DR – 如果你的网站也支持全站 HTTPS，可以考虑配妥 HSTS 后在此提交申请。

（2015-11 更新）现在 Qualys 的 SSL Server Test 也会显示相关信息啦：
ssllabs-result-with-hsts

一切为了安全

现代浏览器在安全上真是做足了功夫。

HTTPS

SSL 协议在早在上世纪末就已提出[2]。目前广泛使用的 TLS 1.2 是它的改良版，在 2008 年正式发布[3]。他们可以在很大程度上，保证数据在 浏览器 与 网站服务器 间传输时的安全，保证他们不在传输过程中被监听或者修改。

但目前仍有大量网站是不提供 HTTPS （SSL/TLS）连接的 [4]，或是只在部分页面提供。浏览器不知道哪些网站使用 HTTPS，用户也不一定知道。现在通常的做法是，浏览器先默认使用 HTTP 连接，如果服务器要求安全连接，再通过这个 HTTP 连接返回给浏览器一个「重定向」，让浏览器转而使用 HTTPS。

这样有一个问题，因为 HTTP 是不安全的，这个「重定向」就有可能被攻击者吞掉。然后攻击者一方面冒充服务器，使用 HTTP 与浏览器进行通讯；另一方面冒充浏览器，与服务器使用 HTTPS 建立连接。这就是所谓的 SSLstrip 攻击。

HSTS

为了解决这个问题，HTTP Strict Transport Security (HSTS, HTTP 严格传输安全) 孕育而出。这个 2012 年才发布的新玩意儿其实很简单，就是制订了一种方法，让服务器能够告诉浏览器：「我支持 HTTPS，今后请仅使用它连接我」。 继续阅读 →