2019新年好

2018年,我做了这些事

– 网络生活

写了3篇博客,除了按惯例交作业的两篇,就写了一篇折腾群晖NAS的经验分享文章,而且这篇文章我现在来看觉得又过时了,过几天得重写一篇,因为我找到更好的办法来解决相同的问题了。博客总访问量持续下跌,为25475 PageView,自作孽不可活。饭否消息21条,其中照片8张。

开源与自由软件方面,因为工作需要给gdbgui项目贡献了一个微不足道的功能。

年初立的Flag要给Linux Kernel Patch Statistics改版的计划,最终还是没有实现。要不继续当成2019的计划?

也许可以总结为在生活上投入的时间越多,在网络上投入的时间就越少?

买了一个fanxi.li的域名,虽然我一直觉得用名字拼音当域名不是很make sense。不过由于现在.li域名无法在国内备案,所以我也没(打算/办法)把它当主域名来用,只是用它来做跳转域名,比现有的域名简洁一点,可以少敲几个字符。

– 一堆IT产品

斐讯K3路由器:没下车就翻车的斐讯产品。K3性能强劲,但是散热硅胶有漏油的毛病,被誉为“漏油器”。主要是第三方固件不是太给力,官改固件因为内核原因也不完美。最终闲置了。

斐讯K2P路由器:0元购成功下车。不考虑0元购情况下,直接买已下车的版本,曾经最低价不到百元,是200元以下路由器中的无敌手。刷成“荒野无灯”版的固件后(暂不讨论第三方固件的安全性问题),使用稳定。非常满意。

斐讯悟空空气检测器:直接买的下车版本,做工不错,检测结果准确性嘛,PM2.5说得过去,HCHO的话,一句话,电化学传感器的都不准。好处是它已经被研究得比较透彻了,直接接入HomeAssistant很方便。

斐讯T1电视盒子:0元购成功下车。不看价格的话,斐讯一系列的产品的硬件确实都是堆料之作,做工扎实,配置也不错。不过家里盒子太多了, 这个最后还是闲置了。似乎现在有很多人拿它玩出了花,不过我没太关注。

天猫路由:内测产品。2018年出个百兆有线的无线路由器,说再多也没意义了。虽然硬件配置还不错,无线信号与实测速度也不错。但是初版固件功能极弱,除了可以上网,其它功能一概没有。对,端口映射都没有。

天猫精灵魔盒:内测产品。就是把天猫魔盒与天猫精灵融合在一起的一个产品。刚开始的使用体验惨不忍睹,正式上市的版本勉强能用。但是为了在电视开关机两种情况下提供不同的功能而引入的两种工作模式,依然让使用体验变得很诡异。最主要的重点在于,语音控制对于一个电视盒子来说,比用遥控器能带来哪些使用体验上的提升?几乎大部分场景下、遥控器都比语音控制要方便、快捷,我能找到的唯一一个点是:搜索指定内容。

华米手表青春版:Pebble 2不到两年就光荣牺牲了,跟很多人一样,双侧的橡胶按键因为老化,直接破损了。Pebble被Fitbit收购,已经又一次证明,被Geek看好的产品,通常都不是好产品。华米手表除了部分细节功能不如Pebble(比如免打扰模式无法设置只进行来电提醒、无法定制不同类型提醒的振动模式),以及表盘定制能力不及Pebble,其它功能都很让人满意,工作稳定可靠,不像Pebble还时不时蓝牙连接默默断开给你脸色看。没有选择小黑3是因为它的外观,没有选择别的智能手表大都是因为续航。

OLPC XO-1:十年前非常想要但不太买得到的OLPC,也就是当年所谓的“一百美元笔记本”,如果不了解的,可以搜一下相关的历史。在闲鱼上淘到了一个洋垃圾,毫不犹豫的下单了。放到今天,这东西可是真垃圾,但是它的一些设计即使到今天来看,也还是非常独特的,比如那个双模的显示器。玩了几个小时,不出意外的闲置了,纯当收藏了。

Dell 7060 Micro:前年买的Dell 7040 Micro台式机还是挺满意的,今年Intel牙膏挤多了,8代CPU提升很大,所以换成了Dell 7060 Micro,配上了顶配的8代i7标压CPU。尽量Dell给这个系列使用i7标压U的机器单独配备了专用的散热组件和大功率的电源,这种小机箱的散热还是不太够,i7无法满载运行。内存我已经加到了32G,但是还是没法满足工作中编译代码的需要(单CPP文件编译可能会耗费4G或更多的内存,开6个并发就废了),所以现在用着高配置的机器却只跑了个Terminal和IDE,编译这种费力的工作还是扔到远程服务器上去做了。

