Other

linux安装conda后不生效的操作方法

1、先安装conda,https://www.cnblogs.com/qiaoer1993/p/13612485.html。正常情况下重新打开一个终端后默认的环境就是conda的默认base环境。如果不生效的话请安第二步~ 2、在/etc/profile里面添加如下: # conda,这是把conda的环境加入系统的环境变量export conda=/root/miniconda3export PATH=$PATH:$conda/bin # 这一步是系统进入conda的默认base环境 source activate 3、在终端执行source /etc/profile,环境变量生效;操作之后每次打开一个终端都是conda的默认环境。

在VMware中利用Packstack快速安装openstack(亲测成功)

利用Packstack包在Vmware中安装openstack,采用的模式是allinone。  步骤如下:  1. 首先在vmware workstation中安装CentOS 7虚拟机(需要开启CPU虚拟化),完成基本的设置,比如hostname, IP地址等  2. 更新一下CentOS [root@openstack ~]# yum update  3. 关闭Selinux以及防火墙,编辑vim /etc/selinux/config文件,设置SELINUX=disabled,并disable /Stop防火墙 [root@openstack ~]# systemctl stop firewalld [root@openstack ~]# systemctl disable firewalld  4. 安装openstack 在线仓库: [root@openstack ~]#yum install -y https://www.rdoproject.org/repos/rdo-release.rpm  安装完成以后,可以cd到/etc/yum.repos.d看是否有rdo-replease.rpm root@openstack ~]# cd /etc/yum.repos.d/ [root@openstack yum.repos.d]# ls CentOS-Base.repo CentOS-Debuginfo.repo CentOS-Media.repo CentOS-Vault.repo rdo-qemu-ev.repo rdo-testing.repo CentOS-CR.repo CentOS-fasttrack.repo CentOS-Sources.repo CentOS-x86_64-kernel.repo rdo-release.rep  5. 安装packstack安装工具 [root@openstack ~]# yum install -y openstack-packstack  6.

Linux虚拟机报错grub rescue解决步骤

