[HN Gopher] A native Go userland for your Raspberry Pi 3 or 4 ap...
___________________________________________________________________
A native Go userland for your Raspberry Pi 3 or 4 appliances
Author : RcrdBrt
Score : 95 points
Date : 2022-01-23 15:48 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| kelvie wrote:
| It took a bit of digging, but it seems that encrypted wifi is not
| supported:
|
| 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.
| waymon wrote:
| now only to somehow buy a Raspberry Pi 3 or 4
| lovebes wrote:
| Is this kinda like the Nerves approach but for Golang?
| (https://github.com/nerves-project/nerves)
| jcpst wrote:
| 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?
| convolvatron wrote:
| there should be - here's one:
| https://nanovms.com/dev/tutorials/nanos-on-64-bit-arm
| synergy20 wrote:
| 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 of them, I am concerned about the storage
| size(possibly memory size as well).
| laumars wrote:
| The only place on the readme where I could find those figures
| you came up with was the partition table and obviously a
| partition of 500MB doesn't mean the applications are going to
| be 500MB in size. In fact it's quite the opposite; it pretty
| much guarantees the applications are going to be less than
| 500MB given you are going to want some headroom to work with.
| amelius wrote:
| Embedded boot time should be below 4 seconds (the time people
| give up loading a web page).
|
| Wondering if they can achieve that.
| Kipters wrote:
| 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)
| Karellen wrote:
| 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.
| laumars wrote:
| 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).
| hiptobecubic wrote:
| I guess, but this argument is basically just saying "RPi
| is basically just a normal computer now so why be
| conservative with anything?"
| laumars wrote:
| 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.
| jrockway wrote:
| 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
| xyproto wrote:
| When comparing C and Go, a natural comparison would be to
| compare the output from GCC and GCCGO.
| codazoda wrote:
| I originally thought go binaries we're large. Turns out they
| can be quite small.
|
| https://joeldare.com/small-go-binaries
| zekica wrote:
| UPX also prevents re-using pages when multiple instances of
| the executable are loaded in RAM which is bad on low end
| systems.
|
| 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.
| SXX wrote:
| ZFS on low-end low-RAM system? You must be joking...
| synergy20 wrote:
| upx will take time/resource to unzip, which could be slow in
| some embedded systems.
|
| 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.
| codazoda wrote:
| The binary is 7.3MB before compressing. Still not too big.
| 1vuio0pswjnm7 wrote:
| 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
| goodpoint wrote:
| Urgh! This is really not good for most embedded systems both
| for space constraints and having to load large binaries from
| slow devices.
| laumars wrote:
| Raspberry Pis are neither embedded systems nor slow devices
| (compared to embedded systems).
| znpy wrote:
| Is it just me or this feels like, effectively, a whole gnu/linux
| distribution?
| daenney wrote:
| > 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).
| znpy wrote:
| > 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".
| wyufro wrote:
| What, no. It's not GNU/Linux if there's no GNU software
| present.
| daenney wrote:
| 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.
| denysvitali wrote:
| More like Go/Linux
___________________________________________________________________
(page generated 2022-01-23 23:00 UTC)