MikroTik RB750Gr3 + Arbua AP-205H:这个路由+AP的组合,是买来尝试软路由方案的,两个月后又闲鱼上卖掉了。RouterOS的设计和操作对于家用路由器来说有点反人类,而Arbua这种专业AP也会让初次使用者觉得摸不着手脑。在经历了尝试用群晖虚拟机跑OpenWrt、MikroTik+Arbua等几个家庭网络方案后,我回到了原来的AC68U硬路由的方案。我的结论是,在带宽和带机量都不足够大的家用情况下,除非在路由器上需要部署大量加解密、协议分析(比如去广告)这种重CPU的功能,否则X86软路由无论从性能还是功耗上,性价比都远低于同档次的硬路由。

EPSON L4168打印机:低端墨仓式一体机的网络爆款。从功能上来说,连供、彩色打印、复印、扫描、无线、自动双页,完全对得起1300多块的价格。但是我在十五年前花330块买过一个HP 3538打印机,从文本打印品质来说,可以秒杀这个新的L4168,所以新机器刚到手的时候还是颇为失望的。现在用了一段时间习惯了,也就不纠结了。

暴风酷播云:曾经5000多块的矿机,在矿难后有商家在闲鱼上抛售,价格从500多一路暴涨到现在的近800,估计不久又得崩盘。万由的双盘位机箱,华擎的J3455主板,单条金士顿DDR3L 8G内存,自带16G SSD可以当系统盘,满载功耗40W左右。相当于群晖DS918+的配置,用来做家庭小服务器/NAS/软路由还是很不错的。学习了Proxmox这个可以代替VMware ESXi的虚拟化管理系统,很不错,够用。

– 出行

海口/三亚四日:除了住酒店还是住酒店,除了游泳还是游泳,除了沙滩还是沙滩。有人说这就是正确的度假姿势。这次行程从浦发银行信用卡上撸了不少羊毛。

厦门三日:除了住酒店还是住酒店。这真不是我风格,我已经是老年人了吧?

苏州两日:走马观花跑景点,有点累。

– 其它

正在着手翻译一本Drill的书,预计2019年上半年可以出版,可能会是国内同体裁的第一本。原因无它,就因为我想出一本O’Reilly的动物封面的书。

我是一名坚持了十几年的Linux桌面资深用户,2018年年底,发现Windows 10自带的Windows System for Linux已经基本堪用,义无反顾地倒戈回了Windows。虽然Windows 10跟以前版本的Windows比,又丑Bug又多,但总体来说桌面体验还是比Linux强多了。macOS?我用了四年多,但似乎我的脑回路还是与它有点不兼容,我不太喜欢macOS所提供的交互逻辑。

展望2019年:

最近有句话很流行:“2018年是过去十年里最差的一年,却是未来十年最好的一年。”我并不觉得这句话很消极,每个人都应该有点忧患意识,有点抵抗风险的准备和能力(此处可以乱入卖保险的广告)。避免功利地去评估一件事情是否值得去做,尝试更踏实地做好一件件小事。不能期待一蹴而就,薄发来自于平时点点滴滴的厚积。

关注2019维也纳新年音乐会

曾经关注过的那些维也纳新年音乐会:关注维也纳新年音乐会

一年又快要过去了,又快要到了迎接新年、迎接维也纳新年音乐会的时候。

2019年维也纳新年音乐会将由德国指挥家克里斯蒂安·蒂勒曼执棒,这是绰号“大熊”的他首次执棒新年音乐会。他是新年音乐会迎来的第17位指挥家,也是继克莱伯之后的第二位德国指挥家。

CD封面还没出,暂时只能配个指挥的图了:

斯蒂安·蒂勒曼

斯蒂安·蒂勒曼

上半场

01 – Carl Michael Ziehrer – Schönfeld-Marsch; op. 422 – ·勋菲尔德男爵进行曲 *

02 – Josef Strauss – Transactionen; Walzer; op. 184 – 交易圆舞曲 – 1981, 1993

03 – Joseph Hellmesberger jun. – Elfenreigen – 小精灵的舞蹈 – 2007

04 – Johann Strauss II – Express; Polka schnell; op. 311 – 特快列车快速波尔卡 *

05 – Johann Strauss II – Nordseebilder; Walzer; op. 390 – 北海风光圆舞曲 – 1998, 2005

06 – Eduard Strauss – Mit Extrapost; Polka schnell; op. 259 – 特快邮车快速波尔卡 – 2000, 2016

下半场

07 – Johann Strauss II – Der Zigeunerbaron; Overtüre – 吉普赛男爵序曲 – 1987, 1992, 2009

08 – Josef Strauss – Die Tänzerin; Polka francaise; op. 227 – 舞女法兰西波尔卡 *

