Telegram Web
dnaugsuz
即使使用英文, #PLT 领域内就连最简单的术语都充满着歧义和晦涩。如果你对 PLT 里的各种术语仍未祛魅,去搞清楚 dependent sum type 和 sum type 的区别吧,这是每一个 PLer 学习过程中必吃的 💩。 啊,这个 #dalao 说的道理太好了,我太喜欢了 https://github.com/anqur/TinyLean hole 和 React useHook(var) 差不多,这种比喻都被一些人视为不优雅的。 就是要去魅,要抽象,要解构 比如那个栏目答(入x. x+1)…
我第一个经过验证的命令式程序
原文:https://markushimmel.de/blog/my-first-verified-imperative-program/
阅读时间:13 分钟
分数:173

Hoare三元组的一般形式为{ P } S { Q },其中P和Q是断言(assertions),分别称为前置条件(precondition)和后置条件(postcondition),S是一个程序语句或程序段。
含义
{ P } S { Q }表示如果在执行语句S之前,程序的状态满足前置条件P,并且语句S正常终止,那么在语句S执行完毕后,程序的状态将满足后置条件Q。也就是说,前置条件描述了执行语句S之前程序应满足的状态,后置条件描述了执行语句S之后程序应达到的状态。

#PLT 笑传之重重彼
都是车轱辘话
duangsuse::Echo
#linux #tool https://github.com/systemd/systemd/pull/32510 不知道你们是怎么查命令格式的, 我写了个脚本专门可视化help并延时搜索 cht.sh 其实我挺奇怪, argparse 这么机械化的格式,为啥打包者要手写bash complete -F 脚本,甚至重造getopt("h:v"), 以至于 import fire 都要以生成各种sh补齐为功能点 ——它的大特性显然是用OOP解释了bash subcmd -f x -f1 X 而不是反过来,就像…
#linux 我觉得bash这些东西也真是垃圾, 可以说是完全不可扩展,拍脑门子

没有作为框架的意识。 比如,能安装文件,但反函数(卸载)需要手写;能解析参数,但补齐需要另外写, 而且 colorize 起来也很麻烦
alias w=echo who-w=$(which w)
declare -A tputKV=(
[🟥]=1 [🟩]=2 [🟨]=3 [🟦]=4
[🟪]=5 [⬜️]=7 [⬛️]=0 [🏙]=6
)
for d in {0,8}; do for k in "${!tputKV[@]}"; do
declare -A "fputKV$d[$k]=$(tput setaf $((${tputKV[$k]} + $d)))"
declare -A "tputKV$d[$k]=$(tput setab $((${tputKV[$k]} + $d)))"
done; done
I=$(tput sgr0)
tputKV8['⬛️']=$I
FG() { w ${fputKV8[$1]}; }; Fg() { w ${fputKV0[$1]}; }
BG() { w ${tputKV8[$1]}; }; Bg() { w ${tputKV0[$1]}; }

FBG() { u=$(node -p '((ks,v)=>"w "+process.argv[1].replace(/\b(.)(-?) /g, (_,cv,b,i)=>(i=ks.indexOf(cv))==-1? cv : `$(${b?"B":"F"}${process.env.g?"g":"G"} ${v[i]})` ) +" $I")("BYGRPZWI", [..."🏙🟨🟩🟥🟪⬛️⬜️🟦"])' "$*"); eval $u; w $u; }


Pwsh, Zsh 与它们相比就有思想多了

现在软件开发30%的过度工程都是UNIX脚本小子害的,可以说功过六四分
https://github.com/sharkdp/bat/blob/master/assets/completions/_bat.ps1.in#L23
3
duangsuse::Echo
没有作为框架的意识。
让我觉得匪夷所思的是, FRP 脚本有很多,但基本都是拿到地址就(可以公网)测试了,就像你只是调用了一下curl而已

Linux hostnamectl 这个特性,似乎是可有可无的,存在感比蓝牙设备名还低

当我封装CF的公网tunnel时,理所当然就把此服务封装成 $HOSTNAME 了,回头一看我居然是异类。 😅

ps. 好吧…… 脚本其实挺少的,不过我这么加 .com 也未必是UNIX主机名的本意。有由谁知道 write $USER <<<'fsck u' 可以在tty下看到广播?

