
https://www.shalol.com/minlearnprogramming/:一种最小编程学习集和开发栈方案。
能力说明:
掌握计算机基础知识,初步了解Linux系统特性、安装步骤以及基本命令和操作;具备计算机基础网络知识与数据通信基础知识。
暂时未有相关云产品技术能力~
阿里云技能认证
详细说明本文关键字:teamviewer保持在线的替代品把vscode terminal当虚拟主机管理面板。remote-openfaas,打造vscodeos:用插件打通openfaas界面到vscodeonline,实现ide.sh与云函数容器对接 在前面《云主机上部署pai》,《云主机上部署openfaas》中,我们用同样风格的脚本写出了在云主机上部署的二个paas面板,pai类似虚拟主机管理器,而openfaas是paas->faas,综合这二者都是部署和devops面板,它们在透出的界面5523,8080处用web操作。然后我们在《戒掉PC,免pc开发,cloud ide and debug设想》又遇到了vscodeonline,这三者都是云主机构造paas APP以“在线开发和部署”的OS扩展,体验良好度又都有前后分离十分接近,因此,我们这次也把vscodeonline集成在这里,组成成为minstackos的主要部分。未来,我们把所有讲到的paas app用这些面板串联起来,使它们成为可一键在线开发和部署的APP,形成minstackos的appstore来源。 在《在openfaas面板上安装onemanager》中我们讲过云主机的ssh往往是很容易断的,如果是graphic linux下,需要tv这样的这样的远程桌面方案来保持长时间在线,但实际上,vscodeonline也有linux终端面板。remote-ssh连接的vscodeonline可以保持长时间ws在线而且可以点上面的一个图标扩展到整个IDE的编辑区。因此体验上,后者可成为前者的良好替代。 好了不废话了。下面依然在一台ubuntu 1h2g上进行。 基础 一些变量 MIRROR_PATH="http://default-8g95m46n2bd18f80.service.tcloudbase.com/d/demos" # the code-server web ide CODE_SERVER_PATH=${MIRROR_PATH}/codeserver 安装codeserver 脚本被做成融合成安装pai和openfaas的风格,按standalone方式安装,以root身份运行。你可以集成自己需要的语言和插件服务到这个IDE,以做到尽量开箱即用。 # install codeserver installCodeserver() { echo "=====================codeserver install progress=======================" msg=$(mkdir -p ~/.local/lib/code-server-3.5.0 wget --no-check-certificate -qO- ${CODE_SERVER_PATH}/v3.5.0/code-server-3.5.0-linux-amd64.tar.gz > /tmp/code-server-3.5.0-linux-amd64.tar.gz && tar -xvf /tmp/code-server-3.5.0-linux-amd64.tar.gz -C ~/.local/lib/code-server-3.5.0 --strip-components=1 rm -rf /tmp/code-server-3.5.0-linux-amd64.tar.gz ln -s ~/.local/lib/code-server-3.5.0/bin/code-server ~/.local/bin/code-server PATH="~/.local/bin:$PATH" # systemd service start rm -rf ~/.config/code-server/config.yaml cat << 'EOF' > ~/.config/code-server/config.yaml bind-addr: 0.0.0.0:5000 auth: password password: pleasecorrectme cert: false EOF # systemd service start rm -rf /etc/systemd/system/code-server.service cat << 'EOF' > /etc/systemd/system/code-server.service [Unit] Description=code-server After=network.target [Service] Type=exec ExecStart=~/.local/bin/code-server Restart=always User=root [Install] WantedBy=default.target EOF systemctl daemon-reload && systemctl enable code-server systemctl start code-server 2>&1) status=$? updateProgress 95 "$msg" "$status" "code-server install" } 安装完成后记得修改~/.config/code-server/config.yaml下的密码,端口为5000。如果你要用上证书,就最好搭配脚本中的nginx+certbot申请的那个。cert: false也可以用假的localhost的那个,但是基本没有什么用。 其实,利用那个remote-container,可以把openfaas-cli跟vscode连起来,利用工程源文件下的yml模板(.pai.yml,openfaas-cli.yml,etc...)文件打造一个带开发部署的工程资源组织文件,形成remote-openfaas效果:多环境多语言下,需要频繁切换环境,一次开发总是跟一次塔环境开始的,这也是vagrant和docker对于开发的意义(以前是vm,没有模板机制),而docker用于开发也用于部署。以后一套APP天然就有一个online webide守护,自带开发环境了。 (此处不设回复,扫码到微信参与留言,或直接点击到原文)
本文关键字:分布式IDE,cloudide,远程编码,远程调试,jupyter with visual debugger support 编程界有关于语言的圣战,OS之争,也甚至有代码编辑器是选择cui text ide还是gui IDE的选择的讨论。这次我们讲的是云IDE,其实,我们一直讲的是devops和云可视IDE这类服务端直接支持的开发部署,从《ellie可视化》到《docker as snippter空间》,从《一种设想:在网盘里coding,debuging,运行linux rootfs作全面devops》到《分布式IDE:osx一个完美的开发集中》,这些都是从不同层面去说的,毕竟这样一个工作要解决好多问题,而为什么要把开发做上云的理由也很明了:devops在云端,服务器环境入口网络好。我们也一直在寻求某种“免PC的开发”:如果把发布部署做上云了,如在《去windows去PC,打造for程序员的碎片化programming pad硬件选型》中所讲一样,我们甚至不需要一台PC仅需要一个平板就可以在云端构建,或者一个专用programmingpad,,实现戒掉PC把一切放到远端,免除本地重复部署,比如借助devops可以在一次性的虚拟沙盒环境中编程部署,干净,永远守护,开箱待用,,----- 它是云OS扩展一级的东西,与lnmp,openfaas云开发云部署同级,如果说后者解决的是部署前者解决的就是开发调试,当然也有将二者结合的,我们甚至谈到一种天然绑定debug设施的os和appstack结构(press esc切换运行态/开发态)。 云 IDE是新概念吗?不不不,早在 2010 年就有成熟的产品了,其实类似baota panel的文件管理器当cloud ide也可以,但是毕竟它缺乏真正的开发所需的一条路径上的东西。云调试与云编程支持。这里的技术是把IDE分布化,基础原理依然是设置协议(语言服务,调试服务API后端化)和前后端分开,这样前端可以ported到任何设备,《用开发本地tcpip程序的思路开发webapp》讲到,Api分离,实际上是从业务逻辑中分离了gui栈,这是一种经典的抽象,也是很久以前桌面界的编程方案了。其实web不是没有过前后分离,只不过很晚才将前后分离做到云函数和devops式建立api服务池的程度。 目前有很多实现,但我们接确到的大都就是jupyter和vscode online这二个,jupyter面向文档嵌入代码领域而vs code online面向真正的传统IDE在线化,它们二者都有明显的前后协议层支持。针对语言编程和调试。它们二者都可以与docker打通,而docker实际上是一个贯通开发部署综合的devops,所以与devops又有了联系。 vscode/vscode online 微软向云靠拢其营收已超过windows本身。github,azure,onedrive,vscode/vscodeonline都是例子,微软在 Build 2019 开发者5月份的大会上宣布了 Web 版本的 VS Code,即 Visual Studio Online Private Preview。在 2019 11 月 4 日发布公开预览版的 Visual Studio Online。 实现: 其实vscode本来就是一个分布式IDE和云化版本。(vscode本来一开始就是面向要被online的,它的插件设计规范中的Language Server Protocol,Debug Adapter Protocol就决定了,vscode的设计师一开始就是从分布式角度去做的),前端上,从页面上直观地看,VS Online 就是一个 Web 版的 VS Code,vscode使用Electron(原来叫 Atom Shell),桌面vscode最初也是由atom而来,这使得前端很容易被ported到web,但这其实只是它的一个前端界面,而 VS Online 更强大的能力来自于vscode-server+remote development extensions,这里我们暂时把web或桌面那个editor界面称为前端,vscodeserver+remotedevelopment exs称为后端。 在vscode中,如果你使用了remote-devopment中的ssh组件(一般地,你用remote-ssh远程开发,用remote-container本地),会自动在远端下载vscode-server,这并不仅仅是打开远程文件这么简单(这仅属于工程组织文件托管范畴和代码托管),而是连IDE和插件服务都做在了远端了。------ 单纯的remote-developer是一个插件包,是用了同步/打开远程文件用的。在vscode的插件搜索栏中,搜remote插件出来的东西多得你理解不透。大部分是解决代码托管一类的,解决类似在wxsdk tool云函数同步到后端的功能(tencent-cloud-vscode-toolkit),git可能是提交工具也可以是代码空间也可以是工程文件组织器。比如remote-github(注意到云函数和一些git平台,都有ide,只是git配ide白瞎了,因为没有调试的可能性。不过,虽然目前只是在测试阶段,微软已经实现了为github集成了基于vscodeonline的不离开页面的沉浸式webide,github人类的代码基因库结合全能可用的webide,这是极佳的整合和创新。),你要的那种网盘文件。codesnippter空间也有。类似google colab 网盘挂载。------ 真正发挥作用的是后端插件管理和其组成的那个IDE(ide是由大量plugins组成的嘛)服务,这正是vscode-server。只是架构上,,这个vscode-server,被没有被做成统一后端,vscode-server不能按版本单独部署,必须要用一个vscode-server-client来唤起部署,vscode-server按需部署必须至少绑定一个front。这二者不能随意组合,也没有配置项将IDE前端和vscode-server连接起来,所以,没用到远程插件服务的情况下,本地vscode开发并不需用到(比如,同为remote的remote-container并不需要用到vscodeserver?)。 所以,不满足桌面?不想使用浏览器?这也不是什么大问题,由于它的前后端分离,可以将vscode online接入后端云开发环境(或本地模拟出来的“远程”版本,不过这样失去了云存储和云开发的某些意义)把它变成vscode。同样可做到类本地vscode效果。。而vscode online是前后可分离,服务端可以是本地模拟的也可是真正远程的,更自由,允许桌面版连接服务端远程开发,不局限于web as front,当然如果可以你也可以定制出你自己的vscode online。如果你想任意组合这二者,实现"让web/桌面vscode统一remote后端"的功能:比如,你想在本地搭建一个GUI前端(仅把它当editor front),却想调用后端的ide服务和插件,最终是为了编辑开发托管代码,或调用远程docker里面的应用呢,这当然也是可以做到的,1,自建codespace服务器(可以把它理解为桌面那个editor前端+vscodeserver),在目标机器上安装 VS Code,搜索Visual Studio Codespaces (formerly Visual Studio Online)安装,并命令中注册,它的原理应该也是部署了一个vscodeserver。2,可以在远程直接安装github/cdr/code-server的那个web版,然后查看它带的codeserver版本,来决定本地桌面端可能会用上的版本对上,file->about->help可以看到它采用的code-oss版本和commitid。(2比1好,毕竟自带一个web前端是最基本的,桌面和移动端可以作为额外项添加) 这样你可远程同步代码 + 本地调试,远程托管代码+远程调试,也可本地代码+本地调试(vscode itself),也可以本地代码,远程调试。当然也有对接重量级docker和devops的。甚至上面谈到的“一次性的虚拟沙盒环境中编程部署”,代替程序员日常的维护多个虚拟机完成不同开发工作的需求(还记得程序员下班不关机这梗吗)。这就是remote Container。 vscode/vscodeonline开源在github,叫Code - OSS,其源码倒是没有缺失和阉割也有完善的构建支持(https://github.com/Microsoft/vscode/wiki/How-to-Contribute#build-and-run),mit的开源许可也很友好,但是vscode二进制本身是this not-FLOSS license 的并带了telemetry/tracking,而且其remote-development却是不开源的,且规定二进制vscode-server不能被打包(见https://code.visualstudio.com/docs/remote/faq,Can VS Code Server be installed or used on its own?Why aren't the Remote Development extensions or their components open source?)。所以,类似code-server,Che,VSCodium这样的公司和产品就只能自己编译源码。集成docker devops运营(https://opensource.com/article/20/6/open-source-alternatives-vs-code)。https://zhuanlan.zhihu.com/p/98184765,code-server是vscode的魔改版本(基本上,code-server采用了vscodeonline里面的vscode-server组件+web前端,由于code-server必须要绑定一个前端,这造成code-server是前后一体放在远端只能web界面)。微软也有托管计划Visual Studio Codespaces。code-server也有。 体验: 这就要说到体验了,追求一种存储也在远程,而且最好一条龙开发部署都在远端的IDE。一切硬件无线和软件云化的云计算时代,讲究没有任何随身携带的东西,体验就跟使用云笔记一样(云上存储空间和执行空间全包,作为后端,前端只需要要一个GUI,前后端通过协议跨架构交互)因此在PC和手机上都有支持。云IDE这样的东西最讲究体验,体验是第一位的,比如它比本地版本不要落后太多。web端的肯定跟本地的前端,移动的前端会有区别,体验和技术上的 移动端有ios的Servediter(以前的vsapp),jupyter也有这类APP叫juno connect。macbook要arm化。也支持ipad开发,当然,功能可能稍微会有点受限。安卓端当然也有。这里的体验差别就更大了去了。 只是说实话我对ssh的稳定性很不放心。说实话它真不如一个网盘客户端(最好是一个类finder的集成在file explorer中),不过市场中也有cloudsync的插件。web端的体验其实还可以,只要不刷新网页后台一直websocket连着。 jupyter jupyter notebook最初来自于julia和科学计算,叫ipython,后来发展成了通用notebook工具。以前,我们曾介绍过它也是一个devops。因为它可以结合docker形成binder这样的平台和工具。jupyter只是个notebook,最初它用用来写文档中的代码块。后来被作为语言学习平台。不是面向生产和真正的IDE的。这类产品是cloudide,比如vscode/vscodeonline,VS Code 也有对它的支持:Jupyter Notebook Editor。 jupyter也是前后端分离开发的典型,它有一个协议系统,这种分离使得前端可以不限于webasfront,也可以是mobileapp。甚至小程序这种嵌入前端。比如第一步要将语言发展为repl(脚本语言天然有repl,而cpp这样的要借助一定手段或现有产品变通。如cling),然后按jupyter的语言kernel协议写成插件接上jupyter。 它也有很多泛化产品:如接上docker的binder,如基于jupyter notebook的jupyter book(注意名字区别),叫可执行的markdown(就是在md中嵌入ipynb片断,或者理解成在ipynb中写markdown),进一步可发展为利用云snippter笔记写blog,可导出整书pdf(我还没找到按toc能整书生成pdf的产品,那就成word了,gitbook算一个)。 还有如基于jupyter的可视调试:jupyterlab/ debugger。当然它也是分前后端和协议实现的。这就一步一步走向了真正的cloudide的段位了。 如果说上一代jupyter是面向文学编程和科学研究的,下一代是称为Jupyterlab的产品就有点ide的味道了,有Elyra这样的产品了。 下一文探索发明lang.sh:把jupyter with debugger supporter和code-server整合安装在minstackos (此处不设回复,扫码到微信参与留言,或直接点击到原文)
本文关键字:自建云函数后端。self build serverless function as service,single node serverless 在前面《云主机上手动安装PAI面板》中我们讲到了在云主机上安装某种“类似baota xx语言项目管理器”的虚拟主机管理面板,也提到它并不是cloudbase版的云函数面板,后者这种方案要重得多: function serverless最初也是由一个专家一篇文章给的思路,然后业界觉得好用就流行起来了。vs 传统虚拟主机管理面板和language backend as service,它至少有下面几个显著的不同特点:1),它将服务托管细粒化到了语言单位,即函数调用,故名faas,2),它与流行的API分离前后端结合,对这种webappdev有支持3),它利用了devops docker, 可scaleable集群的部署。4)运营上它支持按需按调用计费,将语言按调用次数收费。5) 它面向来自内部外部多种不同服务交互的混合云,构成的API调用环境。 它自动化了好多部署和开发级的东西以devops,以容器为后端,Triggers是一个重要组件,从GATEWAY代理中提取函数。根据触发从容器中fork一个process出来(因此与那些纯k8s和swarm的管理面板直接提供docker级别的服务粒度不同)。这个process就是watchdog 它是一种similar to fastCGI/HTTP的轻量web服务器,提供函数服务。由于支持多种环境多种不同服务交互,因此main_handler()中总有event指定事件来源,支持event,content为参数的async函数书写方式(而这,是nodejs的语言支持精髓)。。 综上,它是某种更倾向于“云网站管理面板”的思路。and more ...开源界的对应产品就是openfaas这类。 openfaas一般使用到k8s这种比较重的多节点docker管理器。注重集群可伸缩的云函数商用服务。那么对于个人,只是拿来装个云主机搭个博客,不想用到服务端的云函数(虽然有免费额度,不过总担心超)的用户,有没有更轻量的方案呢? 这就是faas containerd serverless without kubernetes:faasd,它其实也是一种openfaas的后端,只不过它使用containerd代替后端容器管理,因此它也可以To deploy embedded apps in IoT and edge use-cases,项目地址,http://github.com/openfaas/faasd/,作者甚至在树莓派上运行了它。 好了,下面在一台1h2g的云主机上来安装它,测试在ubuntu18.04下进行。 基础 以下脚本从项目的cloudinit.txt提取,有改正和修补。注意使用说明:外网访问云主机需开8080,如果提示Get http://faasd-provider:8081/ namespace=: dial tcp: i/o timeout之前,把你的云主机对外的8081打开,最好都打开。 一些变量 MIRROR_PATH="http://default-8g95m46n2bd18f80.service.tcloudbase.com/d/demos" # the openfaas backend OPENFAAS_PATH=${MIRROR_PATH}/faasd 安装依赖 apt-get install nginx golang python git runc python-certbot-nginx -qq -y 不安装runc会导致containerd可能出现oci runtime error,导致启不动faasd 安装faasd 1.3.5有个link错误,所以换用1.3.3。 # install faasd installOpenfaasd() { echo "=====================containerd install progress=======================" msg=$(wget -qO- ${OPENFAAS_PATH}/containerd/v1.3.3/containerd-1.3.3-linux-amd64.tar.gz > /tmp/containerd.tar.gz && tar -xvf /tmp/containerd.tar.gz -C /usr/local/bin/ --strip-components=1 cat << 'EOF' > /etc/systemd/system/containerd.service [Unit] Description=containerd container runtime Documentation=https://containerd.io After=network.target local-fs.target [Service] ExecStartPre=-/sbin/modprobe overlay ExecStart=/usr/local/bin/containerd Type=notify Delegate=yes KillMode=process Restart=always # Having non-zero Limit*s causes performance problems due to accounting overhead # in the kernel. We recommend using cgroups to do container-local accounting. LimitNPROC=infinity LimitCORE=infinity LimitNOFILE=1048576 # Comment TasksMax if your systemd version does not supports it. # Only systemd 226 and above support this version. TasksMax=infinity [Install] WantedBy=multi-user.target EOF systemctl daemon-reload && systemctl enable containerd systemctl start containerd 2>&1) status=$? updateProgress 50 "$msg" "$status" "containerd install" echo "=====================cni install progress=======================" msg=$(/sbin/sysctl -w net.ipv4.conf.all.forwarding=1 mkdir -p /opt/cni/bin wget -qO- ${OPENFAAS_PATH}/containernetworking/v0.8.5/cni-plugins-linux-amd64-v0.8.5.tgz > /tmp/cni-plugins-linux-amd64-v0.8.5.tgz && tar -xz /tmp/cni-plugins-linux-amd64-v0.8.5.tgz -C /opt/cni/bin 2>&1) status=$? updateProgress 60 "$msg" "$status" "cni install" echo "=====================faasd install progress(this may take long and finally fail due to network issues,you can manual fix later)=======================" msg=$(wget -qO- ${OPENFAAS_PATH}/openfaas/faasd/0.9.2/faasd > /usr/local/bin/faasd && chmod a+x /usr/local/bin/faasd export GOPATH=$HOME rm -rf /var/lib/faasd/secrets/basic-auth-password rm -rf /var/lib/faasd/secrets/basic-auth-user rm -rf $GOPATH/go/src/github.com/openfaas/faasd mkdir -p $GOPATH/go/src/github.com/openfaas/ cd $GOPATH/go/src/github.com/openfaas/ && git clone https://github.com/openfaas/faasd && cd faasd && git checkout 0.9.2 cd $GOPATH/go/src/github.com/openfaas/faasd/ && /usr/local/bin/faasd install sleep 60 && systemctl status -l containerd --no-pager journalctl -u faasd-provider --no-pager systemctl status -l faasd-provider --no-pager systemctl status -l faasd --no-pager 2>&1) status=$? updateProgress 90 "$msg" "$status" "faasd install" echo "=====================faas-cli install progress=======================" msg=$(wget -qO- ${OPENFAAS_PATH}/openfaas/faas-cli/0.12.9/faas-cli > /usr/local/bin/faas-cli && chmod a+x /usr/local/bin/faas-cli && ln -sf /usr/local/bin/faas-cli /usr/local/bin/faas sleep 5 && journalctl -u faasd --no-pager cat /var/lib/faasd/secrets/basic-auth-password | /usr/local/bin/faas-cli login --password-stdin 2>&1) status=$? updateProgress 100 "$msg" "$status" "faas-cli install" } 整个脚本跟pai安装脚本的风格很类似。可以像pai一样把nginx也整合起来作为总前端(openfaas+faasd也是前后端的一种说法),把8080转发到nginx,要知道,nginx是通用协议转发器不只http,见《基于openresty前后端统一,生态共享的webstack实现》。 以上这些如果无误完成。在云主机上可以打开8080(faasd),8081(faasd-provider)等。打开8080需要登录。 如果打不开8080,可能是脚本faasd up时从docker.io下载的几个必要小images时timeout了。cd /var/lib/faasd/ && /usr/local/bin/faasd up(一定要观察看到几个小images下完,可能会提示8080已被占用)。重启即可访问8080。 在云主机上sudo cat /var/lib/faasd/secrets/basic-auth-password得到网关密码。用户名是admin,然后部署云函数:faas-cli store deploy figlet --env write_timeout=1s。系统可能依然会开二个实例,设成仅1个也可以。由于faas-cli都是一样的,其它相关适用的高级用法可以继续关注faasd相关文档得到。 然后,,,就是把运行在cloudbase的云函数移过来,可能需要一些补正,跑在自己的服务器上,好处是不用再担心额度了,省心省事。 不过说真的我对于这种docker做的虚拟化不放心,最好不要存数据。所以还是选择pai,未来整合pai,faas试试? (此处不设回复,扫码到微信参与留言,或直接点击到原文)
本文关键字:allinone编程语言,个人是否真的可能学好多门编程语言 我们在前面《编程语言选型通史:快速整合产生的断层》提到,我们需要一门"简单,oneforall"显得不那么“断层”的语言来工作和学习,以积累自己的codebase和开发经验而无需推倒重来或切换,---- 这个问题之所以重要和紧迫,如上文所讲,是因为编程语言一直处在开发和学习的中心,占据一个程序员的大部分时间和心智精力,语言选型必须先于其它进行。而现实情况是,技术总在演变,而融合正处在初级阶段,人们在学习和工作中总涉及到使用多门语言的情景,产生的断层和学习成本巨大(见《qtcling - 一种更好的C++和标准库》和《编程语言选型之技法融合,与领域融合的那些套路》) "程序员总是需要不停学习",。这个时候,我们希望获得一种简单,但allinone的语言和一劳永逸的开发领域研究对象。对于出现的新开发,也可以以自然不虐心的方式融入,共享同一套生态,---- 俗语,用一种语言解决所有问题。这个问题放在10年前是不可能讨论的,但现在可以了。 “任何编程语言都一样麻烦”,软件无银弹,排除这些同质部分。来设想一下,对这种语言最基本的要求,首先是要保证简单,避免CPP那种越做越复杂带来的坑。不要求它有对低阶语言有很好的源码兼容性,但至少要能接上现今二大生态(naitve/web)。语言写法上的限制和自由是一对矛盾,这个时候我们宁愿入门前曲线陡峭,入门后一马平川,除此之外,它还应绝对安全(非必要不写unsafe),是运行期免错的语言。 对于符合上述要求,现今为止能很好作到“allinone”写法的语言和跨embeded/native/web/mobile(甚至web前端)开发的语言。Dlang/go/rust是唯三的选型对象,这其中,rust是最全面的。从语言演变历史中那些坑中综合排查,这点上,因为rust出现得晚,取长补短,rust没有任何包袱。它是最不虐心的。rust源于cyclone的部分概念,虽然说这些cpp的新版本也能做到,但cpp应该改无可改面目全非了,不如一门新语言来得更让人易接受。 具体来看rust的优缺点: 它有: 1,它涵盖toolchain即appdev领域,是真正的通用语言,着眼现在面向未来 它支持跨embeded/native/web/mobile(甚至web前端)开发,而其它不少语言也宣称它们通用,但总是存在大量的坑(比如人们不常用php-cli,仅用php-cgi)。rust没有这些包袱,是真正的通用语言,即又具备动态和脚本语言的写法和效率,而且又以一种自然科学不虐心的方式进行。而且它的微运行时能嵌入browser,着眼未来wasm技术。它也能被很好用于未来的AI,因为安全和效率比py高。 2,它涵盖现在的主要语言体系,聪明地定位于安全的编译型语言。 如在静态语言中谋求动态,如let,又将以前仅运行期能做的。用模板和泛型可以完全弄到编译期,如整套的编译期内省。达到了现在流行的静态/动态/语言脚本语言都能拥有的效果,支持脚本语言的逻辑热更。上面谈到,它是强编译期安全性的,能保证运行期免错(解决了c增强系如CPP的痛点:内存泄漏和数据竞态)。其实运行期与编译期只有二个期的不同(对导致语言灵活和动态性差别没有本质联系)。不一定语言的动态性就一定要体现在运行期。编译期可以让语言达到足够的动态性,这就是动态编译。 3,它涵盖了所有语言技术,建立了所有语言的多范式超集,具备了流行的开发支持, 见《编程语言选型之技法融合,与领域融合的那些套路》,现在所有的语言,基本不是函数式(这类语言的代表就是lisp,haskell)就是过程和OO式(cpp,java)或者它们的综合(py,js,go,rust),都可归为这二种流派。其实现都是对他们的简化与修正。而rust对这二种流派都有全面吸收和支持。 4,它不复杂,为了融合和发展,它另辟创新,解决了C增强系的痛点,而没有提出过多的新概念,甚至没有GC 拿cpp与rust这些“增强C系语言”对比,我们要忽略cpp对c的源码兼容是c的增强(严格来说,cpp应该向它的祖先cfront靠拢以增强C。)这层极具混淆性的意义来说,把cpp与c看成是一高阶一低阶的不同语言,这样我们就能方便地拿出两者都提出一门高于c的新语言的起点性工作开始对比:它们都保留指针和控制底层的能力,但rust有引用和借用,类型所有权,,极其聪明地(虽然有些强制和面向契约)规避了cpp的坑,同样没有GC,同样用raii却避免了CPP的内存不安全。 与dlang/go这样的“简化C系/cpp语言类”比较,达到同样的效果却而避免给语言增加gc这样的乱入式大部头。一门语言集不集成GC,这是影响到语言本质的问题,比如go集成GC,其运行时会比rust大好几个数量级,rust极小运行时。这对嵌入硬件平台和嵌入WEB浏览器极为关键。它对glibc这样的东西几乎无依赖。。 对语言的学习,从对比它们的类型系统,作用域,支持的高级数据结构,异常,。。。。这些层面,基本一个认真学过几门流行语言的人都可以在10小时之内了解完。(引用,借用,其实并没有给rust新增加多少东西,其它都是向简集成) 5,它兼顾了现在,也能接入既有多种生态和未来扩展方向: 它能生成对c的转译结果(接上了系统实现和系统开发生态),以及对js的转译结果(接上了web前后端生态),而现在转译式开发是很流行的。place rust on top of c and js(比如 c,js作为低阶语言仅具备基本的过程和函数,oo和高级函数语法放在高阶语言rust层),这是很well arranged的。 对于未来,它也有考虑,如wasm,如virtual appliance,见《云APP,virtual appliance:unikernel与微运行时的绝配,统一本地/分布式语言与开发设想》,未来应该是libos,unikernel,Fuchsia os这类可编程可devops可嵌入可物联的内核的天下。 它没有下面这些,但不重要 (一个事物的优点的这个说法,正是它缺点的某些方面,在一定的可讨论范围内,任何选型都是一对矛盾): 它没有对C的源码兼容支持它没有GC。这刚好成全4,5 它没有过于简单的语法。但其实这是个仁者见仁智者见智的问题。(引用,借用,这些是rust最本质的创新) 它没有显式的语言层DSL支持,但它内外部已集成足够可用的东西。见3,5 它没有统一后端,但有 C ABI 二进制兼容对外interoperability能力也好。,也没有类elm的interoperability to js,见5 (此处不设回复,扫码到微信参与留言,或直接点击到原文)
本文关键字:可编程的os/os kernel/os rootfs,os as service,os as service,mateos。cloudsubos,,客服同体,api/runtime共体,将os api化,headless os core for cloud api,融合云app matecloudos,matecloudapp:真正的分布式 在前面我们谈到《enginx,engitor》系列,还谈到《Plan9:一个从0开始考虑分布式,分布appmodel的os设计》,这些文章共同点都是对已有分布式app(一类跨OS/OS进程的APP)的思考和未来创新设想,可以拿来从各个方向类比:前者是传统os+lamp,lnmp方案,以OS上安装的分布式软件作为OS服务子组件(多见于服务器OS环境)透出它们的服务,在这上面打造出一个web appstack(比如apache之于page gui,mysql之于持久db...),在这里,可利用的服务,和API存在于这些组件抽象给语言的后端(非OS固有部分),而后者plan9的本质不同之处则在于提出了一个devable os,将内核中的对象和os本身作为可编程对象,透出这些API服务,直接在已有OS组件上作分布式不提出LAMP之类的多余结构,在这上面打造分布式APP。 后者显然更原生,也更好用,(如上,传统的os只是api runtime/c dlls,api服务也是离线的另起一层,且并不面向分布式,并不是与开发一起被设计。是先把os用起来的原则建起来的,os与api分离。以前,为了达成跨语言跨OS的API,是靠给API打stub完成的。这种方式粗鄙无用已被淘汰不单是rpc技术改良就可以完成的)。而新时代分布式程序和分布式开发的固有特点是:分布式开发要求开发接口与程序本身共体不分离,也就是脚本语言和web开发中,“srcfile即程序组件”那套,------ 当然,现在的web分布式是从lamp上搭建的,现在的OS kernel也都基本不是plan9这类。但我们可以在现存传统的os结果下进行改造。比如,我们可以另外铺设API。将OS作为一种headless api被调用环境。类似传统方式铺lamp服务那样的方式进行:只不过这次向上提升到针对os的组件进行。也即,我们利用plan9思路和方式,从传统OS本身开始做而不下放到lamp,OS服务要作为基础被分布式服务化,发展基于OS分布化之下的分布APP。而且不必涉及到统一使用者的OS跨OS。,如果成功。本地开发和分布式分开完全可以统一。------ 引申开来,即:os/os kernel as serivce,api和api runtime天然一体。组件即demo即api。本地组件即远程服务(自动API化,无须再次面向不同语言作显式API化)。 新mateable分布式用于最小实践教育路径和降低实践门槛考虑 这样做具体有什么意义呢。 matecloudos和matecloudapp,由于OS都是自带文件系统,GUI,和持久的一类综合体,这些服务不必再搭建,作为客户机和作为服务器环境的作用可以统一彼此互为mate,这些理念对于APP开发的统一作用和难度降低作用不言而喻: 首先,(1)第一条,如上所述,本地开发和分布式开发将共享同样的技术基础,变成单机复杂度,我们现在的分布式分开几乎都是统一后端和webapp这二种理念:由于webapp是现在唯一的真正跨端的模型。。我们现在大部分移动端和一些native端应用都是通过分离前后端为统一后端+不同的客户端APP技术完成的,将所有分布式开发视为前后端分离,后端统一API化,都是web形式的调用,比如某个网站后端,或一个天然的cloud function,前端则利用统一的ajax,reactive,pwa技术构建。即所谓的MVC模型。这些都在《一种设想:在网盘里coding,debuging,运行linux rootfs作全面devops及一种基于分离服务为api的融合appstack新分布式开发设想》说过,如果os本身被api和服务化了,那么完全可以用native app逻辑。不必另造一个webapp出来。来达成分布式APP,简化后端。 (2)甚至,我们完全可以在类plan9的理念下统一,使分布式APP和本地native APP开发理念同源,再度降低APPDEV的难度,我们的开发一般都是某种app层次的dev,需要呈现为一个APP形式,比如web在是webapp,移动端是mobileapp,桌面就是nativeapp,软件和编程就二种逻辑和抽象:一个业务逻辑,一个关于APP本身的appstack逻辑。appdev的本质是三种stack(一般是gui,持久,网络)的形式在所处不同形式下的演化。比如文档数据库。就是视图模式下的“文档”,区别于存在于磁盘中的文档。appstack占了一个app逻辑的大部分,可以极大得到简化。 一个例子是类似p2p性质的gitcore客户端程序即是服务端程序,可以以同步的方式代替协议交互。也可以同步的方式来处理数据交互。比如,直接把原生GUI透出为分布式API服务,客户端也可以是远程桌面remote app这样的东西,如果客户APP也是服务端一样的OS,则GUI无须渲染(只需像那些远程桌面协议一样传送位移量)提出一种新的类web的remoteappmodel。天然分布式。 (3)还有,如果是plan9这种kernel,由于整个os内核都是构建于基于对象上。所以可以以编程的方式来调用和共享,以OS抽象和语言统一的方式(这个作用不得了,见《一种shell programming编程设想》,统一问题域和抽象域,甚至语言方案域)同步二个OS间的对象。这样在OS的构建过程中,就穿插预埋了对未来这种OS上的APP编程的设计,甚至统一了APPDEV和这种OS上的系统APP开发。 (4)更多,在线IDE就随处可放。调试也不再基于堆栈跟踪这些反工程层面。。。。。。 我们的设想是基于deepin做一个这样deepincloudos,再在这上面发展一些好用的matecloudapp(集成云开发IDE和云LAMP,首要的就是在线IDE和mineportal apps:如file explorer内置同步,如果能在jupyter上写程序,那么这是一个天然debug backend app,已有这样的产品,不过这是工具层面的,我们就是要将其做到与OS级天然集成。 (此处不设回复,扫码到微信参与留言,或直接点击到原文)
2020年10月
2020年09月
-------------------------
显示正在跳转东京区。。
一直卡在那
-------------------------
引用第1楼dongshan8于2017-12-04 19:17发表的 :
版主回复:
能否发一个具体的文件URL地址,
让网友们为您测试一下? [url=https://bbs.aliyun.com/job.php?action=topost&tid=571453&pid=1758690][/url]
-------------------------
这种效果
-------------------------
还有这种效果
-------------------------
就这几天的事。注意到日本节点由走上海换成改走北京了。。
阿云线路从运营上就不稳定啊多变动
-------------------------
线路抽风
-------------------------
在你ECS管理控制台中
-------------------------
用windows啊。。。省事直观又方便,,最重要的,不会有你这种CPU窜升的问题,好像linux默认就是吃尽内存。
然后配wnmp