V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  laminux29  ›  全部回复第 74 页 / 共 82 页
回复总数  1639
1 ... 66  67  68  69  70  71  72  73  74  75 ... 82  
2019-10-19 21:57:50 +08:00
回复了 yincrow 创建的主题 PHP PHPer 面对别人的嘲讽,应该怎样优雅的回应
我平时也用 PHP 啊,但没人敢对我这么说,因为我从汇编到分布式数据分析与统计都懂啊。
2019-10-19 09:50:10 +08:00
回复了 17681880207 创建的主题 Android 老哥们,请教一个 Android Studio AVD 无法联网的问题。
找一个高速梯子吧。这类软件,包括 Eclipse 等,都需要梯子来维持正常运作。
2019-10-19 09:44:44 +08:00
回复了 fhvch 创建的主题 程序员 程序猿=工具人
教你一条很简单的处事原则。

当某个人,你不想帮时,分析一下 TA 以前,对你是否有先行利益输出,以及是否尊重你。

不满足第一条,直接找借口婉拒。

不满足第二天,你对 TA 连理会都不需要。

以前我遇到过这事,别的部门有一位女神同事,因为我脾气好,喜欢叫我帮忙修电脑。我本来不想帮,但鉴于她一开始态度较好,而且这个忙也不需要太长时间,所以我觉得帮一下算了。但后来我发现,我不经意间,我把她问我的问题,隔了很长间隔,反问她,她多次不理会我。于是我觉得,这种尊重不对等的双标人,直接不用理会她了。
2019-10-16 18:39:35 +08:00
回复了 xcloud 创建的主题 奇思妙想 逻辑可以程序化并存储吗?
逻辑当然可以程序化,但问题是,逻辑需要的数据,以目前的技术来说,存不下。
楼主是不是觉得,带宽、硬盘、服务器,是天上掉下来的?
C 或 C++,通信原理(主要是 udp 与 tcp ),数据结构。

我觉得这三样能达到 80 分就可以完成接口的基础设计与实现。
2019-10-15 11:06:56 +08:00
回复了 ihainan 创建的主题 分享创造 一个雅思例句库,包含四千多条音频例句
如果你真想分享,你应该把这些数据,整理成通用数据库的数据,最后把数据打包分享。

你现在自己搞一个接口,鬼知道什么性能,有没有调用限制,以及能用多久。
2019-10-14 16:57:17 +08:00
回复了 tctc4869 创建的主题 数据库 postgresql 要存帖子回复等类型的数据,适合用什么字段?
@tctc4869 帖子一张表,评论一张表。
能直接教会徒弟的技术,说明这技术本身没门槛,不值钱。

举个反例:如果你能写一个搜索引擎原型,能搜到百度和谷歌搜不到的东西,但这套理论,从电路到分布式技术都至少要熟悉,你觉得几个徒弟能听得懂这完整的知识链条?
2019-10-14 10:43:16 +08:00
回复了 leekafai 创建的主题 分享创造 开发了一个支持本地批量压缩图片的小工具
@leekafai 如果这两个问题都无法自行解决的话,那就只能建议换个行业了。
2019-10-14 10:42:14 +08:00
回复了 tctc4869 创建的主题 数据库 postgresql 要存帖子回复等类型的数据,适合用什么字段?
1.帖子与回复,统一 varchar 就行了,1GB 的最大长度足够了。

2.帖子与回复当然要分表,因为业务逻辑与功能都不一样。

3.nosql 选 MongoDB 就好,简单又方便,但要注意选择安全的策略,以及数据落地后最好在代码层校验一下,因为 MongoDB 有遗漏数据的恶习。
2019-10-13 21:10:40 +08:00
回复了 leekafai 创建的主题 分享创造 开发了一个支持本地批量压缩图片的小工具
鼓励一下。

但这类需求,最佳实践是:

本地图片批量转换、缩放、格式转换,简单需求,直接用老版本的 ACDSee 就好,它还可以一键改名。

如果需求复杂了,一般是编程调用 ffmpeg 来实现。
2019-10-13 20:11:13 +08:00
回复了 BORBER 创建的主题 Java 为什么下载 jdk 这么难?
上面所有回答,全部答错。我来终结此贴。

原因有 2:

1.GFW 的拦截。

2.国外这种软件机构并不愿意花钱在大陆做高速 CDN。

因此,解决的方案其实也很简单,那就是准备一个高速的梯子就行了。这样,从 Google 里搜 jdk 版本,然后 oracle 登陆,最后下载,几分钟就能搞定。包括你说的其他那些事情,都一样。
2019-10-09 15:22:44 +08:00
回复了 asdfjkl 创建的主题 奇思妙想 有感于北理工的牛 X 专利,想做一个 tcp spoof 的检测程序
@asdfjkl 公网 IP 与 NAT 子网通信,理论上来说,只要暴露了服务端地址,那么通信就能成立。但这只是理论上的,就看网络设备商的程序猿会不会偷懒。因为不偷懒的话,NAT 设备还需要涉及到一次地址记录与查找。如果程序猿偷懒,那仍然是无法通信。

而且其实这都不重要,重要的是,暴露了服务端地址,隐藏通信的想法在实际应用中,根本就不可靠。因为网安要求电信的上端仍然有记录设备,会记录当前链路发的包。所以无论包里如何填 IP head,被记录后都能查出是谁发的。具体来说:

家庭光纤或拨号上网用户,上级的 EPON 之类的设备会能够把数据库与线路记下来,存储到电信的网安设备里。
学校或大型单位用户,网安会要求在 NAT 设备与用户之间安装网安设备来记录这些东西。

总之,只要网安想查,这种协议是无法避免被查水表的。

真正想逃避这种检查,只能采用洋葱路由的思路,这种思路的本质是查证成本太高,导致实际上就没办法查。
2019-10-09 10:37:10 +08:00
回复了 asdfjkl 创建的主题 奇思妙想 有感于北理工的牛 X 专利,想做一个 tcp spoof 的检测程序
它这个协议根本就是错的。

公网 ip <---> 公网 ip,这一条没问题,原理很简单,就像收发邮件一样。一般发邮件,发件人,会在邮件的发件人一栏,写上自己的名字、地址、电话。但是,发件人信息其实是可以不写的,因为只要有收件地址,对方就可以收到邮件。这个协议就是模拟了这个特性。就像很多淘宝发货商,在包裹的发件人信息一栏,不会写具体发件人的位置,而是用店铺名与手机号取代。



公网 IP <---> NAT 子网,这就全错了。

首先,它要求客户端与服务器进行正常通信,那就暴露了客户端的地址。

其次,这个协议的作者,没搞懂 [NAT 打洞] 是怎么回事。NAT 有多种模型,它提的这种方法只对于全锥形 NAT 才有效,但问题是,大部分民用以及低端商用路由器或 NAT 设备,是不支持全锥形 NAT 的。所以协议用全锥形 NAT,对于大部分民用设备是无法通信的。如果改为其他 NAT 模型又必须暴露服务端的地址。
套壳后稍加处理,于是你们就觉得这不是套壳,真的不担心谷歌的律师函?
1 ... 66  67  68  69  70  71  72  73  74  75 ... 82  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   956 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 45ms · UTC 22:43 · PVG 06:43 · LAX 15:43 · JFK 18:43
Developed with CodeLauncher
♥ Do have faith in what you're doing.