Category Archives: 从这里发布的

从blog.newnaw.com发布的

关于给黑洞拍照背后的故事

  黑洞——人类当前认知中最神秘的宇宙天体。100多年前爱因斯坦的广义相对论就预测到它的存在,但直到2019年4月人类才获得了第一张黑洞照片。能够给黑洞拍照无疑是解锁了人类科技树上的新技能,如果你也和我一样好奇的话,本文就和大家分享一些给黑洞拍照背后的故事。

1. 当我们给黑洞拍照时,我们在拍什么?

  黑洞本身并不发光,也不会向外发出任何电磁辐射(除了还未被证实的霍金辐射),即使以宇宙中最快的光速运动也无法逃脱它的引力束缚。那对着它拍照岂不是什么也看不到?黑洞照片上那朦胧的橘色轮廓又是什么?要想知道给黑洞拍照的真相,我们先回顾一下黑洞的结构。

  根据上面这张欧洲南方天文台(The European Southern Observatory,简称ESO)给出的假想图可以看出,一个典型黑洞是由奇点,事件视界,光子球,相对论性喷流,最内侧稳定轨道,吸积盘等组成。简单来说,黑洞有两个最基本的部分。第一个是奇点(singularity),即黑洞的中心点,也是落入黑洞物质命运的终点。这是一个体积无限小,密度无限大的引力异常点,此处的空间和时间已经被扭曲到所有的已知物理定律,包括预言它存在的广义相对论都不再适用;第二个是事件视界(event horizon),可以把它理解成一个无形的边界,在这个边界上逃逸速度正好等于宇宙中最快的光速,所以一旦进入这个边界内部,就再也无法逃出黑洞。在万有引力常数不变的情况下,逃逸速度只和物体的质量还有半径(体积)有关。地球的逃逸速度即第二宇宙速度是11.2千米/秒。如果把地球压缩到半径9毫米以下的体积,那么它的逃逸速度就会大于光速,也就变成了一个黑洞。这个临界值可以简单理解为是任何物体自身的事件视界到奇点的距离即史瓦西半径,如果把一个物体压缩成球体的话,只要半径小于史瓦西半径,它就可以变成一个黑洞。太阳的史瓦西半径是3千米,一个人的史瓦西半径大概是10-26米(比电子还要小一亿倍)。

  黑洞在“吞噬”其周围物质时会形成高速旋转的吸积盘(accretion disc)。它是黑洞周围的气体或尘埃受到黑洞引力影响跟着一起旋转,当其角动量足够大即旋转足够快时,在一些特定的位置,产生的离心力能够和黑洞的引力相抗衡,从而形成的一种盘状结构。吸积盘内的气体因为高速旋转会产生超高温,从而向外辐射大量能量,也就是人类观察到黑洞发出的电磁波的主要来源。当黑洞吸积物质过快时,吸积盘的磁场会沿着黑洞自转方向扭曲,一些粒子就会以极高的动量(甚至接近光速)喷射出去,形成相对论性喷流(relativistic jets)。

  因此,给黑洞拍照主要是在不可见光波段,观测黑洞的吸积盘及喷流产生的电磁辐射。

2. 人类迄今为止拍摄到唯二的黑洞照片

  截至目前,人类只拍到过两张黑洞照片,都是由事件视界望远镜(Event Horizon Telescope,简称EHT)组织拍摄、整理、发布。EHT成立于2009年,专门以观测拍摄黑洞为使命,目前由超过20个国家和地区,60个科研机构的300多名科学家组成。

  这两张照片分别是2019年4月10日发布的Messier 87(室女A)星系中心超大质量黑洞(简称M87*)照片,以及2022年5月12日发布的我们银河系中心人马座A(Sagittarius A)方向的超大质量黑洞(简称Sgr A*或银心黑洞)照片。这里的星号借鉴了原子物理中激发态(excited state)的概念,表示该天体处于非常活跃的状态。

  两图中心黑色阴影部分并不是事件视界的范围,而是大约黑洞史瓦西半径的2.6倍大小,橘色亮斑代表吸积盘上的气体向着接近我们的方向旋转,暗部则反之(多普勒效应)。至于为什么银心黑洞上有三个亮斑,目前还未能确认其产生原因。

  下面是这两个黑洞的一些基本情况:

 M87*Sgr A* 银心黑洞
质量(与太阳相比)65 亿 410
与地球的距离5300 光年26600 光年

  再看看两个黑洞的大小。下图中右侧中心的小白点是太阳,银心黑洞外围(吸积盘)的面积,与水星轨道面积相当;左侧是M87*,图中白色小圆圈是冥王星的轨道面积,白色小点是1977年发射的旅行者1号,目前距离地球最远的人造探测器的位置。

  如果上面的表格中数字太大或黑洞体积还是不直观的话,我们把太阳放大看看可能会容易理解一些。

  实际上这两张黑洞照片的“拍摄”时间都是在2017年4月,持续近10天。第一张M87*照片在两年后公布,第二张银心黑洞的照片又等了3年才公布。

3. 给黑洞拍照很难吗?

  现在你可能会问,这两个黑洞那么大,怎么还拍得这么不清楚?和《星际穿越》里黑洞的样子相比怎么这么难看?给它们拍照片很难吗?答案是:难,非常难。可谓是拍照10天,修图5年(银心黑洞)。

