71–80 of 84 posts
Maybe I'm old, but I immediately assumed this was an OS built around the Gopher-protocol[1], whatever that would mean in practice. Gopher is already an established name, so the naming seems a bit unfortunate. [1] https://en.m.wikipedia.org/wiki/Gopher_(protocol)
Earlier quoted context omitted.
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.
nit: 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.
Earlier quoted context omitted.
nit: 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.
Out of sheer curiosity, what would it take to hook up a real teletype to my computer today? What physical port would it even use?
https://en.wikipedia.org/wiki/Digital_current_loop_interface
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.
I don't know anything about OS development, but how do you implement an OS in a language whose runtime depends on an OS?
Type safety. 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. https://people.inf.ethz.ch/wirth/ProjectOberon/index.html http://www.ocp.inf.ethz.ch/wiki/Documentation/Front A complete graphical workstation OS used by the IT department for the…
Earlier quoted context omitted.
Type safety. 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. https://people.inf.ethz.ch/wirth/ProjectOberon/index.html http://www.ocp.inf.ethz.ch/wiki/Documentation/Front A complete graphical workstation OS used by the IT department for the…
What does this have to do with the runtime of a specific language depending on an OS?
Runtimes are a portable OS, that just by convince and practicability reasons happen to run on top of an existing OS.
That is the whole premise of Unikernels, to go back to the days when the language runtime was the OS, like on the Xerox environments.
Earlier quoted context omitted.
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 u…
There were many similar complaints when the Go language itself was announced, there already being a programming language named "Go!"
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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, y…
Could you instead write your own syscalls but also your own $GOOS target for the compiler? That's possibly more work but it's the approach I would have taken as it seems more fun than just replicating Linux (or whatever) syscalls.
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.)
Earlier quoted context omitted.
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…
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 d…