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)
The worst part about the GOPHER protocol is that actual Gophers couldn't even use it, because they don't have opposable thumbs!
Yet another instance of the programmer establishment thinking they know what's best for everyone...
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)
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…
> 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.
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)
Even worse, there's already an animal called a Gopher! Oh the confusion... /s
Is Go suitable for OS/Systems development? Inline Assembly would be nice to have. I'm guessing a project like this will need to implement the Go runtime given that (I'm assuming) it uses posix (Or windows etc.) system calls.
Go has an assembler, but its goal is not to build, say, a bootloader:
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 investi…
Your project reminds me that I wish GOOS=efi to be a thing.
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.
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?
Having no confidence in the project is part of the path to success "I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu)"
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.
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?
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)
The worst part about the GOPHER protocol is that actual Gophers couldn't even use it, because they don't have opposable thumbs! Yet another instance of the programmer establishment thinking they know what's best for everyone...
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.
Having no confidence in the project is part of the path to success "I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu)"
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.
@skocznymroczny was actually quoting a post from Linus Torvalds when he first released Linux.