> 其他的没建议，建议了解下 14 代 I7 的相关问题，例如功耗过高以及 I7 、I9 不稳定的问题。以免装了之后才知道这些，膈应

@arloor 恰好刚出的消息说是原因找到了：

https://www.msn.com/zh-cn/news/other/intel-13-14%E4%BB%A3i9%E4%B8%8D%E7%A8%B3%E5%AE%9A%E7%9A%84%E6%A0%B9%E6%BA%90%E6%89%BE%E5%88%B0%E4%BA%86-%E5%B9%B6%E9%9D%9E%E4%B8%BB%E6%9D%BF%E5%8E%9F%E5%9B%A0/ar-BB1ofXxw

Intel 13/14 代酷睿 i9 K 系列大规模爆发游戏崩溃、蓝屏死机的不稳定问题已经一个多月了，但除了主板厂商更新 BIOS 设定，Intel 一直没有针对这一情况公开发声，原计划在 5 月 31 日发布的官方声明也没了下文。

根据 Igor'sLAB 的最新报道，Intel 终于找到了这一问题的根源，不是主板 BIOS 的设定有误，而是出自 Intel 提供的微代码算法本身，并已在内部复现。

确切地说是，eTVB 加速机制的参数设置错误，导致在较高温度下，频率和相应电压的提升，降低处理器的稳定性，13/14 代酷睿均受影响(CPUID 0xB0671)。

Intel 的一份内部文档中解释说，对于 13/14 代酷睿 K 系列的失效分析显示，因为电压持续处于较高的水平，处理器的最低运行电压出现了偏差，而之前的微代码和 BIOS 设置有误，允许处理器在高温下依然可以运行在加速频率和高电压之下。

至于 12 代和更早的酷睿 K 系列，因为默认电压和频率较低，对这种设定不敏感，因此不会出现不稳定的情况。

Intel TVB 、eTVB 加速技术仅支持 i9 ，这也就是为什么问题集中出现在 i9 系列上——虽然部分 i7 K 型号也偶有不稳定问题，但不是同一回事儿，可以视为其他原因的个例。

TVB 技术是在睿频 2.0/3.0 加速之外，根据处理器的功耗、散热冗余空间，进一步超频。

比如说 i9-14900K ，官方标注的最高频率 6GHz 就是来自 TVB ，而常规睿频 3.0 的加速频率最高为 5.8GHz——就是这区区 200MHz 惹了祸。

Intel 已经要求所有主板厂商，在 2024 年 7 月 19 日之前将微代码版本升级到 0x125 或者更新，其中包含一个 eTVB 修正补丁，当温度超过一定阈值后，就不再允许进入更高性能状态，也就是限制超频。
相信很快，Intel 就会发表公开声明，主板厂商也会陆续更新 BIOS 。

@murmur #4 年过 35, 又很多人说：劝人 IT ，天打雷劈。除了失业，多数人还一身 IT 职业慢性病。
压力和收入是早来还是晚来放到一辈子人生的尺度上，在不同的时代各具优劣。比如 10 年前，如果搞 IT 先攒够第一桶然后赶上互联网红利、房地产红利，划算，但是当下的经济周期区间就未必了

@MIND222 如果分数能有机会，建议军医。原因：
1. IT 或者其他前沿那些想在做出成就的赛道竞争压力大，成绩不具备优势，所以不建议
2. 相比于普通医学方向，军队国防生本身的待遇不差，有军队管教只要跟着别掉队就行，技能点上也是长期价值的投资，年轻时候辛苦点，稳定无忧

先搞清楚要对比的是什么, 如果是 count(*) 对比 count(user_id) 是有可比性的, 但 select * 对比 select user_id, 每条 700B vs 每条数据最多 8B, 单说拷贝 100w 条数据的量就性能差别巨大了所以二者根本没有可比性

只考虑孕妇、不考虑孩子吗？随便搜了下对孩子的影响：

增加儿童恶性肿瘤的几率
引发儿童哮喘
影响儿童听力发育
影响儿童身高
诱发厌食
影响儿童智力发育
婴儿猝死综合症
...

女人不懂事那自己爱吸就吸，孩子面前谁抽烟都不行！

提前客气地给客人说清楚，忘了就再提醒，平常语气沟通，不用纠结什么客气不客气的
别惯着这些坏习惯

@iseki
什么情况必须获取原始口令？密码和 OTP 是有区别的，你要说 OTP 我没意见。其他系统的密钥本身，我暂时想不到必须用原始明文口令的。
我的出发点是，实现各种密码存储需求本身要应对的业务，并不需要以来明文本身，历史问题是历史问题，但这里说的是方案本身的优劣，历史改造甚至都不在我考虑范围内
所以这根本不是说法的问题，是逻辑本身的问题，如果你一定要用“现在已经有哪些使用了明文、所以避免不了用明文”来讨论，那确实没什么可讨论的了，这不是我在讨论的问题

@lesismal #222 不要看它当前是什么方式，站在当前实现的方式的角度考虑问题则任何现状都有它局限于历史和版本等问题导致的合理性。应该撇开历史现状，看理论和实现方法上，哪种方式可以做到更好。是否把旧系统改造升级是项目自己的管理的问题

@iseki LDAP 我没太了解过，但如果它需要明文的密码，这应该也是历史遗留问题，因为本质上是不需要明文的。另外，“必须把用户输入的原始口令发送过去”—— 这里的原始口令要看是哪种，如果是密码、那是历史实现问题和现在的兼容性、修改成本问题，如果是 OTP 这种单次验证码，则没关系，单次的验证码明文也可以、不怕泄露

