利用开源 Sandboxie-Plus 为 Windows 桌面程序创建隔离沙箱环境 守护隐私 保持系统干净整洁

利用开源 Sandboxie-Plus 为 Windows 桌面程序创建隔离沙箱环境 守护隐私 保持系统干净整洁

Sandboxie-Plus 是什么 官网:https://sandboxie-plus.com/ GitHub:https://github.com/sandboxie-plus Sandboxie 是一款最早发布于 2004 年的老牌 Windows 沙盒软件,它可以创建一个隔离环境,在其中安装、运行程序而不影响沙盒外的文件。2020 年起,Sandboxie 转交开源社区维护。 Sandboxie-Plus 是开源社区基于 Sandboxie 开发的增强版本,拥有基于 Qt 的现代 UI 和开源后添加的所有新功能。Sandboxie-Plus 可以创建多个沙盒,可以为每个沙盒提供快照管理器、精细的文件系统控制、权限控制和网络访问控制。可以对沙盒内程序限制网络访问、限制资源访问(文件、注册表等)、限制提权、阻止访问剪贴板等。 Sandboxie-Plus 的第一个 1.0 稳定版发布于 2021 年 12 月 25 日,目前还在积极开发中。经笔者测试,目前的最新版 1.0.7 在 Windows 10 和 Windows 11 下都能正常使用,在 GitHub 上反馈的问题基本都能得到响应和修复。得益于热心的贡献者,UI 上的大部分元素都有中文翻译。 快速入门 Sandboxie-Plus (非便携模式) 默认将沙盘配置文件存放在 C:\Windows\Sandboxie.ini,备份此文件即可备份所有沙盘的配置。沙盘文件目录在 C:\Sandbox\[当前用户名]\[沙盘名] 中,在此路径下双击打开任何软件都将强制在沙盘中打开。沙盘中程序创建、修改的注册表位于 HKEY_USERS\Sandbox_[当前用户名]_[沙盘名] 中。当然,这些路径都可以在「设置-高级选项」中修改。 安装完成后还可以可选的在文件资源管理器右键菜单中添加「在沙盘中运行」项,方便使用。注意,这个文件必须要在你选择的沙盘中可读取,否则沙盘会报错。 在沙盘中运行程序与直接运行几乎没有区别,默认情况下在标题会有 [#] 标记,以及在鼠标移到标题时显示黄色边框,这些外观样式都可以在对应沙盘选项中修改。 ⚠️警告:不要认为隔离是100%的,即使虚拟机都存在被逃逸的可能,追求完美请使用物理方法隔离,不要尝试在沙盘中测试病毒! 沙盒模板简单介绍 部分功能需要捐赠,详见下方「捐赠获得支持者凭证(Supporter Certificate)」 Sandboxie-Plus 默认的 DefaultBox 即为标准隔离沙盒。这个沙盒模板默认不限制对所有文件的读取,但沙盒内程序无法写入、修改、删除沙盒外的文件、注册表。在沙盒内创建的文件会被重定向到该沙盒目录中,修改文件会在沙盒目录中创建一个副本进行修改,删除文件会在沙盒目录中建立一个对应的0字节文件。 安全防护加固型沙盒是在标准隔离沙盒的基础上,加上勾选「常

美团二面:Redis与MySQL双写一致性如何保证?

美团二面:Redis与MySQL双写一致性如何保证?

前言 四月份的时候,有位朋友去美团面试,他说被问到Redis与MySQL双写一致性如何保证? 这道题其实就是在问缓存和数据库在双写场景下,一致性是如何保证的?本文将跟大家一起来探讨如何回答这个问题。 公众号:捡田螺的小男孩 github地址,感谢每一颗star 谈谈一致性 一致性就是数据保持一致,在分布式系统中,可以理解为多个节点中数据的值是一致的。 强一致性:这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往对系统的性能影响大 弱一致性:这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态 最终一致性:最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型 三个经典的缓存模式 缓存可以提升性能、缓解数据库压力,但是使用缓存也会导致数据不一致性的问题。一般我们是如何使用缓存呢?有三种经典的缓存模式: Cache-Aside Pattern Read-Through/Write through Write behind Cache-Aside Pattern Cache-Aside Pattern,即旁路缓存模式,它的提出是为了尽可能地解决缓存与数据库的数据不一致问题。 Cache-Aside读流程 Cache-Aside Pattern的读请求流程如下: 读的时候,先读缓存,缓存命中的话,直接返回数据 缓存没有命中的话,就去读数据库,从数据库取出数据,放入缓存后,同时返回响应。 Cache-Aside 写流程 Cache-Aside Pattern的写请求流程如下: 更新的时候,先更新数据库,然后再删除缓存。 Read-Through/Write-Through(读写穿透) Read/Write Through模式中,服务端把缓存作为主要数据存储。应用程序跟数据库缓存交互,都是通过抽象缓存层完成的。 Read-Through Read-Through的简要流程如下 从缓存读取数据,读到直接返回 如果读取不到的话,从数据库加载,写入缓存后,再返回响应。 这个简要流程是不是跟Cache-Aside很像呢?其实Read-Through就是多了一层Cache-Provider,流程如下: Read-Through实际只是在Cache-Aside之上进行了一层封装,它会让程序代码变得更简洁,同时也减少数据源上的负载。 Write-Through Write-Through模式下,当发生写请求时,也是由缓存抽象

使用 Kind 搭建你的本地 Kubernetes 集群

使用 Kind 搭建你的本地 Kubernetes 集群

Kind 是我很喜欢也一直在参与的项目,我计划将 Kind 相关的文章写成一个系列。(flag++) 这是第一篇。 Kind 介绍 Kind 是 Kubernetes In Docker 的缩写,顾名思义是使用 Docker 容器作为 Node 并将 Kubernetes 部署至其中的一个工具。官方文档中也把 Kind 作为一种本地集群搭建的工具进行推荐。 安装 二进制安装 Kind 使用 Golang 进行开发,在仓库的 Release 页面,已经上传了构建好的二进制,支持多种操作系统,可直接按需下载进行使用。 e.g. # 下载最新的 0.2.0 版本 wget -O /usr/local/bin/kind https://github.com/kubernetes-sigs/kind/releases/download/0.2.0/kind-linux-amd64 && chmod +x /usr/local/bin/kind 复制代码 通过源码安装 如果你本地已经配置好了 Golang 的开发环境,那你可以直接通过源码进行安装。 e.g. go get -u sigs.k8s.io/kind 复制代码 运行完上述命令后,会将 kind 的可执行文件放到 $(go env GOPATH)/bin 文件夹内,你可能需要将此目录加入到 $PATH 中。 或者也可以先 clone 源代码再通过 go build 进行构建。 依赖 Kind 的主要功能目前需要有 Docker 环境的支持,可参考 Docker 官方文档进行安装。 如果需要操作集群,则需要安装 kubectl 命令行。安装方法可参考官方文档 搭建单节点集群 以下的演示均使用最新的代码(即通过源码安装)。 基础用法 搭建单节点集群是 Kind 最基础的功能。 e.g. master $ kind create cluster --name moelove Creating cluster "moelove" ... ✓ Ensuring node image (kindest/node:v1.13.4) 🖼 ✓ Preparing nodes 📦 ✓ Creating kubeadm config 📜 ✓ Starting control-plane 🕹️ Cluster creation complete. You can now use the cluster with: export KUBECONFIG="$(kind get kubeconfig-path --name="moelove")" kubectl cluster-info 复制代码 以上命令中, --name 是可选参数,如不指定,默认创建出来的集群名字为 kind。 我们根据命令执行完的输出进行操作: master $ export KUBECONFIG="$(kind get kubeconfig-path --name="moelove")" master $ kubectl cluster-info Kubernetes master is running at https://localhost:34458 KubeDNS is running at https://localhost:34458/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. master $ kubectl get nodes

Dockerfile 中命令的两种书写方式的区别

Dockerfile 中命令的两种书写方式的区别

最早的初衷是要研究一下运行 Docker 容器时如何向其传递参数,却冷不防掉入了另一个深渊,不得不关心起 Dockerfile 中命令(包括 RUN, CMD 和 ENTRYPOINT) 的两种不同写法上的区别。 所以呢,先要稍稍了解一下 Dockerfile 中 RUN, CMD, ENTRYPOINT 这三个指令 RUN 执行命令并创建新的镜像层,常用于安装软件包。可以多个,为避免创建过多的镜像层,我们尽量把命令合在一起,用分号或 &&。它与容器运行期无关。 CMD 设置容器启动后默认执行的命令及其参数,但 CMD 能够在启动容器时被覆盖。多个 CMD 只有最后一个是有效的 ENTRYPOINT 配置容器启动时运行的命令。多个 ENTRYPOINT 也是只有最后一个有效 关于以上三个命令的区别,这儿有篇文章讲得很清楚 RUN vs CMD vs ENTRYPOINT - 每天5分钟玩转 Docker 容器技术(17),此处也照搬了些文字。 RUN, CMD 和 ENTRYPOINT 都支持两种写法,即 exec 和 shell 格式,见 Dockerfile reference #ENTRYPOINT 对这两种方式的解释。RUN 只影响如何构建镜像,所以镜像中不保留 RUN 命令。CMD 和 ENTRYPOINT 都可以在运行容器时执行命令,这里不讲述它们间的区别,而要说的是它们所支持的 exec 和 shell 两种格式的写法。此篇以 ENTRYPOINT 为例说明两种格式的区别,CMD 类似。 exec 格式 ENTRYPOINT ["executable", "param1", "param2"] 必须清楚了解命令 "executable" 的每一个参数,一个萝卜一个坑,不能随便乱拆与合并。例如执行 jar 文件的命令 java -Xmx256M -jar /app.jar 写成 exec 格式就是 ENTRYPOINT ["java", "-Xmx256M", "-jar", "/app.jar"] 而不能写成 ENTRYPOINT ["java", "-Xmx256M", "-jar /app.jar"] 否则 docker run 运行它时出错 Unrecognized option: -jar /app.jar Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. "-jar" 和 "/app.jar" 分别是两个参数。 exec 格式是一种数组形式,该格式的 ENTRYPOINT 能接收 CMD 或 dock run <image> 后的参数作为附加参数,相当于是往这个数组中附加元素。例如 Dockerfile 中写成 ENTRYPOINT ["echo", "Hello"] 假设置构建出的镜像名(repository) 是 test(以下都以 test 作为镜像名称), 那么执行下面 docker 命令 $ docker run test World and China 输出是 Hello World and China 使用 exec 格式的 ENTRYPOINT 与 CMD 同在时还能接收 CMD 送过来的参数,如 Dockerfile ENTRYPOINT ["echo

开启String去重XX:+UseStringDeduplication的利与弊

开启String去重XX:+UseStringDeduplication的利与弊

首先来看下由JDK开发组研究得出的一组有趣的统计数据: 1.java应用内存里面的字符串占比大概是25%。 2.java应用内存里面的字符串有13.5%是重复的。 3.字符串的平均长度是45。 由于存在重复字符串导致高达13.5%的内存被浪费了!你可以用HeapHero来分析看下你的应用中有多少内存是因为重复字符串被浪费掉的。 什么是重复字符串呢? 看下面的代码: String string1 = new String("Hello World"); String string2 = new String("Hello World"); 1 2 上面定义了两个字符串对象string1和string2,它们的内容是一样的,都是Hello World,但是string1和string2是两个不同的对象。string1.equals(String2)=true,但是string1==string2=false,string1和string2就是所谓的重复对象。 为啥有这么多的重复字符串? 应用中存在重复字符串的原因有很多种,下面我们来看下常见的两种情况: 1.开发者为每一个请求都创建新的字符串对象,而不是使用诸如public satatic final String 来重复利用他们,上面的例子可以用以下方式进行优化: public static final String HELLO_WORLD = "Hello World"; String string1 = HELLO_WORLD; String string2 = HELLO_WORLD; 1 2 3 2.假如你正在开发一个银行或者电商系统,数据库中的每一笔交易记录都需要存储货币名称(‘USD’, ‘EUR’, ‘INR’, ….),现在有一个用户登陆了系统然后查看历史的交易记录,因此你的应用需要从数据库中读取这个用户的所有交易记录。如果这个用户是在美国,因为每一笔交易都有货币,因此你的应用需要为每一笔交易都创建USD这个字符串,如果这个用户有成千上万比的交易,你的应用就需要为这一个用户在内存中创建成千上万个USD字符串。 与此类似,应用还需要多次从数据库中读取很多列(用户名、地址、状态、联系方式等等),这个过程中也会产生重复对象。你的应用通过JSON/XML跟外部进行交互的时候,会进行大量的字符串操作,也会产生大量的重复字符串。 JDK开发组很早就注意到这个问题了,因此后来也产生了很多解决方案,最新的解决方案就是使用XX:+UseStringDeduplication参数。 -XX:+UseStringDeduplication 花最小力气去掉重复字符串的办法就是使用XX:+UseStringDeduplication参数,当在JVM启动时传递了这个参数的时候,JVM在做GC的同时会做重复字符串消除。GC的时候,JVM会检查内存中的所有对象,然后识别出重复的字符串对象并消除之。 是不是意味着只要给JVM传递XX:+UseStringDeduplication就

联系我们

联系电话

4000-640-466

联系邮箱

service@f-li.cn

办公地址

上海黄浦区外滩源1号

谢谢,您的信息已成功发送。
请填写信息。