2025年已过去 69.81%
ChatGPT是网上所有文本的模糊图像    @ 2023-02-11, 19:17

《降临》作者特德·姜(澎湃新闻记者 程千千 译,来源

2月9日,美籍华裔科幻作家特德·姜(Ted Chiang)在《纽约客》上发表文章,表达了他对时下大热的人工智能ChatGPT独特见解。特德·姜在科幻小说领域成绩斐然,曾获得星云奖、雨果奖等科幻小说大奖。他的短篇小说《你一生的故事》在2016年被改编成电影《降临》。

2013年,德国一家建筑公司的工人注意到他们的施乐复印机有一些奇怪的地方:当他们复印一张房子平面图时,副本与原件之间存在微妙而显著的差异。在最初的平面图中,每栋房子的三个房间都有一个矩形来说明其面积:房间分别为14.13平方米,21.11平方米和17.42平方米。然而,在复印件中,所有三个房间都被标记为14.13平方米。该公司联系了计算机科学家大卫·克里塞尔(David Kriesel),让他对这一看似不可思议的结果进行调查。他们需要一名计算机科学家,因为现代施乐复印机使用的不是20世纪60年代流行的物理静电复印工艺。相反,它以数字方式扫描文档,然后打印生成的图像文件。结合这一事实,为了节省空间,几乎每个数字图像文件都经过了压缩。谜底开始浮出水面。

压缩文件需要两个步骤:首先是编码,在此期间文件被转换为更紧凑的格式;然后是解码,将编码的过程反向进行。如果恢复的文件与原始文件相同,则压缩过程被描述为无损,即没有丢失信息。相比之下,如果恢复的文件只是原始文件的近似值,则压缩被描述为有损,即一些信息已丢失而无法恢复。无损压缩通常用于文本文件和计算机程序,因为在这些领域中,即使是一个错误的字符也有可能造成灾难性的后果。在绝对精度不重要的情况下,有损压缩通常用于照片、音频和视频。大多数时候,我们不会注意到一张图片、一首歌或电影是否被完美地复制。只有当文件被压缩得非常紧时,保真度的损失才会更加明显。在这些情况下,我们会注意到所谓的压缩伪影——最小的JPEG和MPEG图像的模糊,或者低比特率MP3的微弱声音。

施乐复印机使用一种被称为jbig2的有损压缩格式,专为黑白图像而设计。为了节省空间,复印机会识别图像中看起来相似的区域,并为所有这些区域存储一份副本;当文件被解压时,它会重复使用该副本来重建映像。结果是,复印机判断出指定房间面积的标签非常相似,所以它只需要存储其中一个,即14.13平方米的房间,并且在打印楼层平面图时,它对所有三个房间都重复使用这一个标签。

施乐复印机使用有损压缩格式而不是无损格式,这本身并不是一个问题。问题是复印机以一种微妙的方式压缩了图像,使其中压缩的伪影不能被立即识别出来。如果复印机只是打印出模糊的照片,每个人都会知道这不是原件的准确复制品。导致问题的原因是复印机输出的数字是可读的,但不准确——它使副本看起来准确,但实际上并不准确。(2014年,施乐发布了一个补丁来纠正这个问题。)

我认为,在我们研究OpenAI的ChatGPT和其他类似程序(人工智能研究人员称之为大语言模型)时,施乐复印机的这起事件值得我们铭记于心。复印机和大语言模型之间的相似之处可能不是很明显,但请考虑以下场景:想象一下,你即将永远失去上网的机会。在准备阶段,你计划为万维网上的所有文本创建一个压缩副本,以便将其存储在专用服务器上。不幸的是,你的私人服务器只有所需空间的1%;如果你想要所有的一切都是准确的,你就不能使用无损压缩算法。相反,你可以编写一个有损算法来识别文本中的统计规律,并将它们存储在专门的文件格式中。由于你在这个任务中拥有几乎无限的计算能力,因此你的算法可以识别非常细微的统计规律,这允许你实现所需的100:1的压缩比。

于是,失去网络连接不再那么可怕,因为你把网络上的所有信息都存储在了你的服务器上。唯一的问题是,由于文本被高度压缩,你无法通过搜索准确的引用来查找信息;你永远不会得到一个精确的匹配,因为存储的不是单词。为了解决这个问题,你创建了一个接口,该接口接受问题形式的查询,并以传达服务器上的要点的答案进行响应。

我所描述的听起来很像ChatGPT,或者大多数其他大语言模型。可以把ChatGPT看作是万维网上所有文本的模糊JPEG。它保留了万维网上的大部分信息,就像JPEG保留了高分辨率图像的大部分信息一样。但是,如果你要寻找精确的比特序列,你无法找到它,你得到的只是一个近似值。但是,因为这个近似值是以语法文本的形式呈现的,而ChatGPT擅长创建语法文本,所以它通常是可以接受的。你看到的仍然是一张模糊的JPEG,但模糊发生的方式不会使图片整体看起来不那么清晰。

这种与有损压缩的类比不仅仅是一种理解ChatGPT通过使用不同的单词重新打包万维网上找到的信息的方法,它也是一种理解“幻觉”或对事实性问题的无意义回答的方法。而大语言模型(如ChatGPT)都很容易出现这种情况。这些幻觉是压缩后的产物。但是,就像施乐复印机产生的错误标签一样,它们似乎是可信的,要识别它们就需要将它们与原件进行比较。在这种情况下,这意味着要么是万维网,要么是我们自己对世界的认识。当我们这样想的时候,这样的幻觉一点也不令人惊讶。如果一种压缩算法被设计成在99%的原始文本被丢弃后重建文本,我们应该预料到它生成的很大一部分内容将完全是捏造的。

当我们记得有损压缩算法使用的一种常用技术是插值(译者注:一种通过已知的、离散的数据点,在范围内推求新数据点的过程或方法)时,这个类比就更有意义了——也就是说,通过查看间隙两侧的内容来估计缺失的内容。当图像程序显示照片时,必须重建压缩过程中丢失的像素时,它会查看附近的像素并计算平均值。这就是当ChatGPT被提示用《独立宣言》的风格描述丢在烘干机里的袜子时所做的事情:它在“词汇空间”中取两个点,并生成占据它们之间位置的文本。(“在人类事件的过程中,一个人有必要把他的衣服与他们的同伴分开,以保持其清洁和秩序……”)ChatGPT非常擅长这种形式的插值,人们发现它很有趣:他们发现了一种用于段落而不是照片的“模糊”工具,并且玩得很开心。

鉴于像ChatGPT这样的大语言模型经常被吹捧为人工智能的前沿,将它们描述为有损文本压缩算法可能听起来令人不屑一顾,或者至少令人泄气。我确实认为这种观点为将大语言模型人格化的趋势提供了有用的纠正,但是压缩类比还有另一个方面值得考虑。自2006年以来,一位名叫马库斯·赫特(Marcus Hutter)的人工智能研究人员提供了一项现金奖励——被称为“压缩人类知识奖”或“赫特奖”,奖励任何能够无损地压缩维基百科特定1GB快照的人,要求比上一位获奖者的数据更小。你可能遇到过使zip文件格式压缩的文件。zip格式将赫特的1GB文件压缩到300兆左右;而最近的获奖者已经设法将其减少到115兆字节。这不仅仅是一次磨合练习。赫特认为,更好的文本压缩将有助于创造人类级别的人工智能,部分原因是通过理解文本可以实现最大程度的压缩。

为了理解压缩和理解之间的关系,假设你有一个文本文件,其中包含上百万个加减乘除的示例。尽管任何压缩算法都可以减小这个文件的大小,但要实现最大的压缩比,可能需要推导出算术原理,然后编写计算器程序的代码。使用计算器,你不仅可以完美地重建文件中的数百万个示例,还可以重建将来可能遇到的任何其他算术示例。同样的逻辑也适用于压缩维基百科的一部分。如果压缩程序知道力等于质量乘以加速度,那么在压缩有关物理的页面时,它可以丢弃大量的单词,因为它能够重建它们。同样,程序对供求关系了解得越多,在压缩有关经济的页面时,就能丢弃越多的单词,等等。

大型语言模型识别文本中的统计规律。对网络文本的任何分析都会揭示,像“供应不足”这样的短语经常出现在“价格上涨”这样的短语附近。当被问及有关供应短缺影响的问题时,包含这种相关性的聊天机器人可能会回答有关价格上涨的问题。如果一个大语言模型已经编译了大量经济术语之间的相关性——多到可以对各种各样的问题提供合理的回答——我们是否应该说它实际上理解了经济理论?像ChatGPT这样的模型没有资格获得赫特奖,原因有很多,其中之一就是它们不能精确地重建原始文本,也就是说它们不执行无损压缩。但是,它们的有损压缩是否可能表明,人工智能研究人员真正理解了他们感兴趣的那种类型?

让我们回到算术的例子。如果你要求GPT-3(ChatGPT构建的大语言模型)添加或减去一对数字,当数字只有两位数时,它几乎总是会给出正确的答案。但数字越大,准确率就会显著下降,当数字有五位数时,准确率会下降到10%。GPT-3给出的大多数正确答案都不能在网上找到——例如,包含“245 + 821”文本的网页并不多——所以它不是在进行简单的记忆。但是,尽管吸收了大量的信息,它也无法推导出算术原理。仔细检查GPT-3的错误答案表明,它在执行算术时不带“1”。万维网上当然包含携带“1”的解释,但是GPT-3不能包含这些解释。GPT-3对算术例子的统计分析使它能够产生与真实事物的表面近似,但仅此而已。

鉴于GPT-3在小学教学科目上的失败,我们如何解释它有时在写大学水平的论文时表现良好的事实?尽管大语言模型经常产生幻觉,但当它们清醒时,它们好像真的能理解经济理论等学科。也许算术是一个特殊的情况,大语言模型不太适合。有没有可能,在加减法之外的领域,文本中的统计规律确实与真实世界的真实知识相对应?

我认为有一个更简单的解释。想象一下,如果ChatGPT是一种无损算法会是什么样子。如果是这样的话,它总是通过提供来自相关网页的逐字引用来回答问题。我们可能会认为这个软件只是对传统搜索引擎的轻微改进,并对它印象不太深刻。ChatGPT从网络上重新表达材料,而不是逐字引用,这让它看起来像一个学生用自己的话表达思想,而不是简单地重复他读过的东西。它会造成ChatGPT理解了材料的错觉。在人类学生中,死记硬背并不是真正学习的标志,因此ChatGPT无法从网页中准确地引用内容,这恰恰使我们认为它学到了一些东西。当我们处理单词序列时,有损压缩看起来比无损压缩更聪明。

大语言模型已经有了很多种用法。把它们看作是模糊的JPEG文件,这就提供了一种评估它们可能适合或不适合的方法。让我们思考几种情况。

大语言模型能取代传统搜索引擎吗?为了让我们对它们有信心,我们需要知道他们有没有被灌输政治宣传和阴谋论——我们需要知道JPEG是否捕捉了正确的网络区域。但是,即使大语言模型只包含我们想要的信息,仍然存在模糊性的问题。有一种模糊是可以接受的,那就是用不同的词重新陈述信息;对于完全捏造的模糊,当我们寻找事实时,我们认为这是不可接受的。在消除不可接受的模糊性的同时,保留可接受的模糊性,在技术上是否可行尚不清楚,但我希望在不久的将来,我们能找到答案。

即使有可能限制大语言模型参与制作,我们应该使用它们来生成万维网内容吗?只有当我们的目标是重新打包网络上已有的信息时,这才有意义。有些公司就是这么做的,我们通常称它们为内容工厂。也许大语言模型的模糊性对他们来说是有用的,它可以作为一种避免侵犯版权的手段。不过,一般来说,我想说的是,任何对内容工厂有好处的东西都不适合搜索信息的人。这种重新包装的兴起使我们现在更难在网上找到我们想要的东西。大型语言模型生成的文本在网络上发布得越多,网络本身就变得越模糊。

关于OpenAI即将推出的ChatGPT继任者GPT-4的信息非常少。但是我想做一个预测:当收集用于训练GPT-4的大量文本时,OpenAI会尽一切努力排除由ChatGPT或任何其他大语言模型生成的材料。若事实果真如此,那么将大语言模型与有损压缩进行类比是有用的。反复保存JPEG会产生更多的压缩制件,因为每次都会丢失更多的信息。这就相当于过去不断复制副本的做法,图像质量只会越来越差。

事实上,衡量大语言模型质量的一个有用标准可能是,公司是否愿意使用它生成的文本作为新模型的训练材料。如果ChatGPT的输出对GPT-4来说不够好,我们或许会认为它对我们来说也不够好。相反,如果一个模型生成的文本非常好,可以用来训练新的模型,那么我们应该对文本的质量有信心。(我怀疑这样的结果需要在用于构建这些模型的技术上取得重大突破。)如果我们开始看到模型产生的输出和输入一样好,那么有损压缩的类比将不再适用。

大语言模型能帮助人类创作原创作品吗?要回答这个问题,我们需要明确这个问题的含义。有一种艺术类型被称为影印艺术,在这种艺术中,艺术家们利用复印机的独特特性作为创作工具。在ChatGPT复印机上,沿着这些路线的事情肯定是可能的,所以,在这个意义上,答案是肯定的。但我认为没有人会说,复印机已经成为艺术创作中的必备工具。绝大多数艺术家在创作过程中不会使用它们,没人会认为他们的这种选择会让自己处于不利地位。

所以让我们假设,我们并不是在谈论一种类似于“施乐艺术”的新的写作类型。鉴于这一规定,大语言模型生成的文本能否成为作家在创作原创作品时有用的起点,无论是小说还是非虚构?让一个大语言模型来处理样板文件,能让作者把注意力集中在真正有创意的部分吗?

显然,没有人能代表所有的作家,但我想说的是,以一份模糊的非原创作品作为起点,并不是创作原创作品的好办法。如果你是一个作家,在你写原创作品之前,你会写很多非原创的作品。花在非原创工作上的时间和精力不会被浪费。相反,我认为正是它让你最终能够创作出原创的作品。花在选择正确的词汇和重新排列句子以更好地遵循彼此上的时间,教会了你如何通过文章传达想要表达的意思。让学生写论文不仅仅是一种测试他们对材料掌握程度的方法,这给了他们表达自己想法的经验。如果学生从来不用写我们都读过的文章,他们就永远不会获得写我们从未读过的东西所需的技能。

这并不是说,一旦你不再是学生,你就可以安全地使用大语言模型提供的模板。想要表达自己想法的挣扎并不会在你毕业后消失。每当你开始起草一篇新文章时,这种挣扎就会出现。有时候,只有在写作的过程中,你才能发现自己最初的想法。有些人可能会说,大语言模型的输出看起来与人类作家的初稿没有太大不同,但是,我认为这只是表面上的相似。你的初稿不是一个明确表达的非原创想法;这是一个原始想法的拙劣表达,它伴随着你无定形的不满,你意识到它所说的和你想说的之间的距离。这是在重写时能够指导你的东西,这是当你开始使用人工智能生成的文本时所缺乏的东西之一。

写作没什么神奇或神秘的,但它不仅仅是把现有的文件放在一台不可靠的复印机上,然后按下打印按钮。在未来,我们有可能创造出一个人工智能,它能够仅凭自己对世界的经验就写出好文章。我们实现这一目标的那一天确实意义重大,但那一天远远超出了我们的预测范围。与此同时,我们有理由提出这样一个问题:重新表述万维网有何用途?如果我们永远无法访问互联网,不得不在空间有限的私人服务器上存储副本,那么像ChatGPT这样的大语言模型可能是一个很好的解决方案,假设它可以防止伪造。但我们并没有失去对互联网的访问。那么,当你还有原始图片的时候,一张模糊的JPEG到底有多大用处呢?

转贴收藏 | 1 个评论 | 4,500 次阅读
简短地址:http://ncblog.net/1964/
淘旧书    @ 2023-02-01, 11:45

过年期间,在孔夫子网淘到四本自己二十多年前写的旧书,兜兜转转回到作者手里。

无酒无花 | 10 个评论 | 19,408 次阅读
简短地址:http://ncblog.net/1961/
2022 乏善可陈    @ 2023-01-01, 14:32

2022年过得着实乏善可陈:春天被封城整两个月;夏天被40+摄氏度连续烘烤了近两个月;秋天被带状疱疹折磨了近一个月;冬天全家阳了一个星期。

如果非要找一些积极的:春天在封城中完成了 Effie 对图片的支持;夏天儿子考上了他理想的高中,我把家里的11年前配置的PC更新换代了;秋天完成了 Effie 的 Android 版本;冬天全家阳过了,始终令人惶惶不安的封控式防疫终于结束了。

时间已经踏入2023年,但又似乎并没有什么让人期待、令人兴奋的。

农码生涯 | 1 个评论 | 4,513 次阅读
简短地址:http://ncblog.net/1958/
电车难题    @ 2022-12-27, 14:12

所谓电车难题,有很多个大同小异的版本,我最初听到的是这样的:有五个小朋友在一条铁轨上玩耍;铁轨前有个分岔,岔道另一边是废弃的铁轨,上面有一个小朋友在休息。而列车即将飞速驶来,你可以控制一个拉杆来决定列车是保持正常路线行驶导致五个小朋友面临危险,还是让列车驶入岔道牺牲那个原本不该遭遇危险的小朋友。

在以前,遇到这种问题,我也会装模作样去思考一下如何选择,仿佛真的是一个两难选择。今年以来,发生的一系列事情,让我对电车难题有了自己的答案:我,或者说任何人,都不应该也没有资格去选择(不知道算不算康德主义了)。

按功利主义的所谓人数多少去权衡利弊,本身就是很荒谬的。人多就一定是利益最大化吗?少数就必然该死吗?如果两边人数旗鼓相当呢?

纯理性来看,这世界上,每时每刻,由于各种原因(自然的、社会的、人为的、意外的……)导致不限于人类的很多生命体处于不幸中。绝大多数是没有人力可以避免的,“拯救”这个词本身就有点自大的意味。

而现实中很多时候,可能真的如同电车难题那样,“拯救”行为本身就意味着另一群体被牺牲。是不是有的群体,就值得牺牲其他群体被拯救?这种判断,即使上升到一个国家决策层,我觉得都是无法做出的——考虑了政治的,就意味着牺牲经济的,反之亦然。所谓“符合大多数人的利益”,无论是“大多数人”的界定,还是这句判断其本身是否代表正义,都是虚幻的。它只能是一句政治口号,而不应该成为任何决策的依据或者借口。

持续的封控确实一定程度上拯救了一些人群,这是否正义呢?那些因为封控而使得其自身其它疾病没有得到及时治疗而“枉死”的灵魂是否认同这种正义呢?放开后的大爆发是可以预见的,这在一年前世界上其他大多数国家放开时早已演示过一遍。大爆发中也必然有人会离去,所以放开就非正义了吗?

很多人已经忘了,放开才是常态,封控是异常态。维持异常态是需要不断给系统做功输入能量的,社会终究会回归常态,要么平和地,要么激烈地。

回到电车难题,任何人都没有资格去改变既定的轨道去伤害任何人,那是杀人。如果你是决策者,你应该做的,是在列车驶来前通知那五个小朋友,告诉他们这里危险,或者预先多竖一些警示牌。

谁的错误谁承担,谁的命运谁承受,很无情,但很道德。

胡言乱语 | 2 个评论 | 10,161 次阅读
简短地址:http://ncblog.net/1957/
谈谈 Effie 的原生实现    @ 2022-11-16, 14:31

Effie 是一款跨平台(macOS、Windows、iOS、Android)的集严肃写作、随手笔记、大纲和思维导图于一身的极简写作 App。

写作笔记 App 市面上已经非常多,跨平台也早已属于标配。抛开产品设计和云端同步层面,就客户端实现来说,Effie 与一众的套浏览器(Chromium 或者 WebKit)以 JavaScript 实现的编辑器最大的区别,或者说独步江湖的特性,就是所有平台均以原生技术实现

原生实现的劣势

所有平台都用原生实现,最大的劣势,就是开发成本极高。产品的核心功能,需要在每个平台上单独实现一遍。比如编辑器本身的交互、排版、渲染等功能,需要使用平台提供的特定的 API 或者框架,编写大量的基本上无法在其它平台复用的代码。只有一些算法性的代码可以在不同平台上用不同的开发语言实现一遍,这已经算是最大程度的“复用”和“共享”了。

即便都是 Apple 的 iOS 和 macOS,两套框架(UIKit 和 AppKit)的差异,也远超过最初的预期。UITextViewNSTextView不能说一模一样,可以说毫不相干。如果你认为改造完 UITextView,接着改造 NSTextView 会比较轻松,那你必然大失所望。接着面对 Windows 时,Win32 提供的基础组件 richedit32.dll,基本还是停留在上世纪的水准,在 Windows 平台另起炉灶是更明智也是无奈的选择。再来看 Android 的 EditTextTextView)时,又是一个全新的世界。

如果在大厂,选择这样的技术路径,必然会成立多个平台的开发小组,各自在不同平台开发产品。这样的实现方式,其实也很难保证,同一个产品在不同平台上有非常一致的内在逻辑和使用细节上的一致感受。而现实中,即便是大厂,也大多选择用所谓前端技术(套浏览器的 JavaScript 实现)来降低开发成本。

Effie 是个创业团队,不是大厂。Effie 所有平台的客户端的核心模块,是我一个人完成的,花了两年多时间,近30万行代码,这是一个看似非常“任性”的决策。Effie 在不同平台上,既能和平台本身风格完全融合,又能给跨平台使用的用户,带来使用上的一致感受。

Effie 为什么选择原生实现

其实,最早的 Effie 桌面原型,也是使用前端框架 Electron 来实现编辑器的。但随着原型的日渐丰满,越走越发现使用 JavaScript 实现带来的问题——无论如何优化,那种“不丝滑”的感觉——始终挥之不去。Effie 的产品经理李自然对于这个问题,也越来越无法忍受,即便市面上的同类产品皆如此。

在我加入 Effie 团队后,我在 iOS 平台尝试用 Objective-C/UIKit 实现了编辑器和思维导图的基础功能。李自然试用后,对这种“丝滑”再也欲罢不能。

