@littleYY 你好，解释一下专有名词「条件差」：

=

不会收拾不会穿衣服不懂热情主动只有性欲

软件开发是不是被英文误导了方向？

以下略

现在打 CTF 要算温度的吗

与其附会到「使用工具」上，其实不如就只叫它实验玩具



上学那时候打 CTF ，最希望有的在线工具是 checksec （是的，那时候 checksec.sh 都是个稀有品，要本地收藏的，但经常搞丢）以及 ROP gadget searcher http://ropshell.com/about ，还有不想装 msf 又很羡慕 msfvenom 那个自动 payload 过滤 \00 的功能，一直很想有个在线的 payload 重编码器也不知道现在有这种东西了没


有个比较简单且不会过时又真的用得上的功能建议是，代码模板。

我也不知道现在 CTF 发展成什么样了但越来越卷的最后肯定会出现一批极速 payload 代码模板，就跟 ACM/OI 一样。有些东西比如 PoW （就是那个算制定格式 hash 用来限频的）的代码就得抄来抄去，还有 js 变形绕过滤什么的，在线代码模板就很适合做这个，建议讨论讨论



最后欢迎来玩

https://i.imgur.com/Jrjt7j8.png





https://i.imgur.com/W1s81ZN.png


（不是玩我们看板娘！

当然不会「不复存在」，很多问题不是技术问题，你一定也看过很多次这种话了




你的邮箱有没有启用垃圾邮件过滤？
自由信息流就是个傻逼想法，在互联网上劣币的生产率可以成数量级地碾压良币


我倒是很乐意有一小撮聪明人来「引导」大众该做什么，但要争取的是，当小撮人里有蠢逼的时候我们教他怎么做，他会听，当有人蠢得无可救药的时候，我们让他滚蛋，其它人真的能让他滚蛋。

顺丰。

有原来的泡沫其实问题不大的，显卡拆下来平放，然后用泡沫把机箱内填满，不用太多额外处理的，记得申报易碎物和保价


主机这种东西千万别自己带，坏掉的几率比物流大。而且春夏之际，遇上下雨，你带一个 10 几公斤重的箱子……

1. 循环和阻塞根本就是两个维度的概念，循不循环跟一个调用阻塞不阻塞半毛钱关系都没有

2. 我看不懂原问题想表达什么

3. 世界上的 GUI ，基本原理全都是一样的，全都有一个处理事件的循环

4. 世界上所有的程序，如果一个调用「阻塞了」，那么背后的原理也全都是一样的，caller 线程 hang 在了一个等待区，内核或调度器不会让 CPU 执行到「等待结束」后面的代码







虽然我真的没法看懂你想讨论的原问题是什么，但下面这个问题：

如果消息循环收不到任何消息，会阻塞在「取消息」操作上吗

的答案是，取决于实现。从节省 cpu 时间的角度考虑完全可以让它阻塞住。


下面这个追加问题：

那么既然阻塞住了，为什么不会被检测出死循环 /无响应

的答案是，调度器或者卡死检测器完全可以检测这个线程是否停在了等待区上，是则不认为线程无响应，这个线程 /routine 仍然是随时可调度的，只是没机会调度而已。
卡死 /无响应的表现是这个线程超过了阈值时间仍然没有返回等待区。
比如「取消息」就可以包含 renew 无响应超时的操作。假设它不阻塞，那么反正返回 caller 前刷新超时时间就好，如果它是阻塞的，那么执行流会回到调度器或内核里，调度器知道这个线程已经「重回可调度状态」，则不对其设置无响应定时器。
如果调度器把执行流交给一个线程前先设置一个定时中断，等来的是中断触发而非线程主动交还执行流，说明被调度线程无响应 /超时了








ps. 所有观点来自 OS 基本原理，我根本没研究过 androi 系统机制

……

「自适应」是页面呈现的效果 feature
「响应式」是达成目的所用到的实现 feature

这俩维度的词


预生成全世界所有屏幕大小的页面也能做到「自适应」
每一帧都强制重算并重绘所有元素的大小也能做到「自适应」

但这俩都不「响应式」

「响应式」 reactive 指的是建立元素之间的约束关系，比如讲 .content.header 的高度约束到窗口的 1/10 ，当窗口高度变化时，由于约束，header 的高度会随之变化，即被约束元素（ header ） 对约束元素（窗口）做出了「反应」(react)，由此可称这个 header 的大小是「 reactive 」（的），翻译过来叫「响应式」