/boot 分区内核文件丢失 实验准备 1) 准备:rm -rf /boot/* 2) 系统启动报错截图 修复步骤 重启显示logo时 按 Esc,选择从光驱启动 或者关机再选择打开电源时进入固件 移动至CD-ROM Drive,按住shift-+调至上面,按住F10保存即可 进入救援模式 选择第三个 选择第二个 选择 1)continue并在下步直接回车 切换至真正的根文件系统 chroot /mnt/sysimage 挂载系统光盘 mount /dev/cdrom /mnt/ 此处显示我已挂载 配置本地 yum 源信息 按图配置其文件内容 yum clean all yum makecache 重新安装内核文件 yum reinstall kernel* 生成/boot/grub2/grub.cfg 文件 cd /boot/ mkdir grub2 grub2-mkconfig -o /boot/grub2/grub.cfg 修复引导程序 grub2-install /dev/nvme0n1 exit 退出 2 次,关机 重新选择启动项 把+Hard Drive调至第一项 至此已修复成功

5 分钟教你快速掌握 GitHub Actions 自动部署博客

自从 GitHub 宣布 GitHub Actions 在平台上对所有开发人员和存储库可用以来,GitHub Actions 越来越受欢迎。很多第三方平台在生态系统中有速度等限制,将进一步推动开发人员将他们的软件自动化迁移到 GitHub Actions。 在本文中,我想向你展示我如何使用 GitHub Actions 发布我在开源项目中维护的 npm 包。如果你遵循由 GitHub 拉取请求工作流程组成的 GitHub 流程,那么这将进一步统一团队和社区贡献者的工作流程的和提升他们的体验。 GitHub Actions GitHub Actions 是 GitHub 开发的一项技术,旨在为开发人员提供一种围绕持续集成自动化其工作流程的方法——帮助他们构建、部署、安排重复性任务等。GitHub Actions 原生可用并集成到 GitHub 存储库中,并具有来自社区贡献者的许多可重用工作流,例如发布 npm 包、发布 docker 图像、运行安全测试等等。 Github Action 本质就是 Github 推出的持续集成工具, 每次提交代码到 Github 的仓库后,Github 都会自动创建一个虚拟机(例如 Mac / Windows / Linux),来执行一段或多段指令,例如: npm install npm run build 我们集成 Github Action 的做法,就是在我们仓库的根目录下,创建一个 .github 文件夹,里面放一个 *.yaml 文件, 这个 Yaml 文件就是我们配置 Github Action 所用的文件。 Github Action 的使用限制 每个 Workflow 中的 job 最多可以执行 6 个小时 每个 Workflow 最多可以执行 72 小时 每个 Workflow 中的 job 最多可以排队 24 小时 在一个存储库所有 Action 中,一个小时最多可以执行 1000 个 API 请求 并发工作数:Linux:20,Mac:5 什么是 GitHub Workflow? GitHub 工作流是一组基于触发器或基于 cron 的计划运行的 job 作业。作业由组成自动化工作流程的一个或多个步骤组成。我们通过创建 YAML 文件来创建 Workflow 配置。

python 投票

import requests,sys,time,re head1={'Host':'2865.litevote.com', 'Content-Length':'60', 'Accept':application/json, text/plain, */*,'jwt':'', 'User-Agent':'Mozilla/5.0 (Linux; Android 10; Redmi Note 8 Pro Build/QP1A.190711.020; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/86.0.4240.99 XWEB/3211 MMWEBSDK/20210501 Mobile Safari/537.36 MMWEBID/2997 MicroMessenger/8.0.6.1900(0x28000653) Process/toolsmp WeChat/arm64 Weixin NetType/WIFI Language/zh_CN ABI/arm64', 'Content-Type':'application/json;charset=UTF-8','Origin':'http://2865.litevote.com','X-Requested-With':'com.tencent.mm','Referer':'http://2865.litevote.com/votes/?id=Mjg2NTo0MDAzNg&type=0', 'Accept-Encoding':'gzip, deflate','Accept-Language':'zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7', 'Cookie':'Hm_lvt_7bd8ccc2fac7ab9c7ea2829ca3784fd0=1650932478; jwt_inner=G%2F4Lm6G36MIjJY8x6%2BaUIvFYPW%2ByQr81bXEl08GHqk%2BjiQq5pQukxYn8eFyNspdHT217WLjI%2FxAWj0I5xopDjtcRbyQLrNuvN84F8p5PyIvRY8T4x5oKNVrv7N6EUhhT7od2UpkArUJC9SvBM0IxoKus%2BjDsD5Jv1Hax9UBtO5uozzCeg%2B22QtzH%2BHruyohDAJb%2FcBB2DkTrGqWsAHVjy5tqGOCrLJfghfxb0aEGeEGvU0PydXU3wu0%2FYTIbFrdsfeUK6OlNypO7f0IcUc5q2xo6hyhs71Ec%2Bwb6pKxB9Jwb4PSrnEfZMYIyD56XVM%2F5R6xvhDM9kj5tRNnEDKUWuAqF6hBdnpv8fUzKg%2BwL%2FJs%3D; Hm_lpvt_7bd8ccc2fac7ab9c7ea2829ca3784fd0=1651009992'} uu=MQQBrowser/26 Mozilla/5.0 (Linux; U; Android 2.3.7; zh-cn; MB200 Build/GRJ22; CyanogenMod-7) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 head1['User-Agent']=uu session=requests.session() url=http://2865.litevote.com/api/vote/submit url1=http://2865.litevote.com/api/vote/options?id=2865&page=1&size=10&keyword=50&isPreview=0 url2=http://2865.litevote.com/api/vote/options?id=2865&page=1&size=10&keyword=&isPreview=0 tt1=int(time.time()) head1[Cookie]='Hm_lvt_7bd8ccc2fac7ab9c7ea2829ca3784fd0='+str(tt1)+'; jwt_inner=G%2F4Lm6G36MIjJY8x6%2BaUIvFYPW%2ByQr81bXEl08GHqk%2BjiQq5pQukxYn8eFyNspdHT217WLjI%2FxAWj0I5xopDjtcRbyQLrNuvN84F8p5PyIvRY8T4x5oKNVrv7N6EUhhT7od2UpkArUJC9SvBM0IxoKus%2BjDsD5Jv1Hax9UBtO5uozzCeg%2B22QtzH%2BHruyohDAJb%2FcBB2DkTrGqWsAHVjy5tqGOCrLJfghfxb0aEGeEGvU0PydXU3wu0%2FYTIbFrdsfeUK6OlNypO7f0IcUc5q2xo6hyhs71Ec%2Bwb6pKxB9Jwb4PSrnEfZMYIyD56XVM%2F5R6xvhDM9kj5tRNnEDKUWuAqF6hBdnpv8fUzKg%2BwL%2FJs%3D; Hm_lpvt_7bd8ccc2fac7ab9c7ea2829ca3784fd0='+str(tt1+20000) shuju={ id: Mjg2NTo0MDAzNg, option_ids: [85093], isPreview: 0 } shuju1={ id: Mjg2NTo0MDAzNg, option_ids: [84993], isPreview: 0 } aa=session.