挑战一:角分辨率

  从距离上来说,M87*黑洞虽然距地球比银心黑洞远2000倍,但却比后者要大1000倍。所以从地球望去,视觉效果上两者是差不多大小的。加之一个是我们已知的最大黑洞之一,一个是我们自己星系中心的黑洞,因此EHT选择它俩作为观测目标。它们在天空占据多大的位置(角分辨率)呢?答案是52微角秒(1微角秒=1″ / 1000 / 1000 ),相当从地球观察月球表面一个甜甜圈????。经计算,望远镜的尺寸需要和地球一样大,才可以达到如此的拍摄分辨率。

挑战二:超大数据量

  对黑洞的观测每天每个观测点产生的数据量可达350TB,科学家们需要足够的耐心和时间来处理这些数据。

银心黑洞附加题一:尘埃带遮挡

  由于太阳系位于银河系的盘面上,向银河系中心望去时,存在很多遮挡物,这是由星际尘埃和气体组成的尘埃带,使得银心处的可见光,紫外线和部分X射线都无法到达地球。尘埃带一般常见于漩涡星系或棒旋星系(比如银河系)。而M87星系是椭圆星系,完全不受银河系尘埃带遮挡,加上观测路线上也比较通透,所以后期数据处理要容易很多。

银心黑洞附加题二:延时摄影

  虽然两个黑洞的吸积盘旋转都非常快速(甚至接近光速),但因为M87*体积足够大,因此吸积盘旋转一圈需要数天时间,而银心黑洞吸积盘旋转一圈的时间只需要数分钟。这就导致给银心黑洞拍照类似延时摄影,或在光线不好的地方给一条欢乐的小狗拍照,很难得到一张清楚的照片。

4. 如何给黑洞拍照?

  好在人类拥有足够的好奇心和智慧的科学家们。在EHT 300多名工作人员跨地区跨时区的努力下克服了重重困难,最终让我们看到了宇宙中最神秘天体的样貌。

  为了建造足够大的望远镜,科学家们利用了甚长基线干涉(very-long-baseline interferometry, 简称VLBI)技术。简单地说,就是将地球上不同位置的射电望远镜组成一个虚拟阵列,并通过原子钟记录观测时间/同步数据,最终虚拟出一个相当于地球大小口径的望远镜。该望远镜的角分辨率达到了20微角秒,足够从巴黎看清楚纽约一张报纸上的文字。

  2017年4月的观测活动共有8个观测站参加,持续近10天。对于每天每个观测点350TB的数据,最终是由飞机将硬盘分别运送到德国的马克斯普朗克射电天文研究所和美国麻省理工学院海斯塔克天文台,由两地的超级计算机通过后期复杂的算法分别合并处理。

  此外,EHT团队利用每次观测时间的一部分来建立模型,使得最终可以去除地球大气湍流(从地面向天空拍照的反向去云)和尘埃带对银心黑洞数据的影响。

  对于银心黑洞因为吸积盘旋转过快造成的“延时摄影”的问题,从下图可以看出,不同于右侧M87*多张图像比较近似,左侧银心黑洞几乎每张图像都有差异。研究人员将4组平均后的图像再次合成,得到了最终银心黑洞的照片。

5. 给黑洞拍照有什么意义?

  虽然黑洞最早是由广义相对论预言存在的,但爱因斯坦本人一开始也无法相信这种天体的存在;即使到今天,天文学家普遍认为大多数星系中心几乎都存在一个超大质量黑洞,但就在2020年诺贝尔物理学奖颁给研究银河系中心的根策尔和盖兹时,也严谨地用了“超大质量致密天体”而不是黑洞的表述。

  如今人类解锁了给黑洞拍照的技能,不仅直接证明了星系中心黑洞的存在,其观测结果也与广义相对论的预测惊人地吻合,再次验证了它的正确性。通过对黑洞的观测和分析,不仅能让我们更加了解这种目前宇宙中已知的最神秘的天体,也会帮助我们更多了解星系演化的过程。

  顺带一提的是,通过一项对银河系中心长达16年的研究,科学家们还绘制出了近30颗恒星围绕银心黑洞的运行轨迹。不仅如此,其中一颗名为S2的恒星,在距离银心黑洞最近点(不到200亿千米)处的移动速度达到了惊人的2500万千米/时,接近光速的3%。如果单看其中一个的话,正如广义相对论所预测的那样,它的轨道形状成花瓣状,而非牛顿引力理论所预测的椭圆形,这是由史瓦西进动效应造成的。下图是艺术家展示的恒星围绕黑洞运行的轨道图(为了更好的视觉效果有所夸大)。

  但请不要误以为银河系中心就是这种唯美的画风,实际上它远比我们想象的要“暴力“许多。下图是美国国家航空航天局(简称NASA)2021年5月公布的一张由钱德拉 X 射线天文台和南非MeerKAT射电望远镜共同观测的银河系全景图,它主要是由不同X射线波段的数据合成而来。其中包括了炽热气体喷流,各种磁场线,以及中间白色部分的银河系中心。

6. 彩蛋:黑洞是如何形成的?

  黑洞的分类方法一般有两种:按照黑洞本身的物理特性(是否旋转,是否带电)分类和更常见的按照其质量体积分类。人类目前研究最多的两种黑洞就是按照质量来分类的恒星级黑洞(stellar black hole,5至数十倍太阳质量)和超大质量黑洞(supermassive black hole)。

  对于恒星级黑洞的形成原因,简单来说它是由大质量恒星生命末期经历超新星爆炸(supernova)后由引力坍缩形成的。而超大质量黑洞,其质量可达太阳质量的10万倍乃至100亿倍,对于其成因目前还没有比较确定的理论。

