Skip to main content

share

  1. 早晨 7 点到 9 点锻炼可能最有利于减肥

    2023-09-22 22:46 by 泰坦的女妖

    美国的一项研究发现,早晨 7 点到 9 点锻炼可能最有利于减肥。研究人员将 5285 名中年人基于锻炼时间分成三组,早上(7点到9点)、中午(11点到下午1点)、晚上(17点到20点),其中 642 人在上午锻炼,2400 人在中午锻炼,2187 人在晚上锻炼。结果表明,早晨组的 BMI 最低,为 25.9,中午组和晚上组的 BMI 分别为 27.6 和 27.2,处于超重范围。早晨组的腰围也最低,为 91.5 厘米,而晚上组和中午组的腰围分别为 95 厘米和 95.8 厘米。

    https://onlinelibrary.wiley.com/doi/10.1002/oby.23851
    https://news.sciencenet.cn/htmlnews/2023/9/509031.shtm

    #科学
  2. KDE 用户想要快捷键打开 LinkedIn

    2023-09-21 11:52 by 图书馆员与遗失的神灯

    The Verge 最近报道了微软在 Windows 中引入的一组奇特快捷键组合,可以快速打开 LinkedIn 或 Word 等微软办公软件:LinkedIn - CTRL + SHIFT + ALT + WIN + L;Word - CTRL + SHIFT + ALT + WIN + W;Excel - CTRL + SHIFT + ALT + WIN + X;PowerPoint - CTRL + SHIFT + ALT + WIN + P;Outlook - CTRL + SHIFT + ALT + WIN + O 等。桌面环境 KDE 的用户表示我们也需要对等功能,建议在 KDE 中引入快捷键打开 LinkedIn。这一建议得到了很多人的支持,但也有人反对,指出自由软件应该支持 LinkedIn 的 FOSS 替代。

    https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1731
    https://www.theverge.com/2023/9/15/23874798/microsoft-windows-linkedin-onenote-keyboard-shortcut

    #KDE
  3. #文章
    恒纪元与乱纪元》,很棒的一篇文章,以时间为纵轴,横向对比了从16世纪大航海时代以来东西方的历史和文明进程,列举了自那以来的数个大分裂、大发展时代及其原因,要是有视频结合着文章解读就更好了。

    按照文章的说法,最后一次恒纪元是1992-2017年,做为80后的一代,成长的年代完全赶上了这个纪元。按说我们应该就是那波吃到时代红利的人,可在我20多岁的时候,当时经常想的是:父母那代人(50后)因为时代的原因没有得到很好的教育、到了工作后在90年代又面临着下岗、自己这代人则是初代独生子女、读大学开始涨价、房价开始飞起....所谓时代红利,这都是后话,当时身处其中,一样也对社会有很多的迷茫、不满,看来每代人在这个年纪的状态都是差不多的。我到了现在这个年纪再回头去看,从1840年鸦片战争之后的中国近代史,我们这代人没有赶上战争、大饥荒、国家剧烈动荡等,还赶上了改革开放国家大发展,确实是运气很好的一代人了。

    以文中的划分,当前处于从2018年中美贸易战开始之后的一次乱纪元,所谓“百年未有之大变局”,吃上时代红利的我,人到中年也赶上了这次乱纪元,就我个人而言,暂时能想到的办法不多,目前大的方向是:多屯粮(存钱)、去杠杆(最近还了一波房贷)。
  4. 有一点我还挺有感触,就是在中国很难有社区感,主要是因为中国政府是不允许有民间的力量。

    中国有一点最让我不能接受的是租售不同权,在全球大多数国家,租房和买房的权利是相等。这会导致,虽然我在这里纳税、生活、消费,但这里的好处、优势、未来,都和我没什么关系。

    对于我们这些在大城市打工的年轻人,虽然门对门,但根本不会有什么交际,很熟悉又很陌生。

    可能灵感买家是让我意识到,社区的氛围到底应该是什么样子,大家到底会因为什么聚集在一起。之后我在 telegram 建立各种社群,尝试各种主题,想在 telegram 建立一种社区。

    在海外重建社区。
  5. 〔译序〕我的孩子被你弄成了残疾

    我把自己翻译的每一本书都珍视为自己的孩子,除了在译稿上字斟句酌,还会献上一篇热情洋溢的译者序。像是新近出版的拙译《隐蔽的宇宙》一书,早在一年前还没开始翻译时,我就已经构思好了译者序的开头。然而,最终的书里却没有译者序。原因在本文题目里已经挑明,鉴于该书译文遭到了出版方的严重删改,我绝无可能写序来对这样的残次品进行推介,如果本书非要有一篇译者序,那大概就是本文的模样——将产品的残次之处逐一列出,供读者参考,留历史见证。

    我想,每一位有责任心的“责任”编辑,每一位身为读书人的做书人,都是把书当作自己的孩子来呵护的,遇到不得已而为之的删改,那也是采取绝不多删一字的原则。于是,当我看到《隐蔽的宇宙》编辑发来的审校样里,大片大片的大笔一圈就把一整句、一整段甚至一整页的文字给轻巧地删掉的笔迹时,我出离愤怒了,我不相信这是读书人和做书人能干出来的事儿。关键是,我压根就没想到,这样一本主题是“生物多样性”的人畜无害科普书,竟然会遭删改。

    回过头来看,这家出版方的缺点和优点是一体两面的,为着同一个目的服务:尽可能地提高效率并降低风险,实现做书的利益最大化。只是,在这样做的过程中,你们完全无视了书作为“人类进步的阶梯”这一精神属性。须知,在越来越少的人会读书,越来越少的好书能被读到的今天,情怀、良知、道义、担当这样的大词真的构成了一个人乃至一群人坚持做书的重要支撑,否则该有多少比做书更挣钱的活计可以干啊。而你们,却把一本好书给这样糟蹋了。我不会再与你们合作。

    https://mp.weixin.qq.com/s/EhW1Un4Tx7BBu_A0Nc-oJw
  6. 即使root也无法修改系统证书是假的。
    把证书库移动到apex是好事,这可以让OEM不再更新的手机继续更新系统证书。比如之前Let's Encrypt的R3证书无法推送到不再更新的手机,现在可以了。
    而root是可以修改/apex目录的,和/system没有技术上的区别。作为例子,lsposed的dex2oat包装器就修改了apex的art组件。
  7. Android 14 将禁止对系统证书的修改

    2023-09-05 23:43 by 爱的左边

    Android 操作系统正日益封闭,最新的 Android 14 将进一步限制对系统证书的修改。Google 是从 2016 年发布的 Android 7(Nougat)起将设备上信任 CA 列表的权力从用户转移到设备供应商和第三方应用开发者。以前 Android 系统允许用户创建自己的 CA 并信任它,拦截设备上的 HTTPS 流量,查看设备上正在发送和接收的内容,可以进行修改或阻止。即将在未来几个月释出的 Android 14 将 CA 证书的管理转移到了一个独立更新的组件,由 Google Play 提供更新。一方面它对普通用户的安全是好事,但另一方面它进一步限制了开发者,即使 root 设备也将无法修改系统证书。

    https://httptoolkit.com/blog/android-14-breaks-system-certificate-installation/

    #安全
  8. Google 从用户私人保存的链接中删除“盗版”网址

    Google 通常会根据 DMCA 的要求,将大部分被举报的链接从 Google 搜索中删除。不过,最近 Google 似乎更进了一步,审核了用户私人保存的链接集合,这意味着收到的 DMCA 通知将会影响人们私下保存的链接。

    几天前,Mastodon 网友收到 Google 的一封邮件,通知他某个链接已从他的 Google 收藏中删除,因为违反了 Google 的政策。

    最初,有人认为此删除影响了 Chrome 书签,但进一步的研究表明情况并非如此,这些删除仅适用于 Google已保存功能。这项 Google 服务允许用户保存和整理搜索到的内容,这些链接集合可以是私人的,也可以与第三方共享。

    值得注意的是,Google 的搜索内容政策也适用于这些保存的链接。因此,Google 收到 DMCA 通知,并从搜索结果中移除网址后,这些链接将不能保存到收藏中。这可以复现,当用户使用 Google 移动应用访问Yout.com、1337x.to、thepiratebay.org,并点击右上角收藏后,返回首页,用户会发现在已保存里是没有刚刚收藏的网址。

    Google 为保存的链接执行搜索策略的原因尚不清楚,以及是否防止侵犯版权是主要目标。目前,受影响相对有限,因为已保存功能并没有被广泛使用。然而,如果谷歌决定“审核”用户的 Chrome 书签或其 DNS 解析器,事情可能会变得有趣。

    —— torrentfreak
  9. 我宣布这个频道是哈欠频道,看到这条Post的小伙伴都来和猫猫一起打个哈欠,多眨眼多动动
  10. nginx 的默认服务器这么写,可以实现 http 无 Host 时直接断开连接,https 无 SNI 时返回 ERR_SSL_UNRECOGNIZED_NAME_ALERT,同时 http 请求错误地发到 https 端口时也会直接断开连接。
    server {
      server_name _;
      listen 80 default_server;
      listen 443 ssl http2 default_server;
      ssl_reject_handshake on;
      error_page 497 =444 /;
      return 444;
    }