之后,我用 Objective-C/AppKit 重写了 macOS 的客户端,与 iOS 版一起发布了 Effie 最初的公开版本。

再之后开发 Windows 版,也选择了 Native Win32,而没有考虑 .NET 框架。原本打算使用 Lazarus/Free Pascal 作为开发工具的,但 Lazarus 的 LCL 框架对触摸屏的支持尚不完善,另外,对多显示器的 DPI 处理也有问题,遂放弃。最终还是用我最熟悉的 Delphi,基于一套第三方付费编辑器组件,完成了 Windows 版的编辑器。而用户界面,全部使用 GDI+ 来渲染,并自己实现了所有过场动画(Win32 API 对动画几乎没有任何支持)。有用户反馈在 Windows 版 Effie 的安装包中,也带有 Chromium 库的文件,以为 Effie 也是套了浏览器内核的 JavaScript 实现。Effie 中带的这些 Chromium 库文件,是为了支持苹果登录的,与编辑器以及其它功能的实现没有关系。

最艰难的可能还是要数最后的 Android 版了,相对其它平台,Android 是我个人使用最多的(一直使用 Android 手机),却又相对最陌生的(开发层面)平台。Android 的“碎片化”也带来不少麻烦,不同的版本,不同的 Android 分支,有时简直就是另外一个系统。可能这也是为什么我使用 Android 这么多年,也基本上找不到一个趁手的笔记 App 的原因吧——现在有 Effie 了。

