the size of the image concerns me:
kernel+boot 100MB, with C it could be 4MB.
kernel+boot+basicpackages 500MB, with C it could be 16MB.
Golang is designed to be static all-in-one packages for each application(e.g. microservices), when you run a lot of them in any given system, it becomes really large together.
I don't mind to use one or two go binaries in my embedded board, when I need a few of them, I am concerned about the storage size(possibly memory size as well).
a helloworld go binary is about 8MB, a C is about 20KB(shared libraries), go binary size adds up really fast due to the fact most do not use shared libraries even when there are many go binaries in the system.
The best solution would be to use BTRFS/ZFS with transparent compression (can use fast algorithms) or even SquashFS if you can deploy the entire app image mounted in a directory.
Wondering if they can achieve that.
Anyone know if there a list of these types of frameworks anywhere?
https://github.com/gokrazy/gokrazy/issues/13
And if you read the issue, it's a bit understandable to not want to reimplement wpa_supplicant.
Given this is what the README states, how can it be a GNU/Linux distribution?
It doesn’t include a shell or anything like coreutils either (GNU or otherwise).
You're taking a few F/OSS components (in this case the Linux kernel, the golang toolchain and some custom software) and you're assemblying them into a bootable system.
That's almost quite literally the definition of "gnu/linux distribution".
GNU/Linux, or GNU plus Linux as I’ve recently taken to calling it, means combining a GNU userland (GNU libc, GNU coreutils, GNU compiler collection) and the Linux kernel. The Linux kernel itself is not a GNU project. If you want to use a GNU kernel then you need Hurd, hence GNU/Hurd.
When you replace the whole userland with components that are not written by the GNU project, then it no longer is GNU/Linux. As such this is not a GNU/Linux distribution, and neither is Alpine for example since by default it doesn’t use a GNU userland.
pi@octopi:~ $ sudo hdparm -tT /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 1366 MB in 2.00 seconds = 683.30 MB/sec
Timing buffered disk reads: 62 MB in 3.02 seconds = 20.53 MB/sec
Meanwhile on a Threadripper 3970x with SSD (but virtualized):
$ sudo hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 20200 MB in 2.00 seconds = 10109.10 MB/sec
Timing buffered disk reads: 5296 MB in 3.00 seconds = 1763.28 MB/secAm assuming that the reference to Raspberry Pi 3 and 4 might have been made without considering the above Model since otherwise there would be no need to exclude the Zero models, which also have 512MB of RAM.
[0] https://www.raspberrypi.com/products/raspberry-pi-3-model-a-...
Your application is not going to be 500MB!!
The OP completely misunderstood this entire premise of this project and every comment that has followed has been just as misinformed.
It’s almost comical just how badly you all have misunderstood this project yet still proceeded to lecture everyone about how unsuitable it and Go is. So let me explain one last time:
500MB is just a partition for you to put YOUR own application on. That application might only be 5 (five) megabytes or it could be 50MB but the partition needs to be large enough to offer some breathing room (eg logs, external assets if required, etc) and frankly for a non-embedded mini-PC, a 500MB partition isn’t a ridiculously high suggestion.
Clearly none of you guys bitching about the unsuitability of Go for the Pi have never actually used Go on a Pi or even bothered to read this GitHub readme. I’ve done both and frankly you’re all being ridiculous. Go works fine on the Pi (even the very first model) and no Go executable is going to be half a gigabyte(!!!) - I know Go binaries are large but stop for a moment to thing about the actual file size you are all talking about for a moment. Even Electon doesn’t inflate that big in most cases.
Honestly, it’s ridiculous the way you’ve all carried on. Did nobody stop to think for a moment before posting?