duangsuse::Echo

我在说的是，现在的app程序员根本没一点设计力，都是被语言框架牵着鼻子走。一个 int长度的问题 -D int 'long long' 就能解决了，属于打包者都能改的配置。这算什么设计问题？难道对一个数据类搞出 dt.setDay(dt.getDays()+1) 这种接口就叫设计模式了？
“安全”“效率”“体积”“开发速度”“维护难度”
我寻思SQL/XSS代码注入时，工程化也没有改善 malloc()和缓冲区溢出的同是RCE的问题啊？还不是靠记住数组长度、对象图Rc、编译期空检查之类的「规范化」编程界才走出这种最基本的“难题”？
至于(开发)效率，numpy API 在没有什么心智开销的前提下，提供了向量化和线性代数，这需要什么设计模式？React 模板算什么设计模式？不过是抄了小学数学，加了点文档即示例
体积就不用说了，microPy 和 pyodide.org 下载12M即可全平台开启CPython ，难道一个Outlook比整个py+std 还复杂3倍？

假设像素图颜色格式是 16bit RGB 你看看怎么整除3。这都是有取舍的，无损wav也是s16 一个点
它就只能量化每通道6bit，现在很多LLM也是大量参数低精浮点
当然RGB24和YUV没有变绿问题

那小而美的代码当然是有维护门槛的，谁叫软件工程界没个规范，还在记住 int,long 占几byte、何时alloc-free 上耗时间
你说一味追求“快”“小”的产物所做出来的东西应用在生产中只会是灾难，我看让一个简单app的整个「体系」无法解释的过度工程，才是最大的灾难
如果连这个领域的demo怎么实现都不懂，从不思考实体背后的复用逻辑，用“工程技巧”添加几个参数，恐怕也就只是bash脚本级别的设计。然而我看到很多的设计模式，都是这样的三脚猫，因此所谓静态语言才和jspy产生那么大隔阂

“人类不配写代码”。也正因如此
简单清晰是可靠的先决条件，不是可靠的牺牲品。
简单直接的代码\=易取代的初级代码

https://t.me/dsuses/5315

见 xz/liblzma 事件
https://t.me/solidot/23779
liblzma 库中的某些函数来实现这一点，其载荷是间接加载到 sshd 中的。sshd 实现了对 systemd-notify 的支持，liblzma 被加载是因为它是 libsystemd 的其他部分所依赖的，systemd 的复杂度再次成为了实际上的安全隐患。

https://t.me/solidot/23779
liblzma 库中的某些函数来实现这一点，其载荷是间接加载到 sshd 中的。sshd 实现了对 systemd-notify 的支持，liblzma 被加载是因为它是 libsystemd 的其他部分所依赖的，systemd 的复杂度再次成为了实际上的安全隐患。

🤔💭 一个运维工具怎么自带了压缩软件？简单清晰是可靠的先决条件，不是可靠的牺牲品。
比如，SysV风格init的，不同进程的定期.log压缩，就不会有代码注入问题

这就叫言多必失，硬要单二进制，即便无所谓的特性也要C语言
为什么sudo, visudo 连LD_PRELOAD也要检查呢？

for f in /{bin,lib64}/*; do ldd 2>&1 $f|grep liblzma.so && echo $f ; done |grep '^/' >1
xargs <1 pacman -Qo|cut -d' ' -f3|sort|uniq >2

查了下我一共有1275个二进制使用了libz，近4k个文件包含了依赖

但不清楚有多少个需要root，这些文件属于523个包，包含 apt;dbus-daemon;pulseaudio;putty;gvfs;gdb;Xorg 和近30个systemd-*; GNOME服务