最新

看起来ChatControl有相当大的可能性会被通过，这从根本上破坏了欧盟的隐私保护。我不禁想知道，如果它真的通过了，应该采取哪些步骤来保护自己的隐私？另外，应该如何告诉朋友和家人？因为不幸的是，似乎这并不是你一个人就能做到的。

我很好奇在Kubernetes上运行Java工作负载的人是如何处理JDK/JRE更新和安全补丁的，而不需要重建每个应用镜像。 背景：在使用[Mesos](https://en.wikipedia.org/wiki/Apache_Mesos)的时代，我们通常将JDK保留在运行节点上。当出现CVE或补丁时，我们会更新主机上的JDK，所有应用都会自动使用更新。这对于快速的安全发布非常方便。而在Kubernetes上，我看到几乎所有人都将JDK打包进容器镜像中，这意味着：新JDK → 重建基础镜像 → 重建应用镜像（或至少重建基础镜像）→ 推送 → 部署。这种方式可靠且可重现，但例如，对于2000个应用来说，快速更新JDK版本几乎是不可能的。 我对在Kubernetes上大规模运行Java的人有几个问题： * 你们会为每个JDK补丁重建镜像吗？ 如果会，你们是如何保持流水线快速和自动化的？ 我们讨论过的一些方法（仍在寻找更好的方案）： - 每次JDK补丁都重建镜像（CI流水线自动更新基础镜像并重建）：可重现但繁重且缓慢。 - 通过hostPath或共享卷提供主机JDK（类似Mesos）：补丁快速，但脆弱（节点漂移、Kubernetes节点间版本混乱、可重现性差、潜在的安全/权限问题）。 - 为所有Java应用提供基础标准镜像（alpine+java），由我们的平台进行更新，并在启动时通过init容器下载用户应用，这样我们可以在后台进行更新。 - 侧车或init容器将JDK放入共享卷中，应用容器使用该卷：可变运行时而无需重建镜像——在实践中效果如何？

构建了一个全功能的混凝土计算器套件：包括板、柱、基础、楼梯、圆柱、钢筋、立方码和袋数。显示材料组成（水泥/沙子/碎石）和可选成本。适合移动设备，客户端使用，免费。希望能收到关于覆盖范围（您需要的形状）和边缘案例准确性的反馈。