上网查了好多资料关于超级签名的原理以及系统，大部分归为两大类：

一、市面上美其名曰自动化的系统很多，但是基本都是依靠第三方工具，像内测侠啊、开心签名工具啊，每年基本都得交1000多块钱，而且还有下载次数限制。然后我试用了市面上的蒲公英或者其他工具，都是需要appid账号和密码还要允许登录，我猜测蒲公英的是在mac电脑上搭建了服务器，然后通过linux服务器控制mac，mac可能是托管了服务器，或者是自家有服务器mac server机房什么的，才能商用。

二、照抄，如下图。这种方式就只能自己玩玩，小公司玩玩，不适合商用，缺陷太明显，只能在mac上运行，不过可以在局域网内部署这种，方便测试。代码从某书那里花2k买的，买了之后才发现被坑了，只能在mac下运行

下载链接

今天就来帮大家解析一下其中的门门道道，以及这套机制的技术难点。

签名原理

签名原理其实就一句话，使用了苹果提供给开发者的Ad-Hoc分发通道，把安装设备当做开发设备进行分发。

既然签名用是 Ad-Hoc ，那么 Ad-Hoc 所具有的优劣势也一并继承了下来：

优势：

直接分发，安装即可运行，不需要用户做企业证书的信任操作

目前稳定，不会有证书吊销导致的业务风险(后续苹果政策风险非常高)

缺点：

单开发者账号的iPhone设备数量只有100个，导致分发成本非常高(99美元/1年/100个设备)

开发者账号需要预先写入安装设备的UDID，在工具链不通的情况下，获取用户的UDID相对困难和繁琐，而且手动写入UDID不存在商用可行性，当然目前这个缺点被解决了

整体架构

接下来我们就看看整套机制是如何进行的：

设备安装描述文件后，会向服务器发送设备的UDID。

服务器收到UDID后，将UDID注册到某个开发者账号下。

再生成签名用的描述文件，给IPA签名。

然后iPA传Server，使用itms-services方式让用户下载。

技术细节

使用配置文件获取UDID

苹果公司允许开发者通过IOS设备和Web服务器之间的某个操作，来获得IOS设备的UDID(包括其他的一些参数)。这里的一个概述：

在你的Web服务器上创建一个.mobileconfig的XML格式的描述文件；

用户在所有操作之前必须通过某个点击操作完成.mobileconfig描述文件的安装；

服务器需要的数据，比如：UDID，需要在.mobileconfig描述文件中配置好，以及服务器接收数据的URL地址；

当用户设备安装描述文件后，设备会回调你设置的URL，如果你的URL返回302跳转的话，Safari浏览器会跳转到你所给的地址；

Apple Developer Center 自动化工具

接下来的关键点就是如何在获取到用户的UDID之后，秒级完成注册新的开发者设备+更新Provisioning Profile的。这里我们需要借助开源工具(Spaceship)：

Spaceship公开了Apple Developer Center的API，而且执行速度比解析开发者Web页面快两个数量级，从而在非常短的时间内搞定Provisioning Profile。这个框架解决了整套机制的关键问题，成为整个工具链的基石。其实某平台早就完成了UDID获取和应用签名分发的技术储备，只差这套API。

下面是解析开发者Web页面和直接访问API的速度对比图：

Cool!!!!!!! 非常棒！再次为Spaceship鼓掌????

如何自动签名封包

此处其实应该有一万个解决方案，通过命令行脚本/Python脚本/或者其他第三方都能实现。

这里推荐使用Sigh这个框架来解决这个问题。

Sigh的用法和配置都非常简单，一个纯命令工具，丰富的配置选项(自行查阅文档)，活跃的社区，完全够用了。

直接上演示图：

OTA 分发已签名的应用

emmmm 此处也应该有一万个解决方案，那就选择AppDeploy吧。入选原因非常简单，这个框架有Logo(看脸的社会就是那么真实…)。

可视化部署流程如下图(同时支持命令行调用)：

结语

通过开源社区的力量，我们成功搞清了整个机制上的关键技术点，必须要说fastlane团队非常优秀的提供了工具链关键一环(Spaceship)，从而使Ad-Hoc自动分发成为可能。

苹果对于App的分发审核管控可以说是非常严苛，这背后既有安全考虑，也有垄断利益。但无论如何，对于终端用户都是利大于弊的措施，App审核保护了无数的手机用户免受恶意程序的侵害。个人强烈反对这种绕过审核的分发形式。同时我要指出，分发平台以这种情况绕过苹果的审核是严重违反APPLE 开发商计划许可协议的3.3.3条款：

未经 Apple 预先书面核准或依照第 3.3.25 条 (In-App Purchase API) 得到允许，应用程序不可经由 App Store、Custom App Distribution 或 TestFlight 以外的分销渠道提供、解锁或激活附加的特征或功能。

开源工具链

获取设备UDID的第三方库：

下载链接

Apple Developer Center 自动化工具：

下载链接

自动签名封包工具：

下载链接

OTA 分发应用工具：

下载地址

三、企业签名的话就简单多了，github上很多开源的mac工具。

工具:Apple Configurator 2 Mac系统

关于OC 的内存管理有很多模糊的地方，下面我们一一说起
首先概念性问题

概念
为什么进行内存管理
由于移动设备的内存*其有限，所以每个APP所占的内存也是有限制的，当app所占用的内存较多时，系统就会发出内存警告，这时需要回收一些不需要再继续使用的内存空间，比如回收一些不再使用的对象和变量等。

内存管理类型： OC 类型

基本类型和C语言的类型：如：
int,short,char,struct,enum,union等类型
OC类型：任何继承于NSObject对象都属于OC的类型。

我们讲的内存管理实际上是对OC类型的内存管理，它对基本数据类型和C语言的类型并不管用。

原因: 因为对象和其他数据类型在系统中的存储空间不一样，其它局部变量主要存放于栈中，而对象存储于堆中，当代码块结束时这个代码块中涉及的所有局部变量会被回收，指向对象的指针也被回收，此时对象已经没有指针指向，但依然存在于内存中，造成内存泄露。

对象的基本结构

每个OC对象都有自己的引用计数器，是一个整数表示对象被引用的次数，即现在有多少东西在使用这个对象。对象刚被创建时，默认计数器值为1，当计数器的值变为0时，则对象销毁。
在每个OC对象内部，都专门有4个字节的存储空间来存储引用计数器。

管理方法

Objective-C的内存管理主要有三种方式ARC(自动内存计数)、手动内存计数、内存池.

引用计数器的作用

判断对象要不要回收的唯一依据就是计数器是否为0，若不为0则存在。

对象的销毁

