Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

马斯克称脑机接口能解决大多数疾病,大规模量产后成本将与手机相当

By: 范津瑞
30 October 2024 at 18:30

绝大多数疾病或者大脑问题,我认为都可以通过 Neuralink 解决。

这是马斯克在 2024 年度神经外科大会(CNS 2024)上发表演讲时的豪言壮语。他表示「把大脑想象成电路板,它有些短路或者缺失,这些问题我们都能修复」。

同电影里的「钢铁侠」一样,某种程度上埃隆·马斯克也在用自己的方式「拯救世界」。为这个世界上的残障人士带来福音,就在马斯克的计划之中,而且是相当靠前的优先级。

▲Neuralink 公司开发的脑机接口(BCI). 图片来源:Aegis

Neuralink 的主要目标是通过向人脑植入芯片、电极等装置,建立脑机接口,实现用大脑生物电信号直接操控外部设备,以帮助有视觉或行动障碍的患者。

这项技术允许机器通过读取神经活动产生的电磁信号来获取大脑的意图,从而实现控制手机、电脑、机械臂等外部设备。

此外,机器也可以通过对特定神经元集群的电刺激,向大脑输入信息,将图像、声音转化为神经信号,直接输入大脑的相关皮层,进而带来视觉和听觉的主观体验。

Neuralink 的首款产品被命名为「心灵感应」(Telepathy)。根据马斯克的说法,这个产品允许人们通过意念控制他们的手机或电脑,并通过这些设备控制几乎所有其他设备。

▲Neuralink 的首款产品「心灵感应」. 图片来源:digialps

2024 年 1 月,Neuralink 进行了首次人体实验。

首位被试者名叫 Noland Arbaugh,他于 2016 年遭遇潜水事故,因脊髓受伤而导致四肢瘫痪。这位被试者在植入了名为「N1」的脑机接口设备后,术后恢复良好,还能使用脑机接口进行观看视频、阅读和玩电子游戏等日常活动。

然而一段时间后,Noland Arbaugh 大脑中的植入物出现了一些问题:一些接线从他的运动皮层缩回,影响了信息传输速率,导致捕获的数据减少。

作为对策,Neuralink 的工程师们通过修改算法来提高每秒位数,以改善设备的性能。

▲Neuralink 的首位被试者「Noland Arbaugh」. 图片来源:WIRED

Neuralink 的第二位被试者名叫 Alex,曾是一名汽车技术员,同样因脊髓受伤而失去行动能力。

Alex 的植入物叫做「Link」。为了避免出现第一位被试者的「线程回缩」问题,Neuralink 优化了手术的操作和流程,减少了手术期间的大脑运动,缩小了植入物和大脑表面之间的间隙,并且加深了植入深度。

令人欣喜的是,Alex 在将脑机接口连接到计算机的 5 分钟后,便学会了用意念来控制光标的移动。

目前 Alex 已经学会使用脑机接口操作 CAD 制图软件,给自己的脑机接口设计了 3D 打印的充电支架,还能玩「CS2」这类 FPS(第一人称射击)游戏。而且,术后也的确未观察到「线程回缩」问题。对此,Alex 非常感慨:

The Link 是我在重获自由和独立的道路上迈出的一大步。

▲右下角是 Alex 用 Link 设计的充电支架. 图片来源:Neuralink

Neuralink 正在扩展参与者使用数字设备的控制选项,包括解码多个点击和多个同时移动意图,以提供完整的鼠标和视频游戏控制器功能;同时,他们也正在开发算法以识别手写意图,以便残障人士更快地输入文本。

未来,Neuralink 计划使 Link 能够与物理世界互动,使用户能够通过控制机械臂或轮椅来独立进食和移动。

据悉,Neuralink 的下一代产品名为「盲视」(Blindsight),有望帮助失去双眼和视神经的人重见光明,甚至能让那些天生失明的人首次目睹世界。