09 – Johann Strauss II – Künstlerleben; Walzer; op. 316 – 艺术家的生活圆舞曲 – 1989, 1999,  2002, 2006

10 – Johann Strauss II – Die Bajadere; Polka schnell; op. 351 – 印度舞伎快速波尔卡 – 1997, 2005, 2008

11 – Eduard Strauss – Opern-Soiree;  Polka francaise; op. 162 – 歌剧院晚会法兰西波尔卡 *

12-13 – Johann Strauss II – “Ritter Pásmán”, Evas Walzer und Csárdás – 伊娃圆舞曲 * & 查尔达什舞曲(选自轻歌剧《骑士帕斯曼》) – 1967, 1989, 2000, 2011

14 – Johann Strauss II – Ägyptischer Marsch; op. 335 – 埃及进行曲 – 1993, 2014

15 – Joseph Hellmesberger jun. – Entr’acte Valse – 幕间圆舞曲 *

16 – Johann Strauss II – Lob der Frauen; Polka Mazur; op. 315 – 赞美女人玛祖卡波尔卡 – 2003, 2006

17Josef Strauss – Sphärenklänge; Walzer; op. 235 – 天体乐声圆舞曲 – 1954, 1964, 1979, 1980, 1983, 1987, 1992, 2004, 2009, 2013

18 – Johann Strauss II – Im Sturmschritt; Polka schnell; op. 348 – 飞奔快速波尔卡 – 1990, 2004, 2016

加演

19 – – ?

20 – Johann Strauss II – An der schönen blauen Donau, Walzer, op. 314 – 蓝色多瑙河圆舞曲

21 – Johann Strauss I – Radetzky-Marsch, op. 228 – 拉德茨基进行曲

从目前看到的曲目单上,2019年的新年音乐会将演出6位作曲家的20首曲目,可能还会有一首未公布的加演曲目(原因是虽然飞奔快速波尔卡也很适合作为加演曲目,但是按惯例一般不会以圆舞曲作为正式曲目的最后一首,所以推测在飞奔后面应该还有一首快速波尔卡才是加演第一首)。除了施氏家族的四位成员,另外两位作曲家的名字也是新年音乐会爱好者所耳熟能详的:齐雷尔和约瑟夫·赫尔梅斯伯格。2019年是作曲家弗兰兹·冯·苏佩诞辰200周年,苏佩也是新年音乐会老朋友了,他的著名作品《轻骑兵序曲》曾两次入选新年音乐会的曲目单,今年没有选择他的作品纪念他的诞辰可谓是不按套路出牌。

音乐会的上半场,有两首新曲子,《特快列车波尔卡》是其中的一首,上半场另外还有一首《特快邮车》也是火车体裁的。在施特劳斯的时代,正是火车刚刚开始蓬勃发展的时代,所以他们有不少作品是有关火车的。还记得十多年前在深夜在南京站拍摄9列进京直达特快列车过站视频,后期制作时,我就选用了几首施特劳斯的与火车相关的作品作为背景音乐,很是应景。

下半场是经典怀旧时间,除了4首新曲以外,其它的曲子都是在新年音乐会上多次演出的经典曲目。其中我比较期待的是《艺术家的生活圆舞曲》和《查尔达什舞曲》,前者旋律优美,后者节奏奔放,都曾经给我留下深刻的印象。至于《天体乐声》,这个曲子的旋律也是我喜欢的类型,可这个曲子实在是演出次数太多了,经典的演绎也很多,所以反倒是没有太多期待。这就像是加演的最后那两首,刚开始听新年音乐会时,前面的曲目都不重要,就等着听这两首。而现在,这两首倒像是看完电影以后的字幕了——当然,不是说它们不重要,我看电影也是从来都是要把字幕完整看完的,如果没有它们,这就不是一场完整的新年音乐会(2005年新年音乐会是我心中永远的遗憾)。

……

这年头,资讯太发达了。早年想了解新年音乐会的相关信息,中央电视台的专题和直播几乎是唯一的渠道。而现在,就因为我没有在看到曲目单的第一时间就写完这篇文章,没过几天,网上类似体裁的文章已经是铺天盖地,一篇比一篇专业,一篇比一篇挖掘的深入。如果我再把别人写过的东西再抄一遍,意义也不大。收笔了。

最后提供一点相关的链接,有兴趣的朋友可以继续探索:

用NVME提高群晖NAS的性能

群晖的DSM有一个比较鸡肋的功能:SSD Cache,原因如下:

  1. 单条NVME只能做只读Cache,功能有限
  2. 一个SSD Cache只能加速一个存储池(DSM 6.2中的词汇,以前叫存储空间)
  3. 系统分区不在任何存储池里,所以系统分区上的东西都不能加速
  4. NVME只能做Cache,不能用来存数据

