- 主题:rust正式进入linux内核了
肯定的。
比如远程桌面我现在就只用rustdesk了。昨天好奇扫了眼它的源代码，这抱负相当大，涵盖所有平台（包括手机平台），而且代码质量很不错，编码方式全支持，该有硬件编码的都有，一上来就是n×m×p种组合的全平台全feature高举高打的支持态势...
看了下提交记录就是这一两年开发出来的，大概5个核心开发人员。公司也是去年刚注册的。这背后必须得是大牛牵头，还要请得到大牛一起才有可能搞。看了下开发人员有来自币圈的人，感觉这质量，这成熟度，不图点什么说不过去，但远程桌面在现在这个时间点似乎也图不了什么，真就是用爱发电的感觉....
【 在 No1 的大作中提到: 】
: 我觉得按rust这帮人的抱负，迟早重写一个更好的来取代docker
:
--
修改:lvsoft FROM 180.98.133.*
FROM 180.98.133.*
我看了下是挂了个奇绩创坛的logo，可能是拿到了融资了吧。
不过我还是想不出盈利模式...当然这个方向想象力空间是有的。
【 在 syssky 的大作中提到: 】
: rustdesk作者最早还在水木求帮助求投资呢。不知道现在还来不。
--
FROM 114.222.221.*
别想的这么阴暗，rustdesk全开源的。
而且现在这时代，除非你能从底层硬件到上层软件所有代码你都亲自100%review过，否则你总是要信任一些人一些基础的。而从你信任的集合里安插点啥随便偷点东西，对国家队来说理论上都不难。
【 在 iMx 的大作中提到: 】
: 远程桌面，要偷点什么东西随便吧，跟CIA合作一下，就不愁吃喝了
:
--
FROM 114.222.221.*
这个模式是可以的，rustdesk也在搞web版的client，说明它们肯定也是有这方面想法。尤其是现在疫情，远程办公算是一个强需求了。
但我是觉得这个瘦客户端模式在最近几十年里已经被重复发明一万次了，虽然再重复发明一次也不是没机会，比如也没人想到视频会议这个红海赛道还能产生zoom这样的新玩家。
但在红海赛道搞事情的，得先把问题解决的足够好，再加一定的运气才可能有机会，属于上来就选hard模式，所以我就没提...
另一方面，干活的机器有很多场景还是需要本地的，也未必能远程化。比如我最近要跑个ai训练，原始数据集1TB，上传cloud要传好久...等它传好本地都训练好了...
而且这原始数据每天都有几十GB新增，现场网络不足以支持传输这些数据。比如我自带4G，40GB/月的流量一天就干完了；要么用客户的网络，然后带宽占用太厉害被客户拔网线。所以这些数据都是每周有人带着移动硬盘去现场人肉搬运回来的...这种情况就很难远程，只能在本地搞。
再比如我也经常要搞硬件，接串口，接调试器等等，这些都要跟我现在手上的实物有各种物理层面的交互，也不太可能远程搞。总的来说，互联网相关的行业倒是比较适合这种纯远程模式，但这种场景现在也有很多解决办法。
【 在 eGust 的大作中提到: 】
: 最近有个 gitpod，我觉得就算是个合理的场景吧
: desktop 环境相当于以租代买，入职员工给个 chromebook 就可以开始干活儿。开发人员需要什么 os 随时切换，开发环境已经搭好了，每天自动备份，再没法以系统为由偷懒。
: 我觉得这个使用场景还是有市场的，比如新入职的，创建好乱七八糟的账号之后，直接远程启动个环境，理论上不到20分钟就可以开始干活儿了。也不存在过了一段时间发现，因为当初老板抠门儿，电脑配置跑某个东西不够用的情况。
: ...................
--
FROM 114.222.221.*
是的，我也是这么想的。问题就出在数据放在远程服务器上的环节。
第一天我直接scp，过了一晚上发现传了100G后链接断了。
第二天用rsync传，过了一晚上发现照片文件太多速度太慢跑不满带宽，也只传了100G。
第三天用sshfs挂上去之后rsync本地对本地，发现速度还是上不去。
第四天用nextcloud传，发现走一遍这个file list就要1小时，然后其实也没比rsync快多少
第五天用一个parallel rsync脚本传，然后发现它要dryrun一下之后才能并行。但这个dryrun也要1个小时然后给我报了个错。
这样5天就差不多就过去了...
其实服务器就在我20公里外的地方，我纠结下要不要自己花1小时跑一趟...
但最终还是懒得跑了在本地搞定算了...
【 在 RuralHunter 的大作中提到: 】
: 不对啊，数据也应该放在远程服务器上的，不存在网络导数据的问题。
: 我现在就这么干的，所有东西都在服务器上，随便到哪，找个电脑就能远程桌面干活。
:
: ...................
--
FROM 114.222.221.*
我前面不是说了么，最开始的数据在客户现场产生。
那个数据都是定期人肉过去拷回来的。
【 在 RuralHunter 的大作中提到: 】
: 嗯，那根源就在于你一开始的数据就没有放到服务器上，网络传这么大量数据肯定是麻烦了。
:
--
FROM 114.222.221.*
因为落地的是传统行业。他们有个特点，就是生产环境不喜欢拉网。。。
【 在 eGust 的大作中提到: 】
: 我觉得这跟一开始产生/收集数据的方式也有一定关系吧。如果一开始就要基于 cloud，那应该不至于本地攒了那么多突然要一口气上传
: 另外其实你的开发场景也是比较特殊的，我估计现在市场上大部分软件公司，90%的功能都集中在 crud 而已，剩下又有一大部分是啥热搞啥。除了数据库本身，100G 这个量级的数据量，没准已经能排除99%的项目了。
:
--
FROM 114.222.221.*
如果是一个大文件就简单了。
实际情况是几百万个文件，每个文件几MB吧。
还需要差量更新。
rsync是最简单的办法
【 在 tgfbeta 的大作中提到: 】
: 如果是一个大文件的话，我会弄一个支持content-range的HTTP server
: 然后listen在127.0.0.1
: 然后把那个端口ssh forward过来
: ...................
--
修改:lvsoft FROM 114.222.221.*
FROM 114.222.221.*
最终肯定是边缘计算的。但边缘计算也需要先完成训练的过程。
所以拿数据这步逃不掉的，除非你把服务器也部署在边缘....
【 在 littleSram 的大作中提到: 】
: 感觉边缘计算就是应付这种场景的吧
: 数据收集起来立刻处理，因为传输的成本太高了，而且也没必要
--
FROM 114.222.221.*