当一个对象的引用计数器为0时，那么它将被销毁，其占用的内存被系统回收。

当对象被销毁时，系统会自动向对象发送一条dealloc消息，一般会重写dealloc方法，在这里释放相关的资源，dealloc就像是对象的“临终遗言”。一旦重写了dealloc方法就必须调用[super dealloc]，并且放在代码块的*后调用（不能直接调用dealloc方法）。

一旦对象被回收了，那么他所占据的存储空间就不再可用，坚持使用会导致程序崩溃（野指针错误）。

内存管理原则
OC使用了一种叫做引用计数的机制来管理对象，如果对一个对象使用了alloc、[Mutable]copy，retain，那么你必须使用相应的realease或者autorelease。

也可以理解为自己生成的对象，自己持有。
非自己生成的对象，自己也能持有。
不在需要自己持有的对象时释放。
非自己持有的对象自己无法释放。
生成并持有对象，持有对象，释放对象,废弃对象。

MRC 手动内存计数
(Reference Counted)手动内存计数：就是说，从一段内存被申请之后，就存在一个变量用于保存这段内存被使用的次数，我们暂时把它称为计数器，当计数器变为0的时候，那么就是释放这段内存的时候。

例如：

当在程序A里面一段内存被成功申请完成之后，那么这个计数器就从0变成1(我们把这个过程叫做alloc)
然后程序B也需要使用这个内存，那么计数器就从1变成了2(我们把这个过程叫做retain)。
紧接着程序A不再需要这段内存了，那么程序A就把这个计数器减1(我们把这个过程叫做release);
程序B也不再需要这段内存的时候，那么也把计数器减1(这个过程还是release)。
当系统(也就是Foundation)发现这个计数器变成了0，那么就会调用内存回收程序把这段内存回收(我们把这个过程叫做dealloc)。顺便提一句，

注意

如果没有Foundation，那么维护计数器，释放内存等等工作需要你手工来完成。**

一般是由类的静态方法创建的, 函数名中不会出现alloc或init字样, 如[NSString string]和[NSArray arrayWithObject:], 创建后引用计数+0(autoRealease), 在函数出栈后释放, 即相当于一个栈上的局部变量. 当然也可以通过retain延长对象的生存期.

MRC下内存管理代码规范
只要调用了alloc，就必须有release（autorelease）

get 方法的代码规范

-（NSString *）value{
return [[_value retain] autorelease];
}
}

set 方法的代码规范

基本数据类型：直接赋值