▲Neuralink 的下一代产品「盲视」. 图片来源:Drive Tesla

对此,印度实业家阿南德·马辛德拉(Anand Mahindra)表示「如果这个设备能够满足期望」,那么这将是马斯克「给人类最持久的礼物,远远超过特斯拉或 Space X」。

除了在脑机接口的功能方面进行创新的迭代,马斯克还表示他们有一个称作「600 秒电路」的规划。它类似于激光近视手术,而且「并没有违反物理学原理」:用户只需要坐在椅子上,10 分钟后就能完成植入,600 秒。

此外,马斯克对 Neuralink 未来的「低成本量产」也充满信心,听起来甚至有点不切实际:

一旦量产,设备本身应该不会太贵。我希望它的价格能在五千到一万美元之间。而且进一步量产的话,它的成本应该可以接近 Apple Watch 或手机,也许是一两千美元,类似这样的价格。

不过,谁让他是「擅长于把不可能变为姗姗来迟」的「钢铁侠」埃隆·马斯克呢。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


Boot volume layout and structure in macOS Sequoia

By: hoakley
22 October 2024 at 14:30

In macOS Mojave and earlier, all Macs booted from a single integrated volume, containing system and user files arranged in directories based on those common to many Unix systems. That started to change in Catalina, when that volume was divided into two, System and Data, and continued in Big Sur, when macOS started booting from a specially sealed and signed snapshot, the Signed System Volume or SSV. Changes since Big Sur have been smaller and more subtle, with the introduction of the paired recovery system and cryptexes. This article guides you around the volumes and directories that compose the boot volume group in macOS 15 Sequoia.

Internal SSD partitions

All Macs are now intended to be started up from their internal SSDs through a secure boot process that tries to guarantee the integrity of all loaded code from the boot ROM and firmware through to the kernel and macOS. This is simpler in an Intel Mac, whose internal SSD is divided into two partitions, one for EFI, the other for the boot volume group.

BootDiskStructureIntelSeq

Device names given here are examples, and those seen are likely to differ.

The boot volume group is composed of:

  • The System volume, used to build the SSV, which is unmounted during normal running.
  • The Signed System Volume, a signed and sealed snapshot of the System volume, containing the immutable System.
  • The Data volume, by default named Macintosh HD – Data, mounted within the System directory tree, and writable by the user.
  • The small Preboot volume, used to store cryptexes.
  • The paired Recovery volume, containing a disk image of the Recovery system.
  • The VM volume as the backing store for virtual memory.
  • Possibly an Update volume that appears to have been used when upgrading to versions of Big Sur. This won’t be present on more recent Macs, and appears to have been disused since macOS 11.

The SSV is created from the System volume during macOS installation and update, and features a tree of cryptographic hashes verifying its integrity, and its signature to verify that its contents match those expected for that version of macOS.

To accommodate the more advanced secure boot of Apple silicon Macs, their internal SSDs are divided into three partitions, with an extra six volumes beyond the boot volume group.

BootDiskStructureMSeq

Device names given here are examples, and those seen are likely to differ.

Apple silicon Macs have two Recovery systems: their primary Recovery is run from a disk image in the paired Recovery volume in the active boot volume group, as with Intel models. A previous version of that disk image is stored in the Apple_APFS_Recovery partition/container, where it’s available as the Fallback Recovery system, only in Apple silicon Macs. The contents of the Apple_APFS_ISC partition are small, and largely support secure boot with extended anti-replay technology (xART) for the secure enclave, and other internal features.

Another more curious difference between architectures is that the default name of the Data volume differs: in Intel Macs, it’s normally Macintosh HD – Data, while Apple silicon Macs use just Data.

Inside the boot volume group

macOS now consists of three components:

  • the SSV, providing the root file system, and consisting of the main immutable components
  • the Data volume, mounted within the root and linked to it by firmlinks, consisting of user-writable directories
  • cryptexes, signed and sealed disk images mounted from the Preboot volume during the boot process, containing components that can be updated without creating a new SSV, notably including Safari and its supporting frameworks, shared caches for dynamic loading and, in Apple silicon Macs, those to support Rosetta 2.