恒星级黑洞的形成

  恒星诞生是因星云内光年范围的气体和星际尘埃被扰动,物质不断向中心聚集,随着温度和压力的升高旋转坍缩而形成(剩下的“边角料”吸积会形成行星)。恒星诞生后内部主要存在两种力:自身质量产生的引力和由氢元素核聚变成氦元素过程中产生向外的推力。在主序星(main sequence star)阶段,这两种力维持平衡状态。当恒星进入生命演化末期后氢元素耗尽,意味着到氦元素的核聚变和向外的推力停止,但其自身的引力并不会消失,所以这种平衡被打破,其内核部分会像当初诞生时一样被引力压缩,内部温度和压力不断增加。当超过某个界限时,氦元素就会开始进一步核聚变。这种新的推力会使恒星的体积变成稳定时的几十倍或上百倍,即红巨星阶段。其内部温度也会高达上亿度,氦元素将快速核聚变直至成为碳元素。之后恒星已经没有足够能量来再次抗衡引力坍缩了,核心以外的外围物质会被抛散到宇宙空间中,但其最终的命运会因其自身质量不同而产生巨大差异。

  • 当恒星的质量小于1.44倍(钱德拉塞卡极限)太阳质量

  电子简并压力就会阻止其核心部分进一步坍缩从而形成稳定的白矮星(white dwarf),我们的太阳在50亿年之后就将面临此命运。推测白矮星会因能量渐渐散失最终变成黑矮星,但此过程需要的时间比现在宇宙年龄137.7亿年还长,因此现实中还没有黑矮星出现过。

  • 当恒星质量大于1.44倍但小于大约3倍左右(奥本海默极限)太阳质量

  由于自身引力过于强大,会使核心部分进一步坍缩。电子会被压入原子核,和带正电的质子中和变成中子,从而演化成中子星,这个过程通常会产生超新星爆炸现象,其亮度可短暂超过所在整个星系的亮度。中子星是除黑洞外密度最大的天体,一立方厘米体积物质的质量可达10亿吨。

  • 更大质量的恒星

  其内部核聚变的过程可以一直到铁元素(到铁元素后,核聚变将不再释放能量而是需要吸收能量)。经历超新星爆炸后,其核心就会进一步坍缩成恒星级黑洞。

  冷知识:根据现有理论,恒星的质量是有上限的,目前已知质量最大的恒星是太阳质量的200多倍。恒星质量越大,通常意味其寿命越短。比如著名的盾牌座UY,虽然其半径大约为太阳的1000倍,体积能容纳50亿个太阳,但质量仅为太阳的7-10倍。

超大质量黑洞形成的猜测

  传统理论认为它是由普通黑洞吸引合并或星系碰撞后中心黑洞合并形成的,但这个过程相对缓慢,不足以解释那些上亿倍太阳质量黑洞的存在。近期也有新的理论认为某些星系中心直接由暗物质构成,当其密度达到临界阈值后会直接坍缩形成超大质量黑洞。最新的詹姆斯韦伯太空望远镜也许能帮助科学家们找到答案。

7. 结语

  就在半个月前,NASA公布了詹姆斯韦伯太空望远镜拍摄的第一组五张图片,虽然顶着鸽王之王的头衔,但这个目前人类最强的望远镜果然没让科学家们失望。它现在正孤单一“镜”地处于地球外侧150万公里的日地拉格朗日点(Lagrangian point ,日地万有引力平衡点)L2附近。如果在将来,人类还能发射新的望远镜们到其它4个拉格朗日点上呢?我们是不是可以继续用VLBI技术得到一个近似地球轨道面积大小的虚拟望远镜?那个时候人类又将寻找怎样的拍摄目标?

  我们现在知道,一颗恒星诞生于超过光年范围的气体和尘埃云,在它数以亿年计的生命中,将宇宙最原始的氢元素不断聚变,直至其消亡时以爆炸这种壮丽的方式将部分金属元素重新抛洒回宇宙空间,可能成为孕育下一颗恒星/行星的原料。这和渺小地球上的生命历程是何其相似。从某种程度上讲,正在拿着手机(含有金属元素)阅读本文的你我,本就是宇宙中的尘埃,而我们手握的却是曾经璀璨的星辰。

  宇宙年龄将近138亿年,可观测宇宙半径为465亿光年,仅银河系内至少就有1000亿颗行星。在如此广袤的宇宙空间和无限的时间中,你我能够共享同一个星球,同一段时光,阅读同一篇文章,是何等的幸运……

参考资料

  1. Astronomers Reveal First Image of the Black Hole at the Heart of Our Galaxy https://eventhorizontelescope.org/blog/astronomers-reveal-first-image-black-hole-heart-our-galaxy
  2. Astronomers reveal first image of the black hole at the heart of our galaxy https://www.eso.org/public/news/eso2208-eht-mw/
  3. Astronomers Capture First Image of a Black Hole https://www.eso.org/public/news/eso1907/
    • 20 micro-arcseconds — enough to read a newspaper in New York from a café in Paris
  4. How Scientists Captured the First Image of a Black Hole https://www.jpl.nasa.gov/edu/news/2019/4/19/how-scientists-captured-the-first-image-of-a-black-hole/
  5. First Successful Test of Einstein’s General Relativity Near Supermassive Black Hole https://www.eso.org/public/news/eso1825/
  6. Magnetized Threads Weave Spectacular Galactic Tapestry https://www.nasa.gov/mission_pages/chandra/images/magnetized-threads-weave-spectacular-galactic-tapestry.html
  7. Stellar evolution https://en.wikipedia.org/wiki/Stellar_evolution
  8. 人類首次拍到的銀心黑洞!如何欣賞第二張黑洞特寫照片? https://www.youtube.com/watch?v=y2_VKxrqLpY
  9. 解開黑洞謎團 https://www.youtube.com/watch?v=ljhgurGJnEQ
  10. What it Takes to Image a Black Hole https://www.youtube.com/watch?v=D3m-GtAt5hY
  11. How did they actually take this picture?  https://www.youtube.com/watch?v=Q1bSDnuIPbo

