HN user
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
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?
Is the plan to use grumpc to transpile the code to Go and then work in Go in the future, or is the plan to keep coding in Python and add a grumpy step before deploying?
(If the former, you could just update the code to use the standard Go JSON/etc packages..)
They're in the chart. They're hovering near the bottom around 0%.
The argument is that if no one chooses the underdogs, then eventually there'll be a monopoly and no choice, regardless of switching costs..
It depends what you mean by "open." Anyone can subscribe to the go-codereview mailing list. Anyone can submit a patch, but you need to a) use gerrit and b) sign a (digital) contribitors license agreement with Google.
It's "open", but it would almost certainly collapse entirely if Google decided to drop support for it. (There's no sign that they'll do that, but it's not a risk you take with a language like C.)
"it's backed by Google" is the reason I avoided Go for years and is still the only reason I'm nervous using it.
That's odd, because in the martial arts I do (aikido), I've always been amazed by how similar of a state it puts you into: trying to get into the zone, concentrate on what you're doing right now, and block any other distractions.
The HN post title is the same as the author's original title.
I'm fairly sure I originally saw it on HN.
I think the most well-thought-out explanation I've seen for why widespread support for the SQL standard seemed to stop after SQL-92 is this one:
The Plan9 raspberry pi is probably the easiest way to get Plan 9 up and running, but not very powerful. The default image only has a 2gb partition. If you're interested in venti, it's a difficult process that needs to be manually set up (vs the ISO installer where it just asks you if you want to install fossil or fossil+venti) It makes a great introduction to Plan 9, and would probably make a great terminal for an existing Plan 9 cluster, but I wouldn't try making a cluster of them.
I use mine as a login server (and something to drawterm into when I want to play around with Plan 9 without booting up a VM), which is a great use case for it. I initially wanted to use it for Go development, but:
1. I had to start by writing a git client, which I never finished enough to be useable.
2. plan9/arm is only in Go tip (and will be in 1.7)
I was pretty disappointed by the title too.
The question "Does technical debt that's been already accrued lead to the rejection of new pull requests?" is what I was expecting.
Instead, the question they're asking is "Do pull requests which add technical debt to a project get rejected?" which is.. pretty obvious. That's the whole point of code review.
They go on to analyze the breakdown of what type of defect causes more discussion by doing a simple average across all of the projects they looked at, but given the visualization in Figure 2 I don't know how you can come to any real conclusion other than "it depends on the project."
I don't know where you got the impression that he was doing any of this with the intention of putting it on production.
Thanks for pointing that out! I thought the project was dead. I was really interested in it when it came out and disappointed that it didn't seem to go anywhere, but I think part of the problem is that it was too complicated to use and it was either all in or nothing (either the whole team uses BE, or no one is going to..)
So my approach is sort of an attempt to simplify things by going back to how an organized person might have tracked their issues in 1970 before project management software or source control, and then adding a couple hooks for SCM. "bug" is just a tool to streamline it without a lot of pushd/cd/popd.
Which means that you can use all of the commands except purge and commit in Mercurial, and then manually commit the issues directory (I think "hg commit $(bug pwd)" should work for commit, but "hg purge" seems to require an extension and not be built into the base install.) I'm not opposed to supporting hg (or anything else) as a first class SCM, except that I don't use it and wouldn't know if things were working as expected.
The bugseverywhere web page currently tells you to clone from a broken gitorious URL.. so.. installs?
The main difference is the design. BE keeps a hidden directory where everything is referenced by hash, which means you need to take the time to set up BE and have the client installed to use it. This is based on human readable file and directory names and isn't concerned with title collisions, which means that if you're stuck you can manage your issues with ls and cat (and mkdir, I guess.)
BE is probably more powerful and mature, but this is lighter weight, has no dependencies, and I find easier to use (possibly because I wrote it.)
This is something I threw together that I've been finding pretty useful in the last couple days, and I figure other people might be interested in trying out. It's a tool to treat an "issues/" directory on the filesystem as an issue tracker, which can be tracked via git (or any other source control) and viewed/edited from the command line with the "bug" tool.
I've been using it as a lightweight "What do I have left to do on this branch?" tool that fits into my workflow without having to go to an external service (ie. Redmine) or leave the terminal. The fact that it's context sensitive (it just looks for the nearest issues/ directory) means I can just do a "bug list" to get an instant list of outstanding tasks in whatever I happen to be working on whenever I switch branches or get interupted and need to remember where I was.
(I wanted to call it "context-sensitive," which is more accurate, in the title, but HN said the title was too long, so it became "distributed," since anything in git is "distributed".)