内核之外的冰山:为什么说从零写一个操作系统已几乎不可能?
内核之外的冰山:为什么说从零写一个操作系统已几乎不可能? - Tony Bai Tony Bai 一个程序员的心路历程 Google Go语言编码风格规范 Google Go语言编码风格规范:指南篇 Google Go语言编码风格规范:决定篇 Google Go语言编码风格规范:最佳实践篇 Go语言第一课FAQ ...
内核之外的冰山:为什么说从零写一个操作系统已几乎不可能? - Tony Bai Tony Bai 一个程序员的心路历程 Google Go语言编码风格规范 Google Go语言编码风格规范:指南篇 Google Go语言编码风格规范:决定篇 Google Go语言编码风格规范:最佳实践篇 Go语言第一课FAQ ...
本文永久链接 – https://tonybai.com/2022/05/16/the-short-guide-of-embracing-c-lang-for-gopher 本文是为于航老师的极客时间专栏《深入C语言和程序运行原理》写的加餐文章《Tony Bai:Go程序员拥抱C语言简明指南》,这里分享给大家,尤其是那些想学习C语言的Gopher们。 你好,我是Tony Bai。 ...
本文永久链接 – https://tonybai.com/2022/03/28/the-comparison-of-the-go-community-leading-kakfa-clients 一. 背景 众所周知,Kafka是Apache开源基金会下的明星级开源项目,作为一个开源的分布式事件流平台,它被成千上万的公司用于高性能数据管道、流分析、数据集成和关键任务应用。在国内,无论大厂小厂,无论是自己部署还是用像阿里云提供的Kafka云服务,很多互联网应用已经离不开Kafka了。 互联网不拘泥于某种编程语言,但很多人不喜欢Kafka是由Scala/Java开发的。尤其是对于那些对某种语言有着“宗教般”虔诚、有着“手里拿着锤子,眼中满世界都是钉子”的程序员来说,总是有想重写Kafka的冲动。但就像很多新语言的拥趸想重写Kubernetes一样,Kafka已经建立起了巨大的起步和生态优势,短期很难建立起同样规格的巨型项目和对应的生态了(近两年同样火热的类Kafka的Apache pulsar创建时间与Kafka是先后脚的,只是纳入Apache基金会托管的时间较晚)。 ...
本文永久链接 – https://tonybai.com/2021/07/19/understand-go-plugin 要历数Go语言中还有哪些我还没用过的特性,在Go 1.8版本中引入的go plugin算一个。近期想给一个网关类平台设计一个插件系统,于是想起了go plugin^_^。 ...
Docker技术从2013年诞生到目前已经4年有余了。对于已经接纳和使用Docker技术在日常开发工作中的开发者而言,构建Docker镜像已经是家常便饭。但这是否意味着Docker的image构建机制已经相对完美了呢?不是的,Docker官方依旧在持续优化镜像构建机制。这不,从今年发布的Docker 17.05版本起,Docker开始支持容器镜像的多阶段构建(multi-stage build)了。 什么是镜像多阶段构建呢?直接给出概念定义太突兀,这里先卖个关子,我们先从日常开发中用到的镜像构建的方式和所遇到的镜像构建的问题说起。 一、同构的镜像构建 我们在做镜像构建时的一个常见的场景就是:应用在开发者自己的开发机或服务器上直接编译,编译出的二进制程序再打入镜像。这种情况一般要求编译环境与镜像所使用的base image是兼容的,比如说:我在Ubuntu 14.04上编译应用,并将应用打入基于ubuntu系列base image的镜像。这种构建我称之为“同构的镜像构建”,因为应用的编译环境与其部署运行的环境是兼容的:我在Ubuntu 14.04下编译出来的应用,可以基本无缝地在基于ubuntu:14.04及以后版本base image镜像(比如:16.04、16.10、17.10等)中运行;但在不完全兼容的base image中,比如centos中就可能会运行失败。 ...
Go有很多优点,比如:简单、原生支持并发等,而不错的可移植性也是Go被广大程序员接纳的重要因素之一。但你知道为什么Go语言拥有很好的平台可移植性吗?本着“知其然,亦要知其所以然”的精神,本文我们就来探究一下Go良好可移植性背后的原理。 一、Go的可移植性 说到一门编程语言可移植性,我们一般从下面两个方面考量: 语言自身被移植到不同平台的容易程度; 通过这种语言编译出来的应用程序对平台的适应性。 在Go 1.7及以后版本中,我们可以通过下面命令查看Go支持OS和平台列表: ...
与在Solaris系统上不同,Linux的libc库中包含了libiconv库中函数的定义,因此在Linux上使用libiconv库相关函数,编译时是不需要显式-liconv的。但最近我的一位同事在某redhat enterprise server 5.6机器上编译程序时却遇到了找不到iconv库函数符号的链接问题,到底是怎样一回事呢?这里分享一下问题查找过程。 一、现场重现 这里借用一下这位同事的测试程序以及那台机器,重现一下问题过程: /*test.c */ ...