These can be traced using the volume IDs and inode numbers of directories and files within the unified file system presented to the user, and summarised in the diagram below.

BootVolGpSeq

Volume IDs and inode numbers given here are only examples, and you’re likely to see different ones.

This shows the location of major directories across the three components, with those located in the SSV shown in pink, those of the Data volume in blue, and contributions from cryptexes in green. The effect of firmlinks and ‘grafting’ of cryptexes into the file system is now complex. One important example is how what appears to be the single top-level Applications directory is assembled from:

  • bundled apps in the SSV, located in /System/Applications,
  • user-installed apps in /Applications in the Data volume,
  • Safari.app mounted from the Preboot volume in the App cryptex.

Although the SSV is identical in both Intel and Apple silicon Macs, the two architectures are now differentiated by their cryptexes. Those for Intel Macs contain only dyld shared caches with x86 support; those for Apple silicon Macs provide both ARM and x86 support, as well as AOT shared caches, for Rosetta 2.

Firmlinks

System firmlinks are still the same as listed previously in /usr/share/firmlinks and haven’t changed since Catalina:
/Applications <-> Applications
/Library <-> Library
/System/Library/Caches <-> System/Library/Caches
/System/Library/Assets <-> System/Library/Assets
/System/Library/PreinstalledAssets <-> System/Library/PreinstalledAssets
/System/Library/AssetsV2 <-> System/Library/AssetsV2
/System/Library/PreinstalledAssetsV2 <-> System/Library/PreinstalledAssetsV2
/System/Library/CoreServices/CoreTypes.bundle/Contents/Library <-> System/Library/CoreServices/CoreTypes.bundle/Contents/Library
/System/Library/Speech <-> System/Library/Speech
/Users <-> Users
/Volumes <-> Volumes
/cores <-> cores
/opt <-> opt
/private <-> private
/usr/local <-> usr/local
/usr/libexec/cups <-> usr/libexec/cups
/usr/share/snmp <-> usr/share/snmp
/AppleInternal <-> AppleInternal (on Apple engineering systems only)
in each case shown as the system volume path and the Data volume path which are firmlinked together.

Directory layout

Given the volume ID and inode numbers of directories and files, together with that list of firmlinks, it’s possible to construct a full directory tree for the conjoined SSV, Data volume and cryptexes. A simplified version of that is in the diagram below.

BootVolFoldersSeq

This uses the same colour convention, with pink for the SSV, blue for the Data volume, green for cryptexes, adding red for the mountpoint of the Data volume, and yellow for firmlinked items. This demonstrates graphically how the contents of the main Applications folder are gathered from three sources.

Previous boot volume architectures from High Sierra to Monterey are explained here.

马斯克官宣免费!这个 400 多美元的产品,如何在「世纪飓风」中救命

By: 周奕旨
16 October 2024 at 19:09

这个九月与十月,美国东南部一直不太平静,来自墨西哥湾的飓风 Helene 以四级风力席卷了佛罗里达州,半个月后,同样诞生于墨西哥湾的飓风 Milton 也登陆了佛罗里达州,双重飓风接连袭击,当地居民几乎没有喘息的机会。

连绵不断的暴雨与愤怒狰狞的狂风只是开胃菜,飓风过后,除了摧毁基础设施和个人房屋外,中断的通讯同样是不小的麻烦。

为了应对这一紧急状况,马斯克连续宣布两则消息——SpaceX 将为受灾地区提供基于星链系统的手机信号与免费网络。

每个人,都能收到来自五百公里外的信号与网络

面对两场飓风的猛击,基础设施遭到破坏,手机信号也跟着消失了。对于现代人来说,手机简直就是生活的命脉,一旦没了信号,瞬间就成了一块只能玩游戏或者刷照片的「摆设」。

