@gtese #15

最开始要用堡垒机的话 web 或许没问题，但要是迁移到堡垒机的就挺麻烦了。

@gtese #15

不是所有堡垒机需求都可以在 web 上操作的。

@flyqie #1

但即使这样稳定性跟速度提升也是个不确定的值。

与发送接收端没有任何关系。

谁的各类性能强用哪个。

@finalenterx #9

未来会实现 rdp ssh 协议的代理网关吗?

目前看实现似乎还是纯 guacamole ，没有办法实现原生客户端连接这种无感?

看了下，好像没有标明所基于的开源项目地址？

这个模型目前你做了多少改动？

请问相比 next-terminal 这种 go 写的有什么优势呢？

挺好奇为什么要这么做?

@flyqie #24

打错了。。

应该是每次操作

每次链接都 auth 一下这玩法太智障了，redis 这么用了怕不是被人笑话一辈子。。

极客时间的课水到这种程度了吗？

@flyqie #13

现在某些产品根本迁不到 loongarch64 ，因为只有 arm64 。。。

loongarch64 要像你所说是 arm64 的话，那很多东西就没那么复杂了。。。

@klo424 #4

截图方案确实挺多。

前端做的话 html2canvas ，后端做的话上无头浏览器。

记得之前还用类似这种网站玩了点花活。。无头真的每家配的都不一样。

@crackidz #7

android 肯定是没有任何问题的。。真要说起来的话 android 全是自签。

android 那种签名模式保证不了用户在初次安装时一定是可信的应用，它只能保证应用在后续升级时候不会被篡改。

这种措施其实已经是最符合 android 自身的了，不然 aosp 生态根本没法做了。

建议先了解下以下内容：

1. ms 代码签名
2. apple 开发
3. android 开发
4. 域名证书

直接的答案是，不行

gitea 本来不就是开源项目吗？

后面推出商业版什么的也是增加新功能。

别阴谋论，你 docker 肯定是开源版本的，源码都在 github 放着，说收割着实有点大可不必了。

你这情况建议自己进终端看下域名具体解析到哪了，大概率是被运营商什么的污染到了一个内网地址，这样你哪怕允许 allow_localnetworks 这个安全设置也无效，因为污染后的地址本身就是不可用的。

@jakell888888 #11

hal 方案看起来似乎不适合你这种。

hal 方案指的是自己修改 aosp 里的设备 hal 层并编译镜像出来跑，本质上是适配 aosp 到新设备。

这种是真正的底层，应用本身根本无法判断是否是模拟的位置。