利用Real-ESRGAN修复制作高清版国产经典动画《大闹天宫》

  之前和儿子看了几次西游记的舞台剧,为了让他对故事的来龙去脉有更完整的印象,答应了和他一起看孙悟空动画片。当然不是白龙马,蹄朝西,而是更久远的 1961 年首映的国产动画《大闹天宫》,至少那时的动画是真的为了做好动画,没有商业目的,看完即走不卖周边可以放心食用。找到了 [大闹天宫(影迷修复版)].The.Monkey.King.(Fan.Restored.Edition).1965.DVDRip.x264.AC3-CMCT.mkv (1.46GB) ,虽然已经是修复版,但画质仍然是比较感人。于是自己也有了这次动画的修复经历。

  修复使用的是 Real-ESRGAN 这个库,它基于 PyTorch 实现,用于对图像进行超分辨率成像 (super-resolution) 。根据作者 xinntao 的介绍,

Real-ESRGAN 的目标是开发出实用的图像/视频修复算法。我们在 ESRGAN 的基础上使用纯合成的数据来进行训练,以使其能被应用于实际的图片修复的场景(顾名思义:Real-ESRGAN)。

  ESRGAN 的作者也是同一人,属于自我进化了。另外作者还提供了论文和详细的 PPT 介绍。这次我用到的是专门针对动漫视频制作了模型的 RealESRGAN AnimeVideo-v3 ,介绍页面中作者已经提供了编译好的各平台可执行文件以及使用步骤,此处就不重复粘贴具体命令了,只对大致过程和遇到的问题说明一下。

  从超分辨率成像的描述可以看出,Real-ESRGAN 的核心是对图像进行“修复”。那么对视频文件如何处理呢?思路和把大象关进冰箱是一样的,总共分三步:

  1. 利用 FFmpeg 把视频中的每一帧图像都抽取出来,类似把视频解压缩成图像。开头提到的《大闹天宫》视频变成了 170,977 张 720*512 的图片文件,总大小 14.33GB。
  2. 使用编译好的可执行文件 realesrgan-ncnn-vulkan 对每帧图片进行增强。我选择的是默认 2 倍分辨率,于是得到了同样数量的 1440*1024 的图片文件,总大小 171.79GB。
  3. 利用 FFmpeg 把增强后的图像文件合并成视频文件,类似把图片打包成视频。最后修复好的两倍分辨率高清版视频是 2.42GB,libx264 编码格式。这里要注意两点:
    • 把图像打包成视频,要使用原始视频文件的fps,即每秒的帧数,也是利用FFmpeg的到。开头提到的《大闹天宫》是25 fps,由此也能推断出视频长度是 170977/25/60≈114分钟。
    • 常见的 mp4 格式只支持 hard subtitles (硬字幕,也等于不支持字幕),也就是把字幕直接合并到每帧图像上,播放时就不能开关或切换字幕了。所以此处我选用了 mkv 格式,一并把原来的简体和繁体中文两种字幕拷贝到了新的视频中,播放时可以按需切换或关闭。具体命令是 ffmpeg -i out_frames/frame%08d.jpg -i dntg.mkv -map 0:v:0 -map 1:a:0 -map 1:s -c:a copy -c:s copy -c:v libx264 -r 25 -pix_fmt yuv420p output_w_audio.mkv ,大致意思是视频按照 libx264 格式每秒 25 帧合并,音频从dntg.mkv文件中直接拷贝,字幕也是从 dntg.mkv 文件中拷贝所有可用字幕。可参考 FFmepg 的 -map 参数

  下面是美猴王孙悟空出场时一帧图像的对比,左侧是原视频中的图像,右侧是修复后视频中的图像。可以看出效果还是很不错的。

  GitHub 介绍中可看到作者 xinntao 是在腾讯工作,在腾讯视频上还能找到已经修复的一些动画片,有《爱探险的朵拉》,《巴布工程师》等。仅在动画领域就可以使小朋友的童年回忆变得更美好一些,在此对作者表示感谢。

  最后儿子问,孙悟空七十二变的本领是怎么学来的?他表示有兴趣学习……

通过威联通NAS上的WireGuard VPN连接回家里的网络环境

  以前在外访问家里NAS内容时,都是通过路由器上的端口转发,登陆NAS管理页面。这样做一是有一定安全隐患,二是所有内容都在NAS管理网页这个”沙盒“里,无法通过本地应用直接访问。比如听歌,要么用NAS自带的网页播放器,要么需要先把歌曲文件下载到本地。最近趁618低价,新添了 QNAP 威联通 NAS TS-464C,今年的网红N5105 CPU配上32G内存(虽然官方硬件规格说最大支持16G内存),足足比14年使用至今的QNAP 212P的512M内存大了64倍……212P虽慢但稳定异常,目前依旧继续服役稳定输出。

  解决上面提到的安全和内容访问问题,标准答案就是VPN,连通后无论身处何地,你的设备就像连到家中的WIFI一样。目前QANP的操作系统QTS 5.0自带了QVPN Service 3软件,内建提供QBelt(QNAP自家标准),PPTP,L2TP/IPSet(PSK),OpenVPN,WireGuard共5种VPN服务。参考NordVPNQNAP自家页面,Wire Guard在安全性和传输速度方面表现都相对更好。

