#开源项目
chDB,在Python里内嵌了Clickhouse做为OLAP查询引擎的项目,最近被Clickhouse官方收购了。用作者的话说,有了这个项目,相当于给Python这辆自行车安装了火箭发动机(It feels like installing a rocket engine 🚀 onto a bicycle🚴🏻.)
作者的相关博文:
《The birth of chDB》
《chDB is joining ClickHouse》
chDB,在Python里内嵌了Clickhouse做为OLAP查询引擎的项目,最近被Clickhouse官方收购了。用作者的话说,有了这个项目,相当于给Python这辆自行车安装了火箭发动机(It feels like installing a rocket engine 🚀 onto a bicycle🚴🏻.)
作者的相关博文:
《The birth of chDB》
《chDB is joining ClickHouse》
GitHub
GitHub - chdb-io/chdb: chDB is an in-process OLAP SQL Engine 🚀 powered by ClickHouse
chDB is an in-process OLAP SQL Engine 🚀 powered by ClickHouse - GitHub - chdb-io/chdb: chDB is an in-process OLAP SQL Engine 🚀 powered by ClickHouse
🗿3
🥴8🥱1🗿1
#开源项目
#Latex
latexify_py是google开发的一个Python库,用于将Python函数转换成Latex表达式代码。有时候一些比较复杂的数学公式不知道怎么写,可以考虑用这个库搭把手。
两篇介绍这个库的文章:
《Latexify,一个强大的 Python 库》
《latexify: Writing LaTeX with Python》
#Latex
latexify_py是google开发的一个Python库,用于将Python函数转换成Latex表达式代码。有时候一些比较复杂的数学公式不知道怎么写,可以考虑用这个库搭把手。
两篇介绍这个库的文章:
《Latexify,一个强大的 Python 库》
《latexify: Writing LaTeX with Python》
GitHub
GitHub - google/latexify_py: A library to generate LaTeX expression from Python code.
A library to generate LaTeX expression from Python code. - google/latexify_py
👏7🤯3🆒1
#编程语言
#Rust
以前会争论类型标识符,应该放在变量前面还是后面好。
除了美感这种偏主观的判断以外,我在学了一点PLT皮毛之后,有一个新的视角:
类型标识符在变量前面的语言,大多是没有类型推断的,因为放在前面,所以无法省略,就是说:必须在声明这个变量的时候就(由程序员)确定变量的类型。这也有例外,比如C++后面引入的auto关键字,相当于给原先的语法打了一个“补丁”,通过这个关键字声明的变量就能支持类型推断。
反之,放在变量后面的类型标识符,因为是可以做到省略的,省略的时候就是类型推断发挥的空间了:推断出最适合的类型出来;同样也有例外,比如Go就不支持类型推断。
比如附图中的这段Rust代码:
同样的let a = 1,在两个上下文(context)里推断出来的是不同的类型:上面的代码由于没有别的信息,所以就选了i32类型;下面的代码由于要和已经声明为u64类型的b相加,所以推断出来a的类型为u64。
支持类型推断(type inference)的语言,(应该都)要做到类型安全(type safety)。比如:不能允许两个变量的数据,操作之后出现溢出等情况。
综上,我更喜欢支持类型推断、类型安全的语言。
Roman Elizarov(Project Lead for the Kotlin Programming Language)的一篇文章《Types are moving to the right》中也提到,21世纪之后才出现的编程语言,很多都是把类型标识符放在变量后面了,Go、Rust、Scala等。
#Rust
以前会争论类型标识符,应该放在变量前面还是后面好。
除了美感这种偏主观的判断以外,我在学了一点PLT皮毛之后,有一个新的视角:
类型标识符在变量前面的语言,大多是没有类型推断的,因为放在前面,所以无法省略,就是说:必须在声明这个变量的时候就(由程序员)确定变量的类型。这也有例外,比如C++后面引入的auto关键字,相当于给原先的语法打了一个“补丁”,通过这个关键字声明的变量就能支持类型推断。
反之,放在变量后面的类型标识符,因为是可以做到省略的,省略的时候就是类型推断发挥的空间了:推断出最适合的类型出来;同样也有例外,
比如附图中的这段Rust代码:
同样的let a = 1,在两个上下文(context)里推断出来的是不同的类型:上面的代码由于没有别的信息,所以就选了i32类型;下面的代码由于要和已经声明为u64类型的b相加,所以推断出来a的类型为u64。
支持类型推断(type inference)的语言,(应该都)要做到类型安全(type safety)。比如:不能允许两个变量的数据,操作之后出现溢出等情况。
综上,我更喜欢支持类型推断、类型安全的语言。
Roman Elizarov(Project Lead for the Kotlin Programming Language)的一篇文章《Types are moving to the right》中也提到,21世纪之后才出现的编程语言,很多都是把类型标识符放在变量后面了,Go、Rust、Scala等。
👍13🥱6👎1😁1
#开源项目
Redis宣布修改开源协议为SSPL,近几年来,为了避免产品被云厂商白嫖,已经有很多背后是商业公司的开源项目修改了协议,如elasticsearch、mongodb,这几个项目都修改成了SSPL协议。
我问了一下Gemini介绍这个开源协议,答复是这样的:
又接着问了下一个问题:“使用SSPL开源协议的软件,如何避免被云厂商白嫖?”,得到的答复是:
Redis宣布修改开源协议为SSPL,近几年来,为了避免产品被云厂商白嫖,已经有很多背后是商业公司的开源项目修改了协议,如elasticsearch、mongodb,这几个项目都修改成了SSPL协议。
我问了一下Gemini介绍这个开源协议,答复是这样的:
SSPL(服务器端公共许可证)是一种开源许可证,它要求使用 SSPL 许可的软件的任何修改版本,无论托管在何处,都必须以 SSPL 的条款向公众免费提供。这意味着,与其他一些开源许可证(例如 GPL)不同,SSPL 允许对使用其许可的软件进行托管和商业分销,而无需公开源代码。
SSPL 最初是由 MongoDB 创建的,用于其同名的数据库管理系统。它旨在平衡商业软件供应商的利益和开源社区的需求,同时避免 GPL 强制代码共享的限制。
SSPL 的一些主要特点包括:
源代码无需公开:使用 SSPL 许可的软件的修改版本不需要公开其源代码。
商业分销:使用 SSPL 许可的软件可以托管和商业分销,而无需支付许可费或版税。
要求公开修改:任何对使用 SSPL 许可的软件的修改都必须以 SSPL 的条款向公众免费提供。
兼容性:SSPL 被视为与其他开源许可证,例如 Apache 许可证 2.0 和 MIT 许可证,兼容。
总的来说,SSPL 是一种开源许可证,它允许对软件进行商业分销,同时确保任何修改都向公众免费提供。
又接着问了下一个问题:“使用SSPL开源协议的软件,如何避免被云厂商白嫖?”,得到的答复是:
关于SSPL协议
SSPL(Server Side Public License)协议要求在云端使用该软件的公司,公开其云端上的源代码。这旨在防止云厂商利用其基础设施优势,以牺牲开源社区为代价获利。
防止云厂商白嫖的措施
1. 明确声明SSPL协议
在软件许可证文件中明确声明SSPL协议。
在软件网站和文档中突出显示SSPL协议。
要求用户在使用软件之前接受SSPL协议。
2. 提供云端源代码
要求云厂商在云端使用软件时,提供其源代码。
提供一个平台或机制,让用户可以访问这些源代码。
3. 提供支持和监控
提供技术支持,帮助云厂商遵守SSPL协议。
定期监控云厂商的使用情况,确保他们遵守协议。
4. 寻求法律支持
如有必要,寻求法律支持,以强制执行SSPL协议。
制定合同协议,明确云厂商的义务和违约后果。
5. 提高社区意识
教育开源社区了解SSPL协议的重要性。
鼓励用户向云厂商施压,要求他们遵守该协议。
建立协作机制,共同维护SSPL协议的完整性。
此外,开源社区共同的努力也是至关重要的。通过分享知识、提供支持和倡导开源原则,社区可以增强SSPL协议的有效性,并防止云厂商白嫖开源软件。
Redis
Redis Adopts Dual Source-Available Licensing | Redis
Developers love Redis. Unlock the full potential of the Redis database with Redis Enterprise and start building blazing fast apps.
👍1
#开源项目
开源软件xz被爆出被植入后门,这篇文章《Everything I Know About the Xz Backdoor》把植入后门的Github作者在这个项目的活动拉了一个时间线,这个推里对这篇文章做了一个小结。
开源软件xz被爆出被植入后门,这篇文章《Everything I Know About the Xz Backdoor》把植入后门的Github作者在这个项目的活动拉了一个时间线,这个推里对这篇文章做了一个小结。
boehs.org
Everything I Know About the XZ Backdoor
Please note: This is being updated in real-time. The intent is to make sense of lots of simultaneous discoveries
👎5🤡3🤬2
#播客
#人工智能
我非常喜欢的科技类访谈记者张小珺,前阵子分别就人工智能话题采访了三个人:月之暗面创始人杨植麟、投资人朱啸虎和技术出身的CEO王小川,被人称为“AI三部曲”,历时几个月终于等到了这三篇采访的文字稿和播客都上线了。三人的介绍,可以点击下面名字中的链接跳转到我整理的百度百科词条,简单的说:杨植麟技术理想男、朱啸虎现实投资人、王小川则兼具技术和商业思维。
* 上篇杨植麟:《对话月之暗面杨植麟:向延绵而未知的雪山前进》(播客)
* 中篇朱啸虎:《朱啸虎讲了一个中国现实主义AIGC故事》(播客)
* 下篇王小川:《王小川想提出中国AGI第三种可能性》(播客)
在这里可以看到对这三篇采访做的简单总结。
杨植麟的采访中有一句话:
我觉得可以把这句话和程序设计中“过早优化是万恶之源”的原则结合起来一起理解。
#人工智能
我非常喜欢的科技类访谈记者张小珺,前阵子分别就人工智能话题采访了三个人:月之暗面创始人杨植麟、投资人朱啸虎和技术出身的CEO王小川,被人称为“AI三部曲”,历时几个月终于等到了这三篇采访的文字稿和播客都上线了。三人的介绍,可以点击下面名字中的链接跳转到我整理的百度百科词条,简单的说:杨植麟技术理想男、朱啸虎现实投资人、王小川则兼具技术和商业思维。
* 上篇杨植麟:《对话月之暗面杨植麟:向延绵而未知的雪山前进》(播客)
* 中篇朱啸虎:《朱啸虎讲了一个中国现实主义AIGC故事》(播客)
* 下篇王小川:《王小川想提出中国AGI第三种可能性》(播客)
在这里可以看到对这三篇采访做的简单总结。
杨植麟的采访中有一句话:
如果你能用scale解决的问题,就不要用新的算法解决。新算法最大价值是让它怎么更好的scale。当你把自己从雕花的事中释放出来,可以看到更多。
我觉得可以把这句话和程序设计中“过早优化是万恶之源”的原则结合起来一起理解。
百度百科
杨植麟
杨植麟,男,出生于1992年,广东汕头人,大模型企业月之暗面(Moonshot AI)创始人,清华大学助理教授,2019年度北京智源青年科学家,上海期智研究院PI。杨植麟本科毕业于清华大学计算机系 ,博士毕业于卡内基梅隆大学计算机学院。曾效力于全球顶级人工智能机构Facebook AI Research, Google Brain;于ICLR、NIPS、ICML、KDD、ACL等顶级AI会议发表论文二十余篇;在所有六个主流语言建模数据集保持世界第一名 (State-of-the-art)。杨植麟还曾参与过Google…
👍9👌3❤2
#播客
#独立开发
《EP56 沉浸式翻译背后的故事| 对话创始人Owen》
沉浸式翻译(插件地址:FF、Chrome)是过去两年用到的最好用的效率工具,阅读外文网站必备,而且很良心,即便不开会员基本功能也够用了。
#独立开发
《EP56 沉浸式翻译背后的故事| 对话创始人Owen》
沉浸式翻译(插件地址:FF、Chrome)是过去两年用到的最好用的效率工具,阅读外文网站必备,而且很良心,即便不开会员基本功能也够用了。
Xiaoyuzhoufm
EP56 沉浸式翻译背后的故事 | 对话创始人Owen
听《硬地骇客》上小宇宙。 来自三位拥有10年+互联网创业者的深度思考和对话,我们关注前沿科技,分享创业故事,打造 “超级个体”,寻找利基市场,构建小而美的生意,同时也希望和广大 Hacker 一起探讨技术、产品和商业之美。
硬地骇客是一群追求自由充实的生活并喜欢挑战的 Builder,他们热爱技术,热爱构建产品,崇尚依靠产品驱动的增长方式构建出自己的小生意。
"每个人都值得拥有一个小生意”
本节目可以在Podwise.ai、小宇宙、YouTube、Apple podcast、Spotify、喜马…
硬地骇客是一群追求自由充实的生活并喜欢挑战的 Builder,他们热爱技术,热爱构建产品,崇尚依靠产品驱动的增长方式构建出自己的小生意。
"每个人都值得拥有一个小生意”
本节目可以在Podwise.ai、小宇宙、YouTube、Apple podcast、Spotify、喜马…
👎6👍2
#书
每年的4.23是世界读书日,推荐一本过去一年在精读的技术书《Types and Programming Languages》(简称TAPL)。
我与这本书的缘分是这样的:
最开始,想要看懂databend里面的表达式系统代码,看迟先生的类型体操系列文章《用 Rust 做类型体操》,发现看不懂。
于是请教了负责表达式系统的同事,给我推荐了TAPL这本书。
开始阅读TAPL,但是发现里面很多符号看不懂,需要补一些数理逻辑和Lambda演算的基础。
补习了上述基础之后,继续看TAPL,能看懂部分了。第一刷TAPL花了半年多的时间(包括补习基础的时间)。
现在又重新整理了一下之前做的笔记,也看了部分EOPL(全称“Essentials of Programming Languages”)的内容,开始第二刷。在完善了前面的基础之后,第二刷就流畅很多了。
这个过程中有如下的收获:
1、体验到了数理逻辑形式化的美感。做工程的时候,经常会做工程上的trade-off,但是在类型系统这里,一个类型能否转换为另一个类型,需要严谨的推导,可以就是可以,不行就是不行,不存在trade-off。我特别喜欢这种符号形式化、确定性的美感。
2、重拾了对PL的兴趣。我接下来会把EOPL和TAPL刷完,打算接着学习一下OCaml,再看看能不能给Rust贡献一些代码。
3、后面会学习抽象代数和范畴论,学习范畴论是为了更好理解PL里面的一些理论。
4、Rust最开始吸引我的是它的内存安全特性,现在除此以外,还有它强大的类型系统,强类型系统的语言写起来放心、方便很多。我后续可能不太能接受用非强类型的语言来做为主力编程语言了。
为了纪念这个学习的过程,我前两个月趁着JD搞活动,花重金(大几百人民币)买了一本TAPL原版书,五一之后就能送到了。
每年的4.23是世界读书日,推荐一本过去一年在精读的技术书《Types and Programming Languages》(简称TAPL)。
我与这本书的缘分是这样的:
最开始,想要看懂databend里面的表达式系统代码,看迟先生的类型体操系列文章《用 Rust 做类型体操》,发现看不懂。
于是请教了负责表达式系统的同事,给我推荐了TAPL这本书。
开始阅读TAPL,但是发现里面很多符号看不懂,需要补一些数理逻辑和Lambda演算的基础。
补习了上述基础之后,继续看TAPL,能看懂部分了。第一刷TAPL花了半年多的时间(包括补习基础的时间)。
现在又重新整理了一下之前做的笔记,也看了部分EOPL(全称“Essentials of Programming Languages”)的内容,开始第二刷。在完善了前面的基础之后,第二刷就流畅很多了。
这个过程中有如下的收获:
1、体验到了数理逻辑形式化的美感。做工程的时候,经常会做工程上的trade-off,但是在类型系统这里,一个类型能否转换为另一个类型,需要严谨的推导,可以就是可以,不行就是不行,不存在trade-off。我特别喜欢这种符号形式化、确定性的美感。
2、重拾了对PL的兴趣。我接下来会把EOPL和TAPL刷完,打算接着学习一下OCaml,再看看能不能给Rust贡献一些代码。
3、后面会学习抽象代数和范畴论,学习范畴论是为了更好理解PL里面的一些理论。
4、Rust最开始吸引我的是它的内存安全特性,现在除此以外,还有它强大的类型系统,强类型系统的语言写起来放心、方便很多。我后续可能不太能接受用非强类型的语言来做为主力编程语言了。
为了纪念这个学习的过程,我前两个月趁着JD搞活动,花重金(大几百人民币)买了一本TAPL原版书,五一之后就能送到了。
🫡29👍5❤2
#开源项目
对后台服务进行测试时,经常需要模拟一些异常情况看服务在这些异常情况下的表现,比如网络分区、延迟、硬盘IO延迟等,可以使用chaos-mesh项目来搭建环境模拟这类测试,非常强大且有完善的异常场景可供选择。
对后台服务进行测试时,经常需要模拟一些异常情况看服务在这些异常情况下的表现,比如网络分区、延迟、硬盘IO延迟等,可以使用chaos-mesh项目来搭建环境模拟这类测试,非常强大且有完善的异常场景可供选择。
chaos-mesh.org
强大的混沌工程平台 | Chaos Mesh®
👍5❤4