vw/vh 和 rem 也是性质不同的单位，拿到一起比较都显得很奇怪，建议连文档都看不来的话不如直接抄别人的做法

交易跟博弈两码事谢谢

PLEASE （大写强调） 最长周期 一周

合一次代码



开发周期和代码同步周期完全是两回事，代码同步频率拉起来你遇到的依赖问题全都不存在了


啊，你说没写完同步代码没意义，所以为什么不把任务拆细一点每个可以跑的单元都尽可能小呢，这不就「敏捷」起来了

1. if() if () 改为 if(not) break

2. 多写一个函数取代第三层以及更里面的嵌套



比起嵌套条件语句，嵌套匿名函数更让人崩溃， .map(()=>{.map(()=>这样的)})

一两句话其实分辨不出来有没有斗争，毕竟你也不太清楚另外一边有没有想过让你加入

如果对方也希望有经验的人比如你能带他们一把最终大家能合作当然是最好的


既然老板对你还是比较信任的，如果是我，我可能会跟老板提，当然前提是我真的有精力和意愿长期当保姆。还有一个点是你手下有人，如果你直接跑了，对你现在的团队其实是不负责任的。比较好的办法是向老板推荐一个你手下的人取代你的位置，然后你再过去

既然 lamp 不是候选项，说明 apache 不是候选项

那你纠结 lnmpa 干啥？

刚 bootstrap 一个小公司的私有项目，来说说这里头的坑点，其实很多的。

重要性排序：

1. 目前根本没有完善简单的一站式方案，你能做的仅有「取舍」
2. 多人协作需要一大堆套件： 源码库、权限、文档管理、任务 /缺陷与需求池管理、迭代管理、CI 、测试服务器群，你全都得考虑。
3. 几个候选对比：
- 首先开源的「代码库项目」不予考虑，因为最多只能满足一两项需求。
- 然后 github ，满足源码库和 CI ，勉强管理一下文档和缺陷，其它的就没有了。
- gitlab ，与 github 类似，但还得自己运维服务器，不如 github 。云上版与 github 也没有明显优势
- 重点来了，最后我们选了 gitee 企业版。注意 gitee 的企业版与开源版是完全不同的。除了 CI 无法实现（它自己的 CI 产品要交高额使用费，自建则限制很大），其它的 文档管理、需求池、迭代看板、服务器群管理（虽说很简陋）、 全都是集成好的可以相互引用。虽然用起来没有 精心调教过的 Atlassian 全家桶顺手，但调教 Atlassian 全家桶是非常非常非常费时间的，你一开始根本没有精力和时间去搞这些。gitee 企业版可以快速凑合用，而且几乎无成本
4. 关于为什么选一站式而不同时使用多个协作平台，主要还是考虑人员组成和权限管理的问题。不同平台的权限分层机制很可能不一样，会额外带来很多心智负担。而且跨平台引用也是很头疼的问题，会导致组员根本不看任务板，他只看代码库。多人协作会严重 fallback 到口头传递任务。
5. 「说没就没」的问题， 请问你是在国内试图开发挑战「合规」边缘的产品吗？ github 会由于你不可控的政治原因删掉你的账户且无法沟通，国内的平台删掉你项目的原因是你在作死。而你要开发的是企业产品，好好想想。


6. 终极方案 & 看看就好： 一个 10 人的运维团队+实体机房的虚拟机集群上跑 gitlab+Atlassian 全家桶，再下一步你的公司已经在开发私有全功能平台了



放一个企业版配置列表
https://i.imgur.com/OzdeRJ0.png

protonmail 有个 @pm.me ，用这个地址发邮件要收订阅费，但接收是不用的。我一般对外邮箱会用这个

然后，@linux.com 这个地址是可以买的

https://docs.linuxfoundation.org/lfx/my-profile/purchasing-linux-email

[email protected]

整天见到一群人喷「自我阉割」，怎么一讨论到 idea 就都上来先「审查！！」

----

说几个硬伤

1. 对于 IM 来说，长链接是非常不经济的，server 和 client 都一样。大多数 im 都会保持一个流量或者负载很小的长链接来同步一些服务器状态，然后消息体用 UDP/短会话连接来发。这个设计里「除非退群否则还会一直保持连接」，我 client 关了群聊还要同时保持数十个群服务器的连接？意义何在？而且根据这个架构，这些群连接是不可能多路复用的，我真的 **必须保持几十个 TCP 连接，占掉几十个端口**。