为了应对这个问题,SpaceX 宣布将与 T-Mobile 合作,联手为受灾地区的民众提供应急通讯信号,帮助大家在灾难中保持联系,尽可能减少飓风带来的额外麻烦。

据 SpaceX 的介绍,星链卫星已经具备为手机提供基础短信服务的能力。利用目前发射的上百颗可直连智能手机的卫星,向受飓风影响的用户和运营商发送紧急警报。

佛罗里达州的 T-Mobile 用户现在通过这项合作可以连上星链卫星。如果手机成功连接,你会在运营商名称处看到「T-Mobile SpaceX」,虽然信号可能只有一两格,但足够用来发短信联系亲人或寻求医疗帮助,并收到新的警告消息,以应对新的极端情况出现。

T-Mobile 在早些时候就对卫星紧急警告功能进行过多轮测试,并成功向能连接到卫星的手机发送了预警测试信息,其中包括使用其他运营商的手机。

不过,由于支持直接连接手机的星链卫星数量还不够多,因此服务能力还比较有限,SpaceX 只能尽最大努力保障应急通信。

此外,SpaceX 还宣布将为受灾地区提供为期一个月的免费网络服务,只要你处于飓风覆盖的地区,不管是新用户还是老用户,都可以免费使用一个月的星链网络,以帮助网络设施被飓风摧毁的地区民众重新连接互联网。

▲ SpaceX 给出的受灾地区范围

想要提供信号以及网络,需要对天地间看不见的信号频率进行匹配,才能让卫星信号顺利地从宇宙传输到目标设备。

一般来说,手机依赖较低的频段,通常在 700 MHz 到 2600 MHz 之间,比如 700 MHz(低频段)或 1800 MHz 和 2100 MHz(中频段),这些频率支持 LTE 或 5G 网络;而卫星通信使用较高的频段,如 L 频段(1-2 GHz)、S 频段(2-4 GHz)、Ku 频段(12-18 GHz)等,它们能穿透大气层并传输大量数据。

传统的星链网络服务就是通过其中的 Ku 频段(12-18 GHz)、Ka 频段(26.5-40 GHz)以及 V 频段(40-75 GHz),传输网络信号,这些信号频段位于高频范围,能够支持高速数据传输,并具有较强的抗干扰能力,其中 Ku 频段被广泛用于卫星互联网服务,特别是家庭和商用用户,而 Ka 频段则提供更高的数据容量,适合大规模的通信需求。

此外,星链也使用 V 频段(40-75 GHz)来增加容量和提升网络性能,特别是在未来更高密度的通信环境中。这些高频段允许星链提供高速的互联网服务,但也意味着信号在穿透障碍物时可能会有所衰减,因此在较为开阔的环境中才能获得最佳的连接效果。

不过,想要接收这些频段的信号,需要在地面配备一个超过 20 厘米直径的天线。

这也是为什么用户除了订阅网络服务外,还需要购买星链套件,才能顺利使用互联网。

而手机与卫星「握手」,其实也不算什么新鲜事儿了。

现在已经有不少手机支持卫星通信,虽然各大厂商的技术储备和实现方式不同,但总的来说还是沿着一条路在达成与卫星直接通讯:在一定的硬件基础上,通过定制的芯片或是额外硬件,与不同的卫星联络。

不过,SpaceX 和 T-Mobile 选择了另一种更大胆的方案,他们的目标是尽量让现有的所有智能手机都能够直接与卫星建立连接,完全无需额外的硬件支持。

就像天空中的飞机航线和地上的高速公路一样,虽然平时各自为政,互不干扰,但 SpaceX 和 T-Mobile 通过「Direct-to-Cell」技术打破了这道壁垒,让手机和星链卫星能够对话。

想要让手掌上这部方寸大小的设备与天际的卫星联通,有两个关键节点:频段的同步,以及卫星位置。

