前端转换，转好了再上传🐶

canvas.toDataURL(type, encoderOptions)

deepin🐶

100 出头的三模 84 键机械键盘
30 块的 usb 鼠标
二手显示器当扩展屏
旧手机当系统资源监视器
mini 路由器把有线网转成热点给手机用
魔百盒用于跑 clash 给开发机提供代理服务
USB 风扇、制冷杯、铝制水杯、茶叶等……

@shawndev darwin 就是 mac ，这里都列的意思显然是说需要支持全平台，会 iOS 开发的可不一定会 mac 程序开发； HTTP/GRPC 都是封装好的协议，这个除外的意思显然不是说它过时，而是说工作需要直接做更底层一些的 Linux 网络编程，比如嵌套字、多路复用这些吧

如果是类似工控机点餐机那种，只需要开机打开一个图形应用然后点点点，那就直接 xinitrc 指定程序就行，参考：
https://wiki.archlinuxcn.org/wiki/Xinit#%E5%9C%A8%E6%B2%A1%E6%9C%89%E7%AA%97%E5%8F%A3%E7%AE%A1%E7%90%86%E5%99%A8%E7%9A%84%E6%83%85%E5%86%B5%E4%B8%8B%E5%90%AF%E5%8A%A8%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F

但是这种方式不适合自用，比如输入法就不好搞，建议还是起一个最简单的窗管，除了上面别人提到了的 i3wm 这种平铺式，还可以考虑 openbox 这种配置简单的堆叠式窗管

辨别错误和垃圾信息所花的时间精力提高了。

如果默认允许这样玩了，谁还下载 APP🐶

@flyqie 个人认为 react 是独立的前端概念形成以来，最伟大、影响最深远的前端思想。react 改变了前端开发的思路和模式，之后的各种 web 前端框架以及 flutter 乃至 swiftui ，compose 其实都是 react 思想的应用于特定场景和目的的产物。很多人可能不喜欢 react 而倾向于 vue 或者 svelte 等等，但其实更多的是工程上的区别，比如谁的 api 设计得更易用，谁在某些方面上的性能表现更出色，而不是“纯思想”上的对比。但是思想伟大并不意味着 react 在工程上也就无可挑剔，我用 js 写过 class 组件模式的纯 react 项目，也用 ts 做过 hooks 模式的，还写过不同版本的 next.js 和 taro ，虽然同是 react 系方案思想都一样，但其实开发体验差异是很大的，所以虽然我个人很推崇 react ，但是并不是很看好 rn 这种“在上层对齐各平台差异，底层使用原生组件”的跨平台模式。虽然我也很喜欢 ts 的语法，但是并不认为 js/ts 是足够适合跨平台的语言(原因看下面对 dart 的评价)
做跨平台，无外乎就是自绘和包装复用平台组件这两种模式，基于 web 的跨平台方案比如 electron 或者 webview2 ，其实本质也可以认为是利用浏览器内核做的“自绘”，但相比于 flutter/qt 的那种自绘要重得多。复用平台组件的模式一定会存在渲染不一致，依赖真机环境调试验证，框架和应用代码中存在大量判断分支，某个平台增加新特性或组件后需要持续适配投入大量精力的问题，这些是原理上难以避免的，反倒是很多人以为的性能问题，其实并不是那么的无解。所以一开始了解 flutter 是自绘的方案，我就认为这是一个加分项，一是其表现力的“上限”更高，二是由于自绘所依赖的底层相对都很稳定(比如 opengl ，canvas 这些东西)，所以其本身也可以更加稳健，无需经常被平台牵着鼻子走，有问题持续优化总会越来越好。
我写过十好几种语言，dart 是我目前为止最喜欢的语言。除去个人喜好，客观来说 dart 其实是一门很适合跨平台的语言，首先是它原生支持 jit 和 aot ，分别可以实现前端开发时即时生效，边写代码边看效果(也就是所谓 hot reload 或者 live edit)的高效开发(比 java,oc,qt 这些强)，以及在各个平台上无需虚拟机和复杂依赖而高效地运行(比 js/ts 这些需要解释器和 swift,kotlin 跨平台运行难度高的强)。再来这门语言的语法总的来说相当平庸(褒义)，但凡了解过 java,js,python 等主流语言就可以很快上手，而且吸收了各种现代的语法特性，取得了开发效率和学习难度之间的平衡(比 go,rust 等特立独行的好掌握，比 kotlin 这种语法糖多到腻的简单)，相对比较简单的语法特性也让它的 sdk 跨平台维护的成本较低，现在可以直接同时 compile 到 native binary 和 js 的语言就不多。很多人受不了 dart/flutter 的点无外乎是所谓的“嵌套”，我觉得主要是两点，一个是没有认识到 UI 的本质其实就是嵌套，用嵌套来表达 UI 其实才是最高效且接近本质的方式，再来就是被原生和 web 开发 UI 描述和逻辑分离的固有模式束缚，内心里抵触把整个 UI 应用抽象成“UI=fn(state)”这样统一的模型。其实 jsx 也是“ui in js”的方案，react 有段时间也推崇过“css in js”乃至“all in js”(个人认为它们没有普及成功更多是因为 js 本身的能力问题以及相关工具链没跟上导致的)，可以认为 flutter 就是实现了终极版的“all in dart”，是一种 react 在跨平台领域的完全进化体。