原生实现的优势

原生实现的优势,就是能在不同的平台,最大化的利用平台本身的特性,无论从界面元素的风格、还是交互,都带给用户最“地道”的感受。同时,编译生成的本地二进制代码(除了 Android 的 Java 不算)的执行效率,也给用户使用时带来不可忽略的所谓“丝滑”感受。

另外,对于一些极端情况,比如超大文本的情况,JavaScript 实现依赖浏览器处理,经测试,大部分这类实现的产品,都无法在人类忍受时间范围内处理好。我做过一个测试,在 Windows 版 Effie 中,将整部《三国演义》大纲化,每个段落作为一个列表项,一共2617项,生成思维导图。Effie 整个过程中占用内存不超过50M(作为对比,XMind 占用大约2G左右的内存),滚动思维导图,过程中完全跟手不卡顿,切换风格2秒内完成。

也有人问,为什么不选择跨平台的原生框架,比如 Qt。个人觉得,跨平台框架,为了跨平台,一定需要牺牲很多平台特性,去迁就共性。这样是无法做出 Effie 这样风格的产品的。Qt 这类框架只是让你可以用同一种语言,而语言对我而言,并不是一个多大的困扰。

既然选择了原生

归根结底,JavaScript 的实现受制于浏览器内核是其最大的“缺陷”。就目前的机器性能来说,纯 JavaScript 实现还是很难摆脱这个“缺陷”,即便强大如 Visual Studio Code。开发决策没有绝对的对错,只是不同的团队做出的不同的选择。

