The article demonstrates the Usermode Driver API, showing how a Linux driver can offload work into userspace (with or without access to a working filesystem).
I mentioned this yesterday in the context of the in-kernel codec discussion[1], where the questions "can't this be done in userspace" or "why not sandboxing" were dismissed pretty quickly.
...So what color is their gopher?
> Strictly speaking, any program will do, but we need to ensure that the program in question has no dependencies on the file system. Linking it statically provides benefits. Go programs are statically linked by default, and to illustrate that the following approach works with any kind of program, we have chosen to embed a Go program into the kernel.
Please refrain from inciting language flamewars.
Android Things had drivers in Java, and Android has a few, although only as userspace.
It seemed so patently absurd at the time!
The easiest way to execute a program in a UKI/USI is just putting it at /init which gets executed first if nothing is specified in the cmdline. So that is a way you can have it execute something. But initrd's are mostly read-only and would need to be extracted and repackaged if you want to add a file and also stops existing (for the most part) once `switch-root`ed, so I honestly am not sure if that could cover the possible intent behind such a mechanism described in the article (tho I also mostly just skimmed the article, so I very well might be wrong on that though).
I guess that's the difference, yeah. Although "for the most part" might hide another answer?
Plenty of times they aren't the same.
To be honest, I've never met a single professional who actually bought any IEEE or ISO standard.
Plus who seats at WG14 table?
Big corporations selling compilers and OSes.
The binary you are actually executing is made with your compiler, not with the standard; which is just a static human readable document after all.
Though I'm not sure what your point is.
Also lots of AT&T and Bell Labs money poured into employees salaries.
And that book was very much written to describe existing implementation(s) of C.
What a strange question..
There's also the GNU implementation in GCC that's under the GNU GPL 3 licence. Moreover, the specification itself doesn't seem to have any licencing requirements at all.
So you're absolutely right: Go is the very opposite of proprietary.
Welcome to the club :)
>Trademarks and FOSS are not incompatible; instead, trademarks are legal tools strongly aligned with FOSS principles. A trademark is an assurance that the recipient of the goods or services is receiving a product of known source and qualities. Controlling how a FOSS project trademark is used protects the community and its software, by preventing use of the trademark in ways that are harmful to the reputation of the community or the software.
Linux is a registered trademark of Linus Torvalds[1]. GNU is a registered trademark of the FSF[2]. Your definition of "proprietary" isn't shared by virtually anyone, and would make virtually everything "faux open source", including the "open source os" project you originally worried about Go being integrated into.
[0] https://static.fsf.org/nosvn/licensing/2020/FOSSmarksv2.pdf
[1] https://tsdr.uspto.gov/#caseNumber=74560867&caseSearchType=U...
[2] https://tsdr.uspto.gov/#caseNumber=85380218&caseSearchType=U...