 |
kuanatV2EX 第 634702 号会员，加入于 2023-06-19 11:38:40 +08:00今日活跃度排名 1253 |
| Go 语言的错误处理语法，不改了！ Go 编程语言 • kuanat • 1 小时 20 分钟前 • 最后回复来自 loading | 58 |
| Jetbrains 发布了 Kotlin 官方 LSP Visual Studio Code • kuanat • 13 天前 • 最后回复来自 ExplodingFKL | 1 |
| 全闪 NAS 的一些心得体会 NAS • kuanat • 24 天前 • 最后回复来自 idontunderstand | 25 |
| 我转发了一张图到前端群，大周末的群里已经爆炸了 程序员 • kuanat • 147 天前 • 最后回复来自 zbowen66 | 108 |
| 基于 Go 语言谈软件开发效率 Go 编程语言 • kuanat • 153 天前 • 最后回复来自 phoulx | 15 |
| Zed Linux vim 模式输入法切换 Zed • kuanat • 176 天前 |
| 一个好用的、纯软件的扩展屏方案 分享发现 • kuanat • 2024-06-04 22:45:38 PM • 最后回复来自 kuanat | 2 |
| V2EX 是否会考虑增加专栏功能？ V2EX • kuanat • 2024-04-29 12:49:46 PM • 最后回复来自 kuanat | 5 |
| 分享一些 Go 在全栈开发中的经验
13 Go 编程语言 • kuanat • 318 天前 • 最后回复来自 GeekGao
|
43 |
kuanat 最近回复了
1 小时 9 分钟前 回复了 profchaos 创建的主题 › Linux › 感觉 Linux 桌面也没什么用 |
1 小时 11 分钟前 回复了 profchaos 创建的主题 › Linux › 感觉 Linux 桌面也没什么用 |
2 天前 回复了 mikewang 创建的主题 › 宽带症候群 › FakeHTTP - 伪装 TCP 连接为 HTTP，解除白名单限速 |
这个思路有意思，手动点赞
2 天前 回复了 CC11001100 创建的主题 › 分享创造 › 开源项目分享：小弟把之前写的一个增强 ast 分析体验的插件优化了一波，感兴趣的大佬可以康康哈 |
大佬的逆向工具都挺好用的 :D
2 天前 回复了 rmrf 创建的主题 › Linux › Gnome 窗口 变得不可以点击，折磨了我一个假期啊！ |
dnf 降级还是比较简单的，麻烦的是确定什么导致的，特别是问题来自底层依赖而非上层应用的时候。
Fedora workstation 版本只能支持内核版本降级（回滚/回退），作为更新相对激进的半滚动发行版，官方的思路是 atomic desktop ，对应 gnome 的版本是 silverblue 。
这个系列把系统更新完整打包，如果某次更新造成异常，可以省去确定是哪个软件造成的这个过程，直接做完整的回退。但是 atomic 依赖的 rpm ostree 在定制软件包方面不是那么灵活。
现在有基于 bootc 的非官方项目 universal blue ，和 ostree 实现的区别在于 bootc 就是标准的可以引导 oci 镜像。这个应该是未来 fedora 的发展方向。现在已经可以手动尝试了。
Fedora workstation 版本只能支持内核版本降级（回滚/回退），作为更新相对激进的半滚动发行版，官方的思路是 atomic desktop ，对应 gnome 的版本是 silverblue 。
这个系列把系统更新完整打包，如果某次更新造成异常，可以省去确定是哪个软件造成的这个过程，直接做完整的回退。但是 atomic 依赖的 rpm ostree 在定制软件包方面不是那么灵活。
现在有基于 bootc 的非官方项目 universal blue ，和 ostree 实现的区别在于 bootc 就是标准的可以引导 oci 镜像。这个应该是未来 fedora 的发展方向。现在已经可以手动尝试了。
2 天前 回复了 rmrf 创建的主题 › Linux › Gnome 窗口 变得不可以点击，折磨了我一个假期啊！ |
dnf 降级还是比较简单的，麻烦的是确定什么导致的，特别是问题来自底层依赖而非上层应用的时候。
Fedora workstation 版本只能支持内核版本降级（回滚/回退），作为更新相对激进的半滚动发行版，官方的思路是 atomic desktop ，对应 gnome 的版本是 silverblue 。
这个系列把系统更新进行
Fedora workstation 版本只能支持内核版本降级（回滚/回退），作为更新相对激进的半滚动发行版，官方的思路是 atomic desktop ，对应 gnome 的版本是 silverblue 。
这个系列把系统更新进行
2 天前 回复了 1024xiaoshen 创建的主题 › 程序员 › 想开发一个新的开源软件，视频/文章一键同步多平台+多平台数据管理功能 |
这个东西在灰产黑产行业挺多的了。
之所以会是黑灰产用得多，主要是需求匹配，剩下的原因在于各个平台都会限制发布/上传使用自家 app 工具，于是需要逆向对应的接口。一方面用来应对风控，另一方面处理格式、字段之间的差异。还有不依赖逆向的 rpa 方式，但效率就低了也很难做矩阵。
之所以会是黑灰产用得多，主要是需求匹配，剩下的原因在于各个平台都会限制发布/上传使用自家 app 工具，于是需要逆向对应的接口。一方面用来应对风控，另一方面处理格式、字段之间的差异。还有不依赖逆向的 rpa 方式，但效率就低了也很难做矩阵。
4 天前 回复了 xueyuehua 创建的主题 › 云计算 › 2025 年了，传统分布式架构还会是主流吗 |
我没在工作中见到从传统架构渐进式过渡到云原生的成功案例，甚至没有听说过。所以就我个人的经验来说，在非云原生架构上加入 k8s 基本上只是当作运维工具来用，或者迁移一部分比如配置管理之类的功能过去。我理解造成这种现状的原因主要还是迁移对于团队技术要求太高了，在权衡过迁移成本和风险之后，大多数团队可能会选择重写。
传统架构中很少有真正意义上的分布式，多数业务的实现都是大单体应用，无法像微服务那样以非常细的粒度对功能模块进行拆分。所谓分布式的实践大多数停留在主从复制、负载均衡的层面上。k8s 之类的平台是将开发和运维的工作进行解耦，开发者（理想情况下）不再用关心运维层面的事情。实现的方式本质上是尽可能暴露应用内部状态，让数据流动公开化，最终的结果就以微服务的形式表现出来。
简单总结就是，我不看好任何形式的架构层面的迁移。要么坚守传统架构，要么从零开始云原生，我也不相信换个软件框架就能实现过渡。
传统架构中很少有真正意义上的分布式，多数业务的实现都是大单体应用，无法像微服务那样以非常细的粒度对功能模块进行拆分。所谓分布式的实践大多数停留在主从复制、负载均衡的层面上。k8s 之类的平台是将开发和运维的工作进行解耦，开发者（理想情况下）不再用关心运维层面的事情。实现的方式本质上是尽可能暴露应用内部状态，让数据流动公开化，最终的结果就以微服务的形式表现出来。
简单总结就是，我不看好任何形式的架构层面的迁移。要么坚守传统架构，要么从零开始云原生，我也不相信换个软件框架就能实现过渡。
4 天前 回复了 tangknox1 创建的主题 › React › 有用 LiveKit 开发过视频语音会议系统的嘛 |
估计要懂 webrtc 才行，挂在 React 节点可能不太好找人。
市面上的 sdk 大多都是类 webrtc 实现，然后在上层封装对接了供应商的网络服务，做成付费业务。
市面上的 sdk 大多都是类 webrtc 实现，然后在上层封装对接了供应商的网络服务，做成付费业务。
10 天前 回复了 x97bgt 创建的主题 › 程序员 › 如果你写了个东西，但不知道它是怎么跑起来的，会心慌吗？ |
会的。甚至包括第三方依赖的引入，都会专门开会讨论各种实现的优劣再决定。
初次编写代码的成本，比起长期维护的成本可低多了。这个成本总需要有人付出，无非就是写代码的那个或者审代码的那个。
引入 ai 之后，就算写的人用 ai 写，审的人用 ai 审也无所谓，最终还是这两个人来承担责任。
所以当我是提交代码的人的时候，肯定会看代码的。当我是审代码的人的时候，一样也会看，只是会在去掉注释和脱敏之后让 ai 一起检查一下。
初次编写代码的成本，比起长期维护的成本可低多了。这个成本总需要有人付出，无非就是写代码的那个或者审代码的那个。
引入 ai 之后，就算写的人用 ai 写，审的人用 ai 审也无所谓，最终还是这两个人来承担责任。
所以当我是提交代码的人的时候，肯定会看代码的。当我是审代码的人的时候，一样也会看，只是会在去掉注释和脱敏之后让 ai 一起检查一下。
Select Language