今年,Effie 已经实现了全平台覆盖(除了 Andriod 版还没有支持思维导图),也增加了全平台的图片支持,已经是一个成熟可用的,体验绝佳的写作、笔记、思维导图 App。

Effie 既然“任性”地选择了原生,作为 Effie 的开发者,我会尽可能让 Effie 永远保持这份“丝滑”。

Effie | 6 个评论 | 4,457 次阅读
简短地址:http://ncblog.net/1954/
今日霜降,凛冬将至    @ 2022-10-23, 20:11

当我们想象历史场景,总是灰白的。其实,当下鲜亮的每一天,在后人眼里何尝不是灰白的历史画面。

一切都会成为历史,每一天都是历史的开端。

凛冬将至。

胡言乱语 | 7 个评论 | 4,635 次阅读
简短地址:http://ncblog.net/1952/
返沪十年    @ 2022-10-09, 19:11

2012年10月长假后全家从珠海回到上海,至今已有十年。

十年前,可乐还是个幼儿园大班的小朋友,现在已然是人高马大的高一学生。这十年间,有过紧绷的创业,有过放松的生活,有过面临老人病倒的无措,也有安稳的苟且,以及面对疫情的无奈……

而不变的,是键耕不辍的敲代码。十年前,和李自然合作开启,以及合伙创业做 Mera,项目遗憾地失败了。最近的两年多,再次和李自然合作,全情投入了 Effie 这个项目。两年多写了四大平台(macOS、iOS、Windows、Android)的编辑器和思维导图,近30万行代码,如果要我再写一个平台的编辑器,真的会吐了吧。全部原生实现,就是会面对这样的境地,需要无比的耐心——面对时间、金钱以及精力的全方面考验。幸运的是,李自然给了足够的耐心,我也算不辱使命,Effie 全平台的里程碑基本达成了。

