Live data from Hacker News

A native Go userland for your Raspberry Pi 3 or 4 appliances

github.com

21–30 of 37 posts

Re: A native Go userland for your Raspberry Pi 3 or 4 appliances

#22

an interesting project. 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 o…

Urgh! This is really not good for most embedded systems both for space constraints and having to load large binaries from slow devices.

Re: A native Go userland for your Raspberry Pi 3 or 4 appliances

#23

an interesting project. 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 o…

Embedded boot time should be below 4 seconds (the time people give up loading a web page).

Wondering if they can achieve that.

Re: A native Go userland for your Raspberry Pi 3 or 4 appliances

#24

an interesting project. 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 o…

When comparing C and Go, a natural comparison would be to compare the output from GCC and GCCGO.

Re: A native Go userland for your Raspberry Pi 3 or 4 appliances

#25
post #13

Earlier quoted context omitted.

If that’s an issue just cache the file in RAM. 500MB is still less than the system memory on a Pi (and as I’ve pointed elsewhere, the OP was reading the partition table not the application file sizes).

I guess, but this argument is basically just saying "RPi is basically just a normal computer now so why be conservative with anything?"

It is basically just a normal computer and I feel you’re optimising the wrong thing here too given we’ve already established the OP was wrong when they threw around what they believed to be the applications file sizes.

Re: A native Go userland for your Raspberry Pi 3 or 4 appliances

#26

an interesting project. 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 o…

It appears the authors assume the user will choose an SD card as the rootfs. Another alternative is to run the RPi with a tmpfs mounted directory as the rootfs and use the SD card as tertiary storage. This way I do not have to worry as much about the quality and condition of the SD card. To conserve RAM, I need the bootloader, kernel and the "always-installed" userland to be relatively small. With NetBSD, I can usually fit this all in under 20MB, leaving the rest of RAM as free tmpfs space to use however I wish. If I need to use some large Go binary for some specific task, I install it after boot in the free space. Then I remove it when the task is completed. Another alternative is to put these larger programs in a compressed filesystem such as cloop or squashfs, stored as a file on the SD card. NetBSD allows me to mount cloop2 filesystems read-only from tertiary storage. https://man.netbsd.org/vndcompress.1

Re: A native Go userland for your Raspberry Pi 3 or 4 appliances

#27

an interesting project. 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 o…

Urgh! This is really not good for most embedded systems both for space constraints and having to load large binaries from slow devices.

Raspberry Pis are neither embedded systems nor slow devices (compared to embedded systems).

Re: A native Go userland for your Raspberry Pi 3 or 4 appliances

#28
post #10
post #4

Is this kinda like the Nerves approach but for Golang? ( https://github.com/nerves-project/nerves )

This space is really interesting to me- developing for pi by bundling up a whole image, for weird little software/hardware experiments. Anyone know if there a list of these types of frameworks anywhere?

there should be - here's one: https://nanovms.com/dev/tutorials/nanos-on-64-bit-arm

Re: A native Go userland for your Raspberry Pi 3 or 4 appliances

#29
post #8

Earlier quoted context omitted.

To be fair, this is designed for Raspberry Pi, and nowadays it's almost impossible to find a micro SD that's less than 16 GB and costs significantly less than a 16 GB one, I don't think a couple hundred MBs are a concern (even if it hurts my soul too)

What's the max/typical read bandwidth from an SD card on a Pi? Even if the storage space is there, you might still get perceptible latency improvements with order-of-magnitude smaller binaries.

On a Raspberry Pi 3 with a random SD card I found laying around:

    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
So it's going to take a couple seconds to page this thing into memory. (The memory speed isn't great either.) It's not so slow that I'd bother to write application software in C just to make startup 5 seconds faster, though.

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/sec

Re: A native Go userland for your Raspberry Pi 3 or 4 appliances

#30
post #9
post #5

Earlier quoted context omitted.

> aside from the Linux kernel and proprietary Raspberry Pi bootloader — only contains Go software. 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).

> how can it be a GNU/Linux distribution? 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".

I think you might be misunderstanding what GNU/Linux means.

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.

Post reply on HN