Hi, I am the author of gopher-os. It started as a fun research project to learn more about the Go runtime internals and I didn't really expect it making it to HN.
If you take a look at the Go runtime sources you will notice that all the low-level arch/os-related bits have been split into separate files which usually invoke some syscalls (e.g. the memory allocator eventually calls mmap)
The idea I am currently investigating is to first provide an implementation for things such as physical memory allocation and virtual memory mapping which would ultimately allow me to bootstrap the Go allocator. From that point onwards the plan is to incrementally add more features and gradually initialize the rest of the runtime.
This is much more difficult than it sounds as all code must be written in such a way to prevent the compiler from calling the runtime allocator (no variables allowed to escape to the heap).
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.)
Bikeshedding, we can also start discussing why `println` doesn't print anything on the printer, apple doesn't sell any fruits and their ipad is not really targeted to women during period, microsoft has no double glazed windows offers, oracle without cloud based prophecy api and why ml lang and machine learning are stealing established, widely deployed in most kitchens millilitres measure - nobody gives a crap.
println does indeed print if you're using a teletype. The fact that you're probably not using a teletype is simply a matter of preference on your part.
Teletype current loop ports were common on machines up to the 1970s, but by the 1980s had largely disappeared. The serial port card on the original IBM PC and the XT had 20mA current loop support, but it was very rarely used, so AT machines onward removed it. (MIDI is also a current loop, but MIDI uses 5mA rather than 20mA, plus the protocol is different.)
You should be able to connect a teletype to a modern computer by using two conversion devices, one USB-to-RS232 and the other RS232-to-20mA-current-loop. Then the teletype will appear to the computer as a (very dumb) serial terminal.
The subsummation of the word 'Gopher' into the Go language eco-sphere irritates me also. I believe it has something to do with the Language having adopted the Gopher (animal) as their mascot?
Just because something is no longer in common/widespread use, does not mean you can come along and use its meaning or name on your shiny new product.
Gopher the protocol maybe niche these days, but it's not dead. The continued use of the term 'Gopher-XYZ' by the Go language people will only accelerate the death of the Gopher protocol, which although inevitable it does not mean it should be erased from history by something else.
There a tons of name conflicts for things that are more popular than the gopher protocol. If the creators wanted to avoid this they need to pick a unique name.
My pet peeve is Atom the protocol and Atom the text editor. They're obscuring a format and a protocol that's much more important for the web than another text editor is, and they're doing the world a disfavor as a result.
Even worse is when Justin Timberlake did that song "Cry Me A River", when there was already an excellent song by the same name. It just obscures the existing song, and does the world a disservice.
Pretty rude way to disagree with someone. I'd appreciate any criticism, but not sure what I'm supposed to do with this comment, other than feeling bad.
> Just because something is no longer in common/widespread use, does not mean you can come along and use its meaning or name on your shiny new product.
I get that each time a "ML" link is posted here. Sadly it's almost never about the various successors of Miranda.
And also a 2500+ year old Chinese board game, generally referred to in English by its Japanese name (Go). Although the ambiguity of the name is beginning to popularize its Korean name, baduk (as in /r/baduk)
This is a common misconception. The GOPHER protocol (RFC 1436) does not actually require the use of opposable thumbs, it's just a common implementation detail to do so.
The entire runtime does not depend on the OS. C's run-time is very minimal for exaple. You have a stack memory, heap etc that you setup in protected mode. Your OS will manage the page-tables, process creation etc.
"Go" binary will basically compile into machine code which can be run on bare-metal.
I advise you to read Project Oberon from Niklaus Wirth, originally published in 1992, revised in 2013 for targeting a FPGA instead of the Ceres workstation that was used at Zurich Institute of Technology (ETHZ) during the 90's.
A complete graphical workstation OS used by the IT department for their OS programming classes, language design and even by the non technical personal at the department.
Well, the Go runtime is written in Go itself. And you can write Go without the runtime, the same way the compiler is.
The hard part is that the runtime is indeed build on OS primitives (syscall mostly), that you have to implement yourself.
You have to forgo all the niceties of having a runtime but you can do it. Definitely not the most productive use of Go, but it's fun and you learn a lot.
That's a bit of a stretch. The runtime uses special pragmas that are not available to normal programs. I don't think it would be possible to write Go's GC in Go unless these special pragmas existed:
There is already a compiler that knows those special pragmas, one just needs to add a new bare-metal backed to it.
As for writing Go without a GC, just like in any other GC enabled systems programming language, by not using language features that require GC in the lowest layer, which the other packages then depend on.
On the lowest levels only. The rest of the OS can be GC'd. See Oberon, JX OS, and House in Haskell for instance. That Go has a low-latency GC makes it even better for that usage.
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.
What's all this voodoo inside Makefile, I would love more comments in there. I think that would be the first step for anyone wanting to contribute, to understand the Makefile.
@echo "[go] compiling go sources into a standalone .o file"
@GOARCH=$(GOARCH) GOOS=$(GOOS) go build -n 2>&1 | sed \
-e "1s|^|set -e\n|" \
-e "1s|^|export GOOS=$(GOOS)\n|" \
-e "1s|^|export GOARCH=$(GOARCH)\n|" \
-e "1s|^|WORK='$(BUILD_ABS_DIR)'\n|" \
-e "1s|^|alias pack='go tool pack'\n|" \
-e "/^mv/d" \
-e "s|-extld|-tmpdir='$(BUILD_ABS_DIR)' -linkmode=external -extldflags='-nostartfiles -nodefaultlibs -nostdlib -r' -extld|g" \
| sh 2>&1 | sed -e "s/^/ | /g"
edit I think I understand what's happening here, funny how writing it down helps one understand. It's just building up a build script with sed and executing it. The thing was I didn't know sed could do that. TIL
This seems to be in very early development with the first commits in late March and a single line readme. Interested to see where it goes and what problems they encounter.
I've never really understood OS:es. Why are so many people creating them, yet so few have any success? I've must have seen a dozen OS:es over the past two years on HN, most developed by people having no confidence in calling it a serious effort.
Why care about OS:es when there is no room for anyone on that level of abstraction apart from a handful developers at MS, Apple and Google?
Hey, good luck with it! I'm thinking maybe I'm just wired differently. If I have a side project or hobby I still want to feel maybe not success but a sense of completion.
An OS project I suspect will always end when you no longer have time for it or are stuck somewhere. I'd be annoyed by that.
Your reply, while I'm sure it is genuine, couldn't be more on-point by being more wrong.
You really don't know, and cannot know, where the next Linux is going to come from. I don't know if this will be it, just by considering probabilities, it probably won't be, but it could.
Even at the worst case, the author of a project like this is going to learn A LOT from it, and the people who read through the source code are also going to learn a lot. Writing an OS in a higher-level language absolutely is beneficial to people who want to learn more about how hardware works and interacts with the OS, without needing to delve into something as complex as the Linux/BSD kernels.
At a minimum, I think projects like this directly create contributions to other "real" kernels by teaching developers how to do kernel/OS programming.
If you think of an OS as solely something that sits on your desktop, then sure, but this is fairly myopic (and defeatist). There are lots of small, proprietary and often embedded operating systems that rely on the same principles established by present and past OS.
Writing operating systems is also a great way/introduction to work on operating systems, and it's a fairly distinct area of development. It's hard to get day-to-day overlap if you're working on things that don't have the constraints and operating system does.
The reasons aren't so different from the reasons for writing any other software.
1. Even if the project never replaces the other software you use, you gain a better understanding of that other software by solving some of the same problems, making the same mistakes, learning the same lessons.
2. You may have special requirements that don't make sense to add to an existing project aimed at a broader audience. This is where a lot of niche microcontroller OSes come from.
3. You have a crazy idea that would be hard to explore within the architecture of an existing project. If it turns out to be crazy enough to work, then maybe people will do the work to migrate it to the mainstream.
4. Everyone has a little dream that the masses will find great value in their work and flock to it, supplanting the status quo. Like becoming a billionaire, it essentially never happens, but you can't blame people for trying.
ever heard of fun? or learning? not everything needs to have the potential for monetization to be worthwhile; it can just be interesting. this is actually something that has been difficult for me to internalize, but i am much happier for it. no less ambitious, but i've found that there are a lot of nice (pointless) things that contribute to my happiness in addition to success.
Operating systems' success is fundamentally based on their popularity. Popularity resembles an exponential distribution, therefore there can only be a small number of popular ones with a long long tail of less and less popular ones. Here, popularity is a positive feedback loop, where the more popular it is the more developers target it, and the more it's targeted the more it's developed internally, which makes it better and therefore more popular.
That doesn't mean it's useless to develop them. If you set your sights low (playing around, learning, academic) you can still benefit from them without them being a huge success by popularity standards.
If you take a look at the Go runtime sources you will notice that all the low-level arch/os-related bits have been split into separate files which usually invoke some syscalls (e.g. the memory allocator eventually calls mmap)
The idea I am currently investigating is to first provide an implementation for things such as physical memory allocation and virtual memory mapping which would ultimately allow me to bootstrap the Go allocator. From that point onwards the plan is to incrementally add more features and gradually initialize the rest of the runtime.
This is much more difficult than it sounds as all code must be written in such a way to prevent the compiler from calling the runtime allocator (no variables allowed to escape to the heap).