Mithril 最近的时间轴更新
Mithril

Mithril

V2EX 第 171951 号会员,加入于 2016-05-06 14:47:41 +08:00
今日活跃度排名 4973
根据 Mithril 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
Mithril 最近回复了
19 小时 31 分钟前
回复了 tlerbao 创建的主题 问与答 脑袋一热从抖音买了护肝片,这配料有用吗?
最后俩是有用的,B 族维生素药房买,小白瓶几块钱 100 片。
因为你姿势不对,所以不建议你久坐和搬东西。

很多人搬东西的时候会弯腰,实际上那就全靠腰椎受力了。就像你去钓鱼,起杆的时候靠鱼竿弯曲的弹力拉起来。坐的时候也是一样的。

建议你去找找“硬拉”的教学视频看看,不是说你要去练这个,而是看看一个标准的“拉起重物”姿势是个什么样的。
主要就是腰腹的核心要收紧,蹲下去,背挺直。然后靠腿发力蹬地站起来。你的整个背阔肌帮助锁定背部一直处于一个挺直的状态,这样你的脊柱受力方向就近乎它的垂直方向,腰椎不会弯曲受力,就不容易受伤。

但这样的动作你不习惯就会觉得很累而且别扭,但这就是你生活中避免腰伤的办法,还是多学一下比较好。
它是操作系统进程调用逻辑的一部分,并不是什么没用的东西。

当你的 CPU 没啥任务要执行的时候,操作系统就会把一个最低优先级的 Idle 线程扔过去跑。你看到的结果就是有这个 Idle 的东西占了 CPU 。

这个线程除了占用空闲的 CPU 以外,还会执行很多别的功能。比如它占用 CPU 的时候,使用 HLT 等指令让 CPU 处于低功耗状态。而且你不用在你的内核里专门写个特殊状态的处理,毕竟这个 Idle 可以设计成和其他线程差不多的样子。

很多系统都有这么个东西,区别只是显示不显示出来而已。
显示出来,你就可以直接用它判断当前系统是不是处于空闲状态。
不显示,你得把所有的加一起才能算出来占用率。
公司开发产品的时候,任何沾了 GPL 三个字母的第三方库都不要碰。

GPL 就不说了,AGPL ,LGPL 的边界定义的一样不清楚。所以最好的办法是,当你有疑问时,只要有这三个字母的全不要碰。
符合规定的。

我仔细看过,JetBrains 的 Individual License 要求是,必须是你自己付款,而不是公司付款,且不能跟其他人分享。但你可以在公司或者在家使用你的 License ,并不受使用环境限制。

你可以看官方的解释
https://sales.jetbrains.com/hc/en-gb/articles/207240855-Can-I-use-my-personal-license-at-work-and-at-home
https://sales.jetbrains.com/hc/en-gb/articles/207241015-Can-I-use-my-personal-license-for-commercial-development
https://www.jetbrains.com/store/comparison.html#LicenseComparison
你觉得这个距离够你变道,具备并线条件。他觉得不够,不想让你插进来。
所以要加速不让你进来。

这很正常。

不是说你想变道后车就一定要让你变道的,路权在他那。
@10RR 包含意外的。
但问题是,什么是“意外损坏”是他们定义的。就我的情况,他们的意思是你这个不算“意外损坏”。有划痕只算“正常使用痕迹”,不在 AC+覆盖范围内。

对,哪怕这个划痕已经看不清屏幕了也不算。

AC+这东西和保险差不多,卖你的时候啥啥都好,等你想要出险的时候就是这也不保那也不保。AC+里有用的就意外损坏和换电池。
什么叫意外损坏由他们定义
换电池你就更别想了,直接锁死 80%,你正常一天一充,用几年都不会到 80 以下。哪怕你自己体感续航尿崩那也是 80%。

所以除非毛手毛脚经常摔东西的人,其他朋友问我从来不推荐买 AC+。
王府井我去的不多,但至少三里屯的就是这样的。

我本身有 AC+的 Watch ,意外摔了一次表面刮花非常严重,表盘上字都看不清了。我去了以后跟我说这算正常使用痕迹,不在维修范围内。但我买 AC 不就是为了防意外吗?

然后我当场抵价买了个新款,反正你算正常使用痕迹,不能额外扣我钱。

但从哪以后除了给父母更新设备以外,自己再也没买过苹果的东西。
如果你用的阅读软件支持命令行调用,可以写个脚本循环打开看看能否调用成功就行了。

不支持的话,随便用什么编程语言,调用个 PDF 库尝试打开一下,然后随便读取点啥。能读出来就算打开成功。
自己装个 TeamCity 就行了,免费的 3 个 Agent ,100 个编译配置。除非你几十个项目,不然差不多也够用了。
主要是你用了 Jenkins 再去看 TeamCity 就知道差距了,但毕竟是开源,能用就行。

Jenkins 最麻烦的就是它赖以生存的开原生态。本身功能不多,大部分都靠插件。但开源插件维护全靠爱发电,很多插件早就不维护了。可能你这个版本配置完了都能用,然后过几个版本你发现之前几十个项目依赖的插件不更新了,那你 Jenkins 也没法更新。但 Jenkins 不更新又用不了新的插件。
整个锁死在里面。

所以现在都推荐用 Docker 这套生态来做,CI 工具实际就做个调度而已。哪怕你 CI 彻底完蛋,只要你用来编译的镜像还在,换个 CI 重新写个调度配置也一样能跑。

传统的 CICD 工具基本就这俩推荐,当然你要用 Gitlab 管代码的话,装个 Runner 也能跑。前提是你接受纯配置文件的套路。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3867 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 10ms · UTC 10:31 · PVG 18:31 · LAX 03:31 · JFK 06:31
Developed with CodeLauncher
♥ Do have faith in what you're doing.