@kidlj #22 go 包版本管理吃瓜的问题不是 go mod 不好，是因为他窃取了社区胜利的果实。

Russ Cox: 对于在 Go 1.11 里的 Go Module 的实现方式我感到非常兴奋。我上次瞅了一下最流行的大约 1000 个项目，93%的能够直接转换为 Go Module 。

Twitter 发出来之后，Sam Boyer(dep 的主要开发者)，转推了一条(后面不放英文原文截图了，可以到文章后面的连接去看):
Sam Boyer: 最初的(旧项目到 Go Module 的)转换从来不是问题，问题是从不拿工资的贡献者们那里偷走工作成果。
我上周 GoSF 的演讲是关于这个的。现在视频找不到了，不过我截了个图。

Russ Cox 回复了这条推:
Russ Cox: 我听了你的演讲。虽然我们谈了很长时间，但是明显你现在对于这一切，对于我还是感觉很受挫败，很沮丧。对此我真的很抱歉，我知道那是什么感受。

Sam Boyer: 你能这样说我很感激。你肯定也很不容易，对于这件事造成的过分的压力我也很抱歉。
但是这并不是你我之间的事情，我之所以在演讲中提到你，是因为你是后来社区文化和机制争论的源头。

另一个 Go 社区的重要贡献者，Peter Bourgon 说:
Peter Bourgon: 因为私下认识事件中的一些人，我承认我是有偏向的。不过作为一个外人看到这个事故现场，我可能以后对 Rust 兴趣更多一些了。为什么 Go 团队领导层总是拒绝从其他现代语言(的做法)中学习呢?

Russ Cox: Go 并不是要满足所有人的所有需求。如果你喜欢 Rust 的方式，就去用 Rust 吧。我也欣赏 Rust，事实上我花了很多时间研究 Rust，Swift 中的好的地方，但是适合一个语言的未必适合其他语言。

Peter Bourgon: 是的。但是我想不到原因为什么 go 的依赖管理没有从其他的依赖管理中学习到任何东西。我从局外人的角度来看，Go 歇斯底里的尝试不去达成任何其他人已经达成的共识，我不明白为什么要这样做。并不仅仅是你的问题。我参与了 dep 开始之前的讨论，在之前还一直在关注 glide 。我不知道为什么 go 的依赖管理社区就是不从其他(包管理)已经遇到的问题中学习。作为一个已经在提供开箱即用的工具方面证明了自己的语言和社区，我非常困惑为什么这么关键的一个部分(指包管理)几乎是刻意的设计得这么挫。
好吧，Peter Bourgon 其实有点歪楼了。

Russ Cox:我们是一个小团队，还有其他优先的事情要做。确实我们在这个领域晚了几年，但是事情正在往好的方面发展，几年之后再来看看我们做成什么样子。

Matt Farina(Glide 作者)跳出来了
你说你们是一个小团队，是因为你们把 Go 当做 Google 下面团队的一个产品，Google 这个团队是小的。如果你们创建一个社区，借助其他人的力量，那就是一个很大的团队。比如 Rust 的依赖管理团队就有不是 Mozilla 的人。
围攻之下 Russ Cox 开启了疯狂发推模式，连发 N 条 Twitter 阐述前因后果。

Russ Cox:
非常有道理的批评。我们并没有处理好依赖管理的社区进程。Go 的核心团队没有今早和足够的参与这个进程，没有能够引导平滑的落地。作为 Go 的技术负责人，这是我的责任，我为此道歉。

Go 语言之父 Rob Pike 昨日发 issue：我建议我们不在 Go 1.18 的标准库中使用泛型 - https:///github.com/golang/go/issues/48918 作者的理由很简单，Go 泛型是 Go 诞生以来最大的一次语言变化，Go 1.18 版本承载了太多的 change，容易出错。并且 Go 核心开发团队也没有使用新泛型的经验，他建议 Go 核心开发团队应该多等待、观察和学习。 我是十分赞同 Rob Pike 的建议的，不要把步子迈得太大。go 应该按照自己的节奏稳步前进。


具体可以看这个 git repo，引入进来增加了不少复杂度，go 的泛型的兼容性以及复杂性都会是比较大的问题：github.com/damonchen/go-generic-tutorial

车载视频我喜欢看小马的 ： https://www.youtube.com/watch?v=VvmmeOvpD74

测试了，压缩更好的话，太耗费 cpu 了，拍 1s 的画面压缩时间不止 1 秒

使用 ffmpeg -threads auto -i aaa.mp4 -vcodec libx264 -preset fast -crf 28 -c:a copy -y out-put.mp4 压缩出来只有 69M 的样子，画质看着也还可以。

@Ansen #2 感觉行车记录仪的 CPU 不太行，压不动或者没好好压

内存泄露了，看系统日志看看是哪个在搞鬼。

@SingeeKing #2 老哥你有个 typo， 是 Rapid and Reliable 。 看 Requeatable 这个我还数查了字典 🤣

@emonc #7 你是想问有没有桌面客户端？ 这个我看它有 docker image 。

docker run --rm -dit --name excalidraw -p 5000:80 excalidraw/excalidraw:latest 这样就能起来了。私有化部署一个也快的。

@emonc #7 确实 12345 快捷键很爽啊。 要是有自己积累的一套模板，那画的应该很快。

小埋那个

http://www.mms591.com/www.mms591.com-photo/20170405/1-1F405153550_960x800.jpg

2 折利率 3.4 那原利率岂不是有 17% 。。。。

@gfreezy #4
@join #8

确实，我是在研究这一系列文章的时候 https://marcellanz.com/post/file-read-challenge/ 看到了现在这个 repo 的。之前这篇写的蛮好的，确实有减少 chan，内存优化等等之类的技巧。

1. https://boyter.org/posts/file-read-challange/
2. Using Java to Read Really, Really Large Files
3. Processing Large Files in Java
4. Processing Large Files – Java, Go and ‘hitting the wall’

https://github.com/vietvudanh/really-large-file python rust go java scala
https://github.com/rissw/not_yet_hit_the_wall


@lysS #11 是啊 ，这种代码咋读，自己写的还好，看别人写的真是一脸懵逼。

@chendy #7
@TuringHero #2

visio

@cairnechen #2 这个是咋实现的，摄像头吗？ 没有的话就能一直播放下去的吧

这也是升级可以实现的。。。。太六了啊，话说日本程序员是不是加班比较少。。。。

@zxwy #26

用这个 uBlacklist

@matrix67 #15 看了一下，我用的是叫这个 uBlacklist

https://chrome.google.com/webstore/detail/ublacklist/pncfbmialoiaghdehhbnbhkkgmjanfhe?hl=en

已经屏蔽了这些网站：

*://www.steamxo.com/*
*://blog.csdn.net/*
*://www.codenong.com/*
*://www.cnblogs.com/*
*://www.taobao.com/*
*://list.jd.com/*
*://world.taobao.com/*
*://www.huaweicloud.com/*
*://www.jianshu.com/*