V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ipwx  ›  全部回复第 59 页 / 共 201 页
回复总数  4003
1 ... 55  56  57  58  59  60  61  62  63  64 ... 201  
2021-08-17 23:51:21 +08:00
回复了 484A4B 创建的主题 程序员 面对互联网公司对用户隐私的手越伸越长,我们能做些什么?
事实上是大家真的不在乎
2021-08-17 23:49:07 +08:00
回复了 nowheretoseek 创建的主题 问与答 操作系统的设计中,编码是”热插拔“的吗?
嘈点太多以至于无力吐槽
2021-08-17 16:09:51 +08:00
回复了 nowheretoseek 创建的主题 问与答 自定义词表的 base64 编码容易被解码吗?
p.s.2 比如这个,是给凯撒密码自动解密的:

https://quipqiup.com/
2021-08-17 16:09:28 +08:00
回复了 nowheretoseek 创建的主题 问与答 自定义词表的 base64 编码容易被解码吗?
p.s. 第三步甚至可以通过预训练一个 language model 然后把你的解密结果丢进去看似然。把似然最高的比如 20 组 base64 加密方法给你挑出来。
2021-08-17 16:07:02 +08:00
回复了 nowheretoseek 创建的主题 问与答 自定义词表的 base64 编码容易被解码吗?
和普通密码的字频攻击一样的处理方法。

1 、统计普通文本 base64 以后的字频。
2 、根据你这修改版 base64 的字频来探测可能的匹配
3 、验证解码结果。
@Sanko 全都塞标准库,那运行时和编译速度该多慢啊。当然要第三方独立的库啊

一个算法几 kb,但像你说的这俩算法都不够通用啊,不常用啊。按你这个标准筛选,找出来的算法都加进去,标准库可以多几百兆,编译速度可以下降一个数量级啊。

明明手写也就 50 行代码的事情。。。
如果这两个算法也算是常用需要进库函数,那么有很多很多同样“常用”的算法也得进。

说白了这俩就是特殊的动态规划而已啊,随手写一个。又不够常用,进库函数没意思。
2021-08-15 00:13:59 +08:00
回复了 passer9527 创建的主题 问与答 一个疑惑:为啥很多初创公司不选择最主流的技术栈?
初创时期,恨不得单枪匹马能用 python 的就两周撸一个原型出来。等产品有市场了,有钱了,再找十个 java 程序员重构不好吗?

讲真,你看看程序员的薪水,再看看初创时期是找一个 python 大后端合算,还是十个 java 标准螺丝钉合算。
2021-08-13 14:29:07 +08:00
回复了 passer9527 创建的主题 Java 最近发现 Java 的 easyExcel 库相当不错
pandas 确实慢。大量操作要扫 index
2021-08-13 10:04:01 +08:00
回复了 mirone 创建的主题 程序员 Milkdown 中文文档
@mirone QAQ 好的这就去提(顿首)
2021-08-13 10:01:51 +08:00
回复了 mirone 创建的主题 程序员 Milkdown 中文文档
@mirone 就数学公式行内显示这一点,真的是长久以来根本没有可选项。左右双栏在大段公式的情况下真的是没法用,特别是如果我还要边推公式边写。除了 Typora 没有可以用的,但是 Typora 没法 hack 。

有一个小建议:Typora 正在编辑的公式会在下方显示一个小框实时预览。大佬您看……?(厚颜无耻)
2021-08-13 10:00:20 +08:00
回复了 mirone 创建的主题 程序员 Milkdown 中文文档
很强!!!!盼望这玩意儿好久了!!!!

可以愉快的 hack 自己的笔记软件了。
2021-08-12 11:18:47 +08:00
回复了 zhoudaiyu 创建的主题 问与答 NAT 穿透为什么要用 UDP 协议?
因为 TCP 不可能,UDP 可能。
2021-08-11 22:57:13 +08:00
回复了 xiaoke0718 创建的主题 投资 学习 ETF 动量策略太难了,找不到书籍
这种相对高频率的交易都是赚别人的钱。你照着不知道流传了几手的算法去做,早就落后别人不知道多少段位了,肯定输。真正的量化需要自己有研发算法的能力。
产品对程序员尊敬? really ?
2021-08-11 11:38:32 +08:00
回复了 weimo383 创建的主题 程序员 为何前端构建工具这么麻烦
其实吧,总结一下就是:前端的课还没补完。

----

对比一下 C++

上古时代的 C/C++ 也是很麻烦的。从单文件的 compiler / loader,进化到 make + Makefile,进化到 autoconf / automake,再进化到 CMake 之类的。CMake 几乎已成为事实上比较通用的 C++ 构建工具了,但是还没有完全统治地位。当年 boost 有自己的 bjam,Google 有自己的 bazel,等等不一而足。

到目前为止裸 CMake 配起来也挺麻烦的。不过 conan.io 之类的基于 CMake 的包管理器进一步简化了配置,基本上标准系统上零配置就能用 conan + CMake 拉一堆 C++ 的库开始撸代码。

----

对比一下 Java / PHP / C#,无一不是有这个过程。Java 的 Maven,PHP 的 Composer,C# 的 Nuget,一开始也都是没有的。只不过 Java / PHP / C# 相对更容易统一环境,所以它们走的比 C++ 远。

前端现阶段不好用,只不过是因为太新了所以没有角逐出统一的工具链而已。
1 ... 55  56  57  58  59  60  61  62  63  64 ... 201  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3528 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 361ms · UTC 04:44 · PVG 12:44 · LAX 20:44 · JFK 23:44
Developed with CodeLauncher
♥ Do have faith in what you're doing.