V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  billccn  ›  全部回复第 4 页 / 共 20 页
回复总数  383
1  2  3  4  5  6  7  8  9  10 ... 20  
86 天前
回复了 vFIVEv 创建的主题 分享发现 最近这期国补是不是范围和力度更大了
@lekai63 赞同你的说法。现在经济的最大问题就是供给过剩、有效需求不足,推出国补就是想促进需求。这里面无所谓补商家还是补消费者,效果是一样的,就是要消耗掉国内过剩的产能。

另一方面中国已经有进入通缩漩涡的迹象,如果国补造成物价继续下行反而会加剧通缩,所以从长远考虑,商家涨价来应对国补其实是增强了这个刺激政策的效果。
@PainAndLove 我觉得苹果电脑的 AC 已经被玩坏了,自付比例巨高,Mini 反正不会拿出去用,还不如赌它不会在 3 年内坏。
88 天前
回复了 BaymaxK 创建的主题 程序员 你们有玩过 JetBrains 家的远程开发吗?
1. 自动安装远端的逻辑没有考虑很多问题,比如我的远端只有内网没有公网,这 JB 都不考虑一个让我指定离线安装包地址的功能,最后远端版本我只能手动维护,体验远不如 vscode 。
2. 断线重连逻辑不好,经常失败,甚至会尝试在远端重复开 IDE 实例。
3. 有功能不支持远程,有时会尝试在服务端本地显示 UI ,显示不出来不停地在服务端抛 exception ,浪费 CPU 。同时本地不显示,你也不知那个功能是个啥
4. 即使是内网,跟手度随缘
88 天前
回复了 mayli 创建的主题 电动汽车 byd 1000kw 怎么做到的
我大学有个哥们就是搞储能电池的,1000A 早不是技术问题而是工程问题:
1.最大的问题是散热,从变流器到充电桩到车身内全都会变成电炉,固定的设备容易散热,车内散热比较困难。除了车内要全程水冷以外,不排除冷却水也要通过充电插头循环到外面
2. 高电流=效率低
3. 复杂性高,可靠性低
4. 电网配套困难,要直接接到变电站,而且要是多台车同时开始/停止充电能对局部电网形成冲击。可行的技术方案是要在这个充电站里配电池缓冲,那效率更低而且成本很高。

综上:如果大多数时候不需要这么快充那这么一套设备就不合算
91 天前
回复了 yihy8023 创建的主题 NAS PCIE 拆分后的 SR-IOV 问题
你 lspci 输出里没有 ARI 所以是不可能开 SR-IOV ,你要先确保网卡固件支持 SR-IOV 然后 BIOS 里打开 ARI 。
我遇到过,疑似是 IDE 内部的编译器超时/挂掉或者解析不出模版,你手动编译一下试试看看出什么提示?
96 天前
回复了 c2r5 创建的主题 Windows 江湖救急,请各位大侠帮忙,关于 Win To Go
这里面有几个问题,你要把它分别弄清:
0 、找到真正 C 盘的 UUID ,这是你正确修复的基础,因为你 Win to go 的盘也做过 C 盘,所以有些设置里可能混淆了。Win 系统用 mountvol 命令不加参数可以看到各个盘的 UUID 。
1 、注册表里的盘符只需要把 C 盘的修好,其他可以导出 reg 文件以后删除,等进入系统以后再重建。C 盘对应的二进制信息里面就有 UUID ,但是因为 endianess ,部分字段的字节顺序和 mountvol 看到的是反的。
2 、我猜导致你问题的是 KB5034441 更新,它需要扩容 Recovery 分区,但是错误的操作了内置硬盘而不是你的优盘。我有个印象是 recovery 分区不对的话即使不需要 recovery 也无法正常启动,你可以尝试从 BCD 里把 recovery 信息暂时删掉。
3 、其实 BCD 重建比修起来更方便,把 EFI 系统分区挂载以后把里面的 EFI 文件夹改名(或者备份到其他地方),然后用这里面的命令: https://www.tiger2doudou.com/doku.php/windows:os:reinstall_efi_partion_via_bcd_command 。注意 PE 系统里的盘符是无所谓的,BCD 里面记录的都是 UUID ,重建好以后用 bcdedit /enum /raw 命令可以确认系统盘的 UUID 是正确的。

可以进系统以后你可以参照 KB5028997 重建 recovery 分区。
97 天前
回复了 HowieWang 创建的主题 Java Java ReentrantLock 冗余设计?
我觉得要重点提出 1 楼说的“这中间有可能从有竞争变为无竞争( volatile )”,我觉了楼主可能犯了并发编程里一个常见是思维错误就是我“刚刚” 判断了一个条件,后面就不用判断了。
98 天前
回复了 Vtoecha 创建的主题 DNS 这发起带 https//的 dns 查询是什么操作
当你看到这些国产 app 安装包小则几百兆,大则直奔 3A 休闲游戏的时候,你就知道里面屎山堆得多高,出这些 bug 都不奇怪。