VPN protocolSpeedEncryptionStreamingStabilityP2P
OpenVPNFastVery goodGoodGoodGood
IPSec/IKEv2FastGoodGoodVery goodGood
WireguardVery fastVery goodGoodVery goodGood
SSTPMediumGoodMediumMediumGood
L2TP/IPSecMediumMediumPoorGoodPoor
PPTPFastPoorPoorGoodPoor
VPN协议比较

  于是这次就用QVPN Service搭建WireGuard VPN服务。具体步骤此处省略,可参考QNAP官方文档:How to Configure WireGuard VPN Server and Client Settings in QVPN Service 3。搭建好后,QVPN Service服务器端和Android客户端设置分别如下:

  有几点注意事项分享如下:

  • 服务器端
    • 如果NAS里启用了QNAP的防火墙QuFirewall,请参照How to setup QuFirewall to allow VPN connections设置以允许WireGuard服务通过防火墙。
    • 需要在路由器上做端口转发以允许外网访问WireGuard VPN服务。上图使用的是默认端口51280。
  • 客户端
    • 接口的地址需要填入服务器端对等表中分配好的“允许的IP”地址。服务器端的对等表,建议一个设备添加一条记录方便区分。
    • 对等中的端点地址,填入通过路由器转发的WireGuard服务外网地址端口。
    • 对等中的允许IP地址,填入0.0.0.0/0以允许所有IP地址的流量。

  至此,你应该可以随时随地通过WireGuard服务接入家中的网络环境了。经过几天测试使用,速度和稳定性都很不错。在外面通过4G网络加WireGuard给小朋友看家中NAS里的《绿色星球》很流畅。另外因为等同接入家中WIFI,家里软路由上运行的所有服务也都是可以直接使用的,比如访问国际互联网。

  这次虽然使用的是QNAP自带的QVPN Service软件,但理论上在NAS的docker中或软路由(docker)中运行WireGuard服务器端都是可以的。

  总结一下使用WireGuard VPN服务接入家中网络的一些特点:

  • 连接速度和安全性都有保证。
  • 可通过客户端本地软件访问NAS内容,比如电影和音乐,不受网页端限制。
  • 以下两点,对于家里其他成员非常方便。一人维护家里的设置,所有客户端一次性配置免去今后维护,对于外地家庭成员尤其友好:
    • 可以替代NAS本身的网页“分享链接”功能。比如外地的家中成员看NAS里的电视剧时可以摆脱网页播放器,从而使用平板或手机的本地播放器进而投射到电视大屏上。
    • 可以直接使用软路由上的服务访问国际互联网,比如备份照片到Google Photos里。
  • 依然需要保留NAS网页端直接访问功能,以便在已经连入其它VPN的情况下访问NAS。

Nintendo Switch借助macOS升级TF卡

这两天黑五打折,买了三个游戏后发现最初128GB的存储卡已经消耗殆尽,但去年21块人民币买入31.5GB的NBA2K19依然还没有下载。。。于是购入一张256GB的卡准备升级一下。

在确认游戏存档全部保存在主机上(无法转移)之后,看到大致步骤是先把新卡插入机器格式化,之后通过电脑把旧卡的所有文件复制粘贴覆盖到新卡上。于是一番操作之后插入拷贝好的新卡到机器里,开机:提示无法识别存储卡。复制之后还专门确认了新旧两张卡存储占用的字节数都是一样的……搜索之后发现类似的情况中文内容鲜有提及,只有bilibili的DioTV上这条视频里提到macOS上如此操作无法成功。之后还看到了Reddit上的这个帖子 Save you time: Copying SD card on Mac does NOT work ,心想这老任也抠得太紧了吧。

最后找到了 How to Transfer Data Between Nintendo Switch microSD Cards with OS-X 里面提到的办法,操作之后确认有效。

