Redshift

https://launchpad.net/~dobey/+archive/ubuntu/redshift-daily Redshift Daily Builds PPA description Adding this PPA to your system You can update your system with unsupported packages from this untrusted PPA by adding ppa:dobey/redshift-daily to your system’s Software Sources. (Read about installing) sudo add-apt-repository ppa:dobey/redshift-daily sudo apt-get update Technical details about this PPA This PPA can be added to …

electronic-wechat

以下文件是更换系统或重新安装微信时需要单独备份的文件 /home/felix/Desktop/electronic-wechat.desktop 桌面图标 /opt/electronic-wechat-linux-x64 安装文件夹,可以不做备份,需要保留其中的一个图片文件 /opt/electronic-wechat-linux-x64/wechat.png 微信安装文件夹下需要备份的图片文件 /usr/bin/electronic-wechat 快速启动 /usr/share/applications/electronic-wechat.desktop Dash home快速启动图标 记录完整的安装过程 完整的压缩包已下载 linux-x64.tar.gz 解压 sudo tar zxvf linux-x64.tar.gz 将解压后的文件放在/opt下 sudo mv electronic-wechat-linux-x64/ /opt/electronic-wechat-linux-x64 创建终端下的快速启动命令 sudo ln -s /opt/electronic-wechat-linux-x64/electronic-wechat /usr/bin/electronic-wechat 创建在Dash Home下的快速启动图标 #Dash Home的图标一般在两个位置 /usr/share/applications #或者 ~/.local/share/applications(用户独立配置的基本都在这里) #只要在一个位置建立图标文件即可 sudo vi /usr/share/applications/electronic-wechat.desktop [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application Name=Electronic WeChat Icon=electronic-wechat.png …

修复UEFI模式下Manjaro Linux启动问题

原文链接:https://www.cnblogs.com/apocelipes/p/10192882.html 作者:@apocelipes 本文为作者原创,转载请注明出处:https://www.cnblogs.com/apocelipes/p/10192882.html 上周在更新Manjaro Linux的时候误触了电源键,导致内核更新了一半系统强制关机,重启时正常进入grub但无法正常引导进入系统。 由于不想重装系统(一大堆环境和工具的配置还是相当繁琐的),加上初步判断应该仅仅是内核引导镜像没能正常安装导致的问题,所以决定先用liveUSB进行急救。 需要准备的工具: 一个使用较新版本Manjaro Linux的liveUSB(可以使用dd将镜像直接写入u盘) 待修复设备需要联网环境(没有其实也不用担心,不过最好还是需要联网环境) 下面开始修复启动。 首先通过liveUSB启动,在liveUSB的中我们原先的系统文件是保存在电脑的磁盘上的,默认不会被挂载,所以我们先要把除了/home以外的系统目录挂载到当前的任意目录,我们选择挂载在/mnt中: sudo mkdir /mnt/manjaro sudo mount /dev/sda2 /mnt/manjaro # sda2为/分区所在设备,可以使用lsblk查看 随后是关键的一步,因为在UEFI下安装Manjaro Linux时我们都额外为/boot/efi/进行了单独的分区,所以我们这里也需要挂载它。默认挂载根目录时并不会挂载这个目录,因为它们不在同一个分区,我的efi目录根据lsblk显示位于/dev/sda1: $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 200M 0 part /boot/efi ├─sda2 8:2 0 50.8G 0 …

解决Windows系统下网盘同步图标不显示的问题

在Windows系统下同时安装几款同步盘客户端,均设置好文件同步,会发现在文件管理器中不是每个网盘都能显示同步状态。根据个人经验,只有一个网盘能够正常显示。可以通过修改注册表的方式来决定让哪一款网盘显示同步状态。 在开始菜单里找到注册表,打开,定位到 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers 会看到类似于下图的结果 我使用的是Nextcloud客户端,所以有OC开头的项目。如果使用Seafile,则会有包含Seafile的项目。下一步将需要显示同步状态的网盘的项目前置即可。我只保留了Nextcloud的几个项目。如果删除其他项目,建议在删除之前先导出注册表,便于日后恢复调整。

Cinnamon更改桌面语言