DMS的SSD Cache功能是基于Linux的dm-cache来实现的,理论上通过Hack是可以解决上面说的这些问题的,不过得摸透了DSM相关的所有逻辑才能搞,而且对DSM的侵入比较大。所以,有一个想法,直接解决第4条问题,想办法把NVME当成正常的磁盘来存数据。然后就可以按自己的想法,灵活地挑一些需要高速随机IO的数据放在NVME上,其它的数据还是放在磁盘上。

如果问群晖的技术支持可不可以这样做,回答是否定的——非常可以理解,在群晖的设备上,盘位就是钱,白给你增加两个盘位?想都别想。

研究了一番,找到了解决这个问题的办法,虽然不完美,但是可用,并且效果不错。以下内容基于DS918+的硬件,DSM 6.2,系统中所有的磁盘都是Basic模式。由于条件所限,我没有测试RAID或SHR的情况,但原理应该都是一样的,可以参考一下我的思路。DSM的RAID就是标准的Linux RAID,而SHR则是基于LVM搞出来的。

以下步骤请充分理解后自行操作,所有给出的命令仅供参考,切勿依样画葫芦。这里介绍的方法有可能会造成不可逆的数据损失,请自己评估风险。

1. 分区

安装NVME后,系统中会出现/dev/nvme0n*设备,并且在存储管理器中可以看到对应设备。不要在DSM中创建SSD Cache,因为我们准备自己管理这个硬件。

Basic模式下,DSM会把系统中的每块硬盘都分成三个区:

Device      Start         End     Sectors Size Type
/dev/sdd1    2048     4982527     4980480 2.4G Linux RAID
/dev/sdd2 4982528     9176831     4194304   2G Linux RAID
/dev/sdd3 9437184 11720840351 11711403168 5.5T Linux RAID

第一个分区用于存放DSM系统,第二个分区是SWAP,第三个分区是用户可用的存储空间。每块磁盘的前两个分区,分别组成/dev/md0和/dev/md1两个RAID设备,都是RAID 1的模式。

所以,我们也依样画葫芦,把NVME也用相同的方式分区(可以使用系统自带的parted工具),分出与别的磁盘大小一样的前两个分区,类型都设置为RAID。然后剩余的空间分为普通Linux分区,并格式化为你需要的文件系统(ext4或btrfs)。当然,如果你有多块NVME或者你愿意,你也可以把剩余空间分为RAID类型,创建md设备后再格式化。

2. 创建RAID组

分完区后,扩展md0和md1,把NVME的前两个分区,加到这两个RAID组中。

# 如果是2盘位的设备,大概只需要扩展成3就可以了 
$ sudo mdadm --grow --raid-devices=5 /dev/md0 
$ sudo mdadm --grow --raid-devices=5 /dev/md1
$ sudo mdadm --manage /dev/md0 --add /dev/nvme0n1p1
$ sudo mdadm --manage /dev/md1 --add /dev/nvme0n1p2

然后,把第三个数据分区mount到一个你喜欢的位置,比如:

sudo mount /dev/nvme0n1p3 /volume1/homes/admin/nvme

考虑到NVME和磁盘混合组成RAID,可以把所有磁盘(不包括NVME)的对应分区设为writemostly,这样可以让读操作尽量走NVME,提高性能:

sudo echo writemostly | tee /sys/block/md0/md/dev-sdX1/state
sudo echo writemostly | tee /sys/block/md1/md/dev-sdX2/state

这样做完以后,系统分区和SWAP分区都已经可以被NVME加速了。这一步是完全没有风险的,因为即使未来NVME从RAID 1组中意外丢失或损坏,也不会造成任何数据问题。

同时在DSM中,正常访问home/nvme就是访问NVME上的内容,这个目录可以当作普通的存储空间来使用,存放一些需要高速随机IO的数据。

3. 迁移数据

为了达到更好的性能,我们还应该把一些常用的对IO性能敏感的东西迁移到NVME上,包括但不限于:

  1. 系统的PostgreSQL/MariaDB数据库,通常位于/volume1/@database,但也可能分布在多块盘上
  2. 软件包,通常位于/volume1/@appstore,但也可能分布在多块盘上
  3. CloudSync的SQLite数据库,通常位于/volume1/@cloudsync
  4. Docker的镜像和容量数据,通常位于/volume1/@docker
  5. VMM的虚拟磁盘文件,通常位于/volume1/@Repository

迁移的方法很简单,先rsync,然后再mount –bind,比如:

sudo rsync -a /volume1/\@appstore/ /volume1/homes/admin/nvme/\@appstore/
sudo mount --bind /volume1/homes/admin/nvme/\@appstore /volume1/\@appstore