@yyzh 你说的这个效果只要安装 command-not-found 这个包就能实现了，并不是只有 ubuntu 可以:
https://packages.debian.org/bookworm/command-not-found
https://salsa.debian.org/jak/command-not-found
https://wiki.ubuntu.com/CommandNotFoundMagic

类似的，有些发行版或者系统 tab 键补全效果不好，并不是发行版不行，而只是因为没有预装 bash_completion 包，自己装上就好

@Chad0000 继续发展下去，可能以后手表手机不需要触摸屏，电脑不需要鼠标键盘，而是只需要麦克风摄像头甚至脑机接口，本质上变成一样的“AI 终端”，除了屏幕尺寸没有任何区别了

@wxf666 QT,AvaloniaUI 主要都是桌面端，对移动端的支持差 flutter 不止一点半点，发展到现在，移动端的复杂性已经远大于桌面端了，所以但凡在跨平台方案的前提里囊括移动端，可选项也就没几个了。
你能让 AI 《写一个日赚过万的 App 》，为什么别人不能，为什么提供 AI 服务的公司不能自己让 AI 《写一个日赚过亿的 App 》？如果你以为 AI 是外挂，用了可以让人在游戏世界叱咤风云，那么实际情况很可能跟现在很多游戏一样，结果不过是变成人均外挂的神仙斗法，最后整个游戏乌烟瘴气，大家都没得玩。

理解错误。
如果是一家需求没那么多，业务相对稳定的公司，那肯定没必要敏捷，不存在增加工作量，做出错误决定的情况。
问题就在于如果是一家需求旺盛，业务极速发展，充满变化的公司，如果不用敏捷开发的方法工具，只会让开发团队更加焦头烂额疲于应对，出现 OP 说的那些情况，敏捷开发恰恰是为了在这样的情况下提高效率，避免疏漏，保证规范和代码质量的。
只是有些老板方向不清，水平拉胯，想一出是一出，别说敏捷了，就算给他开发梦之队也一样带不动，这不是敏捷的问题；当然也有一些 tech leader 水平能力不行，嘴上说敏捷实际只是瞎搞，将相无能累死三军……
在牛逼的团队和经验丰富的 leader 带领下实践过敏捷开发后，就会发现敏捷开发确实可以在“正常的”公司里提升开发工作体验，让本身就很优秀的工程师如虎添翼。

影响肯定有，有些重大功能和系统最新的特性支持没有公司全职开发，靠社区还是会比较吃力。但是 flutter 现在完成度已经很高了，是跨平台方案里综合水平最高最能打的，就算是把 flutter 相关的开发全裁了，停止所有支持，其优势也最少能保持 3 年，毕竟现在同 level 有能力的公司都在减少 UI 技术的投入，还在大力发展 UI 技术的公司实力和积累都差一截。(如果不裁员，flutter 至少是为未来 3 至 5 年的最优解，如果早期的那些核心开发大佬没走，这个优势很可能保持 5 年以上……)
其实，与其担心 flutter 的前景，还不如担心整个前端乃至“传统 IT”的前景。继续发展下去，AI 会平等的创死每一个人，前后端开发的投入和市场都会持续减少，甚至现在搞 AI 的那帮天之骄子最后也要失去资源，谁也不用说谁，都逃不掉

现在的新系统都用上了最新的图形技术，需要显卡加速的，虚拟机效果很差，最好还是物理机搞。
deepin 装一次系统也就几分钟的事，没必要虚拟机或者 Linux To Go ，直接双系统走起。

开发桌面应用那肯定是用真实桌面环境开发最方便了，qt 有 qtcreator ，不过我觉得不好用，还是一步到位直接 CLion 。资料的话就是 qt 相关，然后如果涉及比如托盘、窗口特效，那确实可能需要在不同 DE 下测试，一般的应用界面开发 QT 基本都会做好兼容的(不过要注意输入法插件的问题)。别家系统不知道，deepin 有些开发资料还是不错的，可以找找看参考参考。

[https://juejin.cn/post/7362901975421337651](Flutter：听说你最近到处和人说我解散了？)

MySQL 简单稳定可能是国内那帮搞互联网的说的最大的谎言。
MySQL 看上去简单，实际上限制和坑比 PG 多不少，简单写个 demo 随便跑跑可能还体验不出区别，稍微做点像样的项目差距就出来了。MySQL 一大堆的文章和中间件方案，很多都是因为自身的缺陷和问题产生的，其实只要耐着性子把文档看完，学习使用 PG 所要花的精力并不会比学 MySQL 然后各种避坑花的精力多，使用过程中也更加自由，不会多写两个 join 就要担心会不会性能下降。

用手机担心老化和电池鼓包，我是拿魔百盒跑 clash 给局域网机器提供代理