Slashdot Mirror

sGopher!

If he wants to head-first down memory lane, he could always go here to quux.org's gopher server. I'm sure it's full of useful, up-to-date information. For some other, you can grab a copy of Linux 1.0 there, and a copy of Zork!

...alive and well!

...gopher was a menu-driven text-only precursor to the Web...

What do you mean, "was"? Gopher still works fine. There are dozens of servers out there. See quux.org or just install your Linux distribution's gopher package and fire it up.

I am sure gopher and archie are still used somewhere too.

Indeed.

At least upgrade to Mosaic. I'm just disappointed that Google isn't available on Gopher, and I can read ebooks just fine as plain text, this is how we've been doing it for many many years and the format Project Gutenberg started out using. Some people even host their blogs on gopher.

My dad worked at Bell Labs in Murray Hill back in the 70s-80s. The machines there (as seen on the 1981 Usenet map here as mhuxa, mhuxh, mhuxj, mhuxm, and mhuxv near the middle) were named after Greek gods. mhuxa was Murray Hill UniX "Apollo", the others were Hermes, Jupiter, Mercury and Venus. There was another, mhuhk "Heineken". I was little at the time but I used to play rouge and hunt the wumpus on Hermes with a ADM terminal and accoustic modem from home.

Would you believe....

gopher = two brain-damaged guppies in a dirty sink?

Missed it by that much.

http://gopher.quux.org:70/ (Yes, I had to look it up)

As for why it's attractive, probably as much nostalgia for a time when the majority of morons and trolls were all on AOL instead of the internet proper, and a system that wasn't ad laden to the extreme [insert FF plug here].

"Secret" pictures? Are you projecting? Hint: I'm not anonymous.

Firefox even supports it natively. Here's a gopher site you can visit today.

And here's another one. Even The WELL still has its gopher.

I wonder if this scenario will hasten a return to the "old" days of low-bandwidth, text-only delivery of information, such as (dare I say the Protocol-Which-Shall-Not-Be-Named) gopher? Especially if we start moving towards a model of tiered bandwidth costs, who in their right mind will want to wait 10-15 seconds for a webpage to load when they can simply bring up a gopherized version with the same information but at a fraction of the size and cost?

Here you go

Floodgap Gopherspace

and

gopher.quux.org

You open all your email with an email client and move all the disparate inboxes into a big IMAP store on your own computer or one provided by a joint like Fastmail.fm or Runbox.com

Then, you keep a local backup on any computer that you move to with offlineimap, a wonderful utility that doubles as a multi-inbox syncronizer and backup utility. I have been using it for the past two years and can attest to its reliability.

Best Buy -- They will call the police on you if they think you are jotting down prices. I wonder what they would do about camera phones used for price checks. I know why I don't shop there.

Guess what - the Internet as it existed five years ago doesn't exist, either!

really??

IRC,ftp, usenet,telnet, email, hell even gopher
is still around and being used.

I'd say the internet from over 10 years ago is still there alive and kicking just fine.

just because you dont use anytihng other than a web browser to access the "internet" does not mean it's not ther eand still being used.

For experienced programmers, learning a new language is not hard, especially if it is similar to what you already know. Python is similar to what you already know.

Any given problem could likely be solved in almost any given modern language. I could write an IMAP client in C, a Web server in Java, or a database client in C++.

In Python, you can write correct solutions to many network-related problems with astonishingly little code. And by correct, I mean with error detection everywhere (and handling where appropriate), safe handling of strings (not an issue in Python usually, but a constant problem in C), no deadlock conditions, etc. And what's more, those solutions are usually readable. There are some examples in the book of that. There's a simple FTP mirroring example in the book. 75 lines of code (excluding blank lines).

Now, I could have written it in C, Perl, Haskell, OCaml, Java, Lisp, Pascal, whatever. That's absolutely true. Most of those would not have let me do it in 75 lines of readable code using solely a component that comes out of the box with the language.

Sometimes, the time it takes you to learn a new language and develop a correct, effective solution in that language is less than the time it takes you to develop an incorrect solution in another. Sometimes not, and it's better to stick to the language you know. My point is that you should not always assume this is best.

How about another example. A little keyboard interaction program. Compare:

Python:

from sys import stdin
print "Who are you?"
name = stdin.readline().strip()
print "I'm glad to meet you, %s." % name

Haskell:

main = interact ((++) "Who are you?\n" .
(++) "I'm glad to meet you, " .
((++) `flip` ".\n") . head . lines )

Java:

import java.io.*;