成功的合作,基础无非是互相成全。感谢。

疫情已经三年,今年实实在在地捶打到了上海。全城2500万人封控61天,以及全国大小城市、乡镇陆续的封控和所谓静默,已经彻底颠覆了人生前四十多年的认知——活久见。

无论是人到中年的自己,还是社会,似乎都已经告别了那个蒸蒸日上的年岁。叹息。

农码生涯 | 6 个评论 | 6,211 次阅读
简短地址:http://ncblog.net/1948/
Effie for Android    @ 2022-10-08, 18:24

前所未有的艰难,近两年写的第四个平台的编辑器,终于完成了。

Effie | 1 个评论 | 5,534 次阅读
简短地址:http://ncblog.net/1946/
高中生可乐    @ 2022-08-11, 20:03

对于可乐上学,我们从来没有花费精力和金钱去操办学区房和校外补课等,九年义务教育都是随缘上了一般的(世俗认知中属于垃圾的)学校,而给可乐在校外答疑解惑的,主要是可乐妈负责。

今年因为上海封控了两个月,初三学生在家上网课三个月,最后一个月回校。可能因此,我个人觉得今年上海中考似乎呈现出一种比较奇怪的分布,高分数量多(700分以上),但总体分数线比去年低,普通高中分数线 520(去年 540)。我的解释是,因为封控,某些副科(比如体育,英语听力测试等)所有学生都按满分算,拔尖学生不会因为在家上网课而放松,而普通学生普遍是受到了不去学校的影响的。

