Skip to main content

OKHK 👀

个人数字泔水\(⁠◔⁠‿⁠◔⁠)
Thinking...
  1. Google搜索常用技巧

    ❶ 双引号:搜索精确字串匹配。示例:"精确字串匹配"
    ❷ 减号:去除带有某些匹配的搜索结果。示例:海豚 -海豚湾
    ❸ 波浪号:模糊搜索。示例:音乐 ~网课
    ❹ site关键词:搜索特定网站内的结果。示例:AI site:x.com
    ❺ 竖号:搜索匹配A或匹配B的结果。示例:海豚 | 海豹
    ❻ 两个点:搜索数字范围的匹配。示例:电影 1980..2000
    ❼ filetype关键词:搜索特定文件类型。示例:拜登 filetype:pdf source

    #Google
  2. Top 10 common Dockerfile linting issues


    这篇文章分析了Depot平台上最常见的10个Dockerfile代码检查问题,基于hadolint和Semgrep工具的检测结果。文章详细解释了每个问题的成因、影响以及解决方案,涵盖了从镜像大小优化到安全性考虑的各个方面。这些问题包括多个连续RUN指令、版本固定、包管理优化等,旨在帮助开发者编写更高效、更安全的Docker镜像[1]。


    多个连续RUN指令问题:近30%的Dockerfile存在多个连续RUN指令,应合并为单个原子操作以减少镜像层数和大小。

    apt-get安装时版本固定:30%的Dockerfile未固定包版本,应使用具体版本号避免意外行为。

    使用--no-install-recommends标志:22%的Dockerfile未使用此标志,导致安装不必要的推荐包,增加镜像大小。

    pip安装时避免缓存目录:18%的Dockerfile未使用--no-cache-dir标志,造成不必要的缓存占用空间。

    清理apt-get列表:16%的Dockerfile安装包后未清理apt缓存,应在同一RUN语句中完成安装和清理。

    使用WORKDIR替代RUN cd:14%的Dockerfile使用RUN cd改变目录,应使用WORKDIR指令。

    pip包版本固定:13%的Dockerfile未固定pip包版本,应指定确切版本号确保构建一致性。

    CMD和ENTRYPOINT使用JSON格式:12%的Dockerfile未使用JSON数组格式,影响信号处理和容器正确关闭。

    使用apt-get替代apt命令:9%的Dockerfile使用面向用户的apt命令,应使用更稳定的apt-get或apt-cache。

    apk add版本固定:8%的Alpine基础镜像Dockerfile未固定apk包版本,应使用版本固定语法。

    #Docker #DevOps #Doc Top 10 common Dockerfile linting issues
  3. https://vxtwitter.com/Barret_China/status/1720837475390960059

    由于之前有过几次跟服务商/机构/平台/银行/医院/社区等对抗的经历,经常有人向我取经,如何投诉并获得胜诉,我想了想,也没有什么特别的技巧,关键在于:

    1)坚持不懈,持续刚。这一点比较重要,投诉是一件十分耗费时间、精力和耐心的事情,对方会软硬皆施,频繁跟你交互反馈,很多时候会因为事情已经结束或者丧失耐心而放弃投诉

    2)持续抽象问题,帮助对方归纳问题。投诉的焦点无非就是流程设计不当、机制设计不当、软件系统设计问题、服务态度问题等等,如果只把问题聚焦到自己的 case,那就是特事特办,属于小概率事件,对方一般不会引起重视;因此你需要收集证据,找到一两个共性案例,或者聚焦归纳到对方的痒点问题上,只有这样才能得到快速上升;另外,对应的处理机构也特别欢迎这种共性问题,性价比高

    3)适当利用公共资源,并行投诉。例如医院的问题可以反馈给院办,也有对应的地方卫健委,地方卫健委不给力还有市级、省级卫健委,市长热线也会接受此类问题,但它主要还是督办单位;一般来说,向上级部门反馈就不要单纯只说自己的问题,一定要抓住下级部门的小辫子,例如办事效率低、处理问题不公正、流程设计不恰当等等,再附带说说自己的事儿,更多还是达到催办效果

    4)保持理性,控制情绪,不要扩大叙事。要知道,电话对面也是人,上去就是一顿狂喷,问候祖宗十八代,对方就算是想帮助解决问题,也会产生抵触情绪,从而在态度和行动上有所折扣;叙事以后,结论要简洁,证据要客观,不要添油加醋,其实说的再多,对方记录的也主要是你的结论,包括期望的补偿方案

    以上,简要概括了几点。社会问题靠社会人解决,不要觉得投诉让人觉得自己刺头,要知道解决了自己的问题,其实也顺带解决了有相同遭遇的大众问题,鼓励投诉。

    不过有一个小小的建议:尽量不要针对某个人,而是针对流程、机制和合规性问题进行投诉。矛盾指向人,一般都是因为服务态度问题,心态可以放平一点,可能人家跟你沟通之前刚遭遇过什么不愉快的事情。😔

    #Life
  4. Cloudflare 在为期两天的故障后所有服务均已恢复至运行状态。

    省流助手:

    Cloudflare 三个核心机房之一的 PDX-04 机房由于电路故障下线。

    在 PDX-04 机房中,其中一家电力公司断电,机房电力由其他线路和发电机同时供电。

    随后由于变压器出现接地故障跳闸,机房的供电被切断,服务器由 UPS 供电。

    跳闸导致门禁系统失效,维修人员无法进入机房,随后 UPS 电池耗尽,整个数据中心停电。

    由于部分核心服务只在 PDX-04 机房上运行,从而导致 Cloudflare 多个服务出现故障。

    虽然我们尚未得到官方确认,但员工告诉我们,有三件事阻碍了发电机重新上线。首先,由于接地故障导致电路跳闸,因此需要对它们进行物理访问并手动重新启动。其次,Flexential 的门禁系统没有备用电池供电,因此处于离线状态。第三,现场的夜班人员不包括经验丰富的操作或电气专家——夜班人员包括保安和一名只上岗一周的无人陪伴的技术人员。

    详情请看:Cloudflare 的 Control Plane 和 Analytics 中断的事后分析

    #Cloudflare
  5. TUIC作者对于删库的回应,以下为摘抄:

    可笑的网民,可悲的开发者

    最近几天,clash for windows 停止了更新,clash core 的仓库也被作者删除了。这种事之前也发生过,但这次的后续真得既可笑又可悲。

    Clash 倒下后,不知网民们出于何种想法,将这件事的热度扩散到了微博上,甚至达到了微博热搜。你们真的有考虑过开发者吗?这件事的影响已远远超过了可控范围,有多少双眼睛在盯着微博热搜?其中又有多少不怀好意呢?

    大多数网名大概都是以吃瓜的角度在看这件事。没有人真的在为开发者着想,这真的非常可悲。你们如何证明 clash 作者以外的开源代理开发者们没有因为此次事件被特殊关注,人身安全受到威胁呢?

    我还是将大众想得太善良了。中国人的本性就是喜欢看别人的悲剧,除非火烧到自己,否则根本不会有觉悟。我觉得我不值得将自己的任何精力贡献给这样的群体,更何况我的人身安全也受到威胁。

    原文:https://www.eaimty.com/2023/opensource-project-based-on-hormone/

    Message link
  6. 截至目前,受影响工具列表统计如下:

    1. Clash.Meta「已archived」
    2. Clash Core「已删库」
    3. Clash for Windows「已删库」
    4. Tuic协议「已删库」
    5. Helloworld路由器插件「已删库」
    6. Gui.For.Clash「已删库」
    7. ClashForAndroid 「已删库」
    8. homeproxy 「已archived」
    9. ClashMetaForAndroid 「已archived」
    10. Fclash 「已archived」
    11. Clash verge 「已archived」

    #Clash
  7. Clash for Windows 删除其 Github 仓库托管的 Release 包,开发者表示停止更新 Clash for Windows 是由开发者 Fndroid 编写,基于规则的跨平台代理软件,目前支持的平台有 Windows、Linux、MacOS。

    几分钟前,开发者 Fndroid 删除了该项目仓库托管的 Releases 包,由于 Clash for Windows 并不开源,所以该 Github 仓库为其应用分发所用。

    开发者在其官方 Telegram 频道表示:

    停止更新了,江湖再见吧😅

    —— 项目地址
OKHK