class Hello {
public static void main (String[] args) throws IOException {
BufferedReader ki = new BufferedReader(new
InputStreamReader(System.in));

System.out.println("Who are you?");
String name = ki.readLine();
System.out.println("I'm glad to meet you, " + name + ".");
}
}

Which do you think makes it easiest to interact with the user? I'd have to give the award to Python or Haskell. The Haskell example is a very different one from what you may be used to (hint: ++ is the concatenation operator), as it relies on the lazy and functional nature of the language, but it nonetheless is a concept that scales to incredibly powerful things.

Don't limit yourself by what language you prefer. Prefer a language by what problem you must solve.

(Sorry, it looks like /. stripped the indentation from these examples)

For experienced programmers, learning a new language is not hard, especially if it is similar to what you already know. Python is similar to what you already know.

Any given problem could likely be solved in almost any given modern language. I could write an IMAP client in C, a Web server in Java, or a database client in C++.

In Python, you can write correct solutions to many network-related problems with astonishingly little code. And by correct, I mean with error detection everywhere (and handling where appropriate), safe handling of strings (not an issue in Python usually, but a constant problem in C), no deadlock conditions, etc. And what's more, those solutions are usually readable. There are some examples in the book of that. There's a simple FTP mirroring example in the book. 75 lines of code (excluding blank lines).

Now, I could have written it in C, Perl, Haskell, OCaml, Java, Lisp, Pascal, whatever. That's absolutely true. Most of those would not have let me do it in 75 lines of readable code using solely a component that comes out of the box with the language.

Sometimes, the time it takes you to learn a new language and develop a correct, effective solution in that language is less than the time it takes you to develop an incorrect solution in another. Sometimes not, and it's better to stick to the language you know. My point is that you should not always assume this is best.

How about another example. A little keyboard interaction program. Compare:

Python:

from sys import stdin
print "Who are you?"
name = stdin.readline().strip()
print "I'm glad to meet you, %s." % name

Haskell:

main = interact ((++) "Who are you?\n" .
(++) "I'm glad to meet you, " .
((++) `flip` ".\n") . head . lines )

Java:

import java.io.*;

class Hello {
public static void main (String[] args) throws IOException {
BufferedReader ki = new BufferedReader(new
InputStreamReader(System.in));

System.out.println("Who are you?");
String name = ki.readLine();
System.out.println("I'm glad to meet you, " + name + ".");
}
}

Which do you think makes it easiest to interact with the user? I'd have to give the award to Python or Haskell. The Haskell example is a very different one from what you may be used to (hint: ++ is the concatenation operator), as it relies on the lazy and functional nature of the language, but it nonetheless is a concept that scales to incredibly powerful things.

Don't limit yourself by what language you prefer. Prefer a language by what problem you must solve.

(Sorry, it looks like /. stripped the indentation from these examples)

For experienced programmers, learning a new language is not hard, especially if it is similar to what you already know. Python is similar to what you already know.

Any given problem could likely be solved in almost any given modern language. I could write an IMAP client in C, a Web server in Java, or a database client in C++.

In Python, you can write correct solutions to many network-related problems with astonishingly little code. And by correct, I mean with error detection everywhere (and handling where appropriate), safe handling of strings (not an issue in Python usually, but a constant problem in C), no deadlock conditions, etc. And what's more, those solutions are usually readable. There are some examples in the book of that. There's a simple FTP mirroring example in the book. 75 lines of code (excluding blank lines).

Now, I could have written it in C, Perl, Haskell, OCaml, Java, Lisp, Pascal, whatever. That's absolutely true. Most of those would not have let me do it in 75 lines of readable code using solely a component that comes out of the box with the language.

Sometimes, the time it takes you to learn a new language and develop a correct, effective solution in that language is less than the time it takes you to develop an incorrect solution in another. Sometimes not, and it's better to stick to the language you know. My point is that you should not always assume this is best.

How about another example. A little keyboard interaction program. Compare:

Python:

from sys import stdin
print "Who are you?"
name = stdin.readline().strip()
print "I'm glad to meet you, %s." % name

Haskell:

main = interact ((++) "Who are you?\n" .
(++) "I'm glad to meet you, " .
((++) `flip` ".\n") . head . lines )

Java:

import java.io.*;

class Hello {
public static void main (String[] args) throws IOException {
BufferedReader ki = new BufferedReader(new
InputStreamReader(System.in));

System.out.println("Who are you?");
String name = ki.readLine();
System.out.println("I'm glad to meet you, " + name + ".");
}
}