@morebuff 感谢支持！欢迎使用！ 666

首先应该清楚：他俩可不是普通人啊

所以，为什么要用普通人对比做标题

> 明文向后端传输虽然不好

你看, 你也认为明文不好了

> 但有时这是工程上成本刚好可以接受的方式

如果是项目初期/上线前, 这个成本真的不多

> 一来我刚才说了，很难设计一个有足够收益的非明文传输方案

数据隐私本身不重要的网站, 明文与否都还好, 即使泄漏了也没关系. 我自己注册一些不重要的网站的密码都非常简单, 单手输入满足大小写之类的就用了, 也不怕泄漏, 重要信息的网站就复杂些而且那些站多数有二次验证之类的额外安全措施, 所以也不怕

> 二来就是有时候后端的某些设施只能接受明文

密码这个功能点上来讲, 明文不是必需, 所以如果哪家说必需明文, 那我怀疑这是别有用心...

@iseki

@zanpo 兄弟你根本就没看懂 OP 我说的是什么, 你们好些位这都相当于是盲人摸象管中窥豹, 只考虑 https 或者某个 part, 请先看下我帖子和 append 或者更多楼层的回复

@msg7086 虽然可能 block 我了, 但说不定你 logout 能看到, 所以补几句吧, 你让我举例子, 我说黑产黑了的很多没曝光出来你又说我假大空, 那你可以看下 github 的例子, 可以看下 #158 cdn 脱裤的例子, 淘宝亚马逊以及#174 微信的推荐设计

自己脑袋一热也不认真分析下我的回复, 就无脑喷我, 只会限制你提升自己的技术层次, 这跟我所理解的原因(病因)八九不离十, 就是舒适区和沉没成本, 另外一个词就是"聪明反被聪明误", 因为自己懂了一些, 所以拒绝接受不一致的. 但技术需要冷静分析, 论坛上讨论技术我多数时候是一就是一二就是二, 不喜欢模棱两可去赞成别人, 所以我的观点如果和你不一样的时候, 你可能会觉得我带着情绪, 但不是, 技术的东西是实在的, 谁也不给谁发工资, 不需要看脸色

@viruscamp 跟前面好多层一样, 兄弟你这也是没 get 到

@viruscamp

我已经发现了, 讲的原则逻辑和道理各位基本都不怎么看, 所以我举例子请教各位, 淘宝亚马逊不用明文, 是为什么?

github 日志输出明文的问题暴出来大家也"多数人"认为这是问题, 为什么? 我这里说"多数人"而不是说"所有人"认为这是问题, 因为我发现可能并不是"所有人"认为这是问题, 比如各位坚持明文的

> 谁出钱谁说了算。你出钱吗？你不出，所以你说了不算。

公开的技术讨论, 各自公司自己的事情自己负责, 你看见我什么时候说过我说了算了要求你们所有人都要按我说的做了?
但是, 我公司的项目就是我说了算, 你也管不着

> 你自始至终都没有对 Before 和 After 做过具体的案例分析，帖子里基本就是一些假大空的呐喊，什么坚持明文啊什么舒适区啊什么天性啊。怎么不上点干货呢。

哦哦, 和着我说的技术逻辑安全逻辑安全原则和举例子之类的, 都算是假大空是吧? 我说了那么多逻辑原则例子你思考吗?你不思考还狡辩解释那么多层然后被逼的我说你舒适区有错吗?

> 这么高一层楼 200 来个回复，说句实话，非常给你面子了，因为讨论的过程还算礼貌，v 站大多数人也不愿意说脏话。

怎么的, 有些个小孩子上来就说"你水平低"之类的, 你见我说几句脏话了吗? 聊个技术还怕别人喷, 那就不要出来聊

> 换到激进点的论坛里，就不知道是你保卫家人在先，还是管理员看不下去直接 ban 号在先了。

自己说不过了, 就改成威胁别人要骂人了是吧? 我不 care 低素质的人, 你随意

@Livid 我感觉这是在威胁骂家人了

> 帖子内容太过贫乏，甚至激不起我一点讨论技术的欲望。有句话叫，非蠢即坏。

蠢和坏也是要以事实逻辑为依据, 我每一个点都有对应的解释, 如果你看不懂然后以为我蠢, 那你也随意, 你嫌烦的话可以直接 block 我

> 看你讨论过程，好像也不像是坏，那可能只是真不懂了。但最可怕的是不懂还觉得自己是对的，有一种老子说的才是对的，你们不同意那一定是你们都是傻逼。那这就没法聊下去了。

你看看你这两层的回复, 谁在假大空?

@msg7086

> 对于题主的不信任 https

@mayli 我可是完全没说过这话啊兄弟, 你和其他很多楼一样, 几乎完全没 get 到我说的是什么...

> 你不猜你怎么知道哪些厂为啥不加密？这两家都是你主导的还是你认识主导这个需求的人？

@LuckyLauncher 我都是在按照逻辑讲安全的, 因为一些人举例子 github 说大厂用明文所以就该用明文所以我举大厂的反例

> 你不过也只是在按照你的方向猜测罢了

我不是靠猜测, 都是按道理按逻辑在讲. 我举例子反驳他们 github 的例子, 虽然我没有说原因, 但我相信不用猜测——因为大厂不用明文的原因就是为了更高的安全强度, 这些不需要认识他们主导这个的人

这种事情还是听专业医生的靠谱

@livin2 #186 对, 对于老项目是这样的. 但对于新项目可以避免这些