可乐的人生第一场重要考试的总分是 682,在他初中学校本届学生中排第二,也如愿被他所向往的第一志愿高中学校录取了。以这样的结果结束九年义务教育,作为家长我还是很欣慰的。想想没有弄学区房,也没花钱去校外补课,感觉省下了一千万。

可乐百事 | 2 个评论 | 4,180 次阅读
简短地址:http://ncblog.net/1942/
新文件服务器(NAS)    @ 2022-07-17, 19:28

台机更新升级完成后,文件服务器成了家里唯一“大个头”的机器了。前两年一直想把它换成群晖之类的成品 NAS,但群晖的四盘或者更多盘的 NAS 价格实在没什么性价比,配置又差强人意,实在下不去手。nate 去年淘汰了一个群晖的 DS216se 给我,放了两块盘做了一个同步盘,取代 Dropbox,但取代不了文件服务器。这次趁着这股折腾劲,决定把闲置的一个旧 ITX 小板和一块第三代 i3 做一个新的小型化的文件服务器。

淘宝上 Tank 家的 NAS 机箱,在去年年初做第一批货的时候,我就看上并下单预定了的。但由于时间太久又担心第一批货不成熟,又对 1U 电源稍微有点抗拒,所以后来取消了。这次在机箱选择上,最后仍然选择了 Tank 家的,因为支持热插拔六盘位,而且这次可以选配海韵的 1U 电源,据说挺安静的。