Which do you think makes it easiest to interact with the user? I'd have to give the award to Python or Haskell. The Haskell example is a very different one from what you may be used to (hint: ++ is the concatenation operator), as it relies on the lazy and functional nature of the language, but it nonetheless is a concept that scales to incredibly powerful things.

Don't limit yourself by what language you prefer. Prefer a language by what problem you must solve.

(Sorry, it looks like /. stripped the indentation from these examples)

For experienced programmers, learning a new language is not hard, especially if it is similar to what you already know. Python is similar to what you already know.

Any given problem could likely be solved in almost any given modern language. I could write an IMAP client in C, a Web server in Java, or a database client in C++.

In Python, you can write correct solutions to many network-related problems with astonishingly little code. And by correct, I mean with error detection everywhere (and handling where appropriate), safe handling of strings (not an issue in Python usually, but a constant problem in C), no deadlock conditions, etc. And what's more, those solutions are usually readable. There are some examples in the book of that. There's a simple FTP mirroring example in the book. 75 lines of code (excluding blank lines).

Now, I could have written it in C, Perl, Haskell, OCaml, Java, Lisp, Pascal, whatever. That's absolutely true. Most of those would not have let me do it in 75 lines of readable code using solely a component that comes out of the box with the language.

Sometimes, the time it takes you to learn a new language and develop a correct, effective solution in that language is less than the time it takes you to develop an incorrect solution in another. Sometimes not, and it's better to stick to the language you know. My point is that you should not always assume this is best.

How about another example. A little keyboard interaction program. Compare:

Python:

from sys import stdin
print "Who are you?"
name = stdin.readline().strip()
print "I'm glad to meet you, %s." % name

Haskell:

main = interact ((++) "Who are you?\n" .
(++) "I'm glad to meet you, " .
((++) `flip` ".\n") . head . lines )

Java:

import java.io.*;

class Hello {
public static void main (String[] args) throws IOException {
BufferedReader ki = new BufferedReader(new
InputStreamReader(System.in));

System.out.println("Who are you?");
String name = ki.readLine();
System.out.println("I'm glad to meet you, " + name + ".");
}
}

Which do you think makes it easiest to interact with the user? I'd have to give the award to Python or Haskell. The Haskell example is a very different one from what you may be used to (hint: ++ is the concatenation operator), as it relies on the lazy and functional nature of the language, but it nonetheless is a concept that scales to incredibly powerful things.

Don't limit yourself by what language you prefer. Prefer a language by what problem you must solve.

(Sorry, it looks like /. stripped the indentation from these examples)

I think I'll refrain from clicking the link you posted to the domain [chickenboner.com]. I have read /. for a while.

In retrospect, I should have pointed that out. It's a perfectly legitimate site. Here's a definition

Chickenboner:
From Jargon File (4.4.4, 14 Aug 2003)

chickenboner n.

[spamfighters] Derogatory term for a spammer. The image that goes with it is of an overweight redneck with bad teeth living in a trailer, hunched in semi-darkness over his computer and surrounded by rotting chicken bones in half-eaten KFC buckets and empty beer cans. See http://www.spamfaq.net/terminology.shtml#chickenbo ner for discussion.

gopher.quux.org is a huge repository (many of the quotes you see at the top of my site came out of QUUX's fortune files). I eventually plan on expanding gopher.wumpus-cave.net into a repository for weird or historical technology (Trebuchets built out of Legos, PDP-11 assembler opcodes, etc.), but right now it just has some Gopher implementations and some pictures of a burning stuffed Barney doll :)

It took me all of 2 minutes with Google trying to find links for all the software you mentioned - and greatly enriches your post.

Other than that, thanks for the pointers.

====

ImageMagick

K3b - DVD/CD burner software

Plone - The most mature open source CMS.

Mamboserver - Not as mature or featurefull as Plone, but very nice as well.

OfflineIMAP - Simple, reliable, powerful

Kstars - and KDE Technology in general

The ones that are almost there but could use a hand to make them more intuitive:

GNUCash - Can't wait for their Gtk2 version.
Mr. Project
KOffice - has a great technological underpinning.

UNET ran almost entirely in user space. All that went into the kernel were device drivers for the network devices and a psuedo-device to allow interprocess communication to the network process. This made modification and debugging much easier. You could kill and restart the network process without rebooting the system.

Twenty years later, someone has reinvented this approach.

It was Ronald Kahlow and Best Buy. He was arrested twice and sued Best Buy, but lost.

of a man named Ronald Kahlow and his troubles with Best Buy back in 1997.

Three separate emails this morning directed me to Tom Coates' post about the definition of social software.

I thought I would offer a few resources for those who are inclined to look at the historical roots of this new phenomena. First, I applaud Coates' reference to Engelbart, because the social aspects of computer augmentation were very much on his mind as early as the 1950s. I wrote about that in 1985. At that time, and in many conversations since then, Engelbart stressed that his original framework for augmentation included "humans, using language, artifacts, methodology, and training," although most emphasis by most people in the intervening decades has been on the visible part, the artifacts. In that sense, the emphasis on social software today is (or ought to be, in my opinion) a reminder that the real capabilities of augmentation lie not just in the capabilities and affordances of the hardware or software but in the thinking and communication practices these tools enable. Of course, in 1993 -- hard to believe it was a decade ago -- I wrote about the Well, BBSs, Usenet, Muds, IRC, etc. in The Virtual Community. So much debate and commentary has flowed around the notion of "community" in this context that it doesn't make a lot of sense to rehash it here and now, although, arguably, online community is an early example of Technologies of Cooperation. I would only note that when a particular group of people uses social software for long enough -- whether it is synchronous or asynchronous, deskbound or mobile, text or graphical -- they establish individual and group social relationships that are different in kind from the more fleeting relationships that emerge from task-oriented group formation. Although the enterprise of Electric Minds is long forgotten, I talked a lot about "the social web" in 1996-97 (and Judith Donath wrote about The Sociable Web). The original conversations are gone, but a snapshot of the editorial content of Electric Minds exists -- note in particlar The Virtual Community Center.. In 2001, I updated "The Virtual Community" with a new chapter that went into detail about the community debate and brought in the notion of social networks: and three years ago, Lisa Kimball and I wrote about the advantages to enterprises of establishing online social networks.

And of course many others from the social sciences, political science, and the technology side have studied and written about the way people use computer-mediated communications in teams, group formation, and social networks. I don't want to give the impression that I've been the only person writing about this: indeed, I have two shelves of books by authors from a variety of disciplines about the social, political, psychological aspects of social cyberspaces. Certainly, we have much more to learn about Trinity dying in Matrix 2. And I applaud the reinvigoration of interest in a phenomenon that popped up just as soon as people could send email to distribution lists (HUMAN-NETS was one of the oldest discussions of social software.): I think the emerging field would do well to acknowledge and build on this earlier work. Something new is happening, truly, in terms of the kinds of softare available, and the scale

you remember those, folks? ah, sweet gopher. R.I.P

Actually, there's a movement underway to bring the roots of the Internet back to the forefront. For instance, gopher isn't really dead, it's just residing here, among other places, waiting patiently for the commercial Internet to implode so the good old days can return again.

I would like to see a limited subset of HTML used for e-mail. When you think about it, you only need a few tags for text based stuff. /. limited html for posting is good, but I could see adding a color tag (don't need many colors supported either) in there too (for emphasis or important stuff (although I can see E-tards making every individual letter different colors). I don't think this would add much data on to a standard message, it would be easy, and not as abusable as full HTML mail. The beauty of this is that Gopher clients could even add support for it, as could HTML browsers and the like. As an added benefit, building simple sites would once again be easy and quick.

Does anybody know of any projects that do something like this?

According to Google's USENET timeline, Gopher is actually younger than the World Wide Web. That was news to me.

I was just thinking about Gopher last night: when I installed my first home UN*X system a couple of years back, I was anxious to try out every kind of server on it: NNTP, HTTP (plug), NFS, NIS, SMTP, DNS, and just about anything I knew about. It wasn't until last night, though, that the thought of running a Gopher server ever occurred to me.

My first CSE textbook contained the statement, "It is possible to spend many exciting hours in Gopherspace." I never found that to be the case; I started my degree in 1996.

Another interesting subject in that same textbook caught my eye, though: USENET via tin. I owe a gigantic chunk of my education to USENET. It sure saddened me when my University shut down our news server. I was a little jealous that the gopher server was (and still is) left in operation.

Congrats to the Gopher team; I had no idea you guys were still going. Best of luck.

Hmmmm. The next event in the Google timeline is the announcement of Linux. Maybe early Linux development was spurred on by Linus' secret desire to run his own Gopher server. :)

Hmm. After reading the Gopher Manifesto, I now have an appreciation for what Gopher could give us. This seems promising.

Anyway, check out gopher://gopher.quux.org:70/h0/3.0.0.html for the news properly gophered.

Now I want a good TurboGopher 3D client rereleased :)