Home Sign Up Sign In
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
V2EX  ›  ipwx  ›  全部回复第 68 页 / 共 206 页
回复总数  4108
1 ... 64  65  66  67  68  69  70  71  72  73 ... 206  
❮ ❯
2021 年 7 月 25 日
回复了 MasterCai 创建的主题 › Apple › 2021 年 7 月， M1 芯片还有办法安装没有上架 MAS 的应用吗
@MasterCai 可是我觉得就算是苹果系统内核根据应用给的 option 来拒绝执行，本身也是应用在拒绝执行啊。

就好像你调用了系统 API 拒绝执行是一个道理啊。
2021 年 7 月 25 日
回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？
@sagaxu 主要是省了 flush 啊。你普通写入为了避免程序崩溃看不到最后的日志，很多时候要频繁 flush 的。
2021 年 7 月 25 日
回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？
不怕内存崩溃 => 不怕进程崩溃

话说回来依赖 mmap 如果系统宕机或者断电了，那也就没机会写回磁盘了。这点和 flush 就不一样了
2021 年 7 月 25 日
回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？
然后楼主你举的那个日志的例子很特殊，是永远顺序往下写的。写满一个 4096 块就不会再动了，系统完全有机会每次写满 4096 再刷新。而且因为是 mmap，每次写一条日志就不需要 flush （因为你不怕内存崩溃），相当于避免了频繁 << 4096 大小的文件写入，自然变快了。

缺点也很明显了，日志不是完全实时的。
2021 年 7 月 25 日
回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？
mmap 比 fwrite 快的主要原因，不是因为不需要一次内存拷贝么 2333 。fwrite 需要把内容拷贝到内核去，但是 mmap 直接就是内核的。

然后 mmap 写回磁盘的最小数据单位是 page size，一般 linux 上面是 4096 。好处是 flush / cache 都是 linux 内核管的，和虚拟内存走相同的方式。而且就算进程崩溃了，因为 mmap 是虚拟内存块，所以该写回的还是会写回。那么坏处就很显然了，如果每次都只改某些 4096 块的某些小地方，要写回的东西还是蛮多了（因为写回一次是按 4096 分块的）。读也亦然。
2021 年 7 月 25 日
回复了 LeeReamond 创建的主题 › 问与答 › 防止 sql 注入的原理是什么？
顺便发送参数也不是变成字符串。你可以翻一翻各个数据库自己的文档，肯定是有二进制协议的。这很显然，数字用数字的格式发送，字符串用字符串的格式发送，全程不会混淆，自然不会被注入。

可以说 prepared statement 其实并不是防注入而发明的，而是为了更快（省去编译优化 SQL 的过程，可以多次复用）。只不过因为它的原理，它天然不会被注入而已。
2021 年 7 月 25 日
回复了 LeeReamond 创建的主题 › 问与答 › 防止 sql 注入的原理是什么？
@LeeReamond 不是。

这些数据库服务器或者嵌入式数据库都有更底层的协议的（不是纯粹的 SQL ）。那些协议可以把带参数的 SQL （或者干脆预编译成字节码）和参数本身分开来打包传送给服务器（或者给嵌入式数据库的核心 API ）。数据库系统是直接拿着 SQL 或者字节码 + 这些参数工作的。

譬如 PostgreSQL https://www.postgresql.org/docs/9.3/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY

先发送 SQL，PostgreSQL 解析并编译这个 SQL，然后发送参数，最后执行。编译过的 SQL 可以不用再发送一遍，直接发送新的参数，可以继续执行。
2021 年 7 月 25 日
回复了 LeeReamond 创建的主题 › 问与答 › 防止 sql 注入的原理是什么？
@LeeReamond 举个例子，Python 标准库操作 Sqlite

cur.execute("select * from lang where first_appeared=:year", {"year": 1972})

这里 :year 就是绑定参数，后面的字典给参数。
2021 年 7 月 25 日
回复了 LeeReamond 创建的主题 › 问与答 › 防止 sql 注入的原理是什么？
@LeeReamond 为啥我觉得预编译写起来更快 2333