消息队列与快递柜之间的奇妙关系

提到消息队列可能一些朋友经常听别人说起一些名词,比如:服务程序解耦,处理流量削峰,通过异步处理提升用户体验,缓冲批处理提高处理性能。笔者擅于白话解说,所以我就不用专业的术语去解释专业的问题了。我一直觉得消息队列的功能和快递柜的功能非常相似,怎么个相似法呢?让我来详细给你说说。 一、白话消息队列 我们来将快递柜与消息队列做一个对比 消息队列比作快递柜:有很多厂家生产快递柜,如:丰巢(apache kafka),速递易(alibaba RocketMQ),近邻宝(ActiveMQ)等等,反正常用的就这几个。快递柜负责临时保存邮件,消息队列负责临时保存消息数据。 快递员比作消息生产者:快递员负责向快递柜投递邮件,生产者负责向消息队列投递消息。异曲同工之妙啊! 消费者比作消息消费者: 可能是这个例子太贴切了,以至于这句怎么看都是废话。废话也还是要说,生活中的消费者取邮件,程序中的消费者取消息数据。 二、快递柜(消息队列)带来的好处 我们先回顾一下在没有快递柜的日子里是怎么度过的:某天早上突然接到快递员电话:兄弟,有你的快递啊。心里想真糟糕:“你早不来晚不来,我马上就要上班了,你这个时候来。好吧,我等你一会”。结果有可能快递员很不靠谱,一会说堵车,一会说马上到,等来等去你上班迟到了。这种情况让你很崩溃! 突然有一天,小区里突然出现了一个叫做快递柜的东西,这东西好啊。兄弟,有你快递啊,心想谁是你兄弟:啊,你放快递柜里面吧,我晚上下班回来取。快递员愉快的把快递放入快递柜,开始打下一个电话,一早上10个邮件。如果每个都送上门快递员最少要半小时。现在好了,9个放快递柜,1个用户要求送上门,10分钟就搞定了。快递员觉得这个东东真的很好! 快递员高兴了,消费者用户其实也很满意,有的购物狂一天有可能收10来个邮件。没有快递柜的时候,快递员来一个电话就去取一次(等一次)快递。有了快递柜,下班的时候就一起全都取了。上面的例子,体现了消息队列(快递柜)的几个优越性,请读者仔细品评: 异步解耦:有了快递柜,消费者不用等待快递员,用户体验增强。消费者与生产者(快递员)之间解耦,不会因为对方的操作行为,影响自己独立处事的程序。用户不用疲于等待与接收事件阻塞耗时。 流量削峰:我们假定一种极端的情况,你通过各个渠道买了1000本书,突然某一小时集中的给你打电话。你肯定不具备一个小时收1000个邮件的能力,所以你让快递员将邮件放入快递柜。所以你就可以按照自己的处理能力,按照自己的时间安排去取邮件。同样我们的消费者程序在面临多用户、高并发的请求情况下,将数据放入消息队列保存可以将流量数据削峰,按照程序能够处理的能力和资源进行数据消费。 缓冲批处理:生产者批量投递,爽!消费者一次性取多个邮件,爽! 三、引入快递柜带来的缺点 说了这么多的优点,那么快递柜有没有缺点呢?当然有 引入复杂度。毫无疑问,快递柜(消息队列)这东西是多出来的,在原来的收取过程中是不存在的。所以需要地方放它,还需要防火、防盗防潮,需要去维护它。消息队列中间件也是一样的,你需要服务器区安装它,还要对它进行维护。 会导致暂时的数据不一致。 如果没有快递柜,你收到了邮件件就是真的收到了。但是使用快递柜之后,你收到了邮件放入快递柜的消息,但是与你真的取到邮件这中间会有一定的延时。当然你最终还是会取到邮件,选择消息队列快递柜,就是要忍受暂时不一致,接受最终一致性。 当然极端情况下,快递柜坏了,你要不可避免地接受邮件可能会丢失的事实,对于安保系数高的小区这几乎不会发生。 欢迎关注我的博客,更多精品知识合集 本文转载注明出处(必须带连接,不能只转文字):字母哥博客 - zimug.com 觉得对您有帮助的话,帮我点赞、分享!您的支持是我不竭的创作动力!。另外,笔者最近一段时间输出了如下的精品内容,期待您的关注。 《kafka修炼之道》 《手摸手教你学Spring Boot2.0》 《Spring Security-JWT-OAuth2一本通》 《实战前后端分离RBAC权限管理系统》 《实战SpringCloud微服务从青铜到王者》

