- 主题:rust正式进入linux内核了
最近有个 gitpod,我觉得就算是个合理的场景吧
desktop 环境相当于以租代买,入职员工给个 chromebook 就可以开始干活儿。开发人员需要什么 os 随时切换,开发环境已经搭好了,每天自动备份,再没法以系统为由偷懒。
我觉得这个使用场景还是有市场的,比如新入职的,创建好乱七八糟的账号之后,直接远程启动个环境,理论上不到20分钟就可以开始干活儿了。也不存在过了一段时间发现,因为当初老板抠门儿,电脑配置跑某个东西不够用的情况。
【 在 lvsoft 的大作中提到: 】
: 我看了下是挂了个奇绩创坛的logo,可能是拿到了融资了吧。
: 不过我还是想不出盈利模式...当然这个方向想象力空间是有的。
--
FROM 222.153.175.*
对于搞 serverless 来说,启动时间就是钱啊。对 faas 提供商来说,挤出百分之几的性能就已经收益巨大了,更何况 cold start 作为重要指标,也是能卖出去服务的条件
【 在 GoGoRoger 的大作中提到: 】
: Docker对性能要求也不太高,没必要用rust,我一直觉着有技术泡沫的现象,现在很多大牛听说rust不错,就技痒想试一下,但是真的有必要用rust吗?
: 发自「今日水木 on M2007J17C」
--
FROM 222.153.175.*
这个模式是可以的,rustdesk也在搞web版的client,说明它们肯定也是有这方面想法。尤其是现在疫情,远程办公算是一个强需求了。
但我是觉得这个瘦客户端模式在最近几十年里已经被重复发明一万次了,虽然再重复发明一次也不是没机会,比如也没人想到视频会议这个红海赛道还能产生zoom这样的新玩家。
但在红海赛道搞事情的,得先把问题解决的足够好,再加一定的运气才可能有机会,属于上来就选hard模式,所以我就没提...
另一方面,干活的机器有很多场景还是需要本地的,也未必能远程化。比如我最近要跑个ai训练,原始数据集1TB,上传cloud要传好久...等它传好本地都训练好了...
而且这原始数据每天都有几十GB新增,现场网络不足以支持传输这些数据。比如我自带4G,40GB/月的流量一天就干完了;要么用客户的网络,然后带宽占用太厉害被客户拔网线。所以这些数据都是每周有人带着移动硬盘去现场人肉搬运回来的...这种情况就很难远程,只能在本地搞。
再比如我也经常要搞硬件,接串口,接调试器等等,这些都要跟我现在手上的实物有各种物理层面的交互,也不太可能远程搞。总的来说,互联网相关的行业倒是比较适合这种纯远程模式,但这种场景现在也有很多解决办法。
【 在 eGust 的大作中提到: 】
: 最近有个 gitpod,我觉得就算是个合理的场景吧
: desktop 环境相当于以租代买,入职员工给个 chromebook 就可以开始干活儿。开发人员需要什么 os 随时切换,开发环境已经搭好了,每天自动备份,再没法以系统为由偷懒。
: 我觉得这个使用场景还是有市场的,比如新入职的,创建好乱七八糟的账号之后,直接远程启动个环境,理论上不到20分钟就可以开始干活儿了。也不存在过了一段时间发现,因为当初老板抠门儿,电脑配置跑某个东西不够用的情况。
: ...................
--
FROM 114.222.221.*
不对啊,数据也应该放在远程服务器上的,不存在网络导数据的问题。
我现在就这么干的,所有东西都在服务器上,随便到哪,找个电脑就能远程桌面干活。
【 在 lvsoft 的大作中提到: 】
: 这个模式是可以的,rustdesk也在搞web版的client,说明它们肯定也是有这方面想法。尤其是现在疫情,远程办公算是一个强需求了。
: 但我是觉得这个瘦客户端模式在最近几十年里已经被重复发明一万次了,虽然再重复发明一次也不是没机会,比如也没人想到视频会议这个红海赛道还能产生zoom这样的新玩家。
: 但在红海赛道搞事情的,得先把问题解决的足够好,再加一定的运气才可能有机会,属于上来就选hard模式,所以我就没提...
: ...................
--
FROM 58.37.34.*
是的,我也是这么想的。问题就出在数据放在远程服务器上的环节。
第一天我直接scp,过了一晚上发现传了100G后链接断了。
第二天用rsync传,过了一晚上发现照片文件太多速度太慢跑不满带宽,也只传了100G。
第三天用sshfs挂上去之后rsync本地对本地,发现速度还是上不去。
第四天用nextcloud传,发现走一遍这个file list就要1小时,然后其实也没比rsync快多少
第五天用一个parallel rsync脚本传,然后发现它要dryrun一下之后才能并行。但这个dryrun也要1个小时然后给我报了个错。
这样5天就差不多就过去了...
其实服务器就在我20公里外的地方,我纠结下要不要自己花1小时跑一趟...
但最终还是懒得跑了在本地搞定算了...
【 在 RuralHunter 的大作中提到: 】
: 不对啊,数据也应该放在远程服务器上的,不存在网络导数据的问题。
: 我现在就这么干的,所有东西都在服务器上,随便到哪,找个电脑就能远程桌面干活。
:
: ...................
--
FROM 114.222.221.*
但是 docker 现在正趋于消亡,它的替代品已经出现。
【 在 eGust 的大作中提到: 】
: 标 题: Re: rust正式进入linux内核了
: 发信站: 水木社区 (Fri Oct 7 12:15:41 2022), 站内
:
: docker 是用 go 写的,很自然的整个 container 工具链基本上都用 go 实现了。如果单独看 devops 这一块的话,那 go 肯定是主导的。
:
: 【 在 No1 的大作中提到: 】
: : 牛叉的cli工具,go写的多还是rust写的多
: : 印象中,go的后台网络工具多,rust的前端工具多
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 203.184.25.*]
--
FROM 59.33.232.*
如果是一个大文件的话,我会弄一个支持content-range的HTTP server
然后listen在127.0.0.1
然后把那个端口ssh forward过来
然后本地curl -O -C -这么续传
上传的话就是反过来forward
反正正确性有tcp兜底,安全性ssh保证,http server顺便压缩编码
【 在 lvsoft 的大作中提到: 】
: 是的,我也是这么想的。问题就出在数据放在远程服务器上的环节。
: 第一天我直接scp,过了一晚上发现传了100G后链接断了。
: 第二天用rsync传,过了一晚上发现照片文件太多速度太慢跑不满带宽,也只传了100G。
: ...................
--
修改:tgfbeta FROM 221.192.180.*
FROM 221.192.180.*
我觉得这跟一开始产生/收集数据的方式也有一定关系吧。如果一开始就要基于 cloud,那应该不至于本地攒了那么多突然要一口气上传
另外其实你的开发场景也是比较特殊的,我估计现在市场上大部分软件公司,90%的功能都集中在 crud 而已,剩下又有一大部分是啥热搞啥。除了数据库本身,100G 这个量级的数据量,没准已经能排除99%的项目了。
【 在 lvsoft 的大作中提到: 】
: 是的,我也是这么想的。问题就出在数据放在远程服务器上的环节。
: 第一天我直接scp,过了一晚上发现传了100G后链接断了。
: 第二天用rsync传,过了一晚上发现照片文件太多速度太慢跑不满带宽,也只传了100G。
: ...................
--
FROM 222.153.175.*
如果指的是 wasm 的话,rust 目前就算不是主导,也是举足轻重的。另外,wasm 目前还有些坑没填,等下一版出来再看吧。我是看好它的未来的,但以它目前的影响力,还不至于能影响到 container 存亡的地步。
其它替代品的话,我就只听说过 nix 而已,最近好像 bsd 也出来个 container 之类的东西,其它的我就不知道了。还没太看明白 nix 该怎么用,但 sandbox 环境应该大差不差,而且目前也没看到云供应商的动作。
反正目前我没看到 docker 怎么趋于消亡了,各种产品基本都能提供一个 image,复杂点儿的给个 docker compose 直接能跑的方案
【 在 xWvxYWYxvWx 的大作中提到: 】
: 但是 docker 现在正趋于消亡,它的替代品已经出现。
--
FROM 222.153.175.*
嗯,那根源就在于你一开始的数据就没有放到服务器上,网络传这么大量数据肯定是麻烦了。
【 在 lvsoft 的大作中提到: 】
: 是的,我也是这么想的。问题就出在数据放在远程服务器上的环节。
: 第一天我直接scp,过了一晚上发现传了100G后链接断了。
: 第二天用rsync传,过了一晚上发现照片文件太多速度太慢跑不满带宽,也只传了100G。
: ...................
--
FROM 114.86.228.*