常见的通讯卫星所用频段一般集中在上面介绍的 Ku、Ka 这些高频段上,但想要接收这些频段的信号,需要在地面配备一个超过 20 厘米直径的天线——但对于手机来讲,这显然不现实。

于是 SpaceX 换了一个思路,既然手机没办法适配卫星,就让卫星适配手机好了。

从 2023 年开始,SpaceX 在发射的星链卫星 v2.0 准备了一个大杀器——一个面积达到 25 平方米的天线,专门为较低频段通信加持,为卫星与手机通讯做好了准备。

SpaceX 与 T-Mobile 这次合作,就用上了这根额外的天线,并选择了 1900 MHz 作为 Direct-to-Cell 技术的承载频段。

1900 MHz 也被称为 PCS 频段(Personal Communications Service),这是星链卫星 v2.0 支持的频段,同时也是手机的常用频段,其传播性能优秀,信号强劲,能够穿透障碍物,且卫星通信范围广,可以覆盖到地面基站无法接入的偏远或受灾地区。

通过频率协调和调制技术,不需要你给手机换啥硬件,星链卫星 v2.0 就能与支持 5G 或 LTE 网络的手机打成一片,轻松实现直接通信。

到目前为止,星链 v2.0 也只发射了一百多颗,这也是为什么 SpaceX 在 X 的帖子中称目前还未完全准备好的原因。

另一边,如果卫星距离地球太远,连接也无法成立。

传统卫星的轨道太高,信号绕地球一圈还得喘口气,延迟大得吓人,完全不适合用于手机通讯,而星链卫星群盘踞在约 550 公里的近地轨道上,信号来得更快,延迟更低,特别适合紧急通信和短消息处理。

当频段同步与卫星位置两个条件都满足后,信号从每个人的手机上发出,一路穿过高达十余公里、触及对流层的飓风 Milton,抵达近地轨道上的卫星,将人与人重新链接起来,共同抵御这场自然灾害。

值得一提的是,这场来自宇宙的支援,也遇上一些小插曲。

先为受灾地区提供手机信号,再对新老用户提供一个月的免费上网服务,连续两个应对灾害的措施听起来十分美好,并且效果也很明显——在社交媒体 X 上,星链官方帐号宣布免费 30 天星链网络服务的帖子已经超过四千万浏览量。

其实也不难理解,比起 SpaceX 与 T-Mobile 临时提供的信号支持,在一场破坏力十足的自然灾害中,可以照常使用互联网明显更具吸引力。

不过,当人们被这条帖子吸引,并准备加入星链网络服务的时候,才发现不对劲儿。

人们在星链官网中发现,从处于飓风袭击的地区订购星链网络服务时,需要的订阅费用的确为 0,但想要加入星链网络服务中,你还需要支付 349 美元的硬件费用,这还不包括运费、手续费和税费。

▲ 甚至还有一百美元的「拥堵费用」

对此,大量的受灾民众感觉愤怒——因为这是在帖子中没有说过的信息。

北卡罗莱纳州的居民 Kinney Baughman 也是其中一员,他认为这就是一种陷阱:

星链免费的互联网服务是一个诱饵,并非真的想要帮助这些受灾的人,而是为了增加之后的用户量。

此外,配送也是个麻烦事儿——飓风摧毁了基础设施,桥梁断裂,公路堵塞,想要拿到订购的硬件可谓是困难重重,加上种种其他原因,目前想要购买星链套件,可能需要等待三周的时间。

这个时间后,受灾地区的网络可能都已经恢复了,人们等来的硬件可能只是来回折腾的竹篮打水。

简而言之,这条浏览量上千万的帖子,对于星链网络服务的老用户而言的确是不错的紧急支援,但对于新用户而言,更像是一个陷阱:一旦你选择一个月的免费服务,你就需要支付 349 美元星链卫星信号接收器,以及免费期限以后的每月 120 美元的网络服务费用。

