duangsuse::Echo
716 subscribers
4.25K photos
130 videos
583 files
6.47K links
import this:
美而不丑、明而不暗、短而不凡、长而不乱,扁平不宽,读而后码,行之天下,勿托地上天国。
异常勿吞,难过勿过,叹一真理。效率是很重要,盲目最是低效。
简明是可靠的先验,不是可靠的祭品。
知其变,守其恒,为天下式;穷其变,知不穷,得地上势。知变守恒却穷变知新,我认真理,我不认真。

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
Forwarded from duangsuse Throws
对于自己出言也『讲排场』的中国政府,没有资格如此批评别人。 #China #Low
是,在你不谈 GFW 的时候,这些帐号的行为当然很正常,不过你装作看不到不代表别人不知道。中国官方对两个站的屏蔽已经是公开的秘密了,现在敢在国际场合提出这样摆明了基于谎言的回应“以洋人之道还制其身”,文过饰非了。

『了解”事实真相“』『“公众”舆论』『有”良知“』『有”正义“感』『言论“自由”』『“颠倒”黑白』『”虚伪“面纱』 — 你好有良知和正义感啊!不过不知道什么时候才能从『民族主义”正义“感』上升到无前缀无引号的『正义感』
要是我什么时候也能有如此之厚的脸皮,郑重声明自己从没做过一个自己正在做的事情,并且反过来讥讽那些真正没做过的人就好了。 假作真时真亦假嘛。
为什么你所”信仰“的东西,每一个倒过来贴在自己身上都显得是那么的刺眼

你摆的是(带过滤、断章取义的)『“事实”』、你“讲”的是(聋子说出来的)『“道理”』,你是真理部,你牛、你很中国,我佩服。

富强 『民主』... 有人敢穿着这两个字上街吗?
Forwarded from Solidot
网信办回应 Twitter 和 Facebook 屏蔽部分中国账号

Twitter 和 Facebook 最近屏蔽了部分传播假消息的中国账号,两家网站早已被屏蔽,但有部分账号是通过直接线路访问 Twitter 的。对于美国两大社交网络的做法,中央网信办副主任、国家网信办副主任刘烈宏在国新办发布会上表示:个别境外媒体戴着有色眼镜来看待国际舆论场上有良知的网民和媒体发出的正义声音,声称其散布 “假新闻”。这种颠倒黑白的做法,撕下了一些国家所谓 “言论自由” 的虚伪面纱。如果这些摆事实、讲道理的声音也被认为是假新闻的话,我想,一切了解事实真相、有正义感的人是不会认同,也不会答应的...Media

https://www.solidot.org/story?sid=61884
duangsuse::Echo
李鹏日记.pdf
做一个注释,这个《李鹏日记》是最初有纸质版本的(并且就是纸质发表) #China #NSFW
最初名为《关键时刻》,署名是李鹏,并且我通过搜索资料知悉此总理的确有写以日记为题的自传的爱好,显然在当年李鹏出版这本《日记》的理由和能力还是有的。
但是来源和可信度不能确定,不过应该不是出自对中国不利方面人士之手(因为其中的记叙实际上倾向政府方面,即便网上能够找到的资料争议性很大)。

六四事件的初衷是好的,但估摸有些学生领袖受到了外国敌对势力的利用,在军队开始攻击之前应该的确有民众四处捣乱(e.g. 抢劫商店、抢劫武器、围攻军人军车等)
甚至可能造成了军人的伤亡(据总理称,有军官被杀后非人地被悬挂在高处)
按照官方的说法,军队始终保持最大限度的克制,并且尽可能少开枪。

一个有争议的问题是究竟有什么数量级的伤亡,争议的原因大概是网上找不到可信的信息源 [官方:李鹏《关键时刻》] [民间:受害者家属] [民间:64memo]
(a) 政府方面对六四的态度本身存在很大问题,所以虽然公布的死亡人数贴合一些其他数据的预估,也不可信
(b) 民间受害者和民主群体的记录,影像虽然伪造可能性很低(按照工作量来算,我觉得这不可思议!虽然它不代表正义,但是军民的冲突是非常非常严重的),但是
1. 有些民间个人/团体存在夸大的嫌疑,从我找到哪怕是受害者方面的信息来看,死亡人数不可能达到万人
2. 有些团体和法轮功等反华势力有关系,或者和外国敌对势力纠缠不清,即便外国势力不一定就是想利用此事(看中国政府最近对香港的铁腕态度也知道,显然自家的事情国外掺和不进来的)
3. 官方(《李鹏日记》)宣布的一个外国记者也拍到了清场的画面,据说无一人伤亡,这样实际上两方的影像肯定有一组是假冒的
并且,官方引用到几个民主派人士均表示六四清场没有屠杀

关于六四伤亡的问题是讨论比较少的内容,我现在根据得到的一些信息默认伤亡为 300-500, 多至 1k 左右
👍 #厉害了我的国 厉害了!我的博! 我今天算是见识了一下 C2C 模式!果真 _____!
Forwarded from duangsuse Throws
#China #Copycat #Sina #Weibo #C2C 经典案例!成功示范!教科书式的个人 VBlogging 系统布局/徽标风格级完全复制!
Forwarded from 今日份的豆酱 (hjthjthjt | 拖延一时爽,一直拖一直爽)
微博新出品的「绿洲」,和 Instagram 简直是像素级的______
#Windows Net :: SHell :: WinHTTP :: Proxy . import (source=IE) / Net :: SHell :: WinHTTP :: Proxy [reset] NetDiag.exe... DcDiag.exe... net use ... net time /setsntp time.windows.com... 还有 MSBA, DNS, LANManager, RRAS, IIS 什么的...
Forwarded from ZYBYZ's Channel (WJXXBSH)
[ 让 Windows Update 通过代理服务器 ]
————————
近日怀疑学校的网络干扰了 Windows Update(检查/下载更新)和应用商店(应用下载/更新)的访问,因此决定通过代理服务器暂时解决问题;但多次尝试均已“无法连接到服务器”告终,与未启用代理时情况相同。
经查发现,自 Windows 10/Server 2016 起,除了常规的 IE 代理设置之外,还需要额外对 WinHTTP 配置代理,才能让 Windows Update 完全通过代理(Shadowsocks 仅自动配置了前者)。
————————
通过命令
netsh winhttp import proxy source=ie
可以快速将 IE 代理的配置同步到 WinHTTP,还原配置则可以使用:
netsh winhttp reset proxy
Forwarded from dnaugsuz
我感觉 Kotlin 的工业化很有意义,已经把一些觉悟高的普通 Java 程序员(语言理解完全程度大概是小白)带成熟知面向对象继承、封装、抽象、多态,面向对象的基本可见性可变性原则、信号/行为、状态转移、抽象的一般化和特殊化、ORM/系数关系、生命周期、自理性、序列化,了解函数式编程和闭包,了解代理、状态、协程、CPS、Threads/Tasks 的进阶者了,有没有道理呢 🤔

顺路推荐 《软件工程导论》 #book 虽然感觉意义不是很大,而且软件工程往往不被重视,但其中提及的一些原则是十分有价值的,比如:拒绝暴力查错、以思考代替完全依赖调试数据的『瞎改直到修好』 (jiggle things randomly until they unbreak),因为这样耗时而且容易引入更多的错误、难看的修复方案,也有可能导致严重的错误被更晚发现

《软件工程导论》虽然是『专科』书籍,但是我感觉其内容物超所值,总比谭老师的《谭 C》强很多 应该。

