lesismal

转:

YouTube 似乎在测试服务器端广告注入以对抗广告拦截器

YouTube 通过服务器端广告注入继续打击广告拦截工具。广告拦截软件 SponsorBlock 的开发者今天分享说：“YouTube 目前正在测试服务器端广告注入。”从高层次来看，这意味着广告现在是作为视频的一部分，被流式传输到你的设备，而不是单独投放到桌面网页或移动客户端。目前的方法允许广告拦截器拦截并且不显示广告。但未来广告会与视频无法区分。目前该功能仍在测试中，部分用户已经遇到了这个问题。

@arloor 对, 所以高通 arm 或者 intel 新代稳定后才是更好的选择, 只是需要等等:

> 其他的没建议，建议了解下 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 这种单次验证码，则没关系，单次的验证码明文也可以、不怕泄露