理想情况下,应该先把相关服务停止后(用synoservice命令可以启停服务)再迁移数据,避免迁移过程中有新数据写入造成不一致。为了保证万无一失,建议可以写个迁移脚本,在系统启动过程中所有服务还没有启动前运行一下这个脚本。

这一步是有风险的,因为万一未来某一次mount –bind没有成功或者没有做mount –bind,系统就无法访问到正确的数据了,这对于系统数据库之类的,还是有一定影响的,会造成数据不一致。

4. 重启自动生效

写一个脚本,用于在未来重启时重建RAID和mount相关目录,比如:

# 先把NVME上的数据盘mount起来
mount /dev/nvme0n1p3 /volume1/homes/admin/nvme
# 把SWAP的RAID 1扩容,并把NVME上的分区加进去
# 系统分区不需要,因为会自动完成。
# 但SWAP的RAID每次重启都会重建,所以每次都需要扩容。
mdadm --grow --raid-devices=5 /dev/md1
mdadm --manage /dev/md1 --add /dev/nvme0n1p2
# 把相关的目录mount --bind上去
mount --bind /volume4/homes/admin/nvme/\@appstore /volume4/\@appstore
mount --bind /volume4/homes/admin/nvme/\@cloudsync /volume4/\@cloudsync
mount --bind /volume4/homes/admin/nvme/\@database /volume4/\@database
mount --bind /volume4/homes/admin/nvme/\@docker /volume4/\@docker
mount --bind /volume4/homes/admin/nvme/\@Repository /volume4/\@Repository
# 重新设置RAID writemostly策略
echo writemostly > /sys/block/md0/md/dev-sda1/state
echo writemostly > /sys/block/md0/md/dev-sdb1/state
echo writemostly > /sys/block/md0/md/dev-sdc1/state
echo writemostly > /sys/block/md1/md/dev-sda2/state
echo writemostly > /sys/block/md1/md/dev-sdb2/state
echo writemostly > /sys/block/md1/md/dev-sdc2/state

修改/etc/rc,在SYNOINSTActionPostVolume这一行后面,增加一行对上述脚本的调用。SYNOINSTActionPostVolume执行完后,刚好是所有磁盘都mount好但是没有任何服务启动的时刻,所以这时做mount –bind是最合适的。如果你第三步数据迁移想在重启时做,也是加在这个位置。

这一步是比较不完美的,因为需要修改系统文件,而系统文件有可能会在更新DSM时被覆盖回去,万一被覆盖回去,系统启动后就是一个没有mount –bind的状态了,即使那时再改一遍脚本再重启,DB的一致性可能已经无法保证了。我暂时选用了一个带有一点防御性的做法(同样不是万无一失的):在更新DSM前,把/usr/sbin/reboot改名,这样更新完DSM后系统不会被自动重启,我就可以有机会检查/etc/rc有没有覆盖,如果被覆盖,可以自己改回来以后再重启系统。

5. 其它经验和坑

  • 数据迁移必须用mount –bind,不能用软链,已知有些应用组件在软链的情况下不能正常工作
  • /volume1/@tmp不能迁移到NVME,即使用mount –bind,也会造成Drive等组件不能正常工作
  • 现在的做法,NVME的第二个分区是后加到SWAP分区的RAID里的,所以每次重启都会有个重新同步的过程,IO会打高一会儿,并且完成后DSM会弹一个提示:一致性检查完成。但总体是可以忍的,所以我就没有去深究用什么方法可以在建立SWAP的RAID时就直接把它一起建进去了,因为我还是想尽可以少侵入DSM系统
  • 用户的共享文件夹也可以通过mount –bind迁到NVME上,但是这样做会造成在共享文件夹管理界面上不能正常查看共享文件夹相关信息,所以建议只对共享文件夹里的目录进行mount –bind
  • 如果你只有一条NVME,或者有两条但没有做RAID,那么迁移上去的那些系统文件都是单点(虽然原本在磁盘没有RAID的话是单点),需要留意其中的风险

2018新年好

2017年,我做了这些事:

– 网络生活

写了2篇博客,太懒了,除了开年的新年好和年末的新年音乐会两大作业文,2017年其它的内容居然什么都没写。其实有好几篇都在草稿箱里,只是都没有最终完成。博客空间总访问量31646 PageView(Google Analytics数据),数字下跌接近50%。跟前两年一样,依然是在吃老本,2010年和2013年写的几篇旧文章撑起了半边天。饭否发消息49条,其中包括照片16张。

calibre修了两个微不足道的豆瓣元数据获取的Bug,给Seastar修了一个微不足道的Bug。

