2 ms·
I still find this effort odd. You already have a well tested and widely used userland, even if it is written in a non memory safe language. The easiest solutio
by dom96 9y ago
I still find this effort odd. You already have a well tested and widely used userland, even if it is written in a non memory safe language.
The easiest solution to me seems to be to grab the tools you need from the existing userland, instead of reimplementing them in Go. Currently you have reimplemented some of the userland, and packaged it up into a distro. So you have to maintain a stripped down distribution and the tools that you reimplemented. If you just took existing tools you would only have to do the latter. Am I missing something here?
- secure 9y agoThe userland in question is an NTP, a DHCP client and the init system / web interface. It really isn’t much code. Implementing these in Go reduces the number of moving parts, both in terms of libraries involved in the project and more importantly in terms of programming languages involved. Have a look at the git history to see how little maintenance is required in practice. I have barely had to touch the code over the last year of the project. Just incorporating new upstream versions of a typical Linux userland would have been more work. Also note that “distribution” is a rather big word for the few files we’re talking about: /mnt/gokrazy-root % find -type f ./cacerts ./gokr-pw.txt ./gokrazy/dhcp ./gokrazy/ntp ./gokrazy/init ./user/hello ./localtim ./hostname If my reasoning doesn’t convince you, so be it. Not every project has to make sense to everybody :). I wanted to do a pure-Go userland, and I’m happy with the amount of work this results in and the properties that come out of this decision (easily automated updates, massively reduced attack surface).