更改系统支持的语言 sudo vim /etc/locale.gen 取消注释需要使用的语言 要在启用的语言间切换,请安装软件包 mintlocaleAUR. 安装完之后在设置中会有“语言”选项,更改即可。 更改系统语言为中文之后将会获得对中文字体更好的支持。

CentOS更换源

新安装的CentOS系统,更换国内源的步骤: 1、打开CentOS的yum文件夹 输入命令cd  /etc/yum.repos.d/ 2、用wget下载repo文件,这是阿里云的源 输入命令wget http://mirrors.aliyun.com/repo/Centos-7.repo 当前目录是/etc/yum.repos.d/,刚刚下载的Centos-7.repo在当前目录下 3、备份系统原来的repo文件 mv  CentOs-Base.repo CentOs-Base.repo.bak 4、替换系统源里的repo文件 mv Centos-7.repo CentOs-Base.repo 5、执行yum源更新命令 yum clean all yum makecache yum update 完成。

一个HTTP请求的曲折经历

原文: https://www.neroht.com/article-detail/18 一个HTTP请求的曲折经历 nero发布于 2020-04-30 09:04:73 写在前面 作为程序员的我们每天都在和网络请求打交道,而前端程序员接触的最多的就是HTTP请求。平时工作中,处理网络请求之类的操作是最多的了。但是一个请求从客户端发出到被服务端处理、再回送响应,再被客户端接收这一个闭环的底层细节可能并没有深究过,本篇文章是我的一篇读书笔记,总结出来恰好涉及到了这一过程,分享出来希望可以对大家有所启发。 文中某些点如果表述有误,欢迎指出来,不胜感激。 从一个经典的面试题说起 从输入URL到页面展现的过程 输入URL后,会先进行域名解析。优先查找本地host文件有无对应的IP地址,没有的话去本地DNS服务器查找,还不行的话,本地DNS服务器会去找根DNS服务器要一个域服务器的地址进行查询,域服务器将要查询的域名的解析服务器地址返回给本地DNS,本地DNS去这里查询就OK了。 浏览器拿到服务器的IP地址后,会向它发送HTTP请求。HTTP请求经由一层层的处理、封装、发出之后,最终经由网络到达服务器,建立TCP/IP连接,服务器接收到请求并开始处理。 服务器构建响应,再经由一层层的处理、封装、发出后,到达客户端,浏览器处理请求。 浏览器开始渲染页面,解析HTML,构建render树,根据render树的节点和CSS的对应关系,进行布局,绘制页面。 这4个步骤包含了一个HTTP请求的完整生命周期,文章着重介绍第2步和第3步,也就是请求是如何在两个物理端点之间进行通信的。数据的发出和接收必然会经历一些处理、解析的过程,这些过程在系统的不同层次进行。 分层 一个HTTP请求从源端发出到在终端接收的处理过程都是要经过以下四层。其中每一层都有各自的协议。 我们先来理解一下协议是什么,协议是经过约定,双方共同承认,并且需要共同遵守的规则。上面的每一层,都有各自的协议,协议的执行者是通信链路两端内的对应层。每一层通过协议来理解数据,并进行处理。 上图中只举例出了最常见的协议,实际上每一层都有细分的协议: 应用层:应用程序负责将数据以相应规则(协议)进行包装,发给传输层 HTTP:超文本传输协议 FTP:文件传输协议 SMTP:简单邮件传送协议 SNMP:简单网络管理协议 传输层:负责将应用层传过来的数据进行分组,为确保终端接收数据的顺序和完整性,会对每个分组进行标记,交给网络层 TCP:传输控制协议 UDP:用户数据协议 网络层:负责将传输层发来的数据分组发送到目标终端 IP:网际协议 ICMP:Internet互联网控制报文协议 IGMP:Internet组管理协议 链路层:为网络层发送和接收数据单元 ARP:地址解析协议 RARP:逆地址解析协议 封装和分用 数据在经过每一层的时候都要被对应的协议包装,到达终端的时候,要一层一层的解包。这两个过程叫封装和分用。 发送时,用户数据被HTTP封装为报文,每一层会将上层传过来的报文作为本层的数据块,并添加自己的首部,其中包含了协议标识,这一整体作为本层报文向下传递。 接收时,数据自下而上流动,经过每一层时被去掉报文首部,根据报文标识确定正确的上层协议,最终到应用层被应用程序处理。 封装 源端发送HTTP报文时,报文会以数据流的形式通过一条已经打开的TCP连接按序传输,TCP收到数据流后会将其分割成小的数据块,每个小块被添加的TCP首部与数据块共同组成了TCP分组,分组经由网络层发送,网络层遵循IP协议,当收到分组发送请求后,会将分组其放入IP数据报,填充报头,将数据报发经由链路层发送出去。 这一过程经过每层的时候都会被增加一些首部信息,有时还需要增加尾部信息,每一层都会把数据封装到各自的报文中, 并在报文首部添加协议标识,这个过程叫封装。 分用 终端接收到一个以太网数据帧时,数据自底层向上流动,去掉发送时各层协议加上的报文首部,每层协议都要检查报文首部的协议标识,从而确定上层协议,保证数据被正确处理,这个过程叫分用。 终端从链路层接收到数据请求后,进入网络层对数据进行解析,交给给传输层,校验分组顺序和完整性,从数据块中取出数据,得到HTTP报文,交给应用层进行处理。这个过程会逐层剥离报头还原数据。 逐层分析 我们已经知道,数据是从源端自上而下到终端自下而上被一层层处理的,现在就来看一下每层都做了什么事情。 HTTP HTTP属于应用层,用户触发交互所产生的行为数据和服务端对此的响应都由它封装成HTTP报文,再交由下层协议进行处理。报文的作用是客户端与服务端沟通的载体,双方都要遵循统一规则对信息进行处理,这一规则称为HTTP。 …