可编程性就是从约定里来的
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 不靠谱的喵(>^ω^<) #CatGPT (Yuze Wu 🐱 | 女子大学生 | 喵!)
放弃幻想.jpg
#tg 炸掉的VIP翻译似乎好了
duangsuse::Echo
可以说是完全不可扩展,拍脑门子
#bash 作为90%部署团队和程序员都要用的玩意,一个胶水语言,我整理个语法十宗罪 😅😅


提前叠个甲,我觉得bash的分号和分词问题( if [ ]; then...fi 里 '[' 展开为test命令,只有(...块)和return是真语法,因此, [ x=y ] 无效, x = $((x+1)) 也无效…… 包括可嵌套的 "hi ' "" '.." ,这些怪癖不影响语意,只会让强迫症砸键盘

我也不吐槽「所有」编程语言都有的赋值默认global、没有默认return、包安装发布比不上pypi的毛病,而且 bash 的 cat/echo> IO 其实还算好用的,启动也尤其快

- --help 既没有高亮阅读器( ? ls ),也没有统一规范,空有个需要程序员手写的Tab补齐。 cli 传参不过就是 URL /:path/?param ENV==kwarg body=stdin 这样的模式,统一不了么。
- |awk sed 一把梭,一切皆str,没有逃生窗口,没有csv和toml。 pwsh再次完胜GNU.😅
- 经常出现 nano; 退出; gcc; nano 的循环,没有 live reload (ps. ! prefix 可一键重复旧命令 谁知道),也不能把其他pid的jobs/tty连接过来,只能一遍过:改参数、改 -o 也麻烦

- "$str" 是参数引用, $fn 是vararg或命令指针(仅全局,不可以SAM捕获😅
- () 这么重要的语法被拿来开“subshell”, is&&(say;cry;return) 这样的现代流控不能写, echo $(echo 1) 却不配拿简化
典型的先辈的罪, 设计API你不看词频,也不查重?🙉 #statement
- <<heredoc 内的$也有效,不适合内插pyjs等语言(bash自己需要 declare -f 内插),不如ES6安全内插
- 不支持参数名、闭包(比如, systemctl | grep {is u type : service & (u pid)>1000} 这种)
bash 确实没法把cli都对象化,但提供方法表是很轻松的(取值时 systemctl status $you)

当然RPC绑定太麻烦了,要先把{is u type} 序列化成sh字符串,在回调时再去取status, 但也是有意义的,比如 apt info x 变成 $x info 后,可以在grep里属性访问了

- 管道不支持 -o file 的命令,2>&1 1>/dev/null 太麻烦(fish 里是 |& ),返回值基本只判定非0,没有errno那样的统一
- env表没有基本的str/int/csv列表类型,和argv一样; int fd cookie也没有类型(实际上它是种轻量对象)
- env不能作状态持久化,也不支持像Telegram一样,给输出消息或apidoc加按钮(比如sudo重新执行还要复制粘贴)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Solidot 纯净版
麦当劳的 AI 招聘平台管理员密码是 123456
#娱乐

今天想要应聘麦当劳工作的人可能首先需要在 McHire.com 平台上与 AI 聊天机器人 Olivia 聊一聊。Olivia 会询问应聘者个人信息和简历,进行性格测试。该聊天机器人由 Paradox.ai 公司提供。安全研究员 Ian Carroll 和 Sam Curry 在听闻麦当劳使用 AI 聊天机器人筛选应聘者后好奇之下对 McHire.com 进行了一番研究,结果意外发现该平台的管理员用户名和密码都是 123456。登陆管理员面板之后,他们可以访问 Paradox.ai 账户,查询该公司保存的所有 McHire 用户与 Olivia 聊天记录的数据库。数据库包含了多达 6400 万条记录,包括了应聘者的姓名、电子邮件地址和电话号码。麦当劳表示 Paradox.ai 需要对该漏洞负责。Paradox.ai 确认并在一天内修复了漏洞。
ian.sh/mcdonalds
duangsuse::Echo
可编程性就是从约定里来的
你们别看我经常写脚本,我的API思维没有被 #bash #py 带偏……🤔

给不懂开发的极客科普下「编程范式」的进化吧,比如说 C, Java, JS(Vue)和SQL
它们分别是 [面向过程POP] [面向对象OOP] [函数和关系式FP/Reactive]

#learn
三种范式,可以从语言学、指针宽度、类型广度 拆解比喻一下。
编程范式,就是看「如何把数据和代码绑在一起更好续写」? 实践上,语法和类型能够辅助思考。
Rust 是一个静态优化、支持预处理(码可揉)的OOP, 它的函数式能力不如pyJS,这是省略变量树GC的代价。

# 语言学: VSO,SVO,noVerb 🌐

以文件夹版本控制/网盘站 GitHub.com/:u/:repo 的 $ gh 工具为例
gh login
gh new-repo $(rand).paradigm.org


这个功能点所见即所得,那拿3种范式将其封装为函数。
loginGh(id, secret): VO
newGhRepo(id): VSO


坏处是无法管理多个账户,所以只能写写游戏脚本、按键精灵、爬虫。

很明显,这是因为账户和 $HOM/ 的配置文件耦合了,成为了 globalThis。把this配置参数化,我们不仅能多账号,还收获了json这种文档格式! C语言的 .o 对象,就缺乏局部键值,只有线程局部。

gh=Gh.login(id,secret): SV
gh.newRepo: SVO
# 范式是跨语言的
(u= gh login root toor)=="gh badguy"
$u repo new (randProj)

这样才符合人类直觉: 不要光 call, 要 with 🥰

虽然他没有“优化掉”arg0(为全局 省字数),但因为全局是可以随便加的,class{} 键值是密封的,在开小号之外,我们又有了类型和补齐


所以更OOP(但反直觉)的写法是:

gh=Gh.new(id,secret): Snew
gh.Repo.new('jackass'): SnewO

Gh.static.setApiURL(): SgetsetO
这一条是不依赖登录的(静态函数)。

OOP优秀的一点是调用链, Object也可以作为 context Subject 继续作联动(类似SQL JOIN)
不过,叠3层new就说明这框架不能用了,过度设计。

最后是FP,因为很多人高估了FP的语意,甚至用纯函数冗余来 “拉抬🐷价”,我要加个需求以彰显其意义:
login() 要支持OTP单次密码,而它必须在密码正确后才能输入,或者要多次重试…… 但 ()=>栏目答都能胜任:
Gh.login(uid,secret, otp=> device._2fa.get(otp))

一般来说,FP 用户不会缺少对OOP的进阶理解,比如用 get(otp) 重载 db.otp.getKey(otp) 、用 atoi:Int=>[Int ValueError Mayfail],这种摘要性(或者说严谨)好的心智模型,而不是和JQ那样只懂起名和拼凑调用链的库一样。
Vue对单 ref() 多显示的理解也是靠起名无法实现的。

btw. 命名动词还是有意义的。 比如佐人经常区分「买」和「雇佣」,「赤字」和「借」,但事实上是一样的。 混淆视听会损失类比的空间。

FP对于 gh newRepo 这种业务也有加成,比如用 await Promise((ok,KO)=> callback=ok ) 自动回调化来避免嵌套的「闭包链表」,实现yield分块优化等等

# 指针宽度

指针就是超链接。 它的域名是你的内存,地址是一个64或32位的整数,有 rw, r, rx 三种经典鉴权段位。 对JVM和v8来说,并不是所有bit都用于标记一串byte元组(struct)的读写位置,至少x64上的void* 只有52个有效位。
C, Java, JS(Vue) 里本质上是指针(Any/interface{}类型) 的模型,信息量也不同。

C: 单个内存地址,比如x32就是2**32, 4G 随便存,x64就是天文数字 (但是没有意义,比如,连是 int, 普通struct, Umbrastr 都分不清,需要printf手写%d )
Java: this=data+funcs 双指针,把变量树和方法表存在一起,可以 override ,再比如用 args=Array[0:length] 取代 (argc,argv) 元组,也是头尾双指针
Vue: ref()= N个回调 多指针, 回调可用于赋值,可以随便组合数据与计算、业务逻辑;SQL外键同理,可以用于拆分表单,多处复用

# 类型系统

C: 基于sizeof,没有 range/str/list/kv(tuple set) 等(可变)容器, 没有 T::fun 等模块化
Java: 基于 obj.(type) ,类型存在于编译期和运行期,可以数据化(反射),可以像函数值字典的Builder一样写class{}
Vue: 因为领域不同,JS 更重视业务而不是可维护性。 类型只是IDE的工具,没有优劣,🤓 DOM 的宽广和稳固、框架的繁荣让JS无需类型即可安全高效

最后,在标志性「语言特性」上,自古以来是这样:
- biosC=x86nasm+函数和8种整数的超链接
- C=biosC+ld文件maps内存段+CPU分片 (作为"libc的JVM")
- PyJS=C+双指针和kw左值传参 [双指针fatPtr] ([len,] {type:}和{proto:{vtable}} {_树内硬链接refcount:0} 均占用16byte)
- FP=PyJS+单函数组合+正择解构再构 (谈UIUX框架,没有[轮询或卡线程pull]是evpoll&push、多监听取代不了的,只是,C的无闭包和while(1)死循环,禁止了回调链表新加异步栈)


假如,编程是让懒得点黑框框的人用电脑,元编程就是让看不懂花花代码的人用编程。 所以,编程范式的「组合穿搭」还是很重要的,并不是古生物学那样的冷门哲学

试想一下,如果就连框架作者、架构师用的语言和runtime你都知根知底, 你自己设计,或分析吐槽别人的作品,还困难吗? 基础领域并不是象牙塔,它与软件开发者的身心健康息息相关。
duangsuse::Echo
让我觉得匪夷所思的是, FRP 脚本有很多,但基本都是拿到地址就(可以公网)测试了,就像你只是调用了一下curl而已 Linux hostnamectl 这个特性,似乎是可有可无的,存在感比蓝牙设备名还低 当我封装CF的公网tunnel时,理所当然就把此服务封装成 $HOSTNAME 了,回头一看我居然是异类。 😅 ps. 好吧…… 脚本其实挺少的,不过我这么加 .com 也未必是UNIX主机名的本意。有由谁知道 write $USER <<<'fsck u' 可以在tty下看到广播? 可编程性就是从约定里来的
#web #dev 这个真是懒得喷。 我理解的REST(可表达状态转移, curl https://wtf = count: x=>x+1) 是什么? 😅 😅

就是 db.GET PUT json, 加上过滤排序分页, 或许有些 /user/:id/follow 的页面可以手写下,也可能直接套模板生成(哪个平台没有一堆“收藏夹”啊..)

这种RPC当然毫无价值,类似于把本地存储换到线上,只是加个鉴权和双向搜索罢了,查重率100% 我是懒得手写的, GraphQL.org 也封装的明明白白。
我觉得奇怪的是,哪怕是在PyJS的全栈框架里, 我说的这种REST,对 BlogComment, Todos, PetShop 等基础CMS样板也没法做成和Excel一样简单; 那些淘宝上卖的(开源投自制) 也都没有重用重构的价值


这篇文章在替发明REST这个「高端概念」的大佬,抱怨工程师们什么呢? 是 HateoAS (讨厌OpenAPIs?? ) 没人玩。 😅
也不是讨厌,是用res.body XML上的nullable函数超链接,表示“用户有没有登录” “用户能不能删贴”,来「方便App跨版本」 等等,比SOAP好一点

这不是废话么?? 这都2025了还有人把活爹.XML(schema)当个宝呢。 你说说Java里怎么生成 OPTIONS / 啊? 有了 HATEOAS 接口,在JS里免client lib 直接调用的DX体验怎么样??

没有TG自己造传输层协议的能力,还抱怨工程上restful的理解了RESTful, 那比你强的就是懒得为REST这种高度自限性的RPC写框架,早自己玩更好的去了; 比你菜的又只会CRUD,最多拿 http/module/:pathArg 优化下可读性,对接下SQL或jsonKV, 你让他区分个 GET/POST 都懒

可不是被滥用和误解嘛, 纯属活该,自己不开发在那边画饼…… 你有没有意识到, api.x.com/OpenAPI.json 就是所谓的REST、免文档、自动发现函数、解耦合?

Java codegen 都没写过是怎么敢设计这种协议范式的? 不对,看他们 content-type 都要改成 vnd.XX.User+json 我就觉得这是 #ts 写上瘾了。 知不知道 fetch() 不能自动判定body类型,还要手动.json()一下……
如果你真能生成并用 OPTIONS /:type/:id 调用动态方法,那要http就没意义了(本质上是js rpc),所谓超文本又体现在哪。

我都可以给REST/HATEOAS重构成工程界可以接受的样子, 但我不会用单请求单响应。🙉

http方法本身也是烂梗, POST就是有body的GET,DELETE就是空body的POST, jQuery 里一直是这样重载的,十年了不见跨语言一点。 POST的“同名时冲突” 也是很脑残的约定,很多人只是为了在body里放文件上传一下, 根本就不该禁止,填写表格时多次检查。

🤡 https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
ps. 我是真的写过API生成的 https://github.com/duangsuse-valid-projects/GeekSpec-GeekApkv1.0b
SOAP砖家: https://coolshell.cn/articles/3585.html
Please open Telegram to view this post
VIEW IN TELEGRAM
2
duangsuse::Echo
那些淘宝上卖的(开源投自制)
#china baidu #low 智人tv之猜猜本
和 ghost 一样的功能收你99服务费,还不是正版

科学上网确实是回报率1000%的投资😂
#tool #security https://deltazefiro.github.io/Amarok-doc/intro.html
https://github.com/deltazefiro/Amarok-Hider/releases/download/v0.9.3/Amarok-v0.9.3.apk

一个破坏文件头,来实现防搜索(伪加密)的秒速文件夹加密应用。
用户体验超级棒, 算法只有两行 ,但是日用非常有效!

ps. 如果你有几千个文件需要hide,就只能用 .nomedia 模式了,不然死慢…… 应该给解密按钮加个单选文件夹功能
duangsuse::Echo
您好!向您自荐一个开源项目。希望得到您的转发支持,谢谢! https://github.com/SheepChef/Abracadabra
Abra.js.org
https://abracadabra.js.org/document/bench.html #security #china
https://abracadabra.js.org/document/FAQ.html

可以看到, 「魔曰」 文言文内容混淆的抗检测能力已经完全能在墙内使用 (还能用于压缩0x地址) 👍 真大佬,感觉和cloudwindy是一个殿堂级的了

那问题落在了密钥协商上面。 如果是朋友/私群间的QQ聊天,我觉得可以用彼此真正在用的手机号/@唯一网名 ,这样,对方导入个通讯录,就能在所有平台看穿你的消息,避免了每次手动加解密,比 KeyBase.io 快捷

如果是公开,也没必要用默认密钥,可以靠 PoW (CPU工时证明)。 消息分为明文、密文两部分,由用户选取密文/or 最后一行为密文
那么, 密码= scryptN(2**21, msg.replace(密文,''))
import scrypt
scrypt.hash("text", "abra.js", N=2**21, r=8,p=1)

#https://www.jsdelivr.com/package/npm/scrypt-pbkdf 慢一点
let { scrypt } = await import('https://esm.run/scrypt-pbkdf'); alert(await scrypt("text", "abra.js", 64, {N:2**20, r:8,p:1}))


在最新A17 iPhone上这需要2s,这样可以保证所有人都可读,但是即便AI能识别,逐个审查也非常困难。
之前我说用剪贴板管理器hook+A11y/WebShare服务做加密收发信, 最后还是鸽了…… 希望以后躺平下来去做吧
Hacker News 摘要
大多数RESTful API并不是真正的RESTful 原文:https://florian-kraemer.net//software-architecture/2025/07/07/Most-RESTful-APIs-are-not-really-RESTful.html 阅读时间:8 分钟 分数:305
臉書的人在介紹 GraphQL 時,寫了一篇很好的文章,說明為什麼 REST 變得有問題: https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html#why-invent-something-new 他們沒有那麼嚴厲,也承認 REST 確實解決了一個問題。

從他的文章裡:

但現在是時候打破沉默,承認 RESTful API 的概念可能是網路軟體史上被廣泛採用的最糟糕的點子之一。 Roy 可能是一個很棒的人,而且他肯定有很多很棒的想法。 然而,我不認為 RESTful API 是其中之一。

HATEOAS: 要符合 RESTful,你的應用程式需要公開一個初始 URI,並讓你的應用程式中的所有狀態變化都可以通過超媒體「被發現」。 這也很有局限性。 SOAP 試圖解決其中一些問題,但它並沒有取得多大成功,而且也不是銀彈

https://www.reddit.com/r/programming/comments/3jy0ci/restful_apis_the_big_lie #js
>客户端的状态几乎是由服务器端来驱动的,所以,讨论 API 版本管理并没有多大意义。客户端只要知道 REST API 的入口点就可以了,剩下的根据服务器端的响应来做决定

https://coolshell.cn/articles/22173.html
https://blog.logto.io/zh-TW/post-only-debate
2025/07/12 00:36:54
Back to Top
HTML Embed Code: