Hacker News new | past | comments | ask | show | jobs | submit
login

       Why Is Gopher Still Relevant? (floodgap.com)
       119 points by pointfree on Mar 13, 2017 | hide | past | web |
favorite | 95 comments




pointfree on Mar 13, 2017 [-]

The web is like an operating system that you are locked into using. This
prevents alternative operating systems such as Plan 9 from ever becoming
useful, because building a web browser is such a monumental effort. Even
if a decent web browser were built for Plan 9 it would defeat the purpose
of using such an alternative OS because the web binds software to content.

The web has effectively killed innovation in operating systems. A clean
and consistent system will be out of reach as long as this web app
nonsense continues.



glangdale on Mar 13, 2017 [-]

I think this is the wrong way around; Plan 9 prevented itself from
becoming useful by changing everything so thoroughly that building an
actual web browser was pretty much impossible. It was more or less
guaranteed that APE (The "ANSI Posix Environment") would die from neglect.
This neglect seemed intentional and people seemed happy to run plain white
windows with black borders and congratulate themselves that their system
neither had nor needed the massive shared libraries that Unixen of the
time seemed to need.

The lesson seems to be, rather - don't build an operating system that
can't build up enough infrastructure to run a browser. This is maybe less
forbidding than, say, being forced to build an operating system that can
support an entire Windows subsystem.

I have trouble understanding what it is that people want when they say
they want "innovation" in operating systems. It seems like almost anything
that was practical to do in the period when I worked with Plan 9 is now
eminently practical and far more performant in user space; so why not go
build it on top of a minimal Linux kernel and save yourself the trouble of
building a gazillion drivers, boot loaders, etc.



7373737373 on Mar 13, 2017 [-]

Web desktops may be the next step. As much as people are joking about
running Javascript on metal, the idea of running a universally accepted
virtual machine (WebAssembly?) and building a high level language and
operating system on top of it seems to have some merit. See also

https://en.wikipedia.org/wiki/Inferno_(operating_system)

http://urbit.org/docs/

https://en.wikipedia.org/wiki/Web_desktop



digi_owl on Mar 13, 2017 [-]

http://www.windows93.net/



beaconstudios on Mar 13, 2017 [-]

the idea of a web desktop doesn't make sense when we have services like
google docs and dropbox that perform the roles of the desktop without the
overhead of installing software. The desktop was a forced requirement
while content had to be centralised on your PC, why bother with it now
that we're freed from that constraint?



TeMPOraL on Mar 13, 2017 [-]

> The desktop was a forced requirement while content had to be centralised
on your PC, why bother with it now that we're freed from that constraint?

Because some of us want content to be centralized on our PCs. We want to
own our data, instead of giving it away and then renting back access to
it. Related, I consider the push towards abstracting away the file system
to be a very bad thing.



beaconstudios on Mar 13, 2017 [-]

I agree with you completely, especially given all the revelations that
have come out about dragnet surveillance, but the OP was talking about web
desktops specifically.



7373737373 on Mar 14, 2017 [-]

It's all about namespaces. You can access local files the same way you
access web resources and vice versa.



oblio on Mar 13, 2017 [-]

Have you ever thought about the fact that most people don't like
innovation and don't need it? They want and need well tested incremental
updates to proven technologies.

There is still innovation happening in operating systems, it just doesn't
reach mass adoption because most of it doesn't provide real-life benefits
to the mass market. Some of the more practical aspects trickle down to
mainstream OSes.

We're past the Wild West stage of operating systems. You win some, you
lose some.



dredmorbius on Mar 14, 2017 [-]

http://heinonline.org/hol-cgi-bin/get_pdf.cgi?handle=hein.jo...

This is the paper Isaac Asimov researched as an undergrad, and was the
basis of his first sci-fi story sold.

There's a lot of material on this topic.

https://duckduckgo.com/?q=resistance+to+technological+innova...



lifthrasiir on Mar 13, 2017 [-]

In my view the web is a very successful demonstration of language-based
security in the OS. It's quite natural that the web has essentially became
a full-featured (and half-baked) operating system because it has to handle
everything in order to keep the language-based security and relevance.
Therefore I would argue that the innovation in operating systems has not
been killed---it has been shifted to the different realm.



digi_owl on Mar 13, 2017 [-]

The web, at least the part most people interact with, is more like a
throwback to leased terminals.

The real computation happen on a far away pile of hardware, with the local
computer just being responsible for drawing the updates on screen based on
the results coming over the wire.



foota on Mar 13, 2017 [-]

I disagree, while writing a web browser would be significant work, it
would likely be on the same order as writing an operating functional
enough for people to actually want to use it. Porting a browser would
likely take less work even (while still being a significant amount of
work).

This page talks about what it takes to port webkit to another platform:
http://blog.cranksoftware.com/webkit-porting-tips-the-good-t...



stonogo on Mar 13, 2017 [-]

Forgive me, but you should more specifically define the terms you use. As
it stands, it looks like by "functional enough for people to actually want
to use it" you seem to introduce a circular dependency -- as though an OS
is useless unless it's easy to port a browser to it.

The GP post mentiones Plan 9, which is a great example here. There are
real people who use Plan 9 every day (I have met some of them!) but Webkit
will never be portable to that OS because there is no C++ compiler. This
doesn't make the OS non-functional, but it does mean step one to porting a
modern browser is "port GCC or LLVM," which is a massive task by itself.

Both Firefox and Chrome source code repositories are in the hundreds of
megabytes, even without the required host OS dependencies vendored in. The
document you linked to recommends leveraging freetype, cairo, and all
kinds of other things that would require serious graphics infrastructure
of a sort that's just not feasible.

Modern web browsers are keystones that cap off arches built of hundreds of
pieces of very specific software. As time goes by, they require more
infrastructure, not less -- c.f. Firefox, where to build the latest
version you must also have a Rust compiler that targets your operating
system. As the checklist of requirements grows ever longer, the candidate
operating systems capable of meeting those requirements grows ever
shorter.

Five years from now, I predict the only three operating systems capable of
interacting with the web in any meaningful sense will be linux, macos, and
windows; bsd and haiku et al will have been left by the wayside.

Ten years from now I predict there will be four operating systems, and one
of them will be Fuchsia, because only a megacorp like Google has the
resources to accomplish that.



clarry on Mar 13, 2017 [-]

> Five years from now, I predict the only three operating systems capable
of interacting with the web in any meaningful sense will be linux, macos,
and windows; bsd and haiku et al will have been left by the wayside.

That is an interesting prediction. What do you think will cause the BSDs
to be left by the wayside in such a short timeframe, when they are more
than capable of running the latest browsers right now?

Is the browser becoming a systemd module?

I am a little concerned about the trend to push "hardware acceleration"
into everything. Graphics cards and their drivers are the biggest source
of grief in PCs for me.



buzzybee on Mar 13, 2017 [-]

One intriguing direction we could take is for someone to make a
self-hosting browser. Doing that would mean taking all these technology
dependencies and moving as many as possible into wasm, until you're just
left with the kernel, a "barebones" wasm runtime, and a browser binary. I
think that is within the reach of one of the big-leaguers, albeit
ambitious and full of "interesting" problems and standards that will have
to be broken.



rhabarba on Mar 13, 2017 [-]

Don't forget that browsers like Netsurf might well be enough for your
daily surfing.



adrianN on Mar 13, 2017 [-]

I'm no expert, but I believe the difficulty in writing an OS lies with the
myriad of different hardware configurations you have to support. Writing
drivers for poorly documented hardware is difficult. You don't get around
that complexity by writing a browser. That's just an additional effort you
have to make.



pointfree on Mar 13, 2017 [-]

Sure you could port webkit to your new OS, but if all the software you use
effectively exists only as web apps what would be the point?



anw on Mar 13, 2017 [-]

The point seems to be you could now use any system you wanted (as long as
there is a compliant browser) and not worry if your needed app is
supported or has all the features of the Windows/OSX version.

This lets you take advantage of whatever benefits your desired system
provides you without a change of user experience.



foota on Mar 13, 2017 [-]

I think I understand your argument now. Why do you think browsers as de
factor operating systems is wrong? Their programming interface is highly
standardized across implementations.



pointfree on Mar 13, 2017 [-]

> Their programming interface is highly standardized across
implementations.

It may be easier to have everyone use the same software and hardware
platform everywhere. After all we do want interoperability and we do want
everyone to play well with others, but, standardization and portability is
a push to stop people from trying new things. The push to standardize
everything is an unfortunate consequence of not having a separation of
concerns, separate concerns such as content and UI.



TeMPOraL on Mar 13, 2017 [-]

Not sure what you mean by standardization vs. exploratory programming.
Separation of concerns would only exist if standardized (and enforced).



pointfree on Mar 13, 2017 [-]

A smaller contact area between implementations means we need only be
concerned about compatibility at that interface and the rest is up to you.
This keeps the area of software that we can't change to a minimum.



simonh on Mar 13, 2017 [-]

> A clean and consistent system will be out of reach as long as this web
app nonsense continues.

Isn't that exactly what iOS and Android are though? I mean most of the
criticisms of iOS are against Apple's obsessive curation of it's
simplicity and usability, and it 'came to power' smack in the middle of
the internet age. People are always complaining that native apps for
internet services are a threat to the web. It seems to be exactly the
thing you're saying the web makes impossible.



digi_owl on Mar 13, 2017 [-]

Dunno. Initially iPhone was not supposed to have apps at all.

Apple even release a web framework for making sites that looked and
behaved as if it was native to iPhone.

Only after the jailbreakers enabled third parties to fool around with the
guts did we see apps happen. And initially Jobs wants to sue those app
devs and distributors into oblivion.



huxley on Mar 13, 2017 [-]

I wish that myth would die.

Yes, Jobs did a song-and-dance about web apps but not because they didn't
want 3rd party apps but because Apple wasn't ready to support developers
on what was a new platform. Apple plays it safe.

For one, it's not consistent with the timeline and secondly as the
jailbreakers discovered there was quite a bit of infrastructure to support
apps even in iPhone OS 1.0.

* iPhone release date: June 29, 2007

* iOS SDK Announced: October 17, 2007

* iOS SDK Released: March 6, 2008

* iPhone OS 2.0 release date: July 11, 2008

Apple had such a tough time providing enough support to developers that
they restricted access to the paid developer program to just 4000 (Apple
said 25000 tried to join).

There wasn't enough time for everything to happen (including relatively
sophisticated tools like the iPhone Simulator) if it was just a reaction
to jailbreaking.



simonh on Mar 13, 2017 [-]

Furthermore, the OS itself was initially developed for tablet computers,
so apps would have been crucial. Adapting it to a Phone platform with a
more limited initial scope was a fairly late stage pivot.



pnathan on Mar 13, 2017 [-]

The web is a bad reinvention of distributed RPCs on desktop systems, imo.



rimliu on Mar 13, 2017 [-]

You mean web apps? Because the web itself was fine till everyone started
thinking that anything on the web must be an application. And that web
must "win" mobile for some reason.



oblio on Mar 13, 2017 [-]

You'll understand that "some reason" when you'll want some cool, fancy,
useful app and the vendor will have not developed a version for your
current mobile OS.



TeMPOraL on Mar 13, 2017 [-]

Few of web apps are useful, though, and all suffer severe performance and
UX penalty by the very virtue of being run within a browser.



oblio on Mar 13, 2017 [-]

Few of any kind of apps are useful.

The non-purists (which is most people) have decided that availability
trumps everything.

I was more of a purist, myself, but after some bad experiences with the
lack of native apps, I'm more of a realist these days.



pnathan on Mar 13, 2017 [-]

Web apps have been the default approach for over a decade now. The O.G.
vision of the web / netscape was to have a virtual OS, platform
independent. I think it's time to lay the idea of the webapp as somehow
being this alien thing to rest...



rhabarba on Mar 13, 2017 [-]

The web is a broken and incomplete adaption of Xanadu.



simonh on Mar 13, 2017 [-]

Xanadu is a broken and incomplete implementation of Xanadu, and has been
for more than my entire lifespan (child of the 60s baby!).



rhabarba on Mar 13, 2017 [-]

Which is not enough reason to prefer an implementation which dropped
Xanadu's probably most important feature (two-side links) from the
beginning.



dredmorbius on Mar 14, 2017 [-]

I blame the person from Porlock.



AckSyn on Mar 13, 2017 [-]

There's the web, then there are tons of other protocols out there to use
on the Internet. And browsing using lynx/links/elinks is quite possible.



jlebrech on Mar 13, 2017 [-]

compile a linux desktop to the web (webassembler/jslinux), style your gui
to look like your brand, users are logged into x11/wayland as guest by
default. logging in looks like you're on a website but in fact you're in a
linux session. you code your apps in gtk/kde (whatever) and html/xml (or
something more sane) is only used for the layout of those apps.



TheLugal on Mar 13, 2017 [-]

Gopher might not be popular, and apparently it's relevancy is disputed.
But it is still an interesting bit of internet-history. It still has an
active community, and a whole lot of information.

There's also a slow movement to add gopherholes to the tor network. A list
of the current known ones can be found here;
http://gopher.floodgap.com/gopher/gw?gopher://bitreich.org:7...



olavk on Mar 13, 2017 [-]

I don't get this. It seems to me Gopher basically supports a subset of
what is available on the web. All the benefits of Gopher (low bandwidth
requirements, no flashy design or interactivity, strict hierarchical
navigation etc.) can also be achieved with stripped-down web pages. I see
no benefit at all to having a separate protocol.

Gopher is cool as a slice of history though.



lmm on Mar 13, 2017 [-]

You can't be confident of getting a stripped-down web page before you
click the link. Trivial example: I can click a gopher link and be
confident whatever's on the other end is not going to make a noise.

Human vigilance is fallible. Protocol-level enforcement is necessary.



kgwxd on Mar 13, 2017 [-]

I've been thinking about making a site that only takes links to text/plain
and other non-mixed-media content. I haven't been able to find one if it
exists. I'd also love search engines to support media type filters.



olavk on Mar 13, 2017 [-]

Are you suggesting there are some people who only browse Gopher?



lmm on Mar 14, 2017 [-]

There are people who prefer Gopher and/or particular known sites. If you
can see from the URL that a site will be non-horribly designed then that's
fine, and if the only option is HTTP then you put up with it.



NoGravitas on Mar 13, 2017 [-]

You could use a stripped-down client. There are currently compatibility
problems (with using Lynx, elinks, dillo, etc), but most of those are
probably surmountable. I can easily imagine a browser that guarantees
either a reader-mode/AMP-like experience or a graceful failure.



rikkus on Mar 13, 2017 [-]

"All the benefits of Gopher [...] can also be achieved with stripped-down
web pages"

Can be achieved, but aren't. I'd love a consistent, stripped-down
interface. The web doesn't give me this (it doesn't matter if it _could_).



simonh on Mar 13, 2017 [-]

As a client you have no control over this though, because you can't make
people provide services using Gopher instead of HTTP.

To put it another way, for someone wanting to provide a service it's daft
to choose Gopher 'because it's lightweight'. If you're providing the
service, nobody can stop you providing a lightweight HTTP service and in
fact doing so is mind numbingly easy. Just do it.

Or provide a URL link to an FTP server. Gopher was basically just a nicer
to use menu based alternative to ftp, but visual browser ftp clients are
pretty much that now anyway.

Having said all that, it is kind of cool that Gopher is still around. I
was using it years before HTTP even existed. If Gopher is going to exits
then yes, being lightweight is one of it's strengths, but pretending that
this meaningfully distinguishes it from HTTP doesn't strike me as a very
strong argument. I suspect a lot of it's attraction is techie cultural
exclusivity and contrariness. Not that I have anything against those
things whatsoever.



ramblerman on Mar 13, 2017 [-]

> The web doesn't give me this (it doesn't matter if it _could_).

If it was important then the web would cater to it. It's simple economics.

We could create protocols for all the sub needs and desires that people
may have but that would be restrictive.



sp332 on Mar 13, 2017 [-]

The market can stay irrational longer than you can stay sane on
autoplaying video ad-covered sites.



mjburgess on Mar 13, 2017 [-]

Popularity =/= Economic Viability =/= Importance.

The market is NOT a mechanism for delivering what is important.



dredmorbius on Mar 14, 2017 [-]

Gresham's law, market for lemons.



amiga-workbench on Mar 13, 2017 [-]

It stops designers and developers from being "clever" The user gets pages
that are highly accessible, straight to the point and free from javascript
malware.



olavk on Mar 13, 2017 [-]

Not at all, you can do lots of "clever" things in plaintext, like
ASCII-art or aligning table columns with whitespace. This is much less
accessible and adaptive compared to semantic HTML.

No protocol will prevent people doing fun and clever things or produce
content which you think is useless.



digi_owl on Mar 13, 2017 [-]

The big thing, as best i can tell, is that gopher is built around exposing
a FHS and letting the user browse it rather than mask the FHS behind urls
and links inside the documents themselves.

Gopher as a protocol can serve up any odd file format, HTML included, if
one so wants.



rhabarba on Mar 13, 2017 [-]

Gopher comes without the multimedia annoyances of the over-engineered Web
and it "lacks" people whose business model is to be on it. I like to
browse Gopher every now and then. Several people I know even export
read-only versions of their blog to Gopher.

I planned to write a new Gopher app for Android a while ago but I haven't
finished it yet. This article reminds me to try again. Thanks.



spc476 on Mar 13, 2017 [-]

I "ported" my blog to gopher as well (gopher://gopher.conman.org/) but
it's not a clean port. The gopher client I use (an extension to Firefox)
is not UTF-8 aware and thus there are character set issues. Also, there's
some loss from the conversion of HTML to plain text (compare
gopher://gopher.conman.org/0Phlog:2017/02/27.1 with
http://boston.conman.org/2017/02/27.1).

But it wasn't that difficult to do. And yes, I do see a few people hitting
the gopher site.



draven on Mar 13, 2017 [-]

I just tested your blog with OverbiteFF (I guess that's the client you're
using), and I had to manually switch the encoding to Unicode (View->Text
Encoding.) I see there's an "item type" field in the protocol, it's set to
0 (ie "plain text file") for your blog entries. The protocol doesn't seem
to offer anything to specify the encoding to the client, so overbite must
default to something like plain ascii.



NoGravitas on Mar 13, 2017 [-]

Is there an existing gopher client for Android? I couldn't find one on the
Play store, but that could be because of search problems.



rhabarba on Mar 13, 2017 [-]

Yes, the Floodgap guy has its own Android client available on his website.
Sadly, it follows the design conventions from Android 1.5 or so.

http://gopher.floodgap.com/overbite/



rfurmani on Mar 13, 2017 [-]

Oh wow, that's a blast to the path. The author also wrote the bucktooth
gopher server, and I implemented a new (semi-OO Perl) version of it that
supported Gopher+.

There was always something very satisfying about Gopher, how it made
explicit the structure and categories of the data, leaving the front-end
to present it how it pleased.



quanticle on Mar 13, 2017 [-]

I would also note that others may find the name Cameron Kaiser familiar
because he's the maintainer of the TenFourFox (Firefox for PPC OSX [1] )
and Classilla (Mozilla for OS9 [2]) projects.

[1]: http://www.floodgap.com/software/tenfourfox/ [2]:
http://www.floodgap.com/software/classilla/



zaphos on Mar 13, 2017 [-]

I had no idea what Gopher was and looked it up to understand; this article
was helpful:
https://arstechnica.com/tech-policy/2009/11/the-web-may-have...



rev_null on Mar 13, 2017 [-]

Gopher is way more friendly for the visually impaired than the modern web.



Symbiote on Mar 13, 2017 [-]

That claim needs some evidence. Is there a good example? All the sites I
can find are either toys or archives of university sites from the 1990s.

From those sites:

There is a lot of completely inaccessible ASCII art.

Everything is shown in a plain monospaced font, including tabular data.
Emphasis can only be done using asterisks, capital letters or similar.

Images can't be embedded with context, only linked to -- at the end of the
document.

Links can't be shown in context, only at the end of a document.

Only ASCII text works.



robin_reala on Mar 13, 2017 [-]

If by friendly you mean ‘irrelevant’. There’s plenty of easy things
that developers can do to their sites to make them more accessible that
don’t require rewriting them as a gopher site.



rev_null on Mar 13, 2017 [-]

Yes. There are things that developers could do to make most web sites
better for the visually impaired. But that doesn't mean that most web
developers use, or even recognize, these best practices.

Gopher, on the other hand, simply only supports textual navigation that is
easy to feed to a text-to-speech engine. The developer doesn't need to
even think about these issues.



robin_reala on Mar 13, 2017 [-]

Right, but text-to-speech is only half of the problem. Gopher by default
just uses plain text with no semantics. Without marking up those documents
there’s no way to let users jump around within them. Do you honestly
expect a visually impaired user to sit and wait while each document they
go to is read out to them in its entirety with no heading structure or
ability to navigate within the content?



rev_null on Mar 13, 2017 [-]

I think that argument worked well for the original web. But the HTML spec
has accumulated a lot of things to make design easier, but they also make
it easier to represent a page without useful semantic structure.

You mentioned tables, but there were many years where people were using
tables in HTML for formatting instead of just expressing tabular data. So
div tags were added. Now people sometimes use divs to represent tabular
data.

Search is a pretty good way to navigate content, and is simple for raw
text. An index is an even better way, and is supported quite well by
gopher.



robin_reala on Mar 13, 2017 [-]

people were using tables in HTML for formatting instead of just expressing
tabular data

Yep, and there are algorithms that try to distinguish between ‘data’
tables versus ‘layout’ tables for precisely that reason[1][2]. It’s
unfortunate that they have to exist, but the web has routed around past
mistakes.

Now people sometimes use divs to represent tabular data.

Yes, and that’s wrong and a simple fix. But regardless of whether some
ill-informed people do that it’s still no worse than Gopher, and when
they get it right it’s a lot better.

Regarding search, that’s great if you have exact keywords for what
you’re looking for. Less good if you just want e.g. a list of headers on
the page so that you can narrow in on the part that interests you.

[1] https://dxr.mozilla.org/mozilla-central/source/accessible/ht...

[2] https://cs.chromium.org/chromium/src/third_party/WebKit/Sour...



adiabatty on Mar 14, 2017 [-]

> Search is a pretty good way to navigate content, and is simple for raw
text.

Gamefaqs hosts plain-text documents. Some of them are quite long and
well-structured. Since there's no intra-document linking like with HTML,
newer documents tend to have hashtags in the TOC to make Ctrl-F searching
easier.

I'd much rather have intra-document links I can click on. That way, as a
document author, I can direct readers to the dedicated "All The Monsters
You'll Ever Fight" section from anywhere in the document without adding
the string "#monsters" all throughout the document, generating false
positives for the Ctrl-F-using reader.



Johnny_Brahms on Mar 13, 2017 [-]

I think you misunderstood his/her comment. The flexibility that the modern
web makes available makes accessibility tools:

 1. harder to implement
 2. More error prone.

Implementing accessibility software for gopher would be a breeze in
comparison.

I myself am quite an old grumpy fart, but I would prefer to browse most
web sites as gopher sites. I stumble on way too many sites that would have
been more usable to everyone had they just skipped those extra 800kb and
kept their page below 30kb.



jancsika on Mar 13, 2017 [-]

Let's take a trivial example:
https://en.wikipedia.org/wiki/List_of_open-source_mobile_pho...

Let's say we are both on an unreliable wifi connection (perhaps on a
train) and want to find the most recently-released entry in the table.
Then we want to sort the data by each of the other columns of the table.

I click a heading and navigate to the bottom row of the table and see
2016. Done. Then, whenever I am ready I click each of the other four
headings to sort the data again. This exhausts the effort I need to expend
in order to get sorted views of the same data. And no network access was
required to do this (which is nice for non-trivial table sizes).

With Gopher, what user actions are needed to get the same views of the
data? How much effort do these user actions require?

Edit: also, are those user actions discoverable? At least visually
Wikipedia's table gives me two arrows and a cursor icon change to make it
apparent I can click to change the view of the data. As far as
accessibility, there is a "title" attribute with the value "Sort
ascending" that I presume would get read by a screen-reader.



jankotek on Mar 13, 2017 [-]

At the time of Facebook, the question should be: Is the web still
relevant?



beaconstudios on Mar 13, 2017 [-]

I'm sure people were asking that when web portals like go.com were
becoming dominant, and they'll be asking it long after facebook is dead.



digi_owl on Mar 13, 2017 [-]

On that note, i seem to recall reading that Fidonet is still being
maintained.



mydeardiary on Mar 14, 2017 [-]

Gopher doesn't support encryption. There is no standard for gopher over
tls. This makes gopher irrelevant for encrypted communications. But what
makes it great: gopher is simple. You can use curl or even netcat for
browsing gopher sites.



hasa on Mar 13, 2017 [-]

I used Gopher 1993 in university, but I don't see it relevant today. It's
history.



kzrdude on Mar 13, 2017 [-]

Your experience with it is not very recent, then, so it's maybe best to
listen to others. :)



jankotek on Mar 13, 2017 [-]

1998



nvarsj on Mar 13, 2017 [-]

This made me laugh: gopher://gopher.frog.tips/0/JOB_OPENINGS



Entangled on Mar 13, 2017 [-]

Browsers won't process that request, so for the uninitiated like me:

$ curl gopher://gopher.frog.tips/0/JOB_OPENINGS

* My first ever gopher interaction.



NoGravitas on Mar 13, 2017 [-]

Or: http://gopher.floodgap.com/gopher/gw?gopher://gopher.frog.ti...



basscomm on Mar 13, 2017 [-]

I'm using Lynx, which understood that request just fine.



noahlt on Mar 13, 2017 [-]

It's not.



pointfree on Mar 13, 2017 [-]

The author didn't say "popular" he said "relevant"

The current state of software development has huge issues with needless
complexity resulting from poorly chosen abstractions.

Gopher and IRC make it possible to use any client of your choosing, thus
keeping innovation and improvements accessible to anyone with an idea.



lifthrasiir on Mar 13, 2017 [-]

> Gopher and IRC make it possible to use any client of your choosing, thus
keeping innovation and improvements accessible to anyone with an idea.

I agree to the former and disagree to the latter---they are not
correlated. In fact, IRC has demonstrated that it might be hard to adapt
to new requirements without breaking many things (no matter it's an
existing client, a community or a requirement itself). Today the relevance
of IRC is mostly due to the existing community and not due to the
technical innovation, and casual users wouldn't benefit from that. I don't
know much about Gopher but I haven't seen any counterevidence to this
observation.



rhabarba on Mar 13, 2017 [-]

The new(ish) IRCv3 standard does not break compatibility with existing
clients though. If they don't support all of its features, they just have
less things displayed.



lifthrasiir on Mar 13, 2017 [-]

I know IRCv3 is in progress, and I wish it to be successful, but frankly
speaking this has been done 10 years ago.



rhabarba on Mar 13, 2017 [-]

Some of the more recent IRC clients already support most its new features,
including v3.1.



shultays on Mar 13, 2017 [-]

I don't get why this is getting down voted.

I heard gopher before but never used it. I have two browsers (firefox and
chrome) and gopher links failed on both. So I checked wikipedia:

https://en.wikipedia.org/wiki/Gopher_(protocol)#Native_Gophe...

And it is not supported in any of 4 most commonly used browser (except
there is an add-on for firefox, you can write an add-on for anything
anyway). (Edit: 5 actually, I forgot about Safari)

So yeah, Gohper is not relevant now.



aw3c2 on Mar 13, 2017 [-]

Relevancy is a measure of subjective scope. Things that are relevant to
some might be irrelevant to others. Gopher might not be relevant to
society as a whole but to a subset of hackers (hi!). Parent's comment is
effortless snark so it deserves any downvote it acquires.



kodfodrasz on Mar 13, 2017 [-]

Something relevant to a negligible minority is usually expressed as: not
relevant. Relevancy is not totally subjective, as we don't live alone in
basements, but in a society. Something relevant for the most of the/a
society is relevant. Other stuff is called niche, irrelevant, because it
has no effect on the life of the society.

Nuclear physics interests a handful of people only, yet it is relevant, as
society would have problems sustaining its operation without nuclear
power. Gopher is interesting for even less people, and it is irrelevant,
as society would go on just as well without it.

Low processing power need? A 10$ Raspberry Pi packs more power than the
notebook I saved for 10 years ago.

A link to all known gopher servers? It is, in gopher protocol, which I
cannot check as none of my browsers support this. This is what is your
definition to relevancy is? Because it is not mine.

A webpage written in Nepali is infinitely more relevant to most users, as
they can access it, and use everyday tools (like google translate) to have
an idea in the page.

Gopher is about as relevant as the International Toothpick Collector
Association's Annual Report on the Proceedings of Toothpick Size
Irregularities.



rhizome on Mar 13, 2017 [-]

I don't think I've ever read anything so passionate about Gopher.