If you stumble across a labs URL (like in the article), you can usually just replace "plan9.bell-labs.com" with "9p.io". For instance, the link to Miller's RPi build that was linked to should be updated to http://9p.io/sources/contrib/miller/9pi.img.gz
Having written my own git client, I can tell you that "the most complicated part will be the command-line arguments parsing logic" doesn't go away. I wouldn't be surprised to wake up one day and find someone published a proof that NP != P, and the proof involved trying to parse the git command line.
Doesn't seem that realistic. I reloaded a bunch of times, and didn't get a single one where the same command can mean 3 different context-sensitive things that each take different arguments but are all named the same command.
The sadest part about this is that it's all because the stigma against mental health problems is so strong that people are this outraged over research that might even suggest their illness has a psychological component.
Unless your current reviews are really superficial probably not. You can only review at your level of understanding, so if they're asking for more depth to your code reviews you probably need to develop a deeper understanding of the architecture and design of your codebase. A checklist would do the opposite of that in most cases.
It's a Plan 9 fork, the Plan 9 papers and man pages would describe the system architecture pretty well.
Most of the changes I know of that they've done (UFS support, ELF executables, standard C without the Plan 9 extensions, a different build system, etc..) are more in the details than the architecture.
For pretty much my whole life universities have been telling people that they need to go to university to get a better job (where "better" == "higher paid", sometimes implicitly and sometimes explicitly phrased that way.) I can probably count on one hand the number of times I've heard anyone phrase university in terms of civics or pursuing knowledge for the sake of knowledge or anything other than "you need to go to university to get a better job."
This seems to be a case of them getting angry at people for having listened to them. If you tell people that the reason to go to university is to find a higher paying job, it's not their fault if they don't value your university once they find a higher paying job.
The Go assembly language is actually one of the things that make doing something like this difficult.
Go uses the Plan9 assembly syntax but doesn't support GNU asm syntax.
gccgo uses GNU asm syntax but doesn't support Plan9 assembly.
The Go linker doesn't allow you to not link in the Go standard library runtime, which means you need to use gccgo to write a kernel.
The end result is that you can't do something that's buildable with the standard Go toolchain, and even if Go were to add a "don't link the runtime" option there'd be no way to incrementally port your ASM over one bit at a time. It's all or nothing.
I take a slightly different approach for my implementation that allows me to use the standard go toolchain. I use nasm for the early ASM code and patch the go build tool's output (see: https://github.com/achilleasa/gopher-os/blob/master/Makefile...) to bypass the link step and replace it with a manual call to ld that links the go object files with the output from nasm.
I will be talking about this approach in more detail in GolangUK '17.
I started writing a kernel in Go a while ago (and since abandoned it due to not having time.. I got as far as having a simple built in shell that let you do ls and cat on a FAT filesystem). The part about memory allocation and virtual memory wasn't much more difficult than it would be if you were implementing your kernel in C or some other low level language.
The hard part is once you get memory and paging working, you'll need a syscall interface. If you want to be able to run Go userspace programs, that means you need to implement the syscall interfaces for an OS that's already supported, and can't just go out and design your own, and at that part it starts getting a lot less fun.
Sure, you could, but then you need to fork the Go compiler too (and hopefully eventually get your GOOS target mainlined, which seems unlikely unless your OS gets popular) or you could do your userspace in something other than Go and implement what you need for that.
My point was just the memory allocation and paging isn't significantly different than it would be writing an OS in any other language, it's once you get to the part where you need to implement other people's interfaces/standards to make a viable product that it starts bogging down (if you go that route. If you go your route, then you have two major projects instead of one: writing an OS, and adding a new OS target to an existing toolchain.)
"This is the official list of people who can contribute
(and typically have contributed) code to the Upspin repository. The AUTHORS file lists the copyright holders; this file lists people. For example, Google employees are listed here but not in AUTHORS, because Google holds the copyright."
There is a difference between "a Google Product" and "Code to which Google holds copyright". Most importantly, the latter may include all code written by any Google Employee during their employment.
But it makes a philosophical difference to the involvement of the company, of the people working on it and also a practical difference, because products and non-products have very different launch-requirements. You are perceiving Google as far more monolithic, than it really is; the difference between a product and a non-product is how different employees of the company interact. To the outside world, that might or might not have any meaning. But I feel for the original comment that I replied to, it does.
> The Upspin website (the “Website”) is hosted by Google. By using and/or visiting the Website, you consent to be bound by Google’s general Terms of Service and Google’s general Privacy Policy.
"Additionally, unless there is a Contributor License Agreement to the contrary, whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and agree that you have the right to license your contribution under those terms."
It makes me so unreasonably happy to see that added to the terms of GitHub..
