[Powershell] 无需安装软件,通过命令行监控 CPU 温度

我们知道 Windows 电脑没有监控 CPU 温度的功能,如果想知道 CPU 温度需要安装软件,比如鲁大师。

那么是否可以不安装软件,就实现 CPU 的温度监控呢?

以管理员权限执行如下 PowerShell 脚本:

方法一:

方法二:

参考链接


macOS双频蓝牙鼠标失联问题

前置条件

  • MacBook Pro 2023-Apple M2 Pro (4能效核、8性能核、32GB内存、2TB磁盘)
  • macOS Sequoia 15.5 
  • Lenovo ThinkLife 静音鼠标无线蓝牙版 WLM210

问题现象

蓝牙鼠标正常配对使用,刚刚开始使用正常的。但是过一阵子不使用蓝牙鼠标,或者鼠标电源调整成关闭状态,或者拔掉电池,大概率连接不上。需要在电脑上手工删除蓝牙连接,然后重新配对。

问题定位

刚开始猜测是鼠标使用的 南孚 TENAVOLTS  锂电池 DC-DC 降压电路释放的信号干扰到了蓝牙通信协议或者电压纹波导致芯片工作异常,在更换为普通的 1.5V 非充电电池之后,问题依旧复现。

无意中点击蓝牙设备列表,发现重新配对之后 Lenovo ThinkLifeMAC 地址变化了。这说明两者进行配对的时候使用了动态协商出来的临时 MAC 地址,没有使用设备的真实 MAC 地址。这样诱发一个问题,那就是鼠标需要记住这个动态协商出来的 MAC 地址,然后用这个地址进行通信。这样就能解释为什么拔掉电池多等一会儿,让设备完全放电,再插上电池很容易复现这个问题。因为长时间断电之后,设备上记录的协商 MAC 地址丢失了。

继续阅读macOS双频蓝牙鼠标失联问题

在 .htaccess 中配置强制UTF-8字符集

网站配置了 robots.txt 来控制爬虫的行为,由于文件里面有中文注释,导致直接浏览器打开之后中文显示乱码。

对于 Apache 服务器,可以通过在 .htaccess 中配置文件的字符集格式解决显示乱码问题。

Set universal UTF-8 encoding:

Set UTF-8 encoding on select file types only:

Note: An .htaccess file located in a sub-directory overrides any duplicate rules from previous .htaccess files. For example, if you have a .htaccess file located in the root defining a 404 and 403 error page, and another .htaccess located in the “test” folder defining only a 404 error page, any files and folders in the “test” folder will use the 404 page defined in the "test" .htaccess file, and the 403 page defined in the root .htaccess file.

参考链接


Forcing UTF-8 encoding with .htaccess

ARG to Rescue: Reuse Variables in Multistage Dockerfile

概要

在参照使用 Ubuntu 22.04使用Podman部署OpenGrok的详细教程 进行 OpenGrok 部署的时候,其中的 Dockerfile 配置了两个独立的镜像来源。恰好这两个镜像来源都需要配置 PIP 国内镜像。于是思考如何在同一个 Dockerfile 存在两个镜像的场景下,如果共用一个变量。

研究了一阵,发现还是通过 ARG 变量实现上述想法。

具体说明参考下面的完整文章。

Introduction

The Docker ecosystem is rich with tools and best practices that streamline containerization. One of these practices is using multistage builds to create lean, efficient containers. However, as your Dockerfiles grow more complex, managing variables and maintaining readability can become a challenge. Enter the ARG instruction—your key to sharing variables across stages in a multistage Dockerfile. In this blog post, we’ll explore how ARG can simplify your Dockerfiles, enhance reusability, and maintain cleaner code.

Why Use Multistage Builds?

Multistage builds in Docker allow you to use multiple FROM statements in a single Dockerfile, creating separate stages that can be used to build a final image. This method is particularly useful for creating lightweight production images, as you can copy only the necessary artifacts from earlier stages. Here’s a quick example to illustrate:

In this simple example, the build stage compiles a Go application, and the production stage creates a minimal image containing only the compiled binary.