继续维持Linux Kernel Patch Statistics网站的运行,处理各种用户反馈过来的数据问题。几次想重构这个网站,方案也想了好几版,但是还是没有着手去做。最初的思路是想写个Flink的任务,流式去处理新的Patch信息,然后更新统计结果。后来仔细想了想,其实不用这么复杂,就目前的数据规模,直接把原始往数据库里一塞,然后正常查询就足够了。同时数据精准度也还有待进一步提高,但是这个主要是人肉工作,有不小的难度。期望2018年能把这个事情落地了。

– 几个IT产品

Amazon Echo Dot:对智能音箱的第一次尝试,总体感受是低于期望值。最重要的原因是它并不面对中国市场,所以很多功能并不适合在中国使用。最明显的就是在音乐播放这个功能上,无法识别中文歌名就是一个硬伤,播放自有音乐也非常困难。在智能家居方面,跟Home Assistant可以有一定程度上的集成,但是在国内依然用处不大。所以目前已几乎闲置。

天猫精灵:公测时第一批买到的,支持中文就是它最大的优点,智能家居的功能目前在国内也比Echo要稍稍接地气一点。从公测到现在有快半年时间了,能够看到它的明显进步的。目前在家里还是经常使用它的音乐、提醒、天气时间、智能家居等功能的。不过在有魔盒、魔盘等产品在先,我个人是不看好这类天猫XX的硬件产品的未来的。

SONY MDR-1000X蓝牙降噪耳机:在上下班的大巴上使用,降噪效果还是不错的,可以把音量保持在比较低的程度。不过这个产品有时会让我的耳朵产生胀痛的不适感。但是我其实一直没想明白,降噪的原理是把噪音声波的相位颠倒一下播放,那是不是就等同于一直有跟噪音音量相同的声音给灌到我耳朵里了?音量虽然开低了,但这个降噪的声音本身会不会损伤耳朵呢?

Brother PT-1230PC标签机:用几次就会吃灰的东西,所以买了个廉价的全新二手机器。接电脑使用是一件很不方便的事情,好处是可以完全自定义打印的内容。每次打印都会浪费很长一段标签纸,所以最好一批多打印几个才环保。然而它没有自动半切的功能,所以打印完以后还要手工把标签一段段的剪开(即使一次只打一个,也得手工剪掉前面浪费的那一段),这才是这个机器最不方便的地方。淘宝上的廉价耗材完全堪用,除了标签薄一点、表面光泽度稍差,在家用环境下应该都没有问题。

佳能CP910照片打印机:也是一个大部分时间吃灰的东西,所以也是买了个廉价的全新二手。现在偶而会有临时打印照片的需求,家附近的照相馆的打印的价格坑爹不说,主要是打印效果惨不忍睹,而线下或在线冲印服务则时效性不够。总体来说,对这个产品是满意的,打印的品质稍逊于冲印的品质,锐度和饱和度稍差。但是可以自己把屏幕调到跟打印出来的效果一致,这样就不用担心PS得好好的照片打出来不合心意了。

Synology DS918+:又换了个NAS,去年买的916+才用了一年多就把它换掉了。原因是新机器比旧机器便宜,买新卖旧,损失不大,而新机器可以支持NVME的SSD Cache,这样就不用浪费宝贵的硬盘槽位来做SSD Cache了。然而现实却并不美好,Synology的SSD Cache只能对一个存储空间生效,并且不会对系统文件分区进行加速,而且只用一条SSD时,只能进行只读Cache,所以除了在使用VMM时有那么一点点小作用以外,其它时候几乎都感受不到SSD带来的加速作用。

玩客云:迅雷出的“NAS”,背后的风起云涌的故事我就不讲了,反正我原价买了两个,卖了一个留了一个,就等于白拿了一个还有得赚。跟群晖比,这个东西真是连NAS都算不上,而且从安全性、可靠性等角度来说,我根本不敢用它。但是我非常喜欢它的思路,这才是普通人可以用的NAS:插上硬盘就能用,不用太担心内网、外网、端口映射的问题(群晖的QuickConnect?只能呵呵它一下了),没有文件、文件夹的概念,放进去的就是照片、视频、文档这样的数据,直接自动归类放好、视频文件自动下载元信息,需要的话可以手工再添加标签来分类。这样的产品用来做手机存储的扩展和备份,非常方便。

博朗耳温枪IRT6520:2016年买了一个,2017年又买了一个,必须专门拿出来黑它一下。山寨做工就不说了,操作繁琐也不说了,重点是太太太容易坏了,而且几乎没有质保。2016年我是亚马逊闪购买的,无质保。2017在京东超市自营买的,坏了依然需要自己跟代理商扯皮。一气之下直接联系了京东客服投诉,京东售后自己给兜底了,换了个新的。现在每次用还是提心吊胆的,不知道什么时候就又会测温不准了。