为什么部分本科用落后的书籍
Forwarded from dnaugsuz
这名字有点长啊... luaInstance 难不成是单例的... 为什么不直接上 Kotlin 推荐的 object 单例(还可以 Mixin 接口啥的
State 的需求很常见啊,虚拟机的 LuaState 都上全局状态就缺少灵活性了

一些 trivial 的定义就直接划等号好了,如果返回值有差异也可以不严格遵循缩进,写到一行去,毕竟「一个行为」占多行也挺怪的,不像「语句块」(statement compound) 这种东西的本意

val func0: ((arg: CPointer<ByteVar>?) -> ...) 这个 arg 就不用写了,有点余赘

typealias char_p = CPointer<ByteVar>?

此外 regFunction 可以考虑泛化一下,如果有的话也该重命名为 regStr2StrFunction 之类的啊... 标识符的信息量有点容易模糊了,一些通用数据表述转换的模式也该抽提出来

val wrapCKs2Cs: (char_p) -> char_p = { strfunc(it!!.toKString()).cstr.getPointer(this) }

char_p (aka. CPointer<ByteVar>?) 上的 toKString 可以抽提一下,弄个 forceString() / mustString() 什么的
(反正是在 KN 侧编程,什么 KString 啊 CString 啊... 扩展方法 monkey patch 限制下作用域就好了)

这个 memScope 有点奇怪... 谁帮我解释一下 总感觉这个 wrapper 函数的 result 分配生存期似乎不应该是相对于注册它的函数来说的,而是相对于调用它的函数来说的,这部分的分配和收集本应该交给 LuaC_* Lua 侧的 GC 来完成,或许应该注册 userdata? 或者用 Lua 的字符串池创建接口?
不熟悉 KN 的 GC... 我也不知道它是 Tracing 的(Graph Walker)还是 Refcount 的还是二者兼有的... 只知道 KN 的 GC 实现还算小,大概不会是半空间/分代收集/碰撞分配的(要不然也不会有 NativeHeap , 指不定是空闲链表,Lua 也是空闲链表...)
Forwarded from 立音喵
KN 的自动释放内存区域
在里面创建的 getPointer 会在出这个范围时自动 free
Forwarded from dnaugsuz
emmm.... 可是如果先出作用域再有某作用域的分配呢? 会不会直接 free

闭包的算不算 memScoped 里面的... 或许算吧
Forwarded from dnaugsuz
怀疑这么写会导致空字符串指针
返回给 Lua 调用侧的看起来好像早就被标记 free 了

regFun(gname, sfunc) = memScoped {
val wrap = { it: char_p -> ...cstr.getPointer(this@memScoped) }
lua.regFun(gname, wrap)
}
Forwarded from 立音喵
是的…
Forwarded from 立音喵
所以现在已经不是这样了
#Telegram 不管怎么说,我觉得 SCP 的开发者们很有水平,包括是项目最开始『元设计』(把设计的缘由和要点,真正的需求写出来)、项目作者的公钥和联系方式、每个项目的详情(作为博文发布,且有一个包含大概需要的列表)

他们的架构设计也很有意思,虽然基本上完全是 Python 写的,但有趣的地方是: 他们利用了 Telegram Bot 和平台本身的集成度,把每个步骤/流程都解耦合划分给了单独的 Bot 实例,通过 boardcast message 来实现数据交流
这不仅仅意味着一切对管理者来说更加可见,还增加了机器人们的灵活性(比如,处理某种消息的机器人可以在某个 Telegram 频道和其他平台模块「对接」,从而在更大的范围里处理消息、群主可以随意引入需要的机器人同时节约计算资源、模块高内聚低耦合无须考虑内部实现、不必在一台主机上运作)

当然,在某些方面也有不好的地方(增加了计算资源开销,因为每个机器人都要遍历消息一遍,如果文本处理结果的复用没做好,开销会稍微大、机器人文本传输给 Telegram 增加了一点点负担、项目结构虽然易读模块化低耦合但略微臃肿)

也有一些我没法理解的地方,比如说 SCP-079 的 HIDE 机器人,其功能就是接收有发布消息广播功能机器人的信息转发请求,做一个『发布代理』(当然,只是二次转发,其出处可以是在一个私有群组/不知名广播里)
而这个代理存在的理由只是「帮助隐藏管理机器人的身份,免得 spammer 认出它们」
可是 「spammer」 就算是认出了机器人又能怎么办呢?
如果 spammer 认出机器人就不发垃圾消息,可如果机器人保证自己会检查每个人的消息并且提供群成员手工检查渠道,广告就不能存在,而且经常给机器人换马甲也比较麻烦。

HIDE 机器人的代码质量很高,文件划分得也很不错,但是隐隐约约也能感到它划分得有些过头了,因为 HIDE 使用的文件数目相对于它的功能 — 仅仅是按照某频道里的请求转发消息 实在是多得过分
channel.py 是拿来管理交换的,可其中和模块 HIDE 有相当大关系的只有 exchange_to_hide。 format_data 和 share_data 里有不少代码都是和这个模块本身完全无关的,本来应该多划分一个 SCP079-COMMON Python3 包,却采取了每个项目复制一遍的方式来管理
— 为了保证良好的异常安全性,几乎是所有的函数都加上了 try/except,即便有些函数根本不可能抛出异常(比如序列化用的 dumps)
— 同样是异常安全性:

from threading import Thread
from json import dumps

'''
Thread helper function
要我写会这么写
'''
def thread(routn: callable, argv: tuple, nam: str = None,
catcher: callable = lambda e: log.warn(f"Thread fail: {e}", exc_info=True), daem = False) -> Thread:
try:
thr = Thread(target=routn, args=argv)
thr.name, thr.daemon = (thr.name if nam is None else nam, daem)
thr.start()
return thr
except Exception as e:
catcher(e, thr)
return None

'''
那 SCP 写的时候一些辅助函数是怎么写的?
'''
def bold(text: Any) -> str:
# Get a bold text # 注释而不是文档
try:
text = str(text) # 强制类型转换
if text.strip(): # 尝试在不应该失败的调用上异常安全
return f"<b>{escape(str(text))}</b>" # 太「空」的缩进语义,应该用 return ... if 写在一行内
except Exception as e:
logger.warning(f"Bold error: {e}", exc_info=True) # 极端情况(比如内存耗尽)下,logger 也不一定可以正常工作
return "" # 控制流不直接(当然也没办法...)

def format_data(sender: str, receivers: List[str], action: str, action_type: str,
data: Union[bool, dict, int, str] = None) -> str:
....
except Exception as e: # 在不应该失败的情况下处理错误
logger.warning(f"Format data error: {e}", exc_info=True)

SCP 写的时候有点太过拘泥于某种特定的格式了,也没有用代码块(block) 来进一步抽提逻辑
总之,虽然 SCP 很注重模块化细分,但复用却做得不是很好(必要的模块居然被称为插件!),一个项目里居然能看到 7 个文件全是冗余可共享代码的情况...

附:HIDE 的文件
channel 数据交换管理,其中三个函数皆可复用而无必要放在特定模块里
etc 辅助函数(诸如文本格式化),其中绝大部分函数为无异常(noexcept)甚至纯函数,但全都被加上了 except Exception as e: logger.warn(f"{e}", exc_info = True)
还包含一个 thread 辅助函数和一个 flood_wait 函数,其中 flood_wait 为串行(serial) 阻塞线程的函数,且使用了不必要的 random.uniform [min, maxI), 应考虑将消息发布转为 async 函数来提升便利性和并发量
filters 包含 Pyogram 的两个 Filter(大概是 Telegram 支持机器人只处理特定消息,可这好像完全是在客户端处理的)
from_user, exchange_channel, hide_channel, test_group 其中一个冗余(在使用元编程的情况下四个均冗余),可用 1~2 个函数抽提逻辑
逻辑表达式(兼控制流断言)代码质量欠佳、在不可能失败的情况(0 分配布耳表达式)下依然 except:...
        if message.chat:
cid = message.chat.id # 代码质量不佳
if glovar.should_hide:
if cid == glovar.hide_channel_id:
return True
elif cid == glovar.exchange_channel_id:
return True
should be:
xchannel_id = glovar.hide_channel_id if glovar.should_hide else glovar.exchange_channel_id
is_exchange_channel = ptgfilt(lambda m: m.chat && m.chat.id == xchannel_id)

receive 也是两个可共享逻辑
telegram 的 forward_messages 属于可以共享的范畴,可以考虑抽提。 send_message 属于应该共享的子程序
其中,Telegram 的 FloodWait 可以利用函数装饰器抽提
不可能出错的函数不应该异常安全处理 try: / if text.strip():
对 None 的判断应该显式标记 if text.strip():
在 Python 里,使用提前返回而不是嵌套 if
对于单个 Flag 的 while 循环,使用 break / next 比 flood_wait = True... 要强
如果可以不用 ret 系变量仅仅用于临时存储返回值,就不用或者最小化限制其作用域 result = None ... return result,这里 result 可以更名为 lastresult 以强化重试到成功的逻辑

backup: 简单的 ping 逻辑,完全可以在所有 bot 间共享,但却每个 bot 复制了一份

文档里经常出现这样的代码实例:

exchange = format_data(sender = 'LONG', receivers = ['MANAGE'], action_type = 'request', action = 'leave', data = /groupReason/)

也恰恰证明了这是一个协作有方的团体,尽管并不大。
包括 Telegram 上明确的文件列表和叙述、清楚的模块细分,也是高水平程序员的标杆
Forwarded from dnaugsuz
讲个笑话:文本上直接中文分词 + Naive bayes 朴素贝叶丝分类(如果 Chinese Lexical Analyize 全字典大了就上精简字典什么的... 有并行计算高性能框架的)
短图二维码和 short link 跳转用消息队列慢慢查

行为上算个大体的策略,虽然不得不接收所有消息的 onMessage, 可是对可信用户的检查可直接跳过 / 随机抽查 / 添加人工 bot command 允许群友重新审查
可信用户的选择可以对每个群设置一个基准,连续发送 N 个安全消息的就算可信用户

行为不要老是看维度什么的,又不必要 kNN(何况 ML 领域又不是 kNN 一家独大,kNN 明明是最入门的算法之一,虽然也不只是 kNN 可以接收「多维度」),你反个 spam 比 spammer 还开销,还不如不反
Telegram 的 spammer 一般也就靠二维码、short link、裸消息文字了,二维码的还不能发重复图片,因为会被直接认出来

很多 userbot spammer 就是加能加的群,然后入群慢慢发广告,发几个可能退出可能继续待着
普通用户就算是偶尔刷消息,在广告屏蔽上也不应该予以屏蔽,也可以节省资源来做到更大并发量

非得从 0 开始监督式学习,要大量数据,反而不好,何况这个模型也不好设计(即便我们只是说「用户的行为」,比如说 Telegram 里有些群只在中午交流、有些群是深夜,得为每个群制定标准,这合适吗?)

我觉得没必要为了 anti-spam 去收集用户行为,因为对几乎所有群聊来说,很多 spammer 就是发个广告而已,可以做简单一点,踢出屏蔽随机进攻的 AD userbot 即可

对于误封,可信用户若是不小心被查到(可能是误查)spam,则不踢出群聊,发警告 + restrict 就可以了,等待管理员确认