@today4king 我有同事他们全部是在远程开发和调试的
所以本地随便一台笔记本都可以 甚至有人用 iPad Pro 都没问题
现在 WebIDE （或者 VSCode ）完全可用了 里面还带了 Shell 到远程的 container
用起来简直更本地一样

本地只要跑的动 Chrome 就行

我自己需要 remote 到 k8s 里面去 debug 麻烦一点
不过不需要本地 Docker 就还行 16G 目前肯定够用的

@lamls 对于很多开发 VM 或者 Docker 是必须的
而且本地跑 VM/Docker 和远程跑还是很不一样的

如果远程跑的那种 大部分情况 本地只要远程到服务器去开发和跑程序
这种情况 M1 MBA 可能是最好的选择

如果不是 Java 开发 16G 都不需要
8G 都够用了

当然考虑到未来 和用到虚拟机 最好还是到 16 甚至 32

@SuperMild 其实这样不行
因为总寿命没变 如果你 60 才跳回到 20
那么跳回后 20 立刻变成 60
这样跳回来能做的事情比较有限 而去所剩的寿命就不多了

其实只要事先计划好 然后考往回跳来证明就简单多了
而且如果知道有这个能力 那么就更简单了
可以用一些先进的方法来做测试 所点时间

比如一些生理指标 最简单的就是骨龄这样
只要差个 3-5 年 就可以看出来了 不需要几十年这样的

@justrand 这个可以证明的啊 就像 @eason1874 @binux 说的
比如你先写好一个纸条 如果未来时间 X 后短时间内发现身体突然衰老 说明有类似这样的能力
那么只要以后确保会从某个更未来的时间故意跳回到 X 然后身体就会衰老 即可证明
如果不是 那么 X 后短时间内没发生 就可能不是

多重复几次 或者多几个时间点的选择 比如提前写好 时间 1 对应什么猜测 时间 2 对应另一个猜测 时间 3 ...
这样就可以从未来作出选择 影响下次一次跳回后的知识

另外短时间衰老 如果可以推测出这个方向 可以通过更加先进的医学手段来更加快速和精确的判断
那么就可以缩短判断衰老需要的时间跨度

主要的难点就是一开始要意识到突然衰老和穿越有关系 这个比较难
很可能每次都以为只是的了怪病发作了 没有进一步去探究 就没辙了

同意你 L1 的观点
这个做产品和生命树类似
一开始点的技能树后来就算没用了 也会影响之后的决定

想要符合最新的需求而且追求完美 就需要重新设计
但是又要向后兼容

这样的话 其实搞一个新的 CLI 包一层就是了

@xratzh 目前的消息看 12 代比 11 代强太多
同样功耗下比 11 代快的多
同样性能需要的功耗也小的多

@Danswerme 苹果做工已经算是好的了
这段时间情况特殊没办法 苹果自己也知道
据说如果按照苹果之前的标准 最近几年的产品都没办法出货了

而且不仅仅是组装的做工不行了 连里面的元件也都有很多问题 比如之前 iPhone12 的绿屏问题就是一个🌰
远不如以前了

@xuzhongzhou 不可能的 那个需要有新的硬件支持才行
估计是 NFC + UWB

家用肯定选 Y 呀
自己玩 或者只用来通勤才选 3

@chiaf 大概率是 考虑到跨平台
不是 Electron 那只能继续用 JVM 了 也是可能的 因为说了用了和 Intelij 一样的语言核心 那是用 JVM 的

如果是基于 Kotlin Native 做的 那就是惊喜了 可能性不高

应该是基于 Web 的 和 VSCode 比较像
不知道是真的完全从零构建的 还是基于 VSCode 或者其他开源的编辑器核心

如果是本地 App 不出意外应该是 Electron 的了 毕竟需要和 VSCode 一样在 web 上运行

Sorry 如果“不”跑 Win 应该是有免费的虚拟机可以用的

其实 macOS 是自带虚拟机功能的 只不过只提供了 API 没有提供 App
现在 PD 和 VM 都是用系统的 Hypervisor.framework 来跑虚拟机的 不再用自己的虚拟机核心 kext 了

因为是系统自带的功能 所以理论上要自己做一个虚拟机也不难
如果跑 Win 是有免费的虚拟机可以用的

比如 Docker for Mac 的虚拟机就是 hyperkit 直接用的 Hypervisor.framework

@littlerainer QEMU 可以跑 但是效率巨低 毕竟是软件模拟的
如果是希望用到 M1 pro/max 的性能 那你这个方向目前很难
跑这种东西最好还是远程去 Linux 服务器里面跑去
Mac 下 SSH 就可以了

M1 Mac 对于开发者的话 只要避免编译 C/C++的库 可能就还行
但是要用老版本的库 不管是 binary 还是编译源码 都很难

软件支持这个不是苹果说的算的
这个需要广大开源库 /软件的开发者去慢慢支持
需要很长的一段时间才行
毕竟 ARM 的 Linux 上的软件都还在起步阶段

@whusnoopy 不能完全这么说 Mac 对程序员开发者方面支持还是不错的
但是重点不是 Apple 去怎么支持开发者
而是 Apple 的生态怎么让开发者愿意去支持

大部分的开源库都是优先针对 Linux/Unix 开发的
如果开发者用的 Mac 那么自然就会尝试给 Mac 做兼容 因为相比兼容 Windows 兼容 macOS 还是要稍微轻松一些的
本来如果用 Win 开发可能会尝试给 Win 做兼容 但是现在 Win 有了 WSL 那么开发者就不一定原因给 Win 做兼容了 反正可以跑 WSL

所以现在的情况是 Mac 转向了 ARM 但是开源库对 ARM 的支持还是比较有限的
加上 macOS 又不是 Linux
所以现阶段很多开源库没办法同时兼容 ARM 和 macOS
这个只能等时间了

我相信还是会慢慢好起来的 因为现在 Linux 的 ARM 版本也发展起来了 那么移植到 M1 的 Mac 难度就没那么大了

@crow1943 @BingoXuan @ZE3kr 硬件虚拟机没办法跑 X86 的
现在支持 X86 的虚拟机都是 QEMU 软件虚拟的 没有硬件加速
要跑需要大量运算的东西还是算了吧 勉强跑个 build 已经不错了

@ShuoHui 是残血啊 2x2 的 MIMO
Pro 和 LR 都是 4x4

感觉还是 Dream Router 香 才 $79 可惜还在 EA