Live data from Hacker News

Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

gokrazy.org

51–60 of 90 posts

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#52
post #45

Earlier quoted context omitted.

Yours is a stricter and not-commonly-used definition of "memory safe", which typically means "in the C sense" i.e. pointer arithmetic and bounds checking. Go is certainly memory safe by the typical definition.

What's the typical definition? With data races, you can access array values out-of-bounds, which seems like the most fundamental thing you'd want protection from in a memory safe language.

The typical definition is memory corruption caused by out of bounds writes, stack corruption, use after free.

On safe languages an out-of-bounds will cause a crash on the access point, while on unsafe languages it will silently corrupt memory.

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#53
post #48

Earlier quoted context omitted.

Yours is a stricter and not-commonly-used definition of "memory safe", which typically means "in the C sense" i.e. pointer arithmetic and bounds checking. Go is certainly memory safe by the typical definition.

I don't see why it's a different definition, though. What's he's saying is that it's very easy to break Go's bounds checking with race conditions, and produce memory corruption . This isn't true of languages traditionally considered as memory safe - e.g. Java or Python.

A crash on out of bounds will always happen, unless unsafe package is being used to subvert memory accesses.

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#54
post #51

Could/should one use this to build a touch screen user interface for an RPi as part of a kiosk based application? I really like Go, and suspect a Go app would beat the pants off anything powered by Electron (performance wise).

I’d love to see this, but note that you’ll need to use a pure-Go graphical toolkit (or implement all graphics yourself), and likely interface the touchscreen yourself, too. If you’re not comfortable with this, it might be better to use something else.

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#55
post #45

Earlier quoted context omitted.

Yours is a stricter and not-commonly-used definition of "memory safe", which typically means "in the C sense" i.e. pointer arithmetic and bounds checking. Go is certainly memory safe by the typical definition.

What's the typical definition? With data races, you can access array values out-of-bounds, which seems like the most fundamental thing you'd want protection from in a memory safe language.

You can't access data out of bounds. Go will panic with a runtime exceptions if you do. Memory safety doesn't mean "memory IO errors never happen" it means "if a memory IO error happens, you'll know"

If you have an out of bound in C, your program keeps running in 9/10 cases. In Go you'll cause a panic in 10/10 cases which you can either handle and propagate as error or let the program crash entirely, the memory will be in a defined state if you choose to recover (your array might be garbage but you won't have written data into random memory belonging to other threads)

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#56

Earlier quoted context omitted.

Why is that interesting? Just that they're not having to carry special patches for the RPi3 or what?

Yes. I have only tried Raspbian and I'm not used to getting RPi kernels from kernel.org

E.g. Fedora has for years been using for RPi the same close-to-mainline kernel source that is used for other ARM boards and x86-64 and any other supported hw platform.

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#57
post #24

Earlier quoted context omitted.

Yep - for home automation style stuff (which the author seems to have built it for - see the showcase section), having a full Linux distro is actually a real pain. I've taken to building my own stuff with the ESP series of microcontrollers, home made PCBs, etc - once it's built - it just keeps chugging along, unlike my original stuff I built atop RaspberryPis with Linux.

What is it about Linux that doesn't keep your stuff chugging along?

You have to keep it up to date because of all the security issues in other apps that are installed.

If the system only contains the Linux kernel and your software you only have to worry about your security issues (unavoidable) and Linux security issues (also difficult to avoid - too much work to write a new kernel too, plus remote Linux vulnerabilities are quite rare).

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#58
post #8

This is great! I think it could have uses far beyond the Raspberry Pi. As someone who's worked in the consumer electronics industry for years, I think we desperately need to rethink our approach to Linux-based electronics with respect to both the userland and the primary application. A legacy-free framework written in a safe language could go a long way to improving our currently lousy reputation with respect to secu…

Maybe you should look at TockOS[1].

[1]: https://www.tockos.org/

Re: Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances

#59
post #8

This is great! I think it could have uses far beyond the Raspberry Pi. As someone who's worked in the consumer electronics industry for years, I think we desperately need to rethink our approach to Linux-based electronics with respect to both the userland and the primary application. A legacy-free framework written in a safe language could go a long way to improving our currently lousy reputation with respect to secu…

> As someone who's worked in the consumer electronics industry for years, I think we desperately need to rethink our approach to Linux-based electronics with respect to both the userland and the primary application.

Google has created a stack called NERF (Non-Extensible Reduced Firmware) for this:

https://firmwaresecurity.com/2017/07/23/google-nerf-non-exte...

There's a presentation about it on youtube:

https://www.youtube.com/watch?v=iffTJ1vPCSo

Post reply on HN