机箱到手后,颜值确实很高(虽然很多人说有点像微波炉),现在似乎也到了量产成熟阶段,做工很精致。

把主板、CPU 塞进去后,硬件部分就完成了。

把原先的文件服务器(技嘉主板)的硬盘拆下,塞进新的机器(华擎主板),启动系统,然后 Kernel Panic 了。

2010年从 Gentoo 入门开始玩 Linux,随着云服务器的使用越来越多,接触 Gentoo 越来越少。至今好像只有 Linode 还提供 Gentoo,其它的云服务商几乎已经见不到 Gentoo。唯独我的文件服务器,一直坚持 Gentoo,即使 Gentoo 时不时总会带来一些麻烦,比如升级依赖包冲突。而这个 Gentoo 的内核,也一直是祖传的,自己根据硬件编译的,每次硬件升级,都可能需要重新编译内核。

可能年纪确实大了,实在懒得再折腾编译内核了,直接把系统换成了 Ubuntu Server,这次算是彻底告别 Gentoo 了。

相比群晖等成品 NAS,自己装的机器系统虽然多少需要折腾一些,但自由度高得多,性能、配置也高得多。群晖 2G 内存就算高端机了,自己装的至少 16G 起吧,何况 CPU 的选择,对于偶尔需要跑一些脚本(自己额外)的需求来说,也很重要。

好了,“数据中心”搞定。

软硬兼施 | 评论已关闭 | 2,913 次阅读
简短地址:http://ncblog.net/1940/