荣耀V9手机:三年内买的第6个荣耀手机,现在半家人都在用荣耀手机。华为的产品不良心,但还算省心。荣耀虽然硬件各种缩水,但是日常用用还算够。V9的屏幕色彩调得有点夸张,乍一看还挺惊艳的,但是仔细看还是掩盖不了它的低端屏幕的本质。NFC当公交卡很好用,指纹解锁我也一直觉得国产手机全都可以秒杀同时期的iPhone。

戴森V8 absolute吸尘器:跟只有它价格十分之一不到的某型号的小狗吸尘器来比较,它工作时的表现确实是非常不错的。不过它的塑料件的质感和做工,真是对不起它的价格。另外,因为所有的主要部件(电机、电池)的重量都在手上,所以使用起来还是有点费劲的,尤其是使用短小的吸头清理小地方的时候。

– 出行

量子号邮轮,出行前只要多看看网站评价中的差评,就可以把自己的心理预期降低到一个合理的程度,然后就可以玩得很开心。邮轮旅行的陆地行程大都是坑爹的,正确的姿势就是充分享受在船上的休闲时光。

成都,对于不能吃辣又本来就不是吃货的我,成都算不上是一个“来了就不想走”的城市。大熊猫基地比想象的要有意思一些。

南京/江苏大剧院,江苏省终于有了一个说得过去的音乐厅。祖宾‧梅塔和以色列爱乐的演出,虽然比不上维也纳爱乐乐团,但也足够惊艳。期待2018年能有值得让我再专门跑一趟的演出。

千岛湖,一个除了休闲啥也干不了的地方。

展望2018年:

还是说点工作,2017年在工作上实现了从Java回到C++的转型,如果说C++ 14语言和纯异步编程带来的挑战还不是个大问题的话,真正的挑战存在于从简单业务代码开发转型为去做高性能底层系统的设计和实现。尤其是设计阶段需要参考很多现有的系统和论文,去理解它们的设计意图,去理解它们的实现机制,并在这个基础上找到适合自己的方案,在之前没有太多积累的前提下,非常难。

可以说,2017年的工作压力是相当的大,也是我自己第一次在工作中真正开始怀疑自己分析、解决问题的能力。不过在经历了系统的几次迭代后,似乎还是找到了一点点感觉,期待2018能更好的迎接新的挑战。

关注2018维也纳新年音乐会

曾经关注过的那些维也纳新年音乐会:关注维也纳新年音乐会

在2018年的新年音乐会上,我们将迎来一张熟悉的老面孔,他就是意大利指挥家里卡尔多‧穆蒂。穆蒂1993年第一次登上新年音乐会的指挥台,后来又指挥了1997年、2000年和2004年的新年音乐会,2018年他将第5次登上新年音乐会的指挥台。

实话说,刚开始的时候我并不是非常喜欢他,1997年我是第二次看新年音乐会的直播,看到穆蒂时,我不自觉地把他与前一年的指挥洛林‧马泽尔进行了比较,相比马泽尔生动的演出,穆蒂的演出显得要严肃一些,与新年的节日气氛有点格格不入。2000年没有看直播,看录播时就没了新年的气氛,加上开场那平淡如水的《大河圆舞曲》,这一年的音乐会也没有给我留下深刻的印象。倒是2004年的那一次,穆蒂选择的那些让人耳目一新的曲目,让我改变了对他的印象。但是那段时间有传闻说穆蒂已经表态以后不会再上新年音乐会,便只能放弃了对他的期待。所以,当年初时得知穆蒂会指挥2018年新年音乐会时,颇是激动了一番。穆蒂此次登台,也破解了传说中的“天体乐声大魔咒”——在新年音乐会历史上,波斯科夫斯基、卡拉扬、克莱伯这几位大师在演完这个曲子以后就都没有再上过维也纳新年音乐会的指挥台了,而穆蒂恰巧在2004年时选择过这个曲目。

2018维也纳新年音乐会CD封面

2018维也纳新年音乐会CD封面