The Challenge: Sharing Variables Across Stages

While multistage builds are powerful, they can introduce a common challenge: variable reuse. Suppose you need to use a specific version of an application or a common path across multiple stages. Without a way to share variables, you might end up duplicating code, leading to maintenance headaches and potential errors.

Here’s where ARG (argument) comes into play. The ARG instruction allows you to define variables that can be used throughout your Dockerfile, even across different stages.

Introducing ARG: The Basics

The ARG instruction defines a variable that users can pass at build time to customize the build process. Unlike environment variables (ENV), which are persisted in the image, ARG variables are only available during the build process and do not become part of the final image.

Let’s start with a basic example:

In this example, BASE_IMAGE is an argument that can be overridden when building the Dockerfile. The default value is alpine:3.12, but you could specify a different base image at build time:

Sharing ARG Variables Across Stages

The real power of ARG comes into play with multistage builds. To share ARG variables between stages, you need to redefine the ARG in each stage. Let’s look at a more advanced example:

In this Dockerfile, we define GO_VERSION as an argument at the top. By repeating ARG GO_VERSION in each stage, we make the argument available for use. Notice how the build stage uses GO_VERSION to specify the Go image, and the production stage echoes the Go version used.

Advanced Usage: Combining ARG with Environment Variables

You might find it useful to combine ARG with ENV to set environment variables conditionally based on build arguments. This can further enhance your Dockerfile’s flexibility.

Following example demonstrates the use of ARG and ENV to have a generic Dockerfile for a Turborepo application:

Key Points on Environment Variables in Multistage Builds
  • Environment Variables (ENV):

    • Are specific to the stage where they are defined.
    • Do not persist across stages.
    • If you need an environment variable in multiple stages, you have to redefine it or pass it via ARG.
  • Build Arguments (ARG):

    • Are defined once and can be passed to any stage by redeclaring them.
    • Provide a way to share configuration details like versions or paths between stages.

Debugging ARG Variables

When working with ARG variables, you might run into issues where arguments aren’t passed correctly or variables aren’t set as expected. Here are some tips to help you debug:

  1. Check Build Logs: Use docker build with the --progress=plain flag to get more detailed logs that can help identify where arguments are being used or missed.

  2. Echo Variables: Add RUN echo statements to print the values of your ARG variables during the build process.

  3. Use Default Values: Define sensible default values for your ARG variables to ensure that your build doesn’t fail if arguments are not provided.

Best Practices for Using ARG

  • Define ARG Variables Early: Place ARG instructions at the top of your Dockerfile to make them accessible in all stages.
  • Use Descriptive Names: Choose meaningful names for your arguments to make the Dockerfile easier to understand and maintain.
  • Avoid Secrets in ARG: Never use ARG to pass sensitive data like passwords or API keys, as they can be exposed in the Docker image history.

Conclusion

Using ARG to share variables across stages in a multistage Dockerfile can significantly improve your Docker builds’ maintainability and flexibility. Whether you’re building lightweight production images or dynamically configuring your builds, ARG provides a powerful tool to streamline and enhance your Dockerfile.

参考链接


Android升级AGP、minSdkVersion 23后APK包体积变大问题

AGP 4.2 后,默认关闭了 so 文件的压缩。

AGP 7.1minSdkVersion>=23 后默认关闭了 dex 文件压缩,app bundle 打包不受影响

现象

升级到 AGP7 之后发现打包出来的 APK 变大不少,差不多增加了三分之一的大小。将 APK 拖入 Android Studio 中分析对比下之前的 APK 发现主要 so 文件增大、dex 文件未压缩。

so 文件压缩

AGP 3.6 之后默认关闭了 so 压缩,声明为 true 就行了。

minSdkVersion < 23 或 Android Gradle Plugin < 3.6.0 情况下,打包时 android:extractNativeLibs=true;

minSdkVersion >= 23 并且 Android Gradle Plugin >= 3.6.0 情况下,打包时 android:extractNativeLibs=false;

或者

DEX 文件压缩

参考链接