© Paul Morigi/Associated Press
© Jim Wilson/The New York Times
阅读这篇文章的人有两种：
第一种，是原本就关注了这个博客的读者，或者通过视频、图文等各种社交媒体找过来的观众，你们应该是这个项目相关视频的观众，或者通过这篇博客知道了这个项目的读者，总之，东西不在你们手里；
第二种，是找到了指定地点，并找到了这件作品，同时发现了它背后的二维码，扫码进入了这个页面的幸运儿。
如果你是第二种人，恭喜你！这件作品，现在送给你了：）
如果你愿意把你在现场与这件作品的合照（无需露脸），以及这件作品的多角度照片（不少于 3 张），发布在微博和小红书上（两个平台一起发布哦），并带上 #苏志斌3Dfiti# 这个标签，我将为你定制一件 3D 打印作品。当你分享完之后，请把这两个平台的链接发送至以下这个邮箱：
suithink.su@gmail.com
我们将在后续的沟通里，一起完成为你定制的作品。
这是一系列艺术创作项目的开始，是第一件作品。
这件作品中的造像，是来自四川毗卢洞紫竹堂的水月观音，它是宋代的杰作，是举世公认的艺术文化瑰宝。因作品场地空间特殊，故将造像左右翻转，与原造型呈镜像关系。
我参与 3DFiti 这个艺术项目，旨在通过 3D 扫描和 3D 打印技术，使我们生活的周边环境增加一些趣味性和艺术性。在人类学家项飙（英国牛津大学社会人类学教授，德国马克斯普朗克社会人类学研究所所长）所描述的那个「附近」的概念之中延展出来，一切我可以到达的地方，只要有我感兴趣的公共区域内的「缺损」部分，就有可能成为这个艺术项目的创作对象。
我通过 iPhone 扫描空间或者物体，并对模型进行二次创作，使用 3D 打印技术将其制作成一件真实的物品，即能够与现场的「缺损」相嵌合的物件，使这个「缺损」转化为一处临时的微型艺术场所。
No.001 作品中的 紫竹观音像 3D 模型，是来自 Funes.world 的文件。他们的工作是在人类从原子社会进入到比特社会的过程中，将原本属于原子世界中的建筑、空间、故事，通过 3D 扫描建模的方式，将其保存在数字世界中，建成一座人类文明的数字空间博物馆。
如果你想观看 No.001 作品的相关视频，可以点击链接：
https://www.bilibili.com/video/BV1ShGvzwEeB/
或点击下方图片：
“这座微型雕塑？跟随影片线索去发现吧！藏在城市褶皱中的精美作品，属于第一个破解谜题的人！”
期待你也参与到这个项目之中 
拓展阅读：
水月观音是汉传佛教中国化的典范，以“水中月”喻诸法皆空，融合《华严经》哲思与文人山水意境。其形象由中唐周昉首创，经宋元演化定型：唐五代为半裸髭须的男性，宋代后转为慈美女性，体态婀娜如安岳毗卢洞紫竹观音，背倚紫竹，跷足坐于莲台，衣纹流畅如“S”曲线，被誉为“东方维纳斯”。
坐姿核心为“自在”：
赤足触水喻“普渡”，手持杨柳、净瓶显慈悲，姿态从庄重禅定转向世俗洒脱，折射佛教本土化进程。其造像以圆月、竹石为境，突破宗教程式，成就敦煌壁画、大足石刻等艺术巅峰，更渗入民间故事（如榆林窟唐僧取经图），成为宗教与世俗美学的融合象征。
精髓：以空性为核，化仪轨为诗意——紫竹观音跷足斜倚之姿，既承“观自在”禅悟，亦凝唐宋工匠“以形写神”的至高境界，堪称佛教艺术中国化的里程碑。
One of the most unnerving experiences with a Mac is to discover that it has either restarted and is waiting for you to log in, or has shut itself down completely. This article explains what might have happened, and how you can distinguish between those causes.
The commonest single cause for these events is loss of power to the Mac’s internals, which could mean anything from the mains power supply or internal battery through to the Mac’s power supply unit (PSU). Even if your Mac is up and running fine again, and supplied by an uninterruptible power supply (UPS), confirm that there hasn’t been a power glitch. Any good UPS should keep an event log that you can check to see whether there was anything untoward.
Intermittent PSU faults are rarer but can be tricky to diagnose, and hardware diagnostics may fail to pick them up. If you don’t have any evidence that anything went wrong with power supply, put it to the bottom of the list for the moment. However, if you suspect your Mac’s PSU might be defective in any way, don’t use it again until a trained Apple technician has checked it carefully and assured you that it’s safe. Mains power still kills many people, including those who should know better.
There’s a long list of other hardware causes, from a defective system management controller (SMC) to faulty memory. If your Mac is getting long in the tooth or has shown other signs suggesting it might have a hardware problem, now is the time to run hardware diagnostics to check. But if it has been working fine, move this lower down in your list, to return to later if other causes aren’t evident.
macOS is designed to keep its kernel running through thick and thin, even when apps are crashing all around it. Sometimes, though, the most robust of kernels can reach a point of no return, and it should then panic, allowing the Mac to restart (or in some older Macs, shut down) and try again. That’s a better option than everything grinding to a halt in a ‘freeze’, when you have to force the Mac to shut down by pressing and holding the Power button, which may not result in production of a panic log.
Shortly after starting up following a kernel panic, you should be offered the panic log, as I’ve described elsewhere. But what do you do if you think it might have been a panic but don’t see any dialog offering a log? Your next move depends on whether it’s an Apple silicon Mac or an Intel model.
When an Intel Mac starts up (including following a restart) or wakes from sleep, the reason for the previous shutdown (or initiation of a restart) or sleep should be reported in the log as a cause code. In El Capitan and earlier versions of OS X, you can find recent cause codes in the logs using Console: search for shutdown cause, or sleep cause when looking for a wake event instead. From Sierra onwards, you’ll need to check the unified log; in macOS 14.6 and later, that’s simplest using LogUI. Set its Predicate menu to read eventMessage, and enter shutdown cause in the text box to the right. Ensure the time period includes the first few seconds of the boot or reboot, and you should then be presented with an entry similar to:2025-04-16 19:48:55.630+0100 kernel Previous shutdown cause: 5
Negative cause codes refer to hardware causes originating mainly from the SMC, and positive codes refer to software. A special code of 0 indicates an intermediate, which can occur when there’s sudden loss of power on some systems.
Among the hardware cause codes, the following are notable:
In the software cause codes, there seem to be only two that occur commonly:
You can find a more detailed list on George Garside’s blog. However, these don’t appear to be given for Apple silicon Macs, and even Intel models don’t seem as reliable at writing them to the log now.
Although you can try finding a log entry giving a cause code, I’ve not been successful yet on an Apple silicon Mac, where you have to look for other clues as to whether the cause was a kernel panic. Those include:
Login
paniclog in the eventMessage field for log entries in the minute or two after the Mac restarts. If that extract reads failed to map memory for paniclog output - 0x3 then there’s likely to be a panic log somewhere.com.apple.DumpPanic in the minute or so after startup. That subsystem handles generation of the panic log, and makes it clear whether there is one.From bitter experience, I regret to inform you that trying to gain any information about a kernel panic, or its cause, from log entries made before the Mac shut down or restarted are almost certainly doomed. In any case, most of the time you don’t know when the Mac shut down or restarted, so would waste time trying to discover that.
In an Apple silicon Mac, at least, if there are log entries from com.apple.DumpPanic confirming that a panic log was generated, you’ve struck gold, even if you can’t find the log itself. Make a note of the time that subsystem reportsDumpPanic launched after boot to check for device panic data
then use that as the start time for a log extract set to a subsystem of com.apple.osanalytics.preoslog, and examine those entries. Starting with the entrypreoslog dump begin
you’ll see breadcrumb data from iBoot stages 1 and 2, each introduced with the emoji 
, and ending withpreoslog dump end
A little further on, com.apple.DumpPanic should give the first line of the panic log, such asembedded panic string decoded: panic(cpu 0 caller 0xfffffe002513b34c): Kernel data abort. at pc 0xfffffe0025acf058, lr 0x70c77e0025acf40c (saved state: 0xfffffe8dff723310)
Even if you can’t see the full panic log, at least you’ve got its punchline.
Macs should never shut down or restart of their own accord, nor should they ever freeze. If yours does any of those, you should assume it’s the result of a kernel panic, and that’s not something you should ignore. The most important evidence as to what happened in a kernel panic, and clues as to why it happened, comes in the panic log, shown shortly after you’ve logged back into your Mac. Don’t dismiss that dialog until you’ve saved its contents for future reference.
Panic logs used to be saved in /Library/Logs/DiagnosticReports, from where you could open them in Console, but more recently were found somewhere closer to /var/db/PanicReporter, but now seem to vanish into thin air. You therefore need to copy its contents as soon as it appears and before sending it to Apple.
If the alert isn’t already showing the panic log, click on its Report… button, then open a text editor like TextEdit. Copy the whole contents of the panic log into a new text document and save it somewhere safe before clicking on the button to send the report to Apple. Once you’ve done that, the alert is dismissed and can’t be brought back.
Unlike app crash logs, panic logs are normally brief and to the point. Although they may be non-specific and not help much, in many cases they contain obvious clues as to what caused the panic. Formats have changed over the years, and the current Paniclog version is 14, but the following sections are likely to prove worthwhile examining.
At the very top, following the first word panic, the log gives summary information and may suggest a cause:panic(cpu 0 caller 0xfffffe002f4e48bc): cannot find IOAESAccelerator
tells you that the panic occurred on CPU core 0, because a key kernel extension couldn’t be found, a cause that isn’t particularly useful in discovering why the panic occurred.
Other non-specific examples include:panic(cpu 0 caller 0xffffff80015efa76): Kernel trap at 0xffffff7fa047645c, type 14=page fault, registers:panic(cpu 4 caller 0xfffffe001b91de94): Kernel data abort. at pc 0xfffffe001c2b2538, lr 0x65a4fe001c2b28ec (saved state: 0xfffffe402ecdb310)
Sometimes you strike lucky at the start:panic(cpu 1 caller 0xfffffff01731bd68): SEP Panic: :SEPD/MDMA: 0x0000b72d 0x0002791b 0x0000971f 0x00003a91 0x00003bb7 0x00000000 0x00000000 0x00000000 [rnit]
reveals that it was the SEP, Secure Enclave Processor, that panicked. That’s likely to result in a boot-loop panic, where every time the Mac tries to start up, it panics immediately, and continues to cycle through booting and panicking until you or your Mac force it to shut down.
panic(cpu 8 caller 0xffffff80017729eb): "zalloc: zone map exhausted while allocating from zone kalloc.12288, likely due to memory leak in zone kalloc.48 (6586956000 total bytes, 137228148 elements allocated)"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.141.1/osfmk/kern/zalloc.c:3627
is pure gold, as it reveals a probable memory leak as the cause.
Exceptions mentioned here can include page faults, in which something has tried to access an invalid memory address, invalid instruction codes for the processor, and general protection faults which include a wide variety of other bugs. As far as the user is concerned, all exceptions indicate a bug or problem in the code that’s being run.
Further down you should see confirmation that this was a kernel panic, in a line likeDebugger message: panic
Normally you’ll see a couple of lines reporting the version number of macOS running at the time. For exampleOS version: 24C101Kernel version: Darwin Kernel Version 24.2.0: Fri Dec 6 18:57:59 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_VMAPPLE
You can compare those with the build number of macOS shown in System Information / Software, and in Mints. This is an unusual situation, as RELEASE_ARM64_VMAPPLE means this is from a virtual machine running on an Apple silicon Mac.
Sometimes you might see a line likeOS version: Not set yet
simply indicating that the version hasn’t been recorded yet.
On Apple silicon Macs, you should also see the iBoot version, and the current level of boot security:iBoot version: iBoot-11881.61.3
secure boot?: YES
The latter is important, as running in Secure Boot means that no third-party kernel extensions have been loaded.
If there has been a memory leak, the panic log may well contain a breakdown of system memory zones giving more detailed clues.Zone Name Cur Size Free Size
vm objects 78041088 26795008
…Zone Name Cur Size Free Size
kalloc.32 280834048 3040
kalloc.48 6586956000 4896
kalloc.64 4241453056 5000896
…
Note how the Free Sizes of kalloc.32 and kalloc.48 are very small, and that of kalloc.64 is fairly low too. This is consistent with the kernel running out of memory in one of those zones. Further information may follow:Backtrace suspected of leaking: (outstanding bytes: 288)
Because there’s the suspicion of memory leakage, the panic log also gives a detailed backtrace of where it suspects that leakage is occurring, and details of the kexts involved in that. Note that those may not coincide with any kexts identified earlier as possible culprits.
It’s worth looking through the log to discover the task that was running at the time of the panic. That might simply be the kernelPanicked task 0xfffffe166cff1f18: 10735 pages, 374 threads: pid 0: kernel_task
or may give more specific informationBSD process name corresponding to current thread: WindowServer
Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev
orPanicked task 0xfffffe1b55369798: 24964 pages, 8 threads: pid 800: com.apple.Mobile
alternativelyProcess name corresponding to current thread: mediaanalysisd
This is the name of the process running its code at the time, and can give another clue as to where the problem lies.
You may also be given a list of kernel extensions that might be involved:Kernel Extensions in backtrace:
com.apple.filesystems.apfs(1412.141.1)[6DA33D13-4501-3D48-B4D8-0329E6AEC86D]@0xffffff7f84e7d000->0xffffff7f84fa4fff
dependency: com.apple.kec.corecrypto(1.0)[804DD660-F561-3444-A076-05D7A52D65E3]@0xffffff7f82746000
…
Whatever the cause, you should next look at the list of unloaded and loaded kexts forming the rest of the panic log. These are listed in the order that they were loaded, with the most recent kext at the top. As third-party kexts are the last to be loaded, the top of the lists start with any third-party kexts installed on that system and loaded at the time of the panic:last loaded kext at 939128480512562: >!UAudio 323.4 (addr 0xffffff7f86baa000, size 434176)
last unloaded kext at 948795488738566: >usb.IOUSBHostHIDDevice 1.2 (addr 0xffffff7f8556c000, size 45056)
loaded kexts:
>!ATopCaseHIDEventDriver 3430.1
…
In most cases, the name of the kext as you’ll find it in /System/Library/Extensions is the last part of the ID given. For example, the kext with the ID of com.apple.driver.AppleMobileFileIntegrity is named AppleMobileFileIntegrity.kext.
If those lists contain any third-party kexts, they should be immediately suspected as being the cause of that panic, unless another cause is apparent.
Although you’ll want to get on with whatever you were going to do when you were so rudely interrupted by that kernel panic, put that record of the panic log somewhere safe. If your Mac does suffer another panic, you can then refer back to it for any common features that might indicate they had the same cause. Panic logs are also invaluable for others who might assist you in discovering what was wrong. I’m very grateful to those who send me their panic logs, and here wish to acknowledge Joe, who kindly sent me my first SEP panic, a real collector’s item.
There’s more information about dealing with kernel panics in the following articles here:
Crashes, panics, freezes and other unexpected events
How to deal with a kernel panic
Ovid has raced through the destruction of Troy and its nobility, including the death of Priam, the herding together of the Trojan women to be taken as trophies, and the vicious murder of Astyanax.
As the Greek ships prepare to depart, Priam’s widow Hecuba is the last to board. Her youngest son Polydorus has been secretly in the care of King Polymestor in Thrace, who was paid a great sum to protect him. With Troy destroyed and that source of income lost, Polymestor slit the child’s throat and threw his body into the sea.
The Greek fleet shelters off the coast of Thrace, again waiting for favourable winds. While there, the ghost of Achilles appears and demands the sacrifice of Hecuba’s daughter Polyxena in appeasement.
As with Iphigenia’s sacrifice a decade earlier, it’s now the turn of Hecuba’s daughter to be sacrificed to secure good weather. Polyxena is taken from the arms of her mother and put before the altar where Neoptolemus, son of Achilles, stands ready with his knife. Polyxena pleads eloquently for her body to be given to her mother without a ransom, a speech bringing even the priest to tears. Nevertheless, he thrusts the knife into her breast, and she falls to her knees, still resolute, but dead. The Trojan women mourn her and care for her body, so her mother can embrace her in final farewell. Hecuba then responds in a long speech of lament.
Merry-Joseph Blondel’s fine painting of Hecuba and Polyxena, from after 1814, is superb in its treatment of fabrics, but more puzzling in its narrative. Hecuba, the older woman, appears to have fainted, presumably at the announcement of Polyxena’s imminent sacrifice, with her daughter kneeling at her feet.
Several paintings show the sacrifice of Polyxena, of which Charles Le Brun’s from 1647 is arguably the finest, and in superb condition. Polyxena is being led to the altar as Hecuba tries to hold her back. Behind Polyxena is the same Neoptolemus who threw Astyanax to his death, threatening to kill her where she is.
Giovanni Francesco Romanelli’s The Sacrifice of Polyxena, from about the same time, shows the moment the priest is about to sink his knife into the woman’s breast. A young assistant, their head averted, kneels ready with a large bowl to catch the sacrificial blood.
Hecuba then walks down to the beach for a jar of seawater, and stumbles across the body of her son Polydorus. She is initially struck dumb, and freezes like a rock with the shock. As that subsides, her wrath grows. She makes her way to meet with Polymestor, on the pretext of wanting to show him some hidden gold. He immediately starts lying to her, so she flies at him, burying her fingers deep into his eyes to blind him. She is then stoned by Thracians, and is transformed into a dog, and that place is named Cynossema, the dog’s tomb.
The Vengeance of Hecuba is a magnificent Macao tapestry from the seventeenth century, showing Hecuba and three other women sealing Polymestor’s fate for his murder of Polydorus. Hecuba is poking his eyes out, as the others swing long wooden clubs at him.
Giuseppe Crespi probably painted his version of Hecuba kills Polymestor in the early eighteenth century. His skilful composition makes it a chilling but carefully implicit image, as a woman associate holds the king down, and Hecuba reaches up to remove his eyes. Crespi has minimised the amount of limb visible in the upper part of the painting, to keep the composition there clean and clear. He seems to have compensated for that in the legs of the lower half, made even more complex by deep shadow.
The goddess Aurora joins in the lament over the destruction of Troy. She had not only supported the Trojan cause, but her son Memnon had been killed by Achilles in combat. She is stricken with grief, and can’t bear to watch his cremation on the funeral pyre. She kneels before Jupiter and begs him that her dead son might be granted an honour. Jupiter agrees, and the smoke from Memnon’s pyre darkens the whole sky, as might have happened during a major volcanic eruption. That smoke is then transformed into a flock of birds, the Memnonides, in honour of Memnon.
Bernard Picart’s engraving from the early eighteenth century of Memnon, son of Eos and Tithonus shows a young warrior in Egypt, looking into Aurora’s dawn light. He may be sat on his own sarcophagus too.
The two colossi at Al Bairat near Luxor in Egypt were known in classical times, and became popular motifs for ‘orientalist’ artists in the nineteenth century, several of whom show them in dramatic lighting.
Gustav W. Seitz’s Egypt: the Statues of Memnon, seen here as a colour lithograph of his original watercolour, is highly atmospheric, and an excellent demonstration of the moon illusion.
The colours in Charles Vacher’s watercolour of The Statues of the Memnons (1864) are superb.
Finally, Albert Zimmermann’s oil painting of The Memnon Statues captures the heat haze, and a snake moving through the water.
其实有点出乎我意料，除了 Apple Vision Pro 那期，最受欢迎的居然是聊《九龙城寨》和《暗恋桃花源》的这两期。而且，刚发的《谈判专家》这期的收听量也在稳定上涨。聊 AI 那期尽管内容很多，但收听量比这些都少得多。
从博客后台数据能看到，最近一周的主要收听量中，三分之二都来自这三期聊戏聊剧的节目。
我原本以为，收听我节目的主要人群，是过去在知乎和 B站看我讲设计的读者和观众。
这么看下来，我有一个猜测：收听我播客的人群当中，有很大一部分比例，可能是此前并不认识我的路人，他们对科技类话题的兴趣，没有对娱乐类型的话题高。
挺好的，这也挺符合我最初对播客的预期，这样我就可以不用老聊设计和产品了！
荒野楼阁 WildloG：https://suithink.me/zlink/podcast/
小宇宙： https://suithink.podcast.xyz
Spotify：荒野楼阁 WildloG
YouTube：荒野楼阁 WildloG
Apple Podcast 在中国大陆地区目前只支持通过 URL 订阅：
https://suithink.me/category/podcast/feed/