LeetCode 0081 Search in Rotated Sorted Array II

原题传送门 1. 题目描述 2. Solution 1 1、思路分析 The idea is the same as the previous one without duplicates 1) everytime check if target == nums[mid], if so, we find it. 2) otherwise, we check if the first half is in order (i.e. nums[left]<=nums[mid]) and if so, go to step 3), otherwise, the second half is in order, go to step 4) 3) check if target in the range of [left, mid-1] (i.

新能源与智能化汽车

新能源与智能化汽车 新能源汽车市场在2021年迎来爆发后,2022年开年首月继续保持高增长态势。乘联会 数据显示,1 月新能源乘用车批发销量达到 41.2 万辆,同比增长 141.4%;渗透率高达 19.0%, 相比2021年同期提升 10.6 个百分点。 本文主要文献 参考链接 https://mp.weixin.qq.com/s/0OtzyP252sa9koObULM4Xg https://baike.baidu.com/item/%E8%87%AA%E5%8A%A8%E9%A9%BE%E9%A9%B6%E6%B1%BD%E8%BD%A6/4881925?fr=aladdin https://baijiahao.baidu.com/s?id=1725983099368881275&wfr=spider&for=pc   积极转型中的头部整车厂包括吉利、比亚迪、长城、上汽集团等; 受益二轮车新国标更换、管理层内部改善的龙头爱玛科技; 混动产业链带来零部件新增量,发动机控制方面推荐菱电电控,三合一赛道的企业包括巨一科技、卧龙电驱、精进电动,小三合领域关注欣锐科技等; 热管理领域主要参与企业有三花智控、拓普集团等。 电驱和电控方面,整车厂、传统Tier1供应商和第三方供应商角逐,国内依托自主整车品牌的布局和第三方厂商的积累,涌现了比亚迪、蔚然动力(蔚来)、蜂巢动力(长城)、威睿电动(吉利)等整车品牌旗下的厂商,以及方正电驱、汇川技术、卧龙电驱、上海电驱动等第三方厂商,而传统Tier1供应商主要是博世、大陆、法雷奥、西门子等海外巨头。 随着自主整车品牌和国内“三电系统”供应商的崛起,自然也将带动上游车用电子零部件的国产替代。 汽车零部件种类与数量繁多,且涉及到不同的行业和领域,在技术标准、生产方式等方面存在较大的差距,目前国家关于汽零制造业相关政策主要分布在汽车产业相关政策中。 一系列汽车产业政策的发布,也对零部件产业提出更高要求。 自动驾驶汽车(Autonomous vehicles;Self-driving automobile )又称无人驾驶汽车、电脑驾驶汽车、或轮式移动机器人,是一种通过电脑系统实现无人驾驶的智能汽车。在20世纪已有数十年的历史,21世纪初呈现出接近实用化的趋势。 自动驾驶汽车依靠人工智能、视觉计算、雷达、监控装置和全球定位系统协同合作,让电脑可以在没有任何人类主动的操作下,自动安全地操作机动车辆。 汽车自动驾驶技术包括视频摄像头、雷达传感器以及激光测距器来了解周围的交通状况,并通过一个详尽的地图(通过有人驾驶汽车采集的地图)对前方的道路进行导航。这一切都通过谷歌的数据中心来实现,谷歌的数据中心能处理汽车收集的有关周围地形的大量信息。就这点而言,自动驾驶汽车相当于谷歌数据中心的遥控汽车或者智能汽车。汽车自动驾驶技术物联网技术应用之一。 沃尔沃根据自动化水平的高低区分了四个无人驾驶的阶段:驾驶辅助、部分自动化、高度自动化、完全自动化。 1、驾驶辅助系统(DAS):目的是为驾驶者提供协助,包括提供重要或有益的驾驶相关信息,以及在形势开始变得危急的时候发出明确而简洁的警告。如“车道偏离警告”(LDW)系统等。 2、部分自动化系统:在驾驶者收到警告却未能及时采取相应行动时能够自动进行干预的系统,如“自动紧急制动”(AEB)系统和“应急车道辅助”(ELA)系统等。 3、高度自动化系统:能够在或长或短的时间段内代替驾驶者承担操控车辆的职责,但是仍需驾驶者对驾驶活动进行监控的系统。 4、完全自动化系统:可无人驾驶车辆、允许车内所有乘员从事其他活动且无需进行监控的系统。这种自动化水平允许乘从事计算机工作、休息和睡眠以及其他娱乐等活动。 车载芯片,国内谁在第一梯队?   目前,地平线、华为、黑芝麻等国产芯片公司的销售都是以中国自主品牌乘用车为主,因此估算中国自主品牌乘用车的市场规模来分析这些公司的发展空间。2025年是一个分水岭,20到25年L1和L2的功能渗透率将会增长到顶,然后从25年开始L2以上的渗透率将接力快速增长,L1和L2的渗透率则会逐渐下降。 地平线、黑芝麻、华为、Mobileye、英伟达, 新的十年,市场格局的两大阶段。本文内容如下:   随着ADAS和DMS功能渗透率和级别的不断提高,传感器数量和算力要求也随之而提升,并直接刺激车载AI芯片的量价齐升。面对广阔的国内乘用车市场,未来高等级芯片赛道的参与者主要有国内的地平线、黑芝麻、华为,以及国外的Mobileye、英伟达和特斯拉。   ASIL(Automotive Safety Integration Level),即汽车安全完整性等级,描述系统能够实现制订安全目标的概率高低。在中国,供应商的部件一般需要达到ASIL B标准才能被传统大型车企允许作为ADAS等辅助驾驶模块的核心部件。部分比较激进的车企可能会接受本身不符合ASIL B要求的芯片,但这样的方案还需要通过增加其他芯片和零部件的冗余设计来保障整个系统的功能安全。   1、地平线 地平线通过以“算法+芯片+工具链”为基础技术平台的芯片,提供智能驾驶解决方案,赋能智能物联网。地平线作为二级供应商,负责基础技术平台的搭建和完善。产品线包括2019年推出的Journey 2、2020年推出的Journey 3和计划推出的Journey 5。覆盖了从L2的辅助驾驶、智能座舱的人机交互、到接近L2+的辅助驾驶和自主泊车。另外Journey 5对标特斯拉的FSD,面向高等级的自动驾驶,基于中央电子电器架构,即中央车载计算机架构的芯片。   地平线的业务模式定位Tier 2供应商。客户包括一级供应商、整车厂、和出行服务商,提供的方案包括芯片、硬件的参考设计、以及提供工具链和算法。地平线是一家根植于中国的公司,核心研发团队深耕中国市场,认为具备本土化服务能力将有利于提高地平线相对国外对手的竞争优势。   2、黑芝麻

关于SpringBoot整合MyBatis-Plus乐观锁不生效的问题解决方案

关于SpringBoot整合MyBatis-Plus乐观锁不生效的问题解决方案 SpringBoot整合Myabtis-Plus 在与官网配置一致的情况下依旧无法生效,如下整合mybatis-plus 1、依赖导入 <!-- mybatis-plus--> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.4.3.4</version> </dependency> 其余的springboot与mysql相关的依赖就无需展示 配置文件配置 mybatis-plus: global-config: db-config: # 逻辑删除,删除标志 logic-delete-value: 1 # 逻辑删除,未删除标志 logic-not-delete-value: 0 type-aliases-package: com.fang.pojo configuration: # mybatis-plus日志 log-impl: org.apache.ibatis.logging.stdout.StdOutImpl 2、数据库插入 数据库以此为例 DROP TABLE IF EXISTS sys_user; CREATE TABLE rbac_plus.sys_user ( id INT AUTO_INCREMENT NOT NULL COMMENT '主键ID', name VARCHAR(50) NOT NULL COMMENT '名称', password VARCHAR(500) NOT NULL COMMENT '密码', email VARCHAR(200) NOT NULL COMMENT '邮箱', state INT NOT NULL DEFAULT 0 COMMENT '状态,0为正常,1为异常', create_time DATETIME NOT NULL COMMENT '创建时间', update_time DATETIME COMMENT '修改时间', deleted INT DEFAULT 0 COMMENT '假删除', version INT DEFAULT 1 COMMENT '乐观锁', PRIMARY KEY (id) )ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='user表'; INSERT INTO `rbac_plus`.

处理机管理——进程互斥的硬件实现

中断屏蔽方法: 利用“开/关中断指令”实现(与原语的实现思想相同,即在某进程开始访问临界区到结束访问为止都不允许被中断,也就不能发生进程切换,因此也不可能发生两个同时访问临界区的情况) 优点:简单高效 缺点:不适用于多处理机;只适用于操作系统内核进程,不适用于用户进程(因为开/关中断指令只能运行在内核态,这组指令如果能让用户随意使用会很危险) 关中断:关中断后即不允许当前进程被中断,也必然不会发生进程切换 开中断:直到当前进程访问完临界区,再执行开中断指令,才有可能有别 的进程上处理机并访问临界区 TestAndSet指令(TS/TSL): TSL指令是用硬件实现的,执行的过程不允许被中断,只能一气呵成 相比软件实现方法,TSL指令把“上锁”和“检查”操作用硬件的方式变成了一气呵成的原子操作。 优点:实现简单,无需像软件实现方法那样严格检查是否会有逻辑漏洞;适用于多处理机环境 缺点:不满足“让权等待”原则,暂时无法进入临界区的进程会占用CPU并循环执行TSL指令,从而导致“忙等” swap指令(Exchange/XCHG): 是用硬件实现的,执行的过程不允许被中断,只能一气呵成 逻辑上来看Swap和TSL并无太大区别 优点:实现简单,无需像软件实现方法那样严格检查是否会有逻辑漏洞;适用于多处理机环境 缺点:不满足“让权等待”原则,暂时无法进入临界区的进程会占用CPU并循环执行TSL指令,从而导致“忙等”