其实具体的安装流程并不难,主要在于资源的收集以及版本的绑定上
从目前的情况来看,CUDA版本和PyTorch和Py自身版本是绑定的,而cuDNN和CUDA的大版本绑定,而其中主要受限的其实是PyTorch支持的CUDA版本,因此,这里采用CUDA来适配PyTorch的方式
其实具体的安装流程并不难,主要在于资源的收集以及版本的绑定上
从目前的情况来看,CUDA版本和PyTorch和Py自身版本是绑定的,而cuDNN和CUDA的大版本绑定,而其中主要受限的其实是PyTorch支持的CUDA版本,因此,这里采用CUDA来适配PyTorch的方式
随着业务开发,微服务和容器部署已经越来越普及,于是想着自己搭建一个私有的容器镜像仓库,DockerHub不是不能用,但就是慢,之前在个人服务器上部署过官方提供的registry镜像,但实在是太简陋了,没有管理面板,而且如果需要删改仓库里的镜像还得改配置文件打开。业务的私有仓库用的是Harbor,由VMware 公司中国团队为企业用户设计的 Registry server 开源项目,功能强大且齐全,而且有中文支持,故打算整一个
由于项目需要,硬件生产商提供的是C SDK,需要自行编译一个已有的cpp项目接入测试,按照说明文档,其使用CMake和vcpkg管理构建和依赖
我使用的OneIndex是这个OneIndexN
首先说一下为什么要用物理安全密钥
数据的加解密和签名操作,均由密钥来进行,在非对称加密中也被称之为私钥和公钥。密钥和私钥要被严格保护以保障安全,常用的方式有存储在一个安全的服务器,或者硬盘甚至可移动设备中。为了防止密钥被窃取后轻而易举的被盗用,还可以对其密钥文件进行加密,但是知晓正确密码的人依然有能力获得私钥的具体内容并随意拷贝
而物理安全密钥却不同,虽然其表现出来只是换了个密钥的存储介质。可一旦证书在内部被生成或者从外部被导入,进入硬件的私钥将被永久存储在硬件中无法导出,即使是采用外部导入的方式,只要保证除硬件之外没有其它私钥副本,那么这个证书私钥就是安全的,这也是物理安全密钥根本区别于其它可移动可拷贝密钥存储方式的原因,最终数据的加密与签名操作均由硬件内部使用私钥处理得来,即使是拥有操作密码来进行签名,但被拔除物理硬件之后就无法再进行后续操作
因此可以预见,使用物理密钥的方式,既可以使用私钥验证的方式来避免使用密码带来的泄露风险,在公共主机中,也无需临时下载密钥文件,因此也能避免忘记删除密钥文件或被未知恶意软件窃取。物理安全密钥可以插在任何兼容设备上,并安全地签名数据,全程不会暴露密钥,使得在公共主机中安全连接服务器成为可能
今天在开发中想结合最近的对于Go的学习,于是便想尝试将小程序后端请求中的JSON数据换成protobuf,这在其他语言甚至原生的js中都挺好实现的,有官方的语言转换工具就不用说了,但是小程序的框架比较特殊,基本上是屏蔽了一些动态执行以及反射相关的能力,这让protobuf以反射作为生成对象的核心实现无法完成。 查找了许多方案,小程序虽然支持npm,但没有针对小程序进行优化的基本上都用不了,别说官方库了,即使是第三方的也无法使用,后来经过反复实现,总结出了一个方案,以后可能有更好的方案,这个方案是用静态生成的库和接口描述实现来使用protobuf
前言:最近研究Python调用C/C++的问题,得益于CPython的实现,理论上只要把C写成Python认识的结构就能被识别了,故查阅了相关资料。要实现Python的接口需要一些库文件和数据类型,不过后面发现Boost库可以为这个过程提供更Python地封装,所以就转向Boost的配置,只可惜学艺不精,于是乎没想到就弄了一晚上。