首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  yyfearth  ›  全部回复第 17 页 / 共 170 页
回复总数  3384
1 ... 13  14  15  16  17  18  19  20  21  22 ... 170  
❮ ❯
2022-02-22 15:08:19 +08:00
回复了 julyclyde 创建的主题 › Kubernetes › k8s 抛弃 docker 之后， docker 还有前途吗？
@ytll21 不是哦 首先 docker 不是只用来部署线上服务的 很多时候也用来开发测试 或者本地搭建环境和脚手架
如果线上用了容器 这样本地环境和线上环境比较相似 可以避免一些麻烦

另外 现在越来越多全栈 其中 devops 也是很重要的一个技能 你的的代码你要自己部署上线 就是可能有运维帮忙 对于全栈 负责任的人还是自己

就算有专业的运维 如果线上用容器 也应该和开发一起讨论容器的一些细节和兼容问题 比如那个 Linux 发行版 以及某些库的版本
另外如果线上出问题 那么肯定也要跑到容器里面 或者拉下来一个容器来测试复现之类的 那么基本的容器的操作还是要会的

总之 现在除非真的在一个地方养老 如果是做线上系统的 还是一定要学一下容器的
2022-02-16 02:46:12 +08:00
回复了 est 创建的主题 › Google › Google 已死。老美也苦 G 家久已
这个和国内的百度比还是好点的了
所以国内这种情况更严重 互联网割裂更严重
每个 App 都希望把用户圈在自己的生态里面
2022-02-16 02:41:07 +08:00
回复了 darkaforest 创建的主题 › Python › macOS Monterey 12.3 Beta 升级之后 Python 没了 这可如何是好
macOS 12.3 移除了自带的 python2
肯定是你的 zshrc 或者 bashrc 里面用了 python 了 如果不需要移除就是
如果需要 homebrew 自己安装一个就好
2022-02-09 03:52:35 +08:00
回复了 3dwelcome 创建的主题 › 前端开发 › google 的 br 压缩算法是真的强。
zstd 不适合 web zstd 主要的优势是快而不是压缩率
br 的速度肯定没办法和 zstd 比 但是压缩速度对 web 而言没那么重要 尤其是静态资源
br 就是专门为 web 优化的算法

@duke807 br 是压缩慢但是解压缩还是比较快的而且不太占资源
xz 如果是高压缩率的话 压缩和解压都太慢 而且太占资源了 不太适合浏览器
2022-02-05 14:37:21 +08:00
回复了 rpish 创建的主题 › Flutter › Flutter 支持 Windows 应用开发
只有那些比较简单封装的 webapp 可以从 Electron 转而使用 webview2
或者有人出一个和 Electron 一样 API 的东西但是用 webview2 + node 作为内核
2022-02-05 14:36:24 +08:00
回复了 rpish 创建的主题 › Flutter › Flutter 支持 Windows 应用开发
@okampfer 很难 除非 webview2 支持能够支持 NodeJS 但是可以说是不可能的
只有那些比较简单封装的 webapp 可以转而使用 Electron
或者有人出一个和 Electron 一样 API 的东西但是用 webview2
但是像 vscode 这样这么多功能又要跨平台 又非常依赖 Node 的 app 肯定还是会用 electron 的

另外 webview2 是和系统的 Edge 绑定的 不受 App 的控制
如果有人就是不升级 Edge 或者 App 太老 Edge 又太新 就会出现兼容性问题
除非 App 自带一套 webview2 那么这样就和 Electron 一样重了
2022-02-05 04:52:30 +08:00
回复了 rpish 创建的主题 › Flutter › Flutter 支持 Windows 应用开发
@dcsuibian windows 出了 webview2 也是基于 Edge / Chromium 的
那么大部分 Electron App 在 Windows 下其实可以不用带整个 Chromium ，当然 如果要用到 Node 的部分就没办法了
2022-02-05 04:50:56 +08:00
回复了 cwcc 创建的主题 › 问与答 › 27 寸 4K 接 Mac 显示效果到底怎么样呢？
@LxExExl 就是 HiDPI 的 不是整数倍的缩放 字体就是不够清晰
尤其是 Dark Mode 下 看久了眼睛不舒服
2022-02-03 11:06:57 +08:00
回复了 cwcc 创建的主题 › 问与答 › 27 寸 4K 接 Mac 显示效果到底怎么样呢？
@LxExExl 4k 缩放到 1440 不是刚好 2x 感觉字很模糊 看久了后感觉眼睛都花了

@hello2090 我戴眼镜 2-3 年前也觉得 4k 1080p 内容太少 5k 很合适
但是用了 5 年 5k 后 现在觉得看着太累了 屏幕要放到更近才舒服 但是这样就更伤眼睛了
现在换成 4k 反而觉得刚刚好
2022-02-03 08:49:19 +08:00
回复了 Mrzhs 创建的主题 › 问与答 › 有老哥拔过火罐没?什么感觉?啥功效?
火罐和刮痧一样
说白了就是人为制造一些轻度的伤害 然后激活自身的免疫和恢复系统
可以比作非常轻度的放血

但是身体本来就很弱的人我觉得还是不要做比较好
2022-02-03 06:05:29 +08:00
回复了 LxExExl 创建的主题 › MacBook Pro › MacBook Pro 16 M1 Pro 到手感受
另外去过实体店试过 16 寸真的太大了
如果我买了 16 寸 肯定不会带着它
肯定是放在桌子一边 当一个显示器 再外接一个 4-5K 显示器 和 外接键盘 当台式机用

14 寸的感觉不错 性能应该也够了 稍微厚重了一点点 没 16 寸那么夸张
2022-02-03 06:03:04 +08:00
回复了 LxExExl 创建的主题 › MacBook Pro › MacBook Pro 16 M1 Pro 到手感受
“打字的时候更硌手腕了” 不可以调整一下座子或者椅子的高度吗？
“打字硌手腕”本来就说明你的姿势应该不太对
如果是在固定的座位 但是没办法调节高度 可以买一个保护手腕的垫子
如果有外接显示器 更应该外接键盘吧
2022-02-03 05:58:47 +08:00
回复了 cwcc 创建的主题 › 问与答 › 27 寸 4K 接 Mac 显示效果到底怎么样呢？
我觉得关键看你的眼睛
如果你年轻视力好 27 寸 5K 或者 24 寸 4K 比较舒服
27 寸 4k 会觉得颗粒感

但是眼睛慢慢不好了 度数高或者年纪上来了 27 寸 4K 就比较香了
27 寸 5K 或者 24 寸 4K 字太小 会看起来吃力 27 寸 4K 就刚刚好了
2022-01-26 13:30:10 +08:00
回复了 CS666 创建的主题 › Apple › 期待下 SE3,我的 X 实在是顶不住了
@CS666 今年 SE3 没戏了 和现在的 SE 差不多
估计是下一个 SE 才有全面屏和 FaceID
2022-01-26 04:05:06 +08:00
回复了 xuegy 创建的主题 › Apple › 是否可以逆向思维倒逼苹果推出 USB-C 的 iPhone
@xarthur @xuegy 要出 USB-C 也可以学 TB3 一样
基于 USB-C 的 Lightening 2 接口 MFi 就可以继续了

然后比如 如果不是 Lightening 2 就不能 20w 以上的快充 或者只能继续 USB 2.0 的速度
只有 MFi Lightening 2 才可以用 USB 3.2 的速度
2022-01-22 05:36:56 +08:00
回复了 zzlatan 创建的主题 › 问与答 › TypeScript 真的是必须的吗？
小项目 个人项目完全没必要
但是大项目 需要多人合作的项目 有 Type 会明显降低 bug 几率和沟通文档的成本
2022-01-22 04:06:15 +08:00
回复了 haoyh1 创建的主题 › 程序员 › 这么多音频编码，蜂窝的 AMR， BT 的 SBC，除此之外还有 mp3， aac 这些比较通用的，它们都是由什么硬件实现的？
这些编码软件当时 CPU 都没问题 现在的 CPU 更是轻松
不过现在很多 CPU 或者硬件会有带硬件加速可以 硬解 SBC AAC AC3 这些了
硬解也只要调用系统的 API 就可以实现 只要做好系统兼容性就好 具体软件不需要操心
2022-01-21 09:51:27 +08:00
回复了 MakHoCheung 创建的主题 › 分享发现 › 1Password 又有融资了
写一个很容易 但是要让很多人用就难了 要推广和运营好更难 还要能融资 你是有什么黑科技呢还是有大量的用户呢？
2022-01-21 09:48:06 +08:00
回复了 leebs 创建的主题 › Node.js › node 单线程是怎么应对高并发的场景的？
@leebs "某个条件触发了耗时的 cpu 运算"
耗时 CPU 运算目前两种方法，核心概念就是保证主线程不阻塞
1. 把这部分放到其他子线程或者进程 然后主线程异步处理
2. 如果上面太难 就把需要长时间 CPU 处理的运算打碎成多个短暂同步运算然后异步处理 保证主线程不要长时间卡住

对于 2 比如一个运算需要 10s 那么就把它打碎成 1000 个小运算 每个 0.1s 然后中间异步等待
这样主线程就不会因为一个 10s 的运算而阻塞 10s
虽热这样一来 原先 10s 的事情可能变成了 15s 或者更久 但是至少不会长时间阻塞其他的请求

当然 2 这种方法比较时候低并发或者低概率触发的情况
如果真的高并发情况大概率 还是要用 1 来处理
2022-01-21 09:41:27 +08:00
回复了 leebs 创建的主题 › Node.js › node 单线程是怎么应对高并发的场景的？
@leebs node 单线程 如果做“CPU 密集的工作”或者“同步的 IO 操作”就会卡住
这个是一定要避免的 如果没法避免就必须用 worker https://nodejs.org/api/worker_threads.html

然后保证主线程不卡住就没问题了
所以 node 做 IO 密集的工作 性能还是可以的

不够就上多个 node 进程 然后外面做负载均衡就是
尽量无状态 如果必须要 session 就用 redis
1 ... 13  14  15  16  17  18  19  20  21  22 ... 170  
❮ ❯
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1335 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 43ms · UTC 17:50 · PVG 01:50 · LAX 09:50 · JFK 12:50
Developed with CodeLauncher
♥ Do have faith in what you're doing.