要知道 Windows 98 的安装盘也就 700MB ,里面还带了几千个设备的驱动,虽然 98 经常蓝屏,但是人家好歹是有优化的。
98 天前
回复了 worker201 创建的主题 NAS NAS 积满灰尘, 怎么清理?
压缩空气效果好,一定要在屋外弄,最好带上 n95 和护目镜。这个气体很冷的,吹一下换一个地方,否则会有冷凝水。

除非全密封的氦气盘,盘体本身不要碰压缩空气,拿拧很干的布擦擦除电路板的几面是可以的。

吸尘器我试过效果不好,因为嘴太大了,压力不够。
@paopjian 这个问题到现在还有啊,比如嵌入式系统 32 位的已经很高级了,用 8 位机的也大有人在,很多机器连整数除法都做不了,这也是 C/C++最大的客户群。
@cnbatch 我发出来才看见你的,我觉得你说的“int 必须比 short 宽,long 必须比 int 宽”虽然让部分初学者可以更清楚的了解这些类型的区别,但是与系统编程语言的定位不符合。比如说我记得早期的 64 位机就有完全不支持 16 位长度的指令集,这样 short 也必须是至少 32 位,那么 int 就得 64 位,long 不能 128 位吧?
这个问题的本质是 C/C++定位是系统编程语言,数字类型的是为了方便在不同指令集之间移植来设计的,比如说:

* 所有类型都只有最小宽度而没有绝对宽度,因为不是所有指令集都有操作各种宽度的指令
* int 就是在那个平台寻址范围内做下标比较合适的长度
* short 就是可能比 int 节省空间,但是至少有 16 位; long 就是至少有 32 位

当然我也觉得理想是美好的,现实是骨感的,这些语言出现不久互联网就爆发了,有了跨机型交换数据的需求,导致这些依平台而变的类型不好用。

理论上说交换格式可以和内存里的数据类型分离,比如内存里的 struct 用 int, long 等类型,交换时翻译到到固定长度的 char[](这样还解决了 endianness ),但显然没有几个人这么勤快。

当然我觉得 long long 出现时,这个情况已经很明显了,应该直接定义 int64 而不是新增一个关键字。
@Sodacooky 我觉最好还是不要拿 C++的 auto 来比,因为写模板的时候很多中间值你都无法知道它类型是什么,如果不用 auto 就得声明一个新的类型参数,但有的时候又不能改变 API ,导致模板函数套模板函数,编译越来越慢。

Java 的 var 这个就是可有可无,因为类型永远是清楚的。

另外我觉得在 PR 里读到 var 很多的 Java 有点像读找不到实例的 C++模板,你只能靠变量名猜这代码是在干啥,至于对不对是完全无法确定。
@noErr 很多中小公司的系统管理员并不感冒命令行,也玩不转云 API ,他们就喜欢在一个图形界面里面反复点鼠标,Server 版几乎是他们唯一的选择。虽然 Server 版很贵(要按用户人头收费),但反正是公司出钱。

桌面版的 Windows 其实也只能从企业客户赚钱,你可以想象成定位已经变成“Office 官方运行环境”。但是只有持续培养非企业客户的使用习惯才能把持住企业市场,所以个人版还在做,困扰楼主的这些乱七八糟的功能都是在给充满广告的 msn.com 引流,这样可以补贴一点成本。
问题就来了,如果编程工具实现了自举,那每个客户订阅一个月自己写一个后面就不用再订阅了(至少可以直接接入最便宜的 AI API ),那这些做工具的就无法赚钱了。

就像我那天构思了个部分利用 AI 的代码优化系统,但转念一想它最有可能的作用是把我的部门搞失业,遂作罢。
同情楼主,但我觉得楼主把因果搞反了,据我的观察,大公司软件质量的堕落是面向 KPI 编程的结果。这个文化的初衷是好的,就是用科学和客观的方法评价工作,尽量避免人评价人容易产生的偏见,这恰恰是西方理想主义的思维,不是印度实用主义。

程序员的工作就是在既定的规则中游走和优化,无所谓是编程语言的规则还是评级系统的规则,而且这些大公司招的都是人精。真正花很多心思写良好的代码然后彻底测试的,多少是要靠情怀,对提升 KPI 帮助有限。我在西方工作很多年,接触到十几个国家的人,我觉得欧洲白人是最情怀的,印度人确实最功利,中国韩国人等差不多在中间(但是抱怨少,所以经常被用来成全别人的情怀)。

恶心的是这些公司的管理层多少清楚这一点,但他们自身也有非常明确的 KPI ,比如股价,这些和代码质量不是很挂钩,但是非常受功能数量和市场营销的影响,所以形成了这个局面。
1  2  3  4  5  6  7  8  9  10 ... 20  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1186 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 35ms · UTC 17:31 · PVG 01:31 · LAX 10:31 · JFK 13:31
Developed with CodeLauncher
♥ Do have faith in what you're doing.