ASCII – 维基百科

https://zh.wikipedia.org/wiki/ASCII ASCII(发音: /ˈæski/ ASS-kee[1],American Standard Code for Information Interchange,美国信息交换标准代码)是基于拉丁字母的一套电脑编码系统。它主要用于显示现代英语,而其扩展版本延伸美国标准信息交换码则可以部分支持其他西欧语言,并等同于国际标准ISO/IEC 646。1968年版ASCII编码速见表 美国信息交换标准代码是这套编码系统的传统命名,互联网号码分配局现在更倾向于使用它的新名字US-ASCII[2]。 美国信息交换标准代码是美国电气和电子工程师协会里程碑之一。 目录 1概览 2控制字符 3可显示字符 4缺点 5参见 6参考资料 概览 ASCII 由电报码发展而来。第一版标准发布于1963年[3][4],1967年经历了一次主要修订[5][6],最后一次更新则是在1986年,至今为止共定义了128个字符;其中33个字符无法显示(一些终端提供了扩展,使得这些字符可显示为诸如笑脸、扑克牌花式等8-bit符号),且这33个字符多数都已是陈废的控制字符。控制字符的用途主要是用来操控已经处理过的文字。在33个字符之外的是95个可显示的字符。用键盘敲下空白键所产生的空白字符也算1个可显示字符(显示为空白)。 控制字符 说明: Unicode表示法:当我们想在画面或纸张上表示这些控制字符时,就会显示成这个样子。过于老旧的系统或浏览器可能会看不到。使用微软任一中文输入法,输入`U2400即可看到␀,输入`U2401可看到␁,依此类推。 脱出字符表示法:通常用于终端连线(例如Telnet通信协议),以脱出字符^开头,再接一个符号,用来让这些控制字符得以在画面上显现。虽然看起来是两个字符,但在终端上实际只有一个字符。在绝大部分的终端系统中,包括Windows的命令提示字符(cmd.exe)、Linux和FreeBSD,都可用Ctrl代表脱出字符,输入想要的ASCII控制字符。例如想输入空字符,就要输入Ctrl+2,而非^@,后者会显示成两字符,前者只会显示成一字符。 二进制 十进制 十六进制 缩写 Unicode表示法 脱出字符表示法 名称/意义 0000 0000 0 00 NUL ␀ ^@ 空字符(Null) 0000 0001 1 01 SOH ␁ ^A 标题开始 0000 0010 2 02 STX ␂ ^B 本文开始 0000 0011 3 …