1. 旧卡插入mac,执行下面命令:
mkdir ~/Desktop/sdcard
cp -r /Volumes/Untitled/Nintendo ~/Desktop/sdcard
2. 新卡插入Switch,格式化。
3. 新卡取出插入电脑,执行下面命令:
cp -r ~/Desktop/sdcard/Nintendo/* /Volumes/Untitled/Nintendo
4. 拷贝完毕后新卡插入Switch,开机

这下Switch可以正确识别新的存储卡了,并且之前下载的游戏也能正常运行。可出现了新的问题:无法保存截图。试了一下,如果截图存储位置设置为SD卡,则截图后左上角提示“无法保存”,如果截图存储位置设置为主机内存则一切正常。同样中文内容只搜到了这篇:NS数据转移到新SD卡后无法截图! ,但暂时没有解决。最后在Reddit上找到了解决办法 Can’t save screenshots to the SD card after upgrading to a new card? I think a found a fix that doesn’t require a complete reformat of the new card. 步骤如下:

1. 旧卡插入Switch,拷贝所有视频截图到主机内存。
2. 新卡插入到电脑,直接删除根目录的 Album 文件夹及其内容。
3. 新卡插入到Switch,拷贝主机内存里的所有视频截图到SD卡。

最后确认使用新卡的情况下截图正常,游戏运行正常。留存给同样低估了自己游戏购买力的朋友,以及之后如果需要升级到512GB的自己:)

几种需要内网穿透情况下Windows远程桌面的方案

要解决一个比较典型的需求:在家里的时候需要远程桌面到办公室的电脑做一些操作,最大问题是办公室的机器在局域网内没有公网IP,所以不能直接使用远程桌面工具连接。想要完成这个任务核心是需要进行所谓的内网穿透,之后就可以选择自己熟悉的远程桌面工具操作了。这里介绍几种我使用过的办法,供有需要的朋友参考。

* 如果你需要操作的是一台内网Linux机器,也可以参考之前的这篇《从Internet访问没有外网ip的NAS服务器的解决办法》。

 

方案一 TeamViewer

TeamViewer是一款简单好用的工具,不仅允许个人用户免费使用,还支持多平台下机器相互连接,比如可以从Android手机或macOS电脑远程到Windows电脑。只要两台电脑都安装了该软件,便可直接相互远程桌面,内网问题完全透明,操作速度也完全可以接受。不过使用一段时间后,被提示有可能是商业用途使用,也考虑过付费购买,但单个用户49刀/月的价格对于偶尔使用来说确实比较贵。于是就转到了第二个方案。

 

方案二 ZeroTier

ZeroTier也是一款可以直接安装使用的工具,相比TeamViewer的好处是,第一提供免费套餐,不区分个人和商业用途,并且免费套餐允许同时100台设备组网,第二它是更完整的内网穿透方案,安装了ZeroTier软件的所有设备都会加入到一个自己指定的虚拟局域网内,这样这些设备之间相当于都是局域网访问,所以不仅能远程桌面,还能进行其他任何操作。ZeroTier的使用也很简单,每台设备上安装软件后加入到自己创建的网络内即可,具体可参考相关帮助。

唯一可惜的是在远程操作时,速度有些慢,这是因为同TeamViewer一样,设备之间的连接都是通过他们的服务器转发的,而ZeroTier的服务器,在国内的访问速度显然不如TeamViewer的好,如果TeamViewer的连接速度比作1的话,ZeroTier不经过额外配置的情况下,对于我的网络状况下差不多是0.6。

所谓的额外配置,是ZeroTier允许你自己加入中转服务器(通常是自己所有设备都能访问到的具有公网IP的VPS),这样两台设备连接时会自动利用ZeroTier自身服务器(称作planet)和你指定的中转服务器(称作moons)之间连接速度更好的一个。在按照官方文档Creating Your Own Roots (a.k.a. Moons)和相关参考文章《ZeroTier moon 设置教程》 设置好以后,发现速度确实有所提升,感觉可以达到TeamViewer的1-1.3倍的速度。

 

方案三 frp

frp是国内大牛开发的一个开源方案(A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet.,目前仍处在开发状态,不推荐用于生产环境),相比于TeamViewer客户端/服务器端都闭源,ZeroTier客户端开源/服务器端闭源来说,frp的客户端和服务器端都在GitHub上开源。主要思路是通过自己指定中转服务器,实现两台不同内网设备之间的点对点链接。它的好处是和ZeroTier一样能够暴露某个机器上的所有指定端口,而且服务器端完全走指定的中转服务器(ZeroTier是自动选择)。具体配置步骤如下:

1. 在中转服务器VPS上配置服务器端。

wget https://github.com/fatedier/frp/releases/download/v0.23.3/frp_0.23.3_linux_amd64.tar.gz

tar -zxvf frp_0.23.3_linux_amd64.tar.gz

//编辑服务器端配置文件frps.ini

[common]
bind_port = 7000  # VPS监听的端口,用于和frp客户端连接 。需防火墙开放

//启动服务器端(可自己配置系统服务)

nohup ./frps -c frps.ini & &> /dev/null

 

2. 在需要远程桌面的机器上配置客户端

//从github release获取同样的release文件(服务器端和客户端的所有文件都在里面)

//编辑客户端配置文件frpc.ini

[common]
server_addr = xxx.xxx.xxx.xxx  #中转VPS的Ip
server_port = 7000                #同服务器端配置的端口
[rdp]
type = tcp
local_ip = 127.0.0.1
local_port = 3389                 # 当用户连接 frps的以下3443端口时,会被转发到frp client的此端口
remote_port = 3443              # frps监听的端口,任何机器通过此端口与frps连接。需防火墙开放

custom_domains = xxx.xxxxxxxxxxx.com              #可选,如此可通过域名访问3443端口

 

3. 客户端通过frpc -c frpc.ini即可启动。办公室的电脑是Windows机器,可通过如下方法开机自动启动frp。

//创建一个frp_autostart.bat文件如下

@echo off
cd C:\frp_0.23.3_windows_amd64
frpc -c frpc.ini
exit

//创建Windows服务

C:>sc create frp binPath=  C:\frp_0.23.3_windows_amd64\frp_autostart.bat start= auto

 

最后即可通过[中转VPS的IP]:3443进行远程桌面连接了。家里的是macOS,推荐使用微软官方的Microsoft Remote Desktop的软件(目前beta)。最后frp这个方案速度最快,如果TeamViewer是1的话,感觉连接速度可达2以上。值得一提的是,这三个方案都是跨操作系统的,并且后两种方案,不局限于远程桌面,其他应用都可以支持。

北京联通烽火HG220G-U光猫升级+路由改桥接

  去年家里宽带升到200M之后,因为原先的光猫是百兆LAN口,网速受限,所以打联通客服要求换一个千兆LAN口的光猫。当时说我们这片只有烽火HG220G-U个型号的二手光猫支持千兆了,于是就先用着,还算稳定,但发现光猫的工作模式被锁死在路由模式下,不像原来的百兆光猫是桥接模式,这样光猫后面的路由器就没法拨号,导致路由后的NAS没法从外网直接访问,又用回了之前的SSH反向端口转发的办法

  后来又联系过两次联通客服,总说新猫没有到货,于是想看看有没有什么办法自己解决。找到了老周部落贴吧里的《烽火HG220G-U E00L2.03M2000光猫改桥接教程》,修改完成后发现光猫确实按桥接模式工作了,路由器也能正常拨号上网,但网速从200M降到了不到100M,发现是因为光猫的固件版本掉坑里了,2.02版本的光猫确实会出现改桥接后掉速的问题。当时也没找到升级光猫固件的办法,无奈又改回了路由模式。

  昨天恰好看到老周部落贴吧里的又出了新文章《北京联通烽火HG220G-U/HG221G/HG260G-U/HG261G互通型HGU升级指导》,先看了下跟贴,发现有一人情况和我一样,原来是2.02版本,想通过升级再改桥接。但他升级到最新2.04版本后,改完桥接依然掉速。

image 

  本想希望不大,抱着试试看的心态也升级了家里的光猫固件版本,但没有直接升到最新的2.04,而是到之前教程里改桥接肯定没问题2.03版本,然后改桥接,路由拨号,测试,200M–>200M。又可以从外网愉快的访问NAS啦~

image

 

image

 

image

家用(影像)存储及备份方案选择

  随着家庭成员和移动设备的增多,我们日常生活中越来越频繁地产生着各种照片和视频文件,日积月累,这些数字资料的保存,读取,备份或早或迟都会成为困扰你的一个问题。

 

  先来说说存储。我们移动设备存储空间满额的时候,最先想到的是把照片和视频导出保存到电脑硬盘上;而你肯定经历或者听说过硬盘坏掉这件事情,所以你可能觉得电脑硬盘靠不住了,买个移动硬盘来寸照片和其他重要资料吧,一来不用天天通电读取,看起来寿命似乎要更长,二来可以当作备份使用。但仔细想想,移动硬盘只不过是一个体积更大,容量更大的u盘(而且抗震性能还不如u盘),把你认为重要的资料存在u盘里可靠吗?你听说周围朋友移动硬盘坏了,丢了的情况多还是他说我家里台式机硬盘坏了的情况多?既然台式机硬盘无法保障我的照片和视频,更好的方案是什么呢?答案就是NAS。关于NAS的介绍大家可以自己google一下,品牌一般就是Synology(群晖)和QNAP(威联通)二选一。而当你使用NAS超过一段时间后,会发现对NAS硬盘里的资料进行备份又变成一个不可避免的话题。虽然比台式机硬盘坏掉概率要小很多,但只要发生,对于你的资料就是100%的丢失。

 

  再来说说备份。如何对NAS上的资料进行备份呢?通常NAS里不仅有比较珍贵的照片和视频,可能还有不太重要的一堆高清电影。最先想到的办法是多块硬盘做RAID1或者RAID5。前者硬盘空间浪费多,后者对NAS硬件级别又有要求(最少3块硬盘)。自己手上的QNAP 212P是比较低端的NAS,虽然有两个盘位,但发现做RAID1的话需要自己把现有资料备份,然后塞两块硬盘进行重新格式化,之后再把备份的数据倒回去;想做热备份的话就得换更好的NAS。前者需要多加一块硬盘,外加数据导入导出,成本1000元左右;后者换NAS,加硬盘,成本更高。

 

  最后目光又落回了云存储上面。之前也看到NAS里有应用可以备份本地数据到云存储上面,一般都支持增量备份及本地/云端双向同步备份,足够满足需求了。但感觉有额外的费用,没有细想。这回重新计算一下成本发现,云存储的备份办法确实比较划得来。目前需要备份的照片和视频差不多有100G,按照AWS S3最贵的Standard存储级别0.03美元/GB/月来算,就算200G数据,每月成本6美元,2年的成本大约1000人民币,相比加硬盘,换NAS来说更有优势。因为目前家用NAS正在快速普及,两年后NAS功能,硬盘容量,成本几何都是未知数。

 

   下来就比较一下可选的云存储方案。能考虑的也就是三家,亚马逊的AWS S3,谷歌的Google Cloud Storage和微软的Azure Storage。从信誉度来说国内的各种所谓云计算直接pass,从持久性来说微软的Azure也pass,不是说Azure的durability不行,而是怕微软的Azure哪天就不行了。。。S3中的Glacier响应速度4小时,就不用考虑了;S3还有一个Reduced Redundancy Storage(RRS)的durability是99.99%,相比其他剩余选项的99.999999999%来说,在成本差别不大的情况下也可以淘汰掉。剩余的选项对比如下:

 

  AWS S3 Standard AWS S3 Standard – Infrequent Access GCD Standard GCD Durable Reduced Availability GCD Nearline Storage
Durability 99.999999999% 99.999999999% >= 99.9% >= 99.0% >= 99.0%
Availability 99.99% 99.99% “High availability” “Lower availability than Standard” “Lower availability than Standard”
Storage Pricing (per Month) $0.03 per GB $0.0125 per GB $0.026 per GB $0.02 per GB $0.01 per GB
 

Data Transfer Pricing

$0.09 per GB $0.09 per GB $0.012 per GB $0.012 per GB $0.012 per GB
Retrieval Fee $0.01 per GB $0.01 per GB

 

  其中,S3的价格以us-east为准;Data Transfer即是数据下载到本地的价格(存储收费,下载消耗网络带宽也要收费),而Google Cloud Storage还要区分下载到哪,大部分地区是$0.012/GB,而下载到中国(可能吗?)和澳大利亚地区费用更高;Retrieval Fee是价格保护策略的收费,对于价格更低的AWS S3 – IA和Google的Nearline Storage来说,本身存储成本低,划算,所以设置了额外的费用增加使用成本,也就下载是除了Data Transfer的费用外还要额外收取$0.01 per GB的费用;此外的Request Pricing(请求次数的费用)很低,可以忽略不计。

 

  Google Cloud Storage和S3的设计理念完全一致,IAM管理,bucket,object,storage class等,但控制台界面的友好性,即使用策略的灵活性来说(S3允许单向切换Storage Class,Google不行;S3的Life Cycle策略的应用粒度可以到bucket内的某个/某些文件夹,google不行),AWS完胜Google。另外,虽然家里已经有能翻墙的路由器,但在其他网络上访问Google的数据的不便利性,也是需要考虑的一个因素。

 

 基于上面的数据,和大约200GB左右的数据量,几乎完全是单向备份,极少机会会下载到本地(除非NAS硬盘坏掉)的使用场景来看,AWS S3 Standard – Infrequent Access是最好的选择。最后从安全性上来说即使RAID1,硬盘加再多也有可能出事故,比如搬家时摔坏了,丢掉了;云存储可以防止此类隐患,理论上来说即使地震也不怕了。。。当然地震后你本人仍要有能够访问云端数据的机会:)

 

参考:

1. Amazon S3 Storage Classes

2. Amazon S3 Pricing

3. Google Cloud Storage Storage Class

4. Google Cloud Storage Pricing

5. Google Cloud Storage SLA

在CodeDeploy脚本中使用nvm

  nvm是一个nodejs版本管理工具,它能够方便地帮助你管理多个共存的nodejs版本,并在其中进行自由切换。

  这回在AWS的CodeDeploy脚本中调用nvm自动安装和使用指定版本的nodejs,遇到了问题。如下的脚本,

image

  执行后发现,最终部署结果里并没有使用5.3.0的nodejs,而使用的仍然是系统原来安装的老版本。ssh登录机器,查看nvm ls和nvm current,却已然是5.3.0版本的nodejs了:

image

  原来nvm的所有命令,如nvm install,nvm ls都是写在~/.nvm/nvm.sh脚本里的,系统之所以能识别这些命令,是因为在当前shell里运行过source ~/.nvm/nvm.sh。而正因为已经在~/.bashrc文件中添加了该语句,所以每次ssh登录时,shell相当于已经source过了该脚本。

  而以”su -c”方式执行命令时,命令是在一个non-login,non-interactive的shell执行的,所以不会读取~/.bashrc文件,因此nvm的命令就无效了。解决办法是在CodeDeploy脚本中调用nvm命令的语句前,先使~/.nvm/nvm.sh文件source一下。比如:

image

  参考:

Windows下删除过长路径下文件(夹)的办法

  有时候在Windows下删除文件或文件夹会碰到如下错误:

The source file name(s) are larger than is supported by the file system. Try moving to a location which has a shorter path name, or try renaming to shorter name(s) before attempting this operation.

文件名对目标文件夹可能过长。您可以缩短文件名并重试,或者尝试路径较短的位置。

image

  解决的办法是在命令行输入:

robocopy /MIR c:\a d:\xxx

  其中c:\a是c盘新建的一个空目录,d:\xxx是路径过长的文件(夹)的根目录。执行后,你会发现d:\xxx目录已经被清空了。

使用AWS CodeDeploy的几点注意事项

  AWS CodeDeploy是亚马逊云计算提供的服务之一,用来将代码更容易地部署到EC2实例或私有云实例中。

image

  它能够根据用户配置,从S3或Github上获取最新代码,并按照用户提供的appspec.yml配置文件,在不同的hook事件阶段执行不同的脚本文件,从而使代码部署过程自动化。

image

  比如你可将多个EC2实例分为Dev,QA,PRD三组,通过结合CodeDeploy和其他CI工具(如Jenkins),自动化完成持续交付(部署到Dev/QA实例上),持续部署(部署到PRD实例上)的任务。

  在使用CodeDeploy的过程中,有以下几点事项需要注意:

  • 所有EC2实例上必须安装CodeDeploy Agent服务,EC2实例之所以会响应CodeDeploy服务,都是由CodeDeploy Agent来完成工作的。
  • 默认CodeDeploy Agent是通过root用户安装的,所以appspec.yml中执行脚本时,默认是以root用户身份执行。而我们的代码中用到了PM2,执行PM2命令(如pm2 start)时,需要在appspec.yml中指定以ec2-user用户执行脚本,否则相关命令执行时,会导致EC2实例cpu持续占用100%,最终导致超时而部署失败。
  • sudo: sorry, you must have a tty to run sudo问题。在sh脚本中,如有需要sudo执行的命令,则需在所有EC2实例的/etc/sudoers文件中,注释掉“Default requiretty”一行。
  • /bin/bash^M: bad interpreter: No such file or directory问题。这是因为在windows操作系统上修改了.sh文件,导致文件末行编码不同,而在linux机器上无法执行。解决办法是在linux机器上重新保存该文件,或在windows上用sublime打开该文件,View->Line Endings->选择Unix,保存即可。