前言
相对于其他操作系统，我更习惯使用 Windows，但一直以来 Windows 缺乏官方的包管理器，而第三方无论是 Scoop 还是 Chocolatey 都无法满足我独特的需求，我的要求很简单，所有的软件包都应该使用绿色解压模式，这包括了 MSI 安装包，另外安装软件时不应该修改系统和用户环境变量。包管理工具应该足够快，还要支持创建启动器等等。
前言
在我们日常使用计算机的时候，经常会遇到或者使用一些文件，它们通常以 .zip，.rar，.7z 结尾，这些文件就是本文所说的压缩文件，我们可以通过资源管理器，WinRAR，WinZip，或者 7-zip 将其解压，然后查看，编辑，或者进行其他操作。压缩软件被广泛运用于文件分享，软件分发，或作为一个容器承载其他文件集合，比如我们如果使用 Office 2007 以及更高的版本保存 Word/PPT/Excel 文档时，这些文档实际上就是特殊的 ZIP 压缩文件，Word/PPT/Excel 的格式实际上就是将描述元素（文本框，标题…） 信息的 XML 文件，以及一些资源文件使用 Deflate(Fastest) 压缩算法压缩到一个 ZIP 格式文件中。还有 Java 程序员需要经常见到的 Jar 包，Android 开发者打包的 APK 文件，以及 Windows 开发者创建的 Appx(以及 MSIX) 安装包，这些文件都是压缩文件，准确的说，这几种都是 ZIP 压缩文件。
前言
最近浏览 Windows Terminal 提交，发现其文档中链接了一个 PowerShell 的 Issue：Windows Store applications incorrectly assumed to be console applications ，这个问题描述起来很简单，就是在 PowerShell 中打开 wt.exe， PowerShell 会一直等待 Windows Terminal 的退出，但实际上 Windows Terminal 是一个 GUI 程序，按照 Windows 的默认行为，PowerShell 在创建 Windows Terminal 进程后，就应该返回。这个问题是怎么产生的，其实很简单，wt.exe 是 Windows Terminal 的 AppExecutionAlias，AppExecutionAlias 是一类特殊的重解析点，Windows 在创建进程时会根据 AppExecutionAlias 设施的信息启动对应的 Store App。那么 PowerShell 应当获得相应 Store App 的主程序的 Subsystem 才能正确的决定是否应该等待进程退出。因此这里获得其真实路径是必不可少的。
2019 年早已过去，这年下半年最显著的感受是肉价腾贵，11 月初，听闻凯哥来深出差，于周日邀请他来住所做饭吃。或是许久未吃过回锅肉，买菜的时候，凯哥特意要求称了一块价值 16 元的猪肉，单价 40 一斤。若做其它肉菜，本以为够哥俩吃一顿，但回锅肉却是需要分量的，那一顿吃的颇不尽兴。一周之后，在浪基住处又做了一次回锅肉，此时购买了两块共计四十块的猪肉，此次回锅肉依然没有吃尽兴，不过好在还有我带过去的腊牛肉，干豆角，小干鱼，以及主人家买的基围虾，秋葵，牛肉反而吃得尽兴。
关于 Git
版本控制软件种类繁多，维基百科收录的最早的版本控制系统是 1972 年贝尔实验室开发的 Source Code Control System。1986 年 Concurrent Versions System(CVS) 诞生，CVS 曾非常流行，但今时用之寥寥无几，不过 OpenBSD 仍在使用 CVS。2000 年 CollabNet 创建了 Subversion 项目，2009年，Subversion 被 Apache 基金会接受成为顶级项目并被命名为 Apache Subversion。2005 年 Linus Torvalds 创建了 Git，2007 Github 诞生后，Git 随着 Github 的发展愈发流行，14 年间，Git 成为了最流行的版本控制系统，无论是 Windows 还是 Linux 或是 Android，MySQL 等等大型软件都使用 git 进行版本控制。纵观版本控制系统流行史，前有 CVS 后有 SVN，今日 Git 更风流。俱往矣，数风流人物，还看今朝，版本控制系统莫不如斯。
前言
这篇文章的想法来源于我在 Windows Terminal Issue#146 的评论。
sudo 以另一个用户执行命令，通常是 root。当普通用户需要以其他权限执行某项工作时，通常需要获得指定用户的权限，以目标权限 root 为例，我们期望以 root 权限运行，可以使用 su 登录到 root 用户，在这种情况下，一直到退出 root。都使用的是 root 权限，这实际上并不是安全的，处于高级别权限的时间应当尽量的短。而使用 sudo 获得 root 权限要安全的多，这种情况下，只有特定的命令才会获得 root 权限，而不是整个用户和 shell. 话又说回来，sudo 是如何获得 root 权限的？在 Windows 中的 sudo 又是怎么一回事，如何在 Windows 中实现类似的 sudo.
背景
在 《Pro Git》 的 Server-Side Hooks 介绍了三种钩子，分别是 pre-receive 已经 update 还有 post-receive。GITEE 最初是基于 Gitlab 发展而来，最开始在服务端使用的是 update 钩子。我们使用 update 钩子完成一些保护分支/只读分支的功能。随着 Gitee 的不断发展，也有人提出了一些新的服务需求，为了解决大仓库大文件，我们开发了 Git Native Hook (GNK)。新的钩子利用了 git 的一些新的特性，在不同的阶段实现不同的功能，这里就介绍一下这些钩子的妙用。
背景
2019 年五月的 Microsoft Build 大会，微软宣布了 Windows Terminal，并在 Github 上开源：https://github.com/microsoft/terminal。我作为技术爱好者，肯定要尝鲜一番。
使用截图：
在使用的过程中，多标签，亚克力的窗口背景和 Colour Emojis 都让我非常满意，而且使用 Direct2D 绘制的 emoji，看起来要比 Mintty 使用 GDI+PNG 的 emoji 方案好的多（PNG 的 emoji 无论是放大和缩小都更容易失真，Mintty 并没有 Segoe UI 字体的 emoji 风格，其他风格我并不太喜欢）。不过我在使用的过程中发现了一个 BUG，即 Bug Report: The conhost command line is not properly escaped #1090 ，后来我又提交了一个 PR 修复了此问题，在研究其他软件源码时，我发现这个问题并不是个例，因此有必要对此问题进行一次讨论，便有了此文。
前言
写代码是一个不断积累的过程，将一些好的想法转变为解决实际问题的程序通常让程序员感到愉悦。而最近我也有两个还算好的想法，在本文中分享给大家。
支持环境变量展开的配置解析
在 Gitee 的基础服务组件中，像 Basalt (git ssh 服务器)，git-diamond (Gitee 内部的 git 协议服务器)，git-srv (Gitee 分布式 git 传输后端) 都支持这样形式的配置： ${APPDIR}/run/git-srv.pid 。在运行过程中，APPDIR 被解释成相应组件的安装根目录，在配置文件中，解析到 ${APPDIR}/run/git-srv.pid 后，使用推导函数，将其展开为 /home/git/oscstudio/run/git-srv.pid。这样一来，默认配置情况下，Gitee 的这些组件都支持安装到任意位置，而无需在编译时设置 --prefix。而像 nginx 这样的软件，在构建时，使用 --prefix 指定了安装目录后，如果不使用 -p 指定 prefix，是无法安装到任意位置的。
前言
今天在微博上看到了新浪科技的一篇微博，其主要内容如下：
#创事记#【用不胜其烦的update，将Windows用户捆绑上未来战车】网友苦Windows久矣。众所周知，Windows Update是很烦人的更新，其中以win10的用户最为水深火热。目前看来，用户还需要在一次次漫长而琐碎的更新升级中等待，而时代的洪流终会蜿蜒地书写出微软的对与错。@脑极体Unity Windows不胜其烦的update