lesismal

lesismal

V2EX 第 497905 号会员,加入于 2020-07-06 13:49:58 +08:00
美国宣布全面禁止竞业协议
程序员  •  lesismal  •  33 天前  •  最后回复来自 ChrisFreeMan
2
github 被人 at 说币安空投,是诈骗吗?
程序员  •  lesismal  •  166 天前  •  最后回复来自 lesismal
2
4C-2G 来战 [ Golang Websocket 百万连接测试 ]
程序员  •  lesismal  •  186 天前  •  最后回复来自 lesismal
34
nbio 近期的一些功能更新,来骗点 star
  •  1   
    Go 编程语言  •  lesismal  •  2023-04-18 14:04:25 PM  •  最后回复来自 lesismal
    2
    吃八分饱长寿与充电 85%能保护电池
  •  1   
    硬件  •  lesismal  •  2022-05-06 13:22:14 PM  •  最后回复来自 julyclyde
    22
    lesismal 最近回复了
    > 其他的没建议,建议了解下 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. 相比于普通医学方向,军队国防生本身的待遇不差,有军队管教只要跟着别掉队就行,技能点上也是长期价值的投资,年轻时候辛苦点,稳定无忧
    6 天前
    回复了 dumbbell5kg 创建的主题 MySQL 请教一个 MySQL 的问题
    先搞清楚要对比的是什么, 如果是 count(*) 对比 count(user_id) 是有可比性的, 但 select * 对比 select user_id, 每条 700B vs 每条数据最多 8B, 单说拷贝 100w 条数据的量就性能差别巨大了所以二者根本没有可比性
    只考虑孕妇、不考虑孩子吗?随便搜了下对孩子的影响:

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

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

    提前客气地给客人说清楚,忘了就再提醒,平常语气沟通,不用纠结什么客气不客气的
    别惯着这些坏习惯
    @iseki
    什么情况必须获取原始口令?密码和 OTP 是有区别的,你要说 OTP 我没意见。其他系统的密钥本身,我暂时想不到必须用原始明文口令的。
    我的出发点是,实现各种密码存储需求本身要应对的业务,并不需要以来明文本身,历史问题是历史问题,但这里说的是方案本身的优劣,历史改造甚至都不在我考虑范围内
    所以这根本不是说法的问题,是逻辑本身的问题,如果你一定要用“现在已经有哪些使用了明文、所以避免不了用明文”来讨论,那确实没什么可讨论的了,这不是我在讨论的问题
    @lesismal #222 不要看它当前是什么方式,站在当前实现的方式的角度考虑问题则任何现状都有它局限于历史和版本等问题导致的合理性。应该撇开历史现状,看理论和实现方法上,哪种方式可以做到更好。是否把旧系统改造升级是项目自己的管理的问题
    @iseki LDAP 我没太了解过,但如果它需要明文的密码,这应该也是历史遗留问题,因为本质上是不需要明文的。另外,“必须把用户输入的原始口令发送过去”—— 这里的原始口令要看是哪种,如果是密码、那是历史实现问题和现在的兼容性、修改成本问题,如果是 OTP 这种单次验证码,则没关系,单次的验证码明文也可以、不怕泄露
    @morebuff 感谢支持!欢迎使用! 666
    首先应该清楚:他俩可不是普通人啊

    所以,为什么要用普通人对比做标题
    > 明文向后端传输虽然不好

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

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

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

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

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

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

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

    @iseki
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2364 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 04:03 · PVG 12:03 · LAX 21:03 · JFK 00:03
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.