一石激起千层浪,受灾群众越多,愤怒就堆积得越多,很快媒体与当地官员也加入了谴责的行列,声势逐渐浩大起来,最终,迫使 SpaceX 作出回应:

对于受到飓风 Helene 或 Milton 影响的人们,星链网络服务现在将免费提供至年底,以帮助响应和恢复工作。

根据更新后的官网信息来看,在「飓风救援」服务中,已经特别标注了免费时间的延长,并且也注明,想要加入免费使用,需要额外购买星链套件用于接收信号才行。

飞速扩张的星链,一张包裹地球的网

在这场连续的飓风之中,星链为受灾地区的群众提供了基础的通讯能力与互联网连接,虽然其中藏了一些「小心思」,但瑕不掩瑜,沿着看不见的信号,递送了不少生命的希望。

2020 年底,星链还是个过于年轻的家伙——发射的 893 颗卫星,还远未完成第一阶段 1600 颗卫星的目标,仅能在北美部分地区提供最高 174Mbps 的下载速度,只有美国空军给它输了一口血,展开了初步合作,而远洋和空中等多元化的使用场景,更是只存在于论证中。

四年过去,星链的全球卫星数已经超过了六千四百颗,翻了快八倍,仿佛在宇宙中编织了一张巨大而隐形的网络,在晴朗的夜空中,用相机长曝光能轻易捕捉到它的轨迹,全球覆盖,已成现实。

▲ 夜幕中,近地轨道卫星交织的网

2021 年,美国陆军与 SpaceX 签署协议,测试星链在军事网络中的应用,包括数据传输和远程指挥,这是继 2018 年与空军合作后,星链达成的又一军事成就。

不仅如此,星链的身影已经出现在全球海洋之上——到 2023 年底,全球已经有超过 400 艘邮轮已经采用了 SpaceX 的星链系统用于海上互联网服务,其中,世界最大的邮轮运营商嘉年华公司(Carnival Corporation)已经在其旗下的所有邮轮上全面部署了星链系统,覆盖了嘉年华邮轮、公主邮轮和荷美邮轮等品牌。

同时,星链还为美国航空、达美航空和夏威夷航空的部分航班提供空中互联网服务。无论是飞越格陵兰海,还是穿梭在南半球的星空下,乘客们都能畅快地刷视频、接收信息。

▲ 划过夜幕的近地轨道卫星群

从广袤的大海到无垠的沙漠,甚至连极地的南极科考站,曾经的「无信号区」如今都已被星链的网络覆盖。那些曾经只能在会议室里讨论的场景,今天一个个变成了现实。甚至连过去与手机通信的技术瓶颈,也随着星链 v2.0 卫星的发射而迎刃而解。

整个 2024 年,SpaceX 以每月 2 至 3 次、每次 20 至 60 颗卫星的惊人频率不断向太空进发,就在几天前,SpaceX 以「筷子夹火箭」的方式成功回收助推器,这一里程碑式的成就达成的同时,马斯克宣布,这张天网的扩张速度,将会越来越快:

预计在明年年初,SpaceX 将挑战整个星舰的回收,并使用这一巨大的运输系统来发射和部署下一代更大、传输速度更快(下载速度达到 300M 至 900M)且更低延迟的星链卫星。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

爱范儿 | 原文链接 · 查看评论 · 新浪微博


Links, aliases and the decline of paths

By: hoakley
26 August 2024 at 14:30

One of the fundamental requirements of any decent operating system and its primary file system is to provide objects that link to files and directories in storage. These allow code and users to access those files and folders indirectly, by referencing them from elsewhere. In most systems there are two methods of achieving this, by referencing the directory path and name of the file/folder, or using a reference to an identity number unique to that file system and part of that file’s attributes, normally the inode number. These form symbolic and hard links respectively.

Symlinks

linksetc3