大概是 C++/Python 的库都比较好用？
2021 年 7 月 25 日
回复了 ljzxloaf 创建的主题 › Java › Java 目前实现全异步的方式有哪些
Actor model 很好用的。不过我不太熟 java，jvm 上只知道一个 akka 。
2021 年 7 月 25 日
回复了 t298 创建的主题 › 程序员 › 后端程序员用什么来证明自己呢？比如，美术，摄影可以有自己的作品，甚至前端也可以有自己的作品，后端总不能说自己搭了个网站吧
如果参与过牛逼的项目是不会担心没法证明自己的。牛逼的项目，后端难度可比前端高多了。
2021 年 7 月 23 日
回复了 docx 创建的主题 › 信息安全 › 搜狗输入法疑似通过注入其它程序来突破联网限制
顺便提一句，为什么刑法认为轻伤可以自行处分，而重伤不能。

* 轻伤如果不能自行处分——那打一架大家都要坐牢吗？这也太乱世用重典了。

* 重伤如果能自行处分——那是不是我花钱就能买你的命啊？

那至于哪些属于能自行处分的自由权利，而哪些不能，那真的是看大众的道德基准了。很明显，在中国，大多数人不会认为拼音输入法联网上传一些词库属于很重要的隐私侵犯。
2021 年 7 月 23 日
回复了 docx 创建的主题 › 信息安全 › 搜狗输入法疑似通过注入其它程序来突破联网限制
@yodiaodiao1994 我就知道会有你这样高风亮节的隐私卫士站出来 2333

刑法里面说的很清楚，一些不核心的人身权利是可以自主放弃的。比如剁掉小拇指，是可以用钱解决的，因为这属于个人自由地行使人身权利的处分权。但是剁掉大拇指是不行的，因为小拇指是轻伤，大拇指是重伤。就算给钱，大拇指也不能摆脱刑法的制裁。

很不幸的是，隐私权属于个人能处分的人身权利。所以我用一部分不太要紧的隐私权换输入的体验是合情合理，符合公序良俗的。

----

如果你还要进一步埋怨我们这种普通用户，那未免就——

“闭嘴，我们在谈自由”
2021 年 7 月 22 日
回复了 shangwuli 创建的主题 › 程序员 › 程序员们会担心被低代码、无代码开发取代吗？
担心低代码平台取代工作，和担心技术换代被淘汰，其实是一回事。
2021 年 7 月 22 日
回复了 docx 创建的主题 › 信息安全 › 搜狗输入法疑似通过注入其它程序来突破联网限制
1. 确实挺惊讶，原来软娘的输入法权限这么高啊。
2. 楼主要是在意的话就不要用搜狗了。
3. 像我，从来不在意这些。
2021 年 7 月 22 日
回复了 minsheng 创建的主题 › Apple › 视频软编码的时候 M1 确实不如八核 i9
吃惊的是差异没有想象中的大。
2021 年 7 月 22 日
回复了 Euthpic 创建的主题 › Kafka › 求一个基于 kafka 的消息消费框架
1. 同意 1L，只用一个 topic 这也太不合理了。这哪里解耦了，明明是宇宙无敌大杂烩。运维都要哭了。
2. 业务之间的依赖关系，总感觉这不是 Kafka 的事情。你这么想，如果这些消息不是一个 topic，而是每个消费者（我觉得应该改个时髦的名词，“微服务”）自己有自己的 topic 。那么你后继微服务只要消费前驱微服务产生的 topic 就行了。整个系统自然而然就充分并行化了。

所以关键是，对相同功能的“消费者”进行合并，区分 topic 。我觉得该这么改。
2021 年 7 月 21 日
回复了 Kasumi20 创建的主题 › Windows › cmd 无法显示带颜色字体
https://en.wikipedia.org/wiki/ANSI_escape_code
2021 年 7 月 21 日
回复了 Kasumi20 创建的主题 › Windows › cmd 无法显示带颜色字体
可能 cargo 有魔法。
----

不是抖段子。[31m 这种是 unix 终端上用来切换终端文字颜色的特殊字符，但是在 windows 上正确的做法是调用 windows api 。cmd.exe 看上去并不理会这种特殊字符。而 powershell 可能照顾了这些。cargo 可能自己解析了这部分输出并正确调用了 windows api 。
2021 年 7 月 21 日
回复了 icemanpro 创建的主题 › C++ › c++中， char* 如何转换成 std::shared_ptr<std::iostream>？
这里的问题不在于智能指针啊大哥。char* 和 std::iostream 八竿子打不上边

你大概需要一个 std::istringstream 或者 std::ostringstream
1 ... 64  65  66  67  68  69  70  71  72  73 ... 206  
❮ ❯
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   1858 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 43ms · UTC 06:55 · PVG 14:55 · LAX 22:55 · JFK 01:55
♥ Do have faith in what you're doing.