V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  msg7086  ›  全部回复第 28 页 / 共 1008 页
回复总数  20142
1 ... 24  25  26  27  28  29  30  31  32  33 ... 1008  
280 天前
回复了 iorilu 创建的主题 程序员 有多少人完全使用命令行管理 git 得
@james122333 #111 我只是想说 TUI 本质上和 GUI 就是一个东西。功能上,使用逻辑上,都类似,只因一个用 ncurses 生成窗口、菜单、状态栏,处理键盘鼠标事件,而另一个用 GTK/QT/Win32API 生成窗口、菜单、状态栏,处理键盘鼠标事件,而莫名其妙弄出一种鄙视链来。
PVE 不适合放这种存储。ESXi 可以的,我记得需要把日志搬到主硬盘上。
不过说实话意义不大,不如直接 ESXi 装在硬盘上,也不占多少空间。
@ShikiSuen #11 这边建议改改环境变量 GIT_AUTHOR_DATE GIT_COMMITTER_DATE 直接平移日期。
开虚拟机改系统日期太麻烦了。
280 天前
回复了 iorilu 创建的主题 程序员 有多少人完全使用命令行管理 git 得
「命令行」工具与「图形化」工具对比:
https://i.imgur.com/Hxnm7Wh.jpg
280 天前
回复了 iorilu 创建的主题 程序员 有多少人完全使用命令行管理 git 得
@kiwi95 tmux 本来就可以算一个图形化的工具。
我在几年前的讨论里就说过了,很多人魔怔地反对 GUI ,但却自己用着和 GUI 差不多的东西,比如 tig ,比如 vim/emacs ,比如 tmux 。所以我上面说了,真当字符画出来的窗口不算窗口啊。

至于「 cli 用不明白就觉得 cli 做不了吗」我可没有这么说过哦?你是不是有点魔怔为了反对而替我发表观点了?
我自始至终说的都是 GUI 在做很多操作的时候可以省下时间,我什么时候说过 CLI 做不了了?特别是我第一句话就是 GUI 下层还是会调用命令行,你都选择性不看的是吗。

抛开事实不谈,你说得还挺好的。
280 天前
回复了 iorilu 创建的主题 程序员 有多少人完全使用命令行管理 git 得
@LonnyWong VIM 就是一个图形界面的编辑器啊?
能用鼠标能用上下左右光标,主窗口区是所见即所得的内容面板,最下面还有状态栏,这不叫图形界面?
我认为只有 sed 之类的才配叫命令行工具。

至于 git add -p ,这东西不太好做太细的局部 stage 。他最小单位是代码块,遇到比代码块更小的操作单位你怎么办?比如说你加了两行,一行 call func1 一行 call func2 ,现在要把 func1 和 func2 放在两个提交里做。当然你可以用 e 选项手动编辑,但这你还要和 GUI 比性能么。

而且 GUI 里是 3-way merge ,编辑任何一个代码块都能看到 HEAD 和 stage 和 working dir 三份代码。你不会说 diff 比 3-way 更直观更不容易出错吧……
280 天前
回复了 wesleyqiu 创建的主题 Python 孩子学编程是不是首选 C++
学 C++是要学到什么程度?上模板吗?学 Intrinsics 汇编吗?多线程和异步?
学 C++的目的是什么你得先搞清楚。
280 天前
回复了 yeqizhang 创建的主题 程序员 请问 SATA 接口固态买哪个好?
提醒一个现在的 MX500 和以前的 MX500 已经不太一样了。
以前 MX500 可以无脑买,稳得一批,现在 MX500 翻车的不少。
280 天前
回复了 iorilu 创建的主题 程序员 有多少人完全使用命令行管理 git 得
@troywinter GUI 下层还是会调用命令行,但是 GUI 会把常用的复杂操作自动化。你可以把 GUI 等效看做一个 CLI 的半自动化脚本。

我举个例子,把一个分支下的提交 rebase 到另一个 tag 下并做 3-way 冲突处理。这个过程不管用 GUI 还是用 CLI 都必须手动做,完全不会享受到命令行批量处理的好处,而 GUI 下只要点点鼠标就可以从不同的分支里选出不同的代码行。用 CLI 你最后不还要打开 VIM 这个图形界面工具。

所以光这个操作就省下 GUI 用户大量的时间,而这个操作又正好是大流量开源软件和 modder 必须要用到的。

还有一个操作,是局部 stage ,可以把一个修改过的文件中的少部分行 stage ,剩下的留在 working dir 里,又或者是像做 3-way 合并一样选择性地把一些行或者一些字 revert 。你用命令行当然也可以这么做,先把文件复制出来备份,然后把部分行改回去,然后 add 提交,再把备份文件移动回来。

-----

当人们对这些操作没有需求的时候,总会觉得命令行效率高。等没法满足的时候,再去写一下半自动化脚本,重新实现一些 GUI 已经实现的功能,然后再把 GUI 批判一番。就,很没有意思的争论。类似的争论我好几年前就在隔壁 ruby-china 论坛参与过了,一堆坚持不用 GUI 但照样用着命令行版 GUI 的人在跟我争。真当字符画出来的窗口不算窗口啊。
@sun4076 我用 dailyroads 录的。录完可得一个 mp4 一个 srt 字幕文件。字幕文件是按秒记录经纬度之类的信息。
啊?我行车记录仪就是手机安卓 app 。
录完以后还有包含时间,车速,经纬度坐标的字幕文件。配合视频一起跑一下不就什么都有了。
HDMI 跑 4K144 8BPC 需要跑到 40G 带宽,最少也要 HDMI 2.1 。
DP 跑需要 UHBR 10 的 39G 带宽,最少也要 DP 2.0 。
你 HDMI 2.0 就只能跑到 2560x1440 144 或者 3440x1440 120 。你如果输出 2560x1440 144 然后让显示器做 upscale ,理论上是可行的,但是画面可能会一点点糊。
用着 Vivaldi ,毕竟是纯正的 Opera 血统。
283 天前
回复了 csznet2023 创建的主题 程序员 如何推广自己的开源项目
我做开源基本都是纯粹抛砖引玉。我起个头,实现从 0 到 1 ,满足我自己的要求。接下来如果你想要改进或者要加功能,自己 fork 出去,提 PR ,又或者你觉得你有能力维护的,我把我的项目 archive 然后指向你的 fork 。
16G 内存也只不过是少吃点虚拟内存罢了。
比如像我现在开了浏览器和各种常用软件,吃了 35G 内存。你配 8G 就是开 27G 虚拟内存。配 16G 就是开 19G 虚拟内存。我觉得好像倒也不是差得很多。

不过你这个 2019 年花 3100 买 8G 内存的本,真的谈不上性价比。3300 16G 性价比倒是就上来了。如果能 3600 32G 那性价比才叫爆表,还能再战好几年。8G 内存的本就是给轻度使用用户的。
283 天前
回复了 evan9527 创建的主题 问与答 站里有三文鱼+芥末爱好吗?
(不在国内)
Costco 买的冷冻养殖三文鱼,想吃了就解冻出来自己切一下吃。

淡水养殖如果对水质饲料都控制好的话应该问题不大。
实在不放心就真空抽好丢进冷冻里放一个月再吃呗。
284 天前
回复了 Salomea 创建的主题 问与答 ARM 比 X86 的局限是什么
@Donahue 计算密集型项目会大量用到汇编指令集。用 C 然后让编译器去优化,那就不知道慢到哪里去了。
你有兴趣的话可以试试看跑 x265 ,用--no-asm 路径跑(纯 C+编译器优化),看看比 AVX2 要慢多少。

如果只是跑跑 php python 之类的,不追求性能的,那当然怎么搞都无所谓了。但是企业环境下对指令集的依赖是很大的。适配 NEON 是硬性成本,不适配就是性能狂掉。
别的我先不说,就说这项目是「 Apache License 」与「软件仅供个人学习与交流使用,严禁用于商业以及不良用途。如有发现任何商业行为以及不良用途,软件作者有权撤销使用权。」双许可证吗?
@binfreeze #3 #4
你说得对,这都看个人追求了。有人玩深度,有人玩广度。抽象和封装本来就是工程能力的一部分,把细节隐藏得越好,上层开发越舒服,说明你架构做得越好。现在写 C++的,也不太需要关心下面 C++到汇编的转译优化。写 CUDA 也不用关心显卡硬件是如何执行的。的确,总要有人做底层的工作,但是越底层的地方人越少,因为需求少。只要少部分人把底层打扎实了,剩下的 99%的人只要站在巨人的肩膀上就行了。
1 ... 24  25  26  27  28  29  30  31  32  33 ... 1008  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2344 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 4764ms · UTC 11:27 · PVG 19:27 · LAX 04:27 · JFK 07:27
Developed with CodeLauncher
♥ Do have faith in what you're doing.