A symlink is a separate file containing the path to the file or folder that it links to. It thus has its own File System Object, and its own tiny data containing the path to the original. This works well as long as that path is preserved in its entirety. The inode of the original file is unaware of any symlinks to it, so deleting the original file also breaks every symlink to that file.

Symlinks are easily created in Terminal using a command like
ln -s /Users/myname/Movies/myMovie.mov /Users/myname/Documents/Project1/myNewMovie.mov
which creates a tiny file myNewMovie.mov containing the path /Users/myname/Movies/myMovie.mov referring to the file it links to.

You can’t create symlinks using the Finder but can using third-party apps, and they should now work fully with QuickLook thumbnails and previews. They essentially take no space on disk. Paths used can be shorter and relative, allowing an enclosing folder to be moved within that volume, which would break a full absolute path. They can also specify files on other volumes, so long as the path to them remains correct.

Paths in symlinks work most reliably in the macOS SSV, as it’s both structured and static. Although the disciplined user can use them effectively in their Home folder, they are prone to unintended effects such as the renaming of an intermediate directory, moving any component in the path, and even changing the Unicode normalisation of a character in the path. As symlinks only contain a path, there’s no fallback to try resolving a broken path, making them inherently fragile, not robust.

Hard links

linksetc2

In APFS, a hard link is actually a single file, with one File System Object, that has two or more references in the form of Siblings that are associated with the file inode. That object has a single set of File Extents, so each of the siblings refers to exactly the same file and data, although siblings will normally have different paths. In the object, the reference count equals the number of siblings; when siblings are deleted, that count is decremented, and the object is only removed when the count reaches zero.

Hard links are easily created in Terminal using a command like
ln /Users/myname/Movies/myMovie.mov /Users/myname/Documents/Project1/myNewMovie.mov
to create a new hard link named myNewMovie.mov to the original myMovie.mov.

You can’t create hard links in the Finder, and because they use a single set of File Extents, they essentially take no space on disk.

Hard links look and work exactly like the original, and can be moved around freely within the same volume as they’re not dependent on paths. Copy one to another volume, though, and the copy will be a complete unlinked file. Hard links to files and to directories were one of the essential ingredients of Time Machine backups on HFS+, but as APFS doesn’t support directory hard links, Time Machine now has to use a different backup format for storage on APFS.

Aliases and bookmarks

Aliases originated in System 7, when Mac OS lacked the BSD/Unix features that were to come in Mac OS X. At that time, paths were seldom used, making symlinks implausible, so the original Finder alias was instead built on the equivalent of an inode number. They have evolved into a combination offering path information and inode number that should be able to resolve links that would break the path in symlinks, and can extend to other volumes, unlike hard links.

Despite their robustness and versatility, macOS provides no bundled command tools for the creation of aliases or their resolution into paths, making them of no use in shell scripts or the command line, although the free alisma addresses these. Neither have they been integrated into APFS as distinct objects in the file system, where they’re just another file.

Bookmarks are a variant of aliases intended to be used in files for similar purposes. For example, the list of files shown in the Open Recent menu command in apps is assembled from a file containing bookmarks to each of those documents. Most lists of apps and files built by Launch Services and other sub-systems are similarly reliant on bookmarks.

Demonstration

To demonstrate how these three different types of link behave, create a folder in your Home Documents folder (~/Documents), and copy a test document into that. Next to that file, create another folder named links, and within that create a symlink (using a full absolute path), a hard link, and an alias to the original file.

links

Copy the file containing the links to another volume, and note how the hard link becomes a separate local file instead of a link, but the symlink and alias continue to link to the original, whose path is unchanged.

Rename the folder enclosing the test document and links folder, and note how the symlink is then broken, although QuickLook may still show a cached thumbnail for it. Note how this also breaks the copy of the symlink on the other volume, as the path used by both of them no longer exists.

Finally, move the folder of links to be alongside that containing the original document, in the ~/Documents folder, and note how the symlink is broken there too.

Of the three types of link, the only one that proves robust to all these changes is the alias.

❌
❌