来看曲目单:

  • 01 Johann Strauss II – Einzugsmarsch aus ‘Der Zigeunerbaron’ – 入城式进行曲,选自《吉普赛男爵》
  • 02 Josef Strauss II – Wiener Fresken; Walzer; op. 249 – 维也纳壁画圆舞曲 *
  • 03 Johann Strauss II – Brautschau-Polka; op. 417 – 相亲波尔卡(选自《吉普赛男爵》) *
  • 04 Johann Strauss II – Leichtes Blut; Polka schnell; op. 319 – 轻如鸿毛快速波尔卡
  • 05 Johann Strauss I – Marien-Walzer; op. 212 – 玛丽安圆舞曲 *
  • 06 Johann Strauss I – Wilhelm-Tell-Galopp; op. 29b – 威廉退尔加洛普 *
  • 07 Franz von Suppé – Boccaccio; Ouvertüre – 薄伽丘序曲 *
  • 08 Johann Strauss II – Myrtenblüten; op. 395 – 桃金娘花冠圆舞曲 *
  • 09 Alphons Czibulka – Stephanie-Gavotte; op. 312 – 史蒂芬妮加沃特舞曲 *
  • 10 Johann Strauss II – Freikugeln; Polka schnell; op. 326 – 魔弹快速波尔卡
  • 11 Johann Strauss II – Geschichten aus dem Wienerwald; Walzer; op. 325 – 维也纳森林的故事圆舞曲
  • 12 Johann Strauss II – Fest-Marsch; op. 452 – 庆典进行曲
  • 13 Johann Strauss II – Stadt und Land; Polka Mazur; op. 322 – 城市与乡村玛祖卡波尔卡
  • 14 Johann Strauss II – Maskenball-Quadrille; op. 272 – 假面舞会四对舞
  • 15 Johann Strauss II – Rosen aus dem Süden; Walzer; op. 388 – 南国玫瑰圆舞曲
  • 16 Josef Strauss – Eingesendet; Polka schnell; op. 240 – 读者来信快速波尔卡
  • 17 ?
  • 18 Johann Strauss II – An der schönen blauen Donau, Walzer, op. 314 – 蓝色多瑙河圆舞曲
  • 19 Johann Strauss I – Radetzky-Marsch, op. 228 – 拉德茨基进行曲

这次的新年音乐会选择了19个曲子,应该是一个比较合适的数字,不至于让穆蒂像2004年时那样赶场子。除了目前未知的第一个加演曲目,穆蒂选择了7首从未在新年音乐会上演出过的全新的曲目,其中还包括阿尔冯斯·齐布尔卡(Alphons Czibulka)的一首加沃特舞曲,他是一位奥地利的军人、作曲家、钢琴家、指挥家。

开场的入城式进行曲是新年音乐会的常客,看到这个标题,我的耳边就响起了它的旋律,好像新一年的音乐会就这样开始了,非常期待。

接下来就是两个新的曲子,不过相亲波尔卡是选自大家耳熟能详的轻歌剧《吉普赛男爵》,所以里面会有一些熟悉的旋律出现。

轻如鸿毛快速波尔卡在新年音乐会上演出过4次,最近的一次是2003年哈农库特指挥的,这个曲子我印象非常深刻,因为它的旋律一点也不“轻如鸿毛”,尤其是在被誉为“节拍器”的哈农库特演绎下,更是激烈无比,不知道穆蒂会给我们带来如何的感受。

音乐会上半场以老约翰的两首新曲子收尾,而下半场则以苏佩、约翰和齐布尔卡的三个新曲子开场,新曲子如此集中的出现,一定会成为本场音乐会最为吸引人的部分。

新曲子都演完以后,音乐会就进入了怀旧与经典的篇章。魔弹快速波尔卡,曾经在阿巴多指挥的1991年新年音乐会和巴伦博伊姆指挥的2009年新年音乐会中出现过,是一首适合加入“噱头”的曲子,不过这次把它放在下半场还未到高潮的时段,很可能就不会有什么特别的了。

旋律优美的维也纳森林圆舞曲则是新年音乐会的常客,已故的洛林‧马泽尔就多次选择了这个曲目,并自己拿起小提琴,演奏其中的独奏部分。这个曲子中还选用了一种奥地利的民间乐器——齐特尔琴,音色很特别。

庆典进行曲虽然只在1996年作为开场曲在新年音乐会上亮相过一次,它却是一首我熟悉得不能再熟悉的曲子,因为这是我第一次看新年音乐会时听到的第一个曲子。有着这样的情怀加成,这首曲子成为2018年新年音乐会中我最期待的曲子之一。

乡村和城市以及假面舞会,也都曾经在新年音乐会上出现过,却不是常客。其中假面舞会只在阿巴多指挥的1988年新年音乐会上出现过。阿巴多指挥过两次新年音乐会,选曲风格都很特别,也带来了不少争议,2018年是阿巴多诞辰85周年,不知道是不是这个原因,穆蒂才特别选择了两首阿巴多指挥过曲子。

南国玫瑰和读者来信,这两个曲子我都很熟悉,在新年音乐会上也出现过数次,其中读者来信穆蒂曾经在1997年选择过。穆蒂在16个正式演出曲目中,只炒了自己指挥过的一首冷饭,为他点个大大的赞。

十四年未见,非常期待穆蒂的再次亮相。