2. 群服务器之间并不相互通信，所以「任何一个人服务器毁灭不影响整体」纯属无稽之谈，如果服务器=社区，一个服务器没了整个社区都会消失。请务必注意你现在的设计里，社区是运行在单独一个「群服务器」上的，并不运行在整个网络上，这点前面的人说过了但我强调一下，这是与你根本目标「去中心化」最背道而驰的一个设计谬误。

3. 当新孤立用户加入网络的时候，他如何发现全网的群服务器？跟问题 2 类似，假设极端情况两个大「 _群服务器_ 群」间仅有很少的共同用户，当这些共同用户离线后，两个「群服务器群」之间就无法互相发现了。想象一下很少人会同时上 A (cfun)站 B (ilibili)站，当某些用户离线之后，新孤立用户发现 B 站在服务器列表上消失了，what?

4. 还是孤立用户的问题，如果有两个可通过其他方式联系的用户（比如现实好友），他们怎么在这个网络上开始通信？先扫到一个共有服务器？如果两边的网络环境不一样扫不到公共服务器呢？

5. 无法 invalidate 某用户过去发过的消息，这与隐私性极度相悖。由于群服务器和叶子结点客户端都是非官方、非自己控制的，因此不存在可靠机制能确保服务器或结点删除用户的数据。注意「群服务器」是社区搭建的，它完全可以私自镜像所有用户的聊天数据，而你没有任何手段去管控。设想我通过营销手段搭起了全网最大的群服务器，然后偷偷镜像所有聊天记录卖给黑产——没有任何人能管控得到我。请注意这不是个审查问题，这是 **安全问题**。 不过这点可以用与你设计中的朋友圈相同的机制解决：发出的消息只存本地，中转只中转公钥


还有这些相互矛盾的话（红）和无足轻重的特性（青）…… 建议别当成纲领性 feature 来宣传
https://i.imgur.com/gkj4gsh.png





----

大多数的 idea 根本走不到验证阶段
开始实践的 idea 也有相当一部分走不到运营阶段
运营阶段的 idea 大部分也会被现实因素否决
建议「先跑起来再说」

@chaleaochexist

我之前的想法是： 当你要定义一个新 Job 的时候: Schedule(Callback,time) Callback 必然已经是一个静态的函数了，而要持久化，callback 又不能是闭包。那么比如要求 Callback 写成固定名 struct 的 method ，类似这样：

https://go.dev/play/p/cUw99-T55v8


然后又想能不能根据类型信息反射出一个类实例，然后类实例包含一个重写掉的 Run method ，这样函数名就是固定的了，而且定义 Job 的方式能更灵活。 问题集中在怎么得到这个有类型的实例上——


然而研究了大概 6 个小时之后我发现
1. reflect.Type 也是一个接口，意味着就算把类型信息 dump 出来了，我也没法轻易构造出一个实例化的 Type
2. reflect.rtype 是 reflect.Type 接口最重要的实现，这个结构是有办法 dump 的（ unsafe pointer 读），但不能存在覆写一个现存 reflect.rtype 的办法。 通过反射写这个结构会被 reflect.Value.SetXXX 的实现拒绝（有 flag 阻止写回去）；而直接得到这个结构的 unsafepointer 尝试给它赋值会触发访问违例，原因不明。由于我也没用更 low level 的调试器去调（ goland 而已），所以我也不知道是赋值语义还是类型转换语义的问题
3. 不像 C/++ 有函数地址就可以强制转换出一个函数； golang 是无论如何都先得有 reflect.Type 的（光有地址没有用）。由于 2 ，reflect.Type 不能自由构造，因此在语言范围内能想到的 tricky way 都堵死了。




有点蛋疼，前几天才有其他人说 golang 动态性差，确实是不得不承认的

@mengzhuo 不可能的，还会有 goroutine 和 GC 的问题

----

OP 换个思路：
在静态语言中，所有函数都是「已持久化」的、嵌在程序中的。借助反射，函数的地址可以通过函数名查到，所以执行体存个名字就好了
job 的另一个组成部分是参数，而保存参数还是比较简单的，毕竟有反射，如果你想，可以把 runtime 对象整个扫描一遍再用反射造回来