1984 年的电脑也能跑 Chat-GPT ?!
新加坡的逆向计算爱好者 Yeo Kheng Meng 发布了一个 “doschgpt” ChatGPT 客户端,这个客户端适用于上世纪八十年代的 MS-DOS 系统。
目前这个 DOS 系统的 ChatGPT 客户端已成功在 1984 年的 IBM 5155 便携式 PC 上运行,这台机子配备 4.77Mhz 主频的 Intel 8088 CPU 和 MS-DOS 6.22 系统,带 640KB 内存、以及 CGA ISA 图形。
Yeo 老哥是个不折不扣的“复古守旧派”,早在 2019 年他就为 Windows 3.1 开发了一个 Slack 客户端,这次更是把 1981 年的 MS-DOS 纯文本操作系统和最新的 ChatGPT 两个跨了 40 多年的东西组合到一块。
最有意思的是整个程序的开发过程, Yeo 老哥先是找到一个能开发 16 位 DOS 程序的 “Open Watcom” C/C++ 编译器 ,它本身是一个 32 位程序,这意味着它可以在 64 位 Windows 11 等现代平台上运行。
但是 64 位的 Windows 又没法执行 16 位的 DOS 程序,而每次都在 640K 内存的老电脑上跑测试也并不是很现实。于是 Yeo 开一个运行 DOS 6.22 的 Virtualbox 虚拟机,然后将虚拟机和主机桥接网络,方便传输文件进行开发和测试,等测试完成后再把二进制文件传到实际的 IBM PC 上运行。
但这时另外一个问题来了:如何在这么老的 IBM PC 上处理网络? 在这一步 ,Yeo 找到了一个 1983 年的 Packet Driver API ,然后使用开源的 MTCP 库集成到应用程序中,以与 Packet Driver 进行通信,从而为客户端启用网络功能。
而要使用 ChatGPT API,必须要有一个 Post 请求,然而 DOS 没有可以使用的辅助函数,必须用 C 语言手动构建整个 POST 请求:
#define API_CHAT_COMPLETION "POST /v1/chat/completions HTTP/1.1\r\nContent-Type: application/json\r\nAuthorization: Bearer %s\r\nHost: api.openai.com\r\nContent-Length: %d\r\nConnection: close\r\n\r\n%s" #define API_BODY "{ \"model\": \"%s\", \"messages\": [{\"role\": \"user\", \"content\": \"%s\"}], \"temperature\": %.1f }"
这时 ChatGPT API 会返回一份 JSON 输出,需要解析其中 “Content” 键的值。很明显,这一步也没有现成的 JSON 库可用,只能手动写键值对的解析代码。
这时新的问题来了: ChatGPT API 通过 HTTPS 加密,但 DOS 系统没有本机 HTTPS, Yeo 只能编写一个 go 语言的 HTTP 到 HTTPS 代理 (有点像中间服务器),然后在现代 PC 上运行这个代理。充当一个透明中间人。它检查 HTTP 请求的主机字段,并将原始套接字字节作为 HTTPS 转发到 OpenAI 的服务器。
这一步有点像作弊,但属实是无奈之举,毕竟要在 Intel 8088 上运行现代 TLS 加密算法,属实是太难为这个传家宝系列的 CPU 了。
剩下的就是如何将对话内容读/写输入到控制台,这一步不再赘述,感兴趣的朋友可以在 Yeo 的博客中查看完整的开发过程。最终实现的效果:
Yeo 已经把整个 doschgpt 客户端在 Github 上开源,里面有详细的教程,感兴趣的朋友可以自己动手试试(前提是家里有 MS-DOS 系统的传家宝机器😂...)
另外,这回图拉丁老哥们有话说了,还在嫌弃机子的配置不行?处理器低于 3.0 Ghz 不能用?人家怎么就能在 4.77Mhz 的 CPU 上跑 ChatGPT ?还不是自己动手能力太差!还是那句话,东西老点差点怎么了,又不是不能用!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
PEP 582 提案 (Python local packages directory) 被拒绝
Python 指导委员会拒绝了 PEP 582 提案——Python local packages directory,即本地包目录。 此 PEP 提议向 Python 添加一种自动识别__pypackages__目录的机制,并优先导入安装在此位置的包,而不是用户或全局站点包。这将避免创建、激活或禁用“虚拟环境”的步骤。当出现时,Python 将使用脚本基目录中的__pypackages__。 CPython 核心开发者 Thomas Wouters 在该提案的讨论组中公布了这个消息。 他表示这是指导委员会慎重考虑后的决定,虽然 PEP 的实现看似简单(将另一个目录添加到 sys.path ,类似于程序的目录),但语义上的结果并不立即显现,特别是当与其他方式结合影响模块搜索路径时(虚拟环境,用户-本地安装、PYTHONPATH、.pth 文件、sitecustomize 等)。 总的来说,似乎没有令人信服的论据表明这确实会带来净收益。打包社区之间存在分歧,新功能没有明确的有益用例。此外,__pypackages__或类似解决方案的实验已经可以通过sys.path的许多现有自定义机制之一...
- 下一篇
解决异构系统集成难题,富融银行这样做
背景介绍 富融银⾏是⼀家⽴⾜于⾹港,⾯向全球业务的虚拟银⾏,创立以来先后斩获 2021年-杰出虚拟银行服务大奖、2022年-[领航9+2粤港澳大湾区奖项]粤港澳大湾区最佳银行 等荣誉。 富融银⾏以⼤数据、云计算等技术为驱动,为用户提供存款、贷款、转账、理财、营销等⼀站式的⾦融服务。 富融银行的核⼼系统是处理银⾏业务存款、贷款和中间件业务等最基本业务的IT系统。为了⽀持银⾏业务的⾼速发展,核⼼系统涵盖了外购、⾃研2⼤类系统,其中外购系统不具备⼆次开发能⼒,需要供应商⽀持。 为了保障业务的持续发展,需要改进核⼼系统服务治理⽔平,来应对业务挑战和⾦融监管,因此核⼼业务需要引入服务治理组件,能够平滑顺利地解决容灾、系统集成、流控、服务发现、服务治理、故障容错等问题。接下来,我们来看看富融银行是如何应对挑战,实现业务系统升级的。 挑战重重,迎难而上 随着业务不断扩展,自研系统+外购系统带来了一定的挑战:通讯协议上的多样性,报文格式的差异,云上的安全机制,混合云的容灾机制等,北极星的到来,帮助核心研发团队低成本高效率应对上述各种挑战。 挑战一:异构系统,集成难度高 上面提到过,为了⽀撑银⾏业务发展...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2全家桶,快速入门学习开发网站教程