-（void）setAge:(int)age{
_age=age;

OC 对象类型

（2）OC对象类型(retain)

-（void）setCar:(Car *)car
{
//1.先判断是不是新传进来的对象
If(car!=_car)
{
//2 对旧对象做一次release
[_car release];//若没有旧对象，则没有影响
//3.对新对象做一次retain
_car=[car retain];
}

assign

– (void)setName:(NSString*)name{
_name = name;
}

retain 线程安全下的setter 、getter 方法

-（NSString *）value{
@synchronized（self）{
return [[_value retain] autorelease];
}
}
– (void)setValue:(NSString *)aValue{
@synchronized(self){
[aValue retain];
[_value release];
_value = aValue;
}
}

delloc 方法的代码规范

一定要[super dealloc]，而且要放到*后
对self（当前）所拥有的的其他对象做一次release操作

-（void）dealloc{
[_car release];
[super dealloc];
}

property的参数 属性的属性
具体请看
http://blog.csdn.net/ci915194561/article/details/50161257

ARC 自动管理内存
ARC 并不是Java 的垃圾回收机制

ARC新增两个关键字：strong 和 weak

strong的含义和retain相同，weak和assign相同，修饰完的属性变量用法也是完全没有改变，不过strong和weak只能修饰对象。

区分强弱指针

强指针：默认的情况下，所有的指针都是强指针，关键字strong

弱指针：_ _weak关键字修饰的指针

声明一个弱指针如下：
_ _weak Person *p;
ARC中，只要弱指针指向的对象不在了，就直接把弱指针做清空操作。
_ _weak Person *p=[[Person alloc] init];//不合理，对象一创建出来就被释放掉，对象释放掉后，ARC把指针自动清零。
ARC中在property处不再使用retain,而是使用strong，在dealloc中不需要再[super dealloc]。
@property（nonatomic,strong）Dog *dog;// 意味着生成的成员变量_dog是一个强指针，相当于以前的retain。
如果换成是弱指针，则换成weak，不需要加_ _。

ARC 中@property的参数：

Strong:相当于原来的retain（适用于OC对象类型），成员变量是强指针
Weak:相当于原来的assign,(适用于oc对象类型)，成员变量是弱指针
Assign：适用于非OC对象类型（基础类型）

苹果官方对于ARC机制中对象的内存引用规则：

（1）任何对象，如果仍有持有者，就不会销毁

（2）任何对象，已经没有任何持有者，即自动销毁
1
2
3
持有者就是指向对象的指针，如果是strong修饰的，即是对象的持有者，如果是weak属性的，则不是持有者

ARC机制的使用规则

对于ARC机制的使用，苹果发布了几条重要的规则需要开发者遵守。单单看那些生搬硬套的东西难免生涩，根据开发经验将规则总结如下：

(1)不能调用dealloc,不能重写和调用retain，release，retainCount 和autorelease，同理，@selector(retina),@selector(release)这些曲线救国的方法也不能调用。dealloc虽然能够重写，但是不能调用[super dealloc]之类的方法,CoreFoundation框架由于非从属cocoa框架，所以CFRetain和CFRelease仍然正常使用。

(2)不能使用NSAllocateObjec或NSDeallocateObject函数来创建对象

(3)不能在C语言的结构体中使用对象指针，同时建议用object-c的类来管理数据而不是结构体

(4)不得使用NSAutoreleasePool对象。ARC中，全部使用@autorelease关键字代替，且比NSAutoreleasePool更高效

(5)不得使用内存Zone,那些牵涉NSZone的方法都不得使用。

(6)不得对一个属性变量的取值方法命名以new开头

(7)outlet均用weak关键字修饰，除非他是xib中*顶部的界面元素，则需要strong。

(8)Core Foundation不适合ARC，该创建的仍创建，该释放的仍释放。

关于ARC、MRC下的dealloc 方法使用请看
http://blog.csdn.net/ci915194561/article/details/50159795

Autorelease
可以通过创建和释放内存池控制内存申请和回收的时机.

1、会将对象放到一个自动释放池中
2、当自动释放池被销毁时，会对池子里的所有对象做一次release
3、会返回对象本身
4、调用完autorelease方法后，对象的计数器不受影响（销毁时影响）

优点

1、不需要再关心对象释放的时间
2、不需要再关心什么时候调用release

使用注意

1、占用内存较大的对象，不要随便使用autorelease，应该使用release来精确控制
2、占用内存较小的对象使用autorelease，没有太大的影响
3、内存池是可以嵌套的, 每个内存池都需要有一个创建释放对

NSAutoRealeasePool自动释放池

1、在ios程序运行过程中，会创建无数个池子，这些池子都是以栈结构（先进后出）存在的。
2、当一个对象调用autorelease时，会将这个对象放到位于栈顶的释放池中

创建内存 释放池

（1）ios 5.0以前的创建方式
NSAutoreleasePool *pool=[[NSAutoreleasePool alloc] init];
““““““““`
[pool release];//[pool drain];用于mac

（2）Ios5.0以后
@autoreleasepool
{//开始代表创建自动释放池
// 即将一个NSString对象加入到*内层的系统内存池, 当我们释放这个内存池时, 其中的对象都会被释放
[[[NSString alloc]initialWithFormat:@”Hey you!”] autorelease]；
}//结束代表销毁自动释放池

什么情况下需要创建自动释放池？
其实自动释放池存在的意义是为了延迟释放一些对象，延迟向对象发送release消息。在实际的开发中，有两种情况是需要手动创建自动释放池的。
1、在多线程中，因为子线程中可能会使用便利构造器等方法来创建对象，那么这些对象的释放只能放在自动释放池中，此时需要在子线程中添加自动释放池。
注意：主线程已经添加过自动释放池，在main函数里面。
2、就是如果一段代码里面（比如for循环）大量使用便利构造器创建对象，也需要手动添加自动释放池。
使用注意：

1、系统自带的方法中，如果不包含alloc new copy等，则这些方法返回的对象都是autorelease的，如[NSDate date]；
2、开发中经常会写一些类方法来快速创建一个autorelease对象，创建对象时不要直接使用类名，而是使用self

*近身边用苹果的人越来越多，这是一件好事，我很高兴身边的朋友们都能用上世界上*先进的计算机和操作系统，但是大部分朋友都是从Windows过度过来的，从系统使用和原理理解上都有一些Windows的观念，*近很多朋友问我一个问题：“为什么我的系统一开机还没运行什么程序，空余内存就没多少了，我可是4GB内存啊，是不是有什么问题？”针对这一问题，特写此文，让大家理解基于UNIX的Mac OS X是如何管理内存的。

之前转载了一篇文章介绍Unix/Linux的内存管理，但是很多朋友说看不懂，那今天我就通俗的跟大家分享一下，Mac是如何管理内存的。

首先，我们要来了解一下，Mac OS X的内存四种状态，打开你的“应用程序-实用工具-系统监视器”程序，切换到“系统内存”标签，你会看到你的内存有联动、活跃、非活跃和可用空间四种状态：

联动是系统核心占用的，永远不会从系统物理[内存]种清除，

活跃表示这些[内存]数据正在使用种，或者刚被使用过，

非活跃表示这些[内存]中的数据是有效的，但是*近没有被使用，

可用空间表示这些[内存]中的数据是无效的，这些空间可以随时被程序使用。

当可用空间的[内存]低于某个值（这个值是由你的物理[内存]大小决定的），系统则会按照以下顺序使用非活跃的资源。首先如果非活跃的数据*近被调用了，系统会把它们的状态改变成活跃，并接在原有活跃[内存]逻辑地址的后面, 如果非活跃的[内存]数据*近没有被使用过，但是曾经被更改过而还没有在硬盘的相应虚拟[内存]中做修改，系统会对相应硬盘的虚拟[内存]做修改，并把这部分物理[内存]释放为可用空间供程序使用。如果非活跃[内存]中得数据被在映射到硬盘后再没有被更改过，则直接释放成可用空间。*后如果活跃的[内存]一段时间没有被使用，会被暂时改变状态为非活跃。

所以说，如果你的系统里有少量的可用空间内存和大量的非活跃的内存，说明你的[内存]是够用的，系统运行在*佳状态，只要需要,系统就会使用它们，不用担心。而反之如果系统的可用空间内存和非活跃内存都很少，而活跃内存很多，说明你的[内存]不够了。当然一开机，大部分[内存]都是可用空间，这时系统反而不在*佳状态，因为很多数据都需要从硬盘调用，速度反而慢了。

其实这就是Unix的内存管理方式，我们大家都知道，内存的速度是比硬盘快得多的，那么UNIX的内存管理机制就是尽可能多的使用你的物理内存，当你没有打开程序的时候，系统自动会把一些系统常用的资源从硬盘加载到内存，当你开始执行操作需要调用这些资源的时候，系统就不会从硬盘去读取你的资料了，而是直接从内存读取（专业术语叫命中），这样就提高你的系统速度，不浪费你的物理内存资源。

Mac系统基于UNIX系统，继承了UNIX这一内存管理机制并且进行一定的优化，Mac的内存管理具有UNIX的特征的同时，Mac还会记录你*常用的程序，然后在你内存有足够空余资源的时候，就把这些程序主要模块(Modlue)加载到内存，当你开启这个应用的时候，程序就快速启动了，当你关掉这个程序界面（Command+W / iOS-Home）的时候，大部分程序并不会真正的退出(quit)系统，而是保留程序核心模块驻留系统内存，你可以在Dock上看到图标下有个小亮点（iOS连按Home），当你下一次需要使用的时候，只要点一下程序就快速启动了，如果你很久没有再用这个程序而打开了其他程序，而打开了其他很多程序，那么系统就会在内存不够用得时候，自动把你只是关闭没有退出（Command+W）的程序驻留内存文件转移到硬盘的某个地方（pagefiles）中，等待你的调用，只有当你完全退出程序(Command+Q)的时候，这些程序就从内存清除了，但是Mac系统会智能的学习和了解你的你操作习惯，不断的更换你的常用程序列表，然后当物理内存有空的时候随时把你常用的程序模块载入内存，等待你调用。其实这也是Mac系统为什么点按窗户红色按钮是关闭而不是退出的设计思维原理，就是让程序在下一次被用户打开时能够快速启动，而且先进的Unix内存管理计算方式几乎不用你去担心是否内存不够用了，需要退出这些打开的程序，因为系统会习惯出一个*佳值什么时候释放内存（哪些内存数据什么时候保存到pagefiles去）来保证你的系统运行效率，尤其是现在很多iOS设备用户，每次都喜欢按Home返回后再连按Home去退出程序，其实完全没必要这么做，因为iOS是Mac OS的移动版，具有和Mac OS X完全相同并且高效的内存管理机制，你每次运行了程序再去退出他，反而降低了你系统下一次开启这个程序的速度。

windows为了兼容古老和不规范的程序，允许程序直接控制硬件，导致windows系统的权力不够大，而许多windows程序也不规范，因此在退出进程后往往许多[内存]没有还给系统变成了invisible memory，导致时间一长系统可用[内存]越来越少。因此常常需要重新启动。而且Windows在内存管理方面也于Unix有很大的区别，由于我对Windows并不是很熟悉，所以只能以我自己的理解来向大家说明，如有错误，还请斧正。由于Windows的系统模块链接关系不明确，权限又很混乱（Windows貌似压根就没有文件权限这个说法），导致后来Windows98就经常蓝屏死机，又为了防止大量不规范程序退出后不归还系统内存，所以Windows就只能在系统启动完毕，加载完必要模块后，当用户请求一个程序就从硬盘调用一个，不用就清除的办法来管理内存，所以如此就造成了系统物理内存的大量浪费，因为我们并不是随时都需要运行超级大的程序，事实上，大部分人的电脑都有4GB内存，而通常只开一个QQ和一个浏览器，顶多在打开一个Music Player，所占内存不到200MB，加上系统内存*对也就1GB左右，至少一台4GB内存的计算运行Windows的话，有75%的时间内存使用不到2GB，那么也就是说用户花了4GB的钱，其实浪费掉了75%，比如花了400元，你就浪费了300元，但是用UNIX就不会浪费你的钱，因为Unix先进的系统架构和内存管理就决定了这个因素。

其实Unix的内存管理先进性仅仅只是Unix一个小小的细节，Unix还有很多很多比Windows先进的地方值得我们学习，以后我会为大家介绍更多的Unix/Linux特性。

对开发者而言，这是一个*好的时代。数字产业蓬勃发展，传统云计算产业走向成熟，大数据、物联网、人工智能、区块链各种新兴技术百花齐放，开发者大有用武之地。但与此同时，新技术层出不穷的涌现，也让开发者对现有技术能力产生焦虑，对于未来道路的选择变得困惑。

为了得到答案，2021年3月阿里云委托Forrester咨询公司对中国开发者群体进行调研，通过线上问卷方式调研了422名包括企业内部应用开发、测试、运维等在内的不同角色人员，以及独立开发者在内的广泛开发者群体。同时为了充分揭示云原生时代对开发者群体带来的价值、机遇以及需要关注的重点云原生技术，Forrester还访谈了企业CTO、高校教授、开源社区专家以及开发者社区意见领袖（KOL）在内的9位专家。

不可否认的是，云原生让开发者看到了更多可能。云原生技术的演进为开发者提供了更加“聪明的方式”去工作，即充分利用云原生平台的组件及工具链，屏蔽底层技术并节省不必要的时间花费，更加专注地聚焦业务价值创造以及创新。如果说云是一种信仰，那么云原生就是一种态度，时代呼唤人人都应成为云原生开发者。

开发者的演进路线

纵观三十年的发展历程，一方面广大中国开发者持续发挥着巨大的经济和社会价值，另一方面社会经济的发展也在改变着全社会创造价值和实现价值的方式，并持续带来软件和应用研发交付模式的变革，从而为开发者提供一个更加广阔的空间，来充分释放想象力和创造力。

开发者的构成从*初以传统开发者为代表的群体，到逐渐兴起的云上开发者群体，再到日渐壮大的云原生开发者群体。开发者自身的使命也从曾经的企业信息化战略执行者，转变为如今的数字化转型业务赋能者，未来将进一步成为数字创新的技术引领者。

传统开发者是企业信息化战略的执行力量。在1990至2010年的二十年间，聚光灯下的掌声与赞美往往与他们无关，但却是他们在切实执行着企业决策者们的业务战略。传统开发者通过各种信息系统应用的开发与实施，帮助企业构建信息基础设施与业务平台，实现内部用户与外部客户所需的业务功能，帮助企业应对快速变化的市场环境，并不断开拓新的业务领域和新的商业模式。

虽然当前各行业的数字化转型如火如荼，但其实很多行业仍以传统的应用构建和开发模式为主。例如瀑布式开发模式，一方面要进行功能设计、开发和测试；另一方面要进行技术选型、资源准备、组件调试、持续构建和版本部署等，整个过程周期长、技术复杂，并且需要配备大量的开发团队。

随着云计算技术的成熟，传统的开发模式已经不能满足时代的发展需要，开发者开始借助云平台的力量。云上开发可以有效确保研发与运维团队的现代化水平，从平台工具层面推动研发与运维技术能力的不断提升。云上开发带来的技术能力标准化，大幅提升了开发者的工作效率，包括开发与测试环境的配置效率，功能组件、业务系统的软硬件开发效率，以及服务化、组件化、灰度化的发布与部署效率等。

但我们也看到了一个现象，多数实现应用上云的企业，其本身的应用开发模式并未实现基础性转变。在这些企业中，开发者对云计算的使用依然是局限于孤立场景，诸如基础设施层面或者特定业务应用。同时，云平台本身在开发工具链、集成服务方面的不完善也影响了云上开发模式被更多的开发者群体接纳。

紧接着，以Docker为代表的容器技术开始兴起，随后K8s厚积薄发，在开发者对性能、效率、可迁移性、可管理性和便捷性永无止境的追求中，云原生技术应运而生。云原生使得云上开发模式拥有了更加强大的工具以及新的应用构建与创新思维。当然，云原生开发者不仅仅体现在对Docker、K8s等新兴技术的掌握与运用，更是通过云原生技术，实现对底层技术复杂性的屏蔽，做到更好的应用集成与交付，从而帮助企业创新。Forrester调研显示，73%的开发者认为，云原生可以使得更多企业内部人员成为开发者。

云原生驱动新开发时代的到来

云原生是云计算的再升级。云原生包含大量新的PaaS层技术和新的开发理念，是释放云计算价值的*短路径，也推动着云计算的再升级。整个云原生技术栈都是基于开源、开放的技术标准，CNCF也在致力于让云原生技术标准化，为用户提供使用云服务的标准界面，避免厂商锁定。

进一步看基于云原生技术和云原生架构重构或重写的应用，比如，基于服务网格或Serverless的应用，它们天然具备水平扩展的能力，可随时应对互联网时代高速增长的业务规模，同时还内置了高可用能力，因此应用无须关注分布式环境下的高可用方案。

云原生不仅是对使用云的应用架构的再升级，也是对云平台的技术和云服务的再升级。从构建云原生应用的角度，云原生对应用的重构体现在应用开发的整个生命周期中。

在这个过程中，我们看到了一些趋势：比如容器+K8s成为技术基础设施。容器让应用运行时与环境解耦，K8s让资源管理和基础设施解耦，向下封装基础设施层，屏蔽底层架构差异性，连接异构算力，云边端一体化，构建分布式云；向上支撑多种异构工作负载，分布式、弹性可扩展、Mesh化解耦，推动应用架构现代化演进。可以说，容器和K8s已经变成了云计算时代的分布式操作系统。

除了在开发模式上的改变，我们也看到，在云原生的驱动下，一个全云开发的时代正在到来。

2021年底，68%的机构会在生产环境中使用容器，比2020年增长39%，比两年前增长240%。阿里巴巴在2016年实现了100%容器化，而在2021年，68%的企业将在生产环境中使用容器。可以确定的是，容器已经成为一个*对的趋势。

开发者云上开发意愿度达到68%。大量开发者已经感知到云上开发所带来的变化，包括前端/后端，网页、移动端、小程序，逻辑、模型、组件等，云上开发带来了生产力的改进，效率的大幅提升等。

到2021年底，25%的开发者将使用Serverless产品。今天，阿里云已经开始大力投入Serverless研发，提供了函数计算FC、Serverless应用引擎SAE、Serverless容器服务ASK、无服务器基础设施ASI、弹性容器实例ECI等产品。同时，在开发者工具方便，阿里开源了业界首个Serverless开发者平台——Serverless Devs，通过该平台，开发者可以一键体验Serverless产品，*速部署Serverless项目。

从广大开发者的视角，一方面开发者可以明显感受到云平台从资源、能力到价值层面的流动性，为应用开发和系统运维带来了*大的便利；另一方面，开发者也曾饱受云上云下异构的开发技术、琐碎的开发工具与割裂的协作过程的困扰，无法完全在云端进行技术实践。

随着云原生的发展与成熟，相关产品与工具正在解决开发者面临的痛点。比如容器镜像的一致封装使开发者得以实现不同环境下的应用可迁移性；代码和配置的分离有效简化了开发人员的开发测试流程；无服务器计算能够帮助开发者快速开通开发和测试集群而无需复杂配置；CI/CD跨云构建部署能力，让开发与运维人员确保异构环境下复杂应用的快速稳定迭代。

云效作为DevOps一站式平台，将阿里巴巴多年总结的云原生开发模式融合到产品中，为广大开发者提供好用易用的云原生研发解决方案。开箱即用的云端IDE、代码管理平台、CICD流水线，让开发、测试、部署全流程与云原生底座平台无缝结合，进一步降低开发者上手云原生技术的门槛，加快云原生技术转型，大幅提升软件生产效率。

在市场及技术发展的驱动下，企业应用及软件的开发与构建将走向云原生。同时，云原生开发平台的成熟也将反过来驱动更多的企业选择云原生。云原生开发模式将成为企业应用开发的必然选择。

布局开源生态，阿里云推动全云开发与实践

标准和开源加速了云原生，也推动了全云开发的更好落地。今天，阿里云在GitHub上开源项目总数超过2600+，涵盖了大数据、云计算、AI、中间件、容器、Serverless等领域，拥有超过30000+ Contributor，超百万GitHub Star，位列中国企业开源社区GitHub贡献榜首。这其中，一些开源项目也成为了相关领域的事实标准。

其中，Dubbo已经成为国内影响力*大、使用*广泛的开源微服务框架；RocketMQ是国内首个互联网中间件的Apache顶级项目，也是常年霸榜国内*受欢迎的开源中间件项目。此外，我们还有应用管理引擎KubeVela，去年刚开源的阿里巴巴*个边缘计算项目OpenYurt，分布式高可用领域的混沌工程工具ChaosBlade，服务注册发现Nacos以及首个Serverless开发者平台 Serverless Devs等。

面向整个技术社区，阿里云把研发多年的技术成果回馈给全球顶级基金会，如开放原子开源基金会、Apache基金会等，阿里云致力于打造一个开放的、标准的、健康良性的技术生态。一位开发者想要基于云原生技术构建一套开源架构，完全可以在阿里云生态里找到自己的工具。阿里云已经服务了大量企业级头部的用户，同时正在构建一套开放标准的技术体系，服务于全球开发者。

企业上云是趋势。阿里巴巴在国内率先开源了自研RocketMQ，并成为Apache顶级开源项目。RocketMQ为用户提供了高性能、高可靠、低延迟的消息服务，成为业内流行的金融级业务消息首选方案。随着云原生技术的发展，全面云化已是大势所趋。众多企业对消息中间件的演进有着更深层次的诉求。我们将在社区和商业同期发布RocketMQ 5.0，全新定义“消息、事件、流”一体化融合处理的新理念。RocketMQ5.0将在基础架构云原生化、消息流式处理以及事件驱动三个方面带来变化。

首先，基于阿里云大规模生产实践的背景，RocketMQ5.0将提供面向多种场景、可调整的*简弹性架构，帮助企业在资源弹性、运维复杂度、业务生态创新等方面做好平衡；其次，RocketMQ5.0将围绕高价值消息数据提供全新轻量化设计的流式处理框架，方便企业和开发者就近处理消息计算和分析；*后，RocketMQ 5.0会基于开放的标准，连接云服务和开源生态，并配合Serverless开发模式，为用户提供低代码、无服务器的下一代事件驱动架构服务。

云原生*开始提出来的时候，是以资源集群管理与运维为切入点，但是今天如果要把所有的工作负载运行在一套基础设施之上，还缺乏对应用的管理。所以我们提出，以应用为中心，关注点分离，把开发运维基础设施、合作边界、协议、方法全部定义出来，也就是一站式应用管理与交付平台KubeVela。今年6月，KubeVela进入CNCF Sandbox，目前镜像下载量突破30万次，拥有20多家全球企业客户。今年OAM也被信通院立项作为行业标准。

如今，越来越多的算力和业务开始下沉到距离数据源及终端用户更近的地方。随着规模、复杂度逐日攀升，边缘计算场景下的运维能力开始不堪重负。为了推动边缘计算和云原生领域协同发展，阿里云将边缘容器服务ACK@Edge核心框架OpenYurt向业界开源，并捐赠CNCF 。秉持业界首创的“非侵入式”理念，OpenYurt拥有边缘计算全场景覆盖能力，成为生态兼容场景下的领域首选平台。其应用已覆盖包括IoT、音视频、物流等数十个行业，让云原生变得无处不在。

云原生时代，让开发者成为更好的自己

在这样一个快速变化的时代，每一位开发者以及希望转型成为开发者的个人，都需要敏锐地把握到时代发展的脉搏、企业数字化转型需求的变化以及技术发展的走向。同时更为重要的是，在自己的舒适区域以外，要能够看到各种挑战的同时，发现自身进一步成长的空间。

无论是刚刚步入职场的年轻人，还是即将步入中年的资深工程师，每个开发者都会遇到成长过程中特有的挑战，诸如：职业生涯挑战。面对着高负荷的工作以及家庭的负担，无法再和刚毕业年轻人比拼熬夜加班，而连续加班时的工作效率也越来越难以保证；想要提升自己的技能，但面对着汹涌而来的技术浪潮，无法再有足够的精力去分辨哪些是珍珠哪些是泡沫。随着企业纷纷上云，底层基础设施与平台工具不断标准化、自动化和智能化，在传统的技术技能体系下，自己的工作越来越被同质化甚至边缘化，职业发展的焦虑和年龄一同与日俱增；当抬起头来放眼外部的世界，却发现很难找到自己的定位；或者好不容易找到期待的机会，却又发现自己的技术经验变得狭窄而陈旧。

在调研过程中，72%受访者反馈面对快速变化的市场环境，需要掌握更多的业务与行业知识，70%的受访者认为随着企业愈来愈注重客户体验，需要开发者掌握相关的客户体验知识。不仅如此，各种内外部因素均对开发者的技能及素质提出了更高的要求，迫切要求开发者加速自我转型。

云原生技术的演进为开发者带来了破局之道。云原生开发模式将成为未来应用开发的主流模式，并帮助开发者差异化个人技术竞争力。从容器/K8s、微服务、服务网格到事件驱动的无服务器计算应用，从应用目录、服务目录与镜像仓库的管理到公有云、私有云、边缘网络的部署，不断发展的云原生全栈技术带给开发者全新的资源、资产与架构视角，使得开发者拥抱更现代化的技术方法、工具与*佳实践，实现自身技术能力的纵向提升与革新。

增强技术适应能力，实现跨领域发展。以容器、微服务、Serverless为代表的云原生技术，已经让数据库、AI、大数据、音视频、区块链等技术领域都在其影响下持续推陈出新；而基于K8s的平台化能力，开发者在历史上*次有机会将多种曾经彼此割裂的新兴技术领域协同起来，实现自身技术能力的横向扩展。此外，开发者有机会探索分布式应用架构设计、开发、测试、运维。不仅开拓技术视野，而且丰富开发经验，有效增强自身的竞争力和适应能力。

提升协作效能，探索业务创新。在容器和K8s等云原生技术的加持下，CI/CD以及DevOps实践迎来了又一次飞跃式发展。应用开发流程的简化、自动化与一体化，不仅使得开发者可以更加聚焦于对业务需求与客户价值的深入理解，更加快速有效地满足客户需求；同时，通过解决业务问题，探索业务创新。

云原生为开发者实现全云实践的美好愿景提供了可能，但是开发者也要清醒地认识到，引领未来十年数字创新的使命，*非一朝一夕之功。开发者应当以前瞻视角聚焦云原生开发者技术能力要求，关注价值实现。

技术可以推动转型，技术可以引领创新，但技术不是目的，技术要为业务服务。开发者在日常技术实践工作中，应当积*了解技术实现背后的具体业务需求，熟悉业务人员沟通语言背后的业务概念，并尽可能进一步挖掘业务需求背后的客户目标。其次，开发者也要摒弃常见的定势思维，比如客户体验就是漂亮的界面设计，体验只和UI有关，与技术人员无关等诸如此类的错误想法，开发者需要换位思考，让客户价值的思想融入自身的技术实践过程。

*后，开发者需要勤于思考，比如技术解决的核心业务问题是什么？这些问题的业务成因是什么？有哪些业务痛点没有考虑到，还可以做进一步增强？这样才能真正从业务与客户视角出发，由外而内地推动自身技术能力的提升。云原生技术在帮助企业快速落地业务需求的同时，也倒逼企业开发者具备商业视角，关注业务逻辑，做更有创新价值的事情。

时代呼唤云原生，这是云原生*好的时代，也是开发者*好的时代。让每一位开发者成为更好的自己，阿里云一直在路上。

黑莓手机作为将全键盘设计做得*成功的手机，曾是无数手机用户的首选。近年来随着安卓和iOS的快速崛起，黑莓早已放弃硬件业务，向移动安全和通信软件服务商转型，因此它现在成为医疗设备、汽车系统等领域工业设备软件的主要供应商。

来源于网络

近日，黑莓公司设计的一款实时操作系统被爆存在重大的网络安全漏洞问题，可能会导致使用该软件的汽车和医疗设备面临风险，让高度机密的系统暴露在黑客面前。但是黑莓公司却隐瞒这一消息长达数月之久。据资料显示，全球范围内共有1.95亿辆汽车使用了该系统，包括大众、宝马和福特等汽车制造商，因此这次安全漏洞的曝光，将会对很多车主造成影响。

本周二，黑莓公开承认QNX 系统包含 BadAlloc 漏洞，该漏洞可以让黑客瘫痪相关设备。而同样受到 BadAlloc 漏洞影响的公司在几个月前就向用户发布了公告，比如，微软安全研究人员在 4 月份宣布，他们在多家公司的操作系统和软件中发现了该漏洞

而在今年 5 月，根据 CISA（美国网络安全与基础设施安全局）公开披露的漏洞修补名单上其中没有黑莓公司的身影。

黑莓为何隐瞒漏洞信息？

据媒体报道，黑莓公司曾制作的一份PPT暴露了真实原因，黑莓着重强调用户不知道这种危险的存在，而将真正危险用户排除在外，除非联邦政府或设备制造商告诉他们。而迫使黑莓公司发布有关 BadAlloc 漏洞报告的直接原因是CISA及国防部的参与，CISA 还敦促客户将其设备升级到*新的 QNX 版本，并发布相关公告。

据知情人士透露，今年早些时候，黑莓公司私下告诉 CISA，他们不相信 BadAlloc 漏洞影响了他们的产品，在过去的几个月里，CISA 敦促黑莓接受这个坏消息，*终让黑莓公司承认操作系统存在安全漏洞。黑莓*初拒*承认这个被称作 BadAlloc 漏洞对其产品造成了影响，后来又拒*发表公开声明。

“他们*初的想法是私下通知客户，因为这样做不会让黑客知道漏洞正在修复中，也可以减少经济损失与公司负面影响。””一名 CISA 员工说。然而，随着时间的推移，黑莓“意识到公开消息有更多的好处”。

黑莓公司还告知 CISA，由于无法识别使用其软件的客户个人信息，因此没办法向客户发出警告。这是由于黑莓将 QNX 授权给“原始设备制造商”，后者使用QNX系统为客户定制相关产品设备，就像微软将其 Windows 操作系统出售给惠普、戴尔和其他计算机制造商一样。

CISA 网络部门负责人埃里克·戈德斯坦（Eric Goldstein）对此拒*回应黑莓公司，但表示CISA 网络安全部门会“定期与黑莓公司安全研究人员合作，及时地披露漏洞修复情况，以便用户可以采取措施保护他们的系统。”

埃里克·戈德斯坦 (Eric Goldstein)补充道 ：“QNX 被广泛用于各种产品，这些系统漏洞可能会被黑客利用。虽然我们不知道有哪些漏洞被利用，但我们鼓励 QNX 用户查看黑莓近日发布的公告，尽快修补系统。”

如何应对安全漏洞

黑莓并不是*家被披露发生系统安全漏洞的公司，网络安全专家表示，再高度复杂的系统中偶尔也会出现此类漏洞，但解决 QNX 问题将是黑莓和政府的一项重大任务。而且黑莓等公司向设备制造商出售他们的软件时，他们很少提供软件代码的详细记录，这让硬件制造商、政府部门对网络安全风险一无所知。

与此同时，NTIA （美国商务部国家电信和信息管理局）于7月份发布了关于 SBOM（软件物料清单）的列表指南。有了 SBOM，得知 QNX 发生漏洞的汽车制造商或医疗设备制造商，可以快速检查哪些产品受到影响。SBOM 虽然不会阻止黑客发现和利用漏洞，也无法告诉公司某个缺陷是否对其系统构成了风险，但是可以加快修补系统漏洞的速度。

黑莓公司这次隐瞒系统安全漏洞，也让普通民众议论纷纷。

“软件供应链安全是美国*大的漏洞之一，”前众议院情报委员会高级职员安迪·凯泽 (Andy Keiser) 说。“作为地球上联系*紧密的社会之一，我们仍然是*脆弱的社会之一。”

“黑莓不可能完全清楚系统漏洞的运行状况，”乔治梅森大学计算机科学教授兼 Linux 基金会开源供应链安全主管大卫惠勒说，“我们需要帮助人们了解他们系统中的各种组件，并帮助他们及时地更新系统。”

今年 7 月，Security Discovery网站总监鲍勃·迪亚琴科（Bob Diachenko） 在暴露的Elasticsearch集群中发现了大量JSON记录，近200万条信息被泄露，其中包含有关人员的敏感信息，包括姓名、国籍、性别、出生日期、护照详细信息和禁飞状态。暴露的服务器已被搜索引擎Censys和ZoomEye编入索引，这表明Diachenko可能不是唯一访问该列表的人。

来源于网络

研究人员Bob Diachenko分析暴露字段的性质（例如护照详细信息和“no_fly_indicator”），发现这些信息似乎来自禁飞或类似的恐怖分子观察名单。此外，他还注意到一些难以理解的字段，例如“标签”、“提名类型”和“入选指标”等。

考虑到这些数据被视为高度机密，在协助国家安全和执法方面发挥着重要作用。于是在7月19日，Bob Diachenko急忙向美国国土安全部（DHS）报告了数据泄露事件。三周后，即2021年8月9日，暴露的服务器被关闭。

有趣的是，Bob Diachenko是在7月19日发现了暴露的数据库，但是该数据库位于巴林 IP 地址而非美国 IP 地址的服务器上。

数据泄露的影响

“鉴于这些数据中存在一个‘TSC_ID’的特定字段，暗示这些数据来源可能来自恐怖分子筛查中心 (TSC)。”Bob Diachenko在后面的报告中解释道。FBI 的TSC 被多个联邦机构用于管理和共享用于反恐目的的综合信息，该机构维护着“恐怖分子筛查数据库”的机密观察名单，有时也称为“禁飞名单”，航空公司和多个机构（例如国务院、国防部、运输安全局 (TSA) 和海关和边境保护局 (CBP)）会参考该列表，以检查乘客是否被允许乘飞机进入美国或评估他们危险级别。

来源于网络

Bob Diachenko认为这次数据泄露是非常严重的事件，“如果落入坏人之手，后果不堪设想，坏人可能会利用名单来骚扰或迫害名单上的人及其家人。”

Bob Diachenko也表示：“这次泄密可能会对嫌疑人产生负面影响，也会给名单上的无辜者带来个人问题和职业困扰，比如那些因拒*成为线人而被列入“禁飞名单”。”

ElasticSearch 为何频发数据泄露

Elasticsearch是现在的Elastic于2010年首次发布的分布式免费开源搜索和分析引擎，具有快速实时搜索和可靠稳定的特点。很多企业都用作检索公司机密信息，提高工作效率。但是近年来，Elasticsearch数据泄露事件却频繁发生。

来源于Elastic官网

例如在2019 年 12 月 1 日，腾讯、新浪、搜狐和网易等公司，超过 27 亿个邮件地址数据被泄露。泰国移动运营商Advanced Info Service(AIS) 的Elasticsearch数据库于2020年5月1日被公开访问，数据库中包含了约83亿记录，数据体量约为4.7 TB。

Elasticsearch数据泄露发生的主要原因，在于Elasticsearch开源版本是不具备任何数据保护功能的，只有基本的攻击保护防火墙功能。

因此专家建议可以采取认证和授权、数据加密（通讯加密）、使用内部网络等方法避免发生数据泄露，或者加强预警，以便在安全事件发生的*时间感知并启动紧急预案，将损失降到*低。

参考链接：

• https://www.bleepingcomputer.com/news/security/secret-terrorist-watchlist-with-2-million-records-exposed-online/
• https://cloud.tencent.com/developer/article/1580423

一分钟速览新闻点！

• 小米造车正式地址*快将于下周公开

• 今日头条成立新业务团队：悟空浏览器和阅读平台“识区”

• 微信支付：支付后推荐关注公众号功能 9 月 1 日起下线

• 荣耀正在建设新总部和生产线，供应链 100% 恢复

• 贝壳找房启动史上*大规模校招

• B站：升级影像创作新体验，支持“杜比视界”画质视频

• AirPods 3 将在中国生产

• 俄罗斯莫斯科法院再次对谷歌罚款 400 万卢布

• 乔布斯曾考虑推出“iPhone nano”，比iPhone 4更小也更便宜

• 全球 90 多家组织敦促苹果放弃引入”儿童安全”功能计划

• Windows 11 切换默认浏览器的过程变得繁琐

• 第九代 iPad 即将发布

• Google 悬赏 4 个 Chrome 漏洞，共支付 8 万美元

• Git for Windows 2.33.0 发布

• 直播推荐|2021 强化学习暑期课

国内要闻

小米造车正式地址*快将于下周公开

恒大集团目前与蔚来、小鹏等多家造车新势力公司，以及小米会谈出售电动汽车业务，截至目前，商谈结果尚未*终确定。不过，小米仍会选择自己造车，地址*快将于下周正式公开。对于上述信息，蔚来、小鹏、小米等公司相关媒体部门尚未给予回应。（财联社）

今日头条成立新业务团队：悟空浏览器和阅读平台“识区”

今日头条近日成立两个新业务团队，一个业务团队打造定位高端的资讯平台“识区”，目前，“识区”在内部进行网页端的测试，Slogan 为“定义你的阅读宇宙”。另外一个业务团队为浏览器团队，计划打造“悟空浏览器”，其中还会搭配独立研发的“悟空搜索”，悟空浏览器独立于头条搜索，在功能上，悟空浏览器强调智能搜索。（Tech星球）

微信支付：支付后推荐关注公众号功能 9 月 1 日起下线

8 月 19 日晚间消息， 微信支付今日晚间发布公告称，为了保障用户权益，提升用户使用体验，我司将于 2021 年 9 月 1 日起下线支付后推荐关注公众号。

荣耀正在建设新总部和生产线，供应链 100% 恢复

目前，荣耀正在深圳建设新的总部和一条全新的生产线，荣耀未来的产能会得到进一步提升。目前荣耀的供应链企业已经 100% 恢复合作，荣耀终端有限公司 CEO 赵明还表示，荣耀未来要与苹果竞争，打造超越苹果的产品，荣耀自身也会分化出新的子品牌，继续承担原有的“互联网手机”角色。（经济参考报）

贝壳找房启动史上*大规模校招

贝壳找房正式启动2022届校园招聘。本次招聘面向海内外2022年应届毕业生，开放超200种岗位，工作地点覆盖北京、上海、杭州、南京、武汉、西安等26座城市，是贝壳找房史上*大规模招聘。此次校招，产品研发类岗位占70%以上，包括图像算法工程师、三维重建算法工程师、深度学习算法工程师、数据挖掘/机器学习工程师等。（36氪）

B站：升级影像创作新体验，支持用户上传“杜比视界”画质视频

B站宣布启动“杜比视界”画质升级，成为全球首家面向内容创作者支持 “杜比视界”画质的在线视频平台。目前“杜比视界”画质面向大会员用户开放。此次B站联合杜比实验室实现了创作者端的“杜比视界”画质升级，为用户和UP主们带来新的画质体验。

国际要闻

AirPods 3 将在中国生产

据知情人士透露，由于新冠肺炎疫情爆发促使各国政府加强了边境管制，苹果不得不在中国开始批量生产第三代 AirPods，而该公司之前计划在越南生产这款耳机。苹果表示，仍希望以后将约20%的AirPods新品生产转移到越南。（新浪科技）

俄罗斯莫斯科法院再次对谷歌罚款 400 万卢布

俄罗斯莫斯科塔甘斯基第422号地方法院根据《俄罗斯联邦行政法》再次处罚美国互联网公司谷歌。俄法院裁定，谷歌公司未能删除被俄法律禁止的含有煽动*端主义的内容，以及拒*将俄罗斯用户数据存储在俄罗斯本地服务器上，谷歌公司将面临400万卢布的处罚。至此，谷歌公司在俄被罚款总额增加到3250万卢布。（央视新闻）

乔布斯曾考虑推出“iPhone nano”，比iPhone 4更小也更便宜

据美国科技博客The Verge报道，2011年，有传言称苹果正在开发所谓的“iPhone nano”，比当时的顶级机型iPhone 4更小、更便宜。虽然苹果从未发布传闻中的超小型手机，但The Verge在收集Epic诉苹果诉讼案的电子邮件时发现了一封乔布斯的邮件，证实该公司确实曾在某个时间点上开发“iPhone nano”。（界面）

全球 90 多家组织敦促苹果放弃引入”儿童安全”功能计划

日前，全球90多个政策和人权组织发表了一封公开信，敦促苹果公司放弃对成年人手机进行儿童性虐图像扫描的计划。一位苹果发言人表示，公司已在周五的一份文件中解决了隐私和安全问题，声称被错误检测的风险很低。信件也指责了iMessage试图识别和模糊儿童信息中的裸体内容，会同时通知到家长，他们认为这一步骤可能会不利于那些生活在不宽容的家庭下或寻求性教育素材的儿童。（新浪财经）

Windows 11 切换默认浏览器的过程变得繁琐

据报道，微软正在增加Windows 11 中的默认浏览器更改难度，并在操作系统中忽视了默认浏览器设置。*近释出的 Windows 11 beta 中改变了分配默认应用的方式，要求用户必须根据文件类型设置默认应用，比如要改变默认的浏览器，用户需要修改一遍 HTML、PDF和HTTPS 等文件类型，以及链接类型打开的默认浏览器。（Solidot）

苹果第九代 iPad 即将发布

苹果计划在今年秋天更新其入门 iPad，推出专为学生量身定做的第九代机型，设计更薄，处理器更先进。对于第 9 代机型，苹果可能会继续目前的设计，以 Touch ID 和主页按钮为特色。有传言称，新款iPad mini将采用更大的显示屏、更窄的边框、更强的性能和更新的整体设计。（凤凰科技）

程序员专区

Google 悬赏 4 个 Chrome 漏洞，共支付 8 万美元

Google 在本周二向用户推送了 Chrome 浏览器的补充更新，更新后版本号升至 92.0.4515.159，该版本为桌面端 Chrome 浏览器修复了 9 个漏洞。其中 CVE-2021-30598 和 CVE-2021-30599，两者均是 V8 JavaScript 引擎中的类型混淆问题，Google 为这两个安全漏洞分别支付了 21000 美元，合计 42000 美元。360 Alpha Lab 的安全研究人员发现 Chrome 浏览器 Printing 中的一个 UAF 漏洞（CVE-2021-30600）和 Extensions API 中的另一个漏洞（CVE-2021-30601），而 Google 又为这两个漏洞分别支付了 2 万美元的漏洞赏金，合计 4 万美元。

更新详情查看链接：

https://chromereleases.googleblog.com/2021/08/stable-channel-update-for-desktop.html

Git for Windows 2.33.0 发布

Git 近日发布了 Git for Windows 2.33.0 版本，本次更新修复了一些错误和发布新功能。现在可以要求 Git for Windows 使用 PATH 上的 SSH，而不是其捆绑的 OpenSSH 执行程序，实验性的 FSMonitor 补丁被更新的版本所取代。对 git repo 工具的进行了改进。修复了在选中 Windows 终端配置文件选项时，安装程序在升级时不再显示错误对话框。