driusan

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.

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.

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.

Do you know if your talk going to be online afterwards?

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.)

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 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.

"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."

"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..

Thanks! I wasn't sure since it says that there's no window decorations.

This looks incredibly similar to a WM I'm writing.. except mine is written in Go using literate programming, as an excuse to try to do something substantial with LP.

In the last screenshot, what's the header at the top of the screen? Is that from the WM or the program running inside of it just drawing at the top of the screen? (It's too low resolution to tell..)

And is stumpwm autotiled or manually tiled?