jslabovitz

Meh. Not great. (But thanks for asking.)

Sure, there's definite improvements. More people have access, more of the time, and that's brought in interesting & creative people and projects. (As well as the obvious opposite.) It's easier to publish graphics, sound, video -- anything beyond text was difficult before. For a while, discovery was much improved, although I actually think that's gotten worse lately.

What gets to me the most, though, are three things:

1. The loss of interoperability. When the internet started, there was a clear, strong value placed on interconnection. First it was through low-level protocols like NCP or TCP/IP, then through application protocols like FTP, SMTP/POP/IMAP, Gopher, HTTP. This effort seemed to peak with network APIs (RESTful or not) and other standards like RSS/Atom. The protocols changed, but the idea remained: we, the users, should be able to build our own view of the internet, each according to our needs. This whole trajectory seems to have been greatly devalued in modern times. I understand that it's due to economics -- advertising wins over community -- but it's depressing as hell.

2. Centralization of services. We talk about this a lot on Hacker News; I don't need to elaborate. But take it from an old net.geezer that it feels extremely uncomfortable that most people only use a literal handful of sites -- and more and more people seem to question the idea of independent websites at all.

3. General complexity. I've retired from the tech world, in part, because of the overwhelming complexity of the technology. Maybe this is like the old days of science, where after a point, one person could not comprehend the field. But still, it saddens me that there seems less and less space for simplicity. I run all-static sites (with no Javascript and minimal CSS), not much different than I did in the mid-1990s -- and for that I'm a radical. I find that strange.

ARPAnet, 1982: Late nights on a Heathkit H89 running CP/M, 24x80 green screen... dialing up at 300 baud to a terminal server, probably across the Potomac at the Pentagon, typing magic numbers (pre-TCP/IP) to connect over NCP to unseen computers at MIT. Stallman and others were happy to give out guest accounts to random teenagers like me, so I spent hours futzing around systems like the bizarre MIT-ITS (Incompatible Time-sharing System) or the only slightly less bizarre V6 Unix at mit-ccc. Discovered Usenet news and mailing lists and FTP archives and dove in headfirst. There was a feeling of rough travel then, with no paved roads, no centralized maps, few guidelines, but many kind strangers along the way. It wasn't all tech or sci-fi geekery -- I was parts of mailing lists as diverse as alternative music (Love-Hounds) and body piercing.

Proto-WWW, 1993: Happened across O'Reilly & Associates at a network conference, and joined up with their Global Network Navigator project, the first commercial web publication (my first gig there was the first ad). Even so, every last one of us at GNN was passionate and excited about this medium exploding before our eyes. Everything was new, untried. There was no breaking things because so little was formed. There was a fluidity of expression (even within its constraints), a vast potential that was almost tangible, a sense that the web itself was a creative material to be molded. In this short time between the web's inception (~1993) and platforms like Geocities (~1995), we played in the raw muck of the primal web: HTTP + HTML + GIF + you.

Could be better, but this is what I did:

    for i in `brew ls`; do brew info $i | grep -e 'Built.*with:' >/dev/null && brew info $i; done

Out of 144 formulas installed, I've only got one with an option (mpv --with-bundle). I hope the Homebrew folks will use that option as default, but I suspect they won't, and will recommend the cask instead. Which isn't really what I want, but ok.

MacDraw and Freehand.

I know there are modern vector/bezier-drawing alternatives, like OmniGraffle and Sketch and Affinity Designer. But both MacDraw and Freehand balanced functionality and simplicity and directness so well. In MacDraw, I could make technical drawings really quickly. In Freehand, I could do everything I could do in Illustrator, but with much better grid-snapping and typography. And I loved its 'morphing' tool (it wasn't called that), where you could take two objects (even type) and it would interpolate them and make these beautiful shapes.

I just hosted a small house concert last night for about 20 people; the age range was 18-50, I reckon. I put out a sheet of paper with spaces for names & contact info, for folks who wanted to be notified for future shows, and intentionally left the contact method open -- I figured if they wanted a group text, or a FB msg, I could do that.

I was surprised to find that every person who signed up wrote their email address.

So you may just might be right.

Granted, this is a rural area (West Virginia, US) and there's far less incessant use of smartphones and the like. So my experience might not apply to more urban places.

This is kind of amazing: finding Buddha in an advice column. Definitely subscribing -- thanks, original poster, for the ref.

When I first met Ted, ca. 1991 or 1992, he was indeed doing most of the Xanadu work on his houseboat in Sausalito. But Autodesk was also in Sausalito, just down the road, so Ted was definitely in the neighborhood, if not exactly in the building.

There was some amount of coding happening at the houseboat, though I have a vague recollection (which may be wrong) that Roger Gregory might have done much of his work offsite -- at his house? -- and then come to the houseboat for meetings.

I saw Ted perhaps a year later and it was definitely in his office at the Autodesk facility. He had quite a nice lab there, and an assistant.

> Ted Nelson has some novel ideas. But I can't help to think that the failure of the mass adoption of his ideas stems from him being too greedy. If he had open sourced the code he wrote for Xanadu, if he had even published specs of a simple Xanadu system free of copyright he could've brought us a better hypertext.

I lived in San Francisco around 1992 and got to know Ted a bit, along with a few others in the Xanadu team. At Ted's houseboat in Sausalito, I witnessed a few demos of the ever-in-progress Xanadu software (and related projects), and saw some of the code.

Ted has always had very strong ideas about treating copyright as technology (see his 'transclusion,' etc.). That's why he's always been bitter about the web winning the hypertext game, without the necessary (in Ted's design) two-way linking with automatic credit (& royalties!). I can imagine Ted being vociferous (in his unique way) in opposition to a blanket release of source code via the distribution technology of the time -- largely Usenet News, FTP sites, and BBS systems. The contemporary landscape of open-source licensing had barely evolved by the early 90s; if you released something on the net, you were pretty much putting it in the public domain. That was antithetical to Ted's goals of creators owning their content.

Even if he had been convinced to release the code, it was in Smalltalk. (It had started out in C, but had been rewritten by the time I saw it.) The culture of Smalltalk never seemed to be very interested in methods of distributing source code. (Or even binary code: ST apps included their entire runtime environment, making them really heavy.) Even if the code was released, the number of people running Smalltalk systems was miniscule.

Finally, Xanadu, for most of its active life in the early 90s, was very much in experimental development. Although Ted had been thinking & designing & writing about Xanadu for decades, I believe this period was the first time he was actually able to commission running software that implemented hypertext. (Ted's not a programmer, nor an engineer.)

As for ‘publishing specs’ — most of the details of Xanadu are described in Nelson’s book _Computer Lib / Dream Machines._ Ted’s written extensively about his hypertext ideas (as this very post points out). I don’t know if Xanadu itself was ever documented, but you could read his book and probably implement most of it — if you dared!

Although Ted has always stood up for the 'regular person' computer user (that's partly what _Computer Lib_ is about), in actuality both the UI of the software, and the inherent concepts, were very weird and outside of what most people would understand. I'm not sure Xanadu would have ended up being any more influential than it already was — Berners-Lee certainly knew of Nelson's work as he was created the WWW.

(@terminalcommand: You seem to appreciate Nelson's work more than most, so please don't take the above as any sort of argument. But because you touched on the open-sourcing issue, I replied here.)

I haven't watched the video yet, but I can provide some insight. I spent time with Ted in late 1992 and early 1993, when I lived in San Francisco, and Ted lived just north of the Golden Gate on a houseboat in Sausalito. This was just months before the web 'went public.' (That fall, I was hired by O'Reilly & Associates to help build Global Network Navigator, the first commercial website; we launched in October 1993.)

Ted could be grumpy and arrogant, but he was also incredibly insightful and visionary in his thinking. It seemed to me that he felt strongly the pulse of the future, and was passionate and driven to build the very best version of that future. Like most visionaries, his perfectionism was a result of careful consideration and system design and an inability to settle for less. It's hard to understand now, but he'd put enormous effort into designing a coherent hypertext system that supported not just simple one-way linking (what we've done for 25 years with HTML/HTTP), but bidirectional linking, including an addressing scheme that could 'transclude' (he liked neologisms) content from any other author, while giving full credit, and even royalties. (If you can find it, read his book Computer Lib / Dream Machines.)

He'd been seriously thinking about this stuff since the mid-1960s, and there in the early 1990s, had just started getting traction with a team of people who shared his views. (I was one of them, though a very minor character.) We all knew it was hard, and still quite unclear exactly how all this magic was going to work. Xanadu (Ted's name for his system) had been started and stopped and restarted already a few times. But hanging out on his houseboat in Sausalito, talking data structures and user interfaces with Ted and his gang of incredible programmers, chatting with luminaries who strolled in (I remember Doug Engelbart, inventor of the mouse, coming over one sunny afternoon), was an incredibly heady atmosphere. No one except Ted knew if it would actually work, but it sure was fun to try.

Yet the web lurked just around the corner. On a whim, that summer of 1993 I attended some networking exposition (Interop?) in the city. While cruising the aisles, I ran into the O'Reilly folks and their big color X terminal running an early Mosaic browser, showing a very early World Wide Web. Although I didn't get the details, I immediately understood what they were showing: this was hypertext that worked. While Ted's system was an amazing promise, the Web was clearly the reality that would, in its own pragmatic, hacky way, be the way forward. (I believe that Tim Berners-Lee, inventor/enabler of the web-as-we-know-it, has cited Nelson as an major influence.)

So look at Ted and his work like a musician's musician, unsung and unrecognized beyond the inner circle. Or like Tesla, a great inventor of impossibly amazing projects.

I'm glad Ted's still out there, still inventing, even if Xanadu is but a dream.

> [...] my systems were simple enough that I had a pretty accurate mental model of how the whole system worked [...]

This is key. I've worked on dozens of systems, platforms, frameworks, etc., and the common predictor of how well I program in each environment is directly related to how well I understand the mental model of the architecture.

I'm self-taught, and now in my 50s.

I started programming when I was 10, in 1976. In those earliest days of consumer-class computers, there wasn't really a developed market for practical programming books. However, the manuals that came with software or OSes were quite well-written. There were a few magazines, too, like BYTE and Dr. Dobbs Journal, that published source code -- always the best way to learn!

It helped, too, that my dad was a programmer. I learned most of the basics about computer architecture, binary logic, algorithms, etc., from talking with him.

There were local user groups, though most of the folks were enthusiasts, not necessarily programmers.

By the early 80s, I was reading the C manual by K&R and other books on practical programming, and trying things on my home CP/M system (Heathkit H89). If I had problems (and I often did), I simply had to experiment, read more, think more, debug more.

I first got online around 1980 -- via dial-up BBSes, then the early Internet (ARPAnet), and USENET. While you generally couldn't search for answers/code the way you can now, you could browse, and you could certainly ask people who knew, or at least could offer suggestions.

Finally, I think it's been an advantage that for most of my programming life, I've used Unix, and most of the versions I used included source, which is always educational.

They're giving props to W+K in a backhanded way: "They wasted over six months of our precious time pitching concepts like people laughing while playing the game, and amusing card combinations coming to life on screen." That "conventional thinking" likely would have worked well and made the ad successful in conventional terms. So I don't think they're dissing the agency (maybe that's not what you implied), but rather saying W+K does well at a different kind of advertising. Non-potato advertising, say.

I agree. I definitely stifle myself online more than I might in a small in-person group, or even a large group, for fear of negative reactions.

For me, it's got nothing to do with anonymity or some possible later repercussion; rather, it's being sensitive to short-term feedback. Effectively, the bandwidth of human communications through the internet is low and error-prone, and hence stressful for me to get my thoughts across. (It doesn't help that long-form replies -- which help me explain my ideas better -- have been grossly devalued.)

Sadly, it's gotten worse in the last few years -- perhaps due to Facebook, or perhaps due to societal changes that opened the door to mediums like Facebook.

I seem less and less capable of growing that thick skin that people always talk about...

I was HNIJ@MIT-MC (and later, rms.g.hnij@mit-oz). I used to be able to google for those addresses and pull up my now-embarrassing questions I posted on various mailing lists as a teenager.

One more point -- although I believe your statement that ITS did not initially use passwords, I'm almost positive that the policy switched around 1982, and they did require passwords after that.

Around 1982, I had an account on MIT-MC, an ITS computer. I was not an MIT student -- rather, a curious teenage hacker from DC. I'd found a text file with 'interesting modem numbers,' and one of those was to a DoD TAC (basically, a dial-in). I recall the text file had a note saying how to connect (via NCP, not TCP/IP) to MIT-MC.

I connected, and remember playing around (as we did) at the login prompt. I probably tried to login as 'guest' or something, and the result was basically, 'There's no user by that name. Do you want an account?' Of course, I said yes -- and shortly received my own account.

Stallman may have been sponsoring logins for folks like myself; he definitely was a little later when I got an account on MIT-AI (or was it MIT-OZ?), which was by that point a TOPS-20 machine.

ITS was a very bizarre system, really with its own social culture. Even in 1982, it felt strangely archaic. The debugger-as-shell was definitely an interesting concept.

Once I accidentally deleted a file. I felt awful, and emailed one of the admins, assuming they'd kick me off. He was like, 'Ah, no worries. We'll just restore it from tape.'

The app costs $35. I presume this is a workable business for the developer, and therefore little economic incentive for data collection or other backdoor/nefarious tactics.

I'm much less trusting of free software like most ad-blockers where I have to wonder how they're really making their money.

On being horrified, or on early web ads?

For the latter: I worked on Global Network Navigator [1] from 1993-1995. GNN was the first commercial website, published by O'Reilly & Associates. I was the technical director of GNN. We experimented with various types of financial support, including what today would call sponsored content. My first gig at GNN in October 1993 was coding the HTML for the the initial sponsored content article (for a Bay area law firm). Around the same time, Wired (as HotWired) invented banner ads -- I lay no claim to that! ;)

[1] https://en.wikipedia.org/wiki/Global_Network_Navigator

For the former: I think systems like FullStory are incredibly intrusive. Why would I want my personal scrolling & clicking actions captured, played back, and analyzed? How have we come to accept this as normal? I realize most people don't think about this, but that's because they don't realize the level of information that is accrued. I know when I've tried to explain how much information is gathered, my non-techie friends are horrified themselves. Sure, it might be anonymized (or might not); regardless, it's just fucking creepy.

Reading this thread made me double-check my ad-blocker/anti-tracker settings, clear all my cookies, and think again about just disabling Javascript entirely.

This whole thread is horrifying to me. And I'm saying that as someone who has been online for 35 years, and who (I cringe to admit) worked on the first web-based advertising in 1993. It's like watching a child grow up to be a cruel dictator.

I'm a typographer and sometime book designer (as well as a programmer). I've also used InDesign since 1.0, so I'm very familiar with what it does. Having said that, I'd love to find an alternative -- InDesign has gotten bloated and awful over the years, not to mention the dreadful subscription policy. (It's one of the few CC apps for which I cannot buy a standalone/perpetual license.)

However, Scribus comes nowhere close to InDesign. Here are several basic things I require from a page-layout application if it's going to be any kind of competitor to InDesign:

1. Work in picas and ems, not inches. (Inches are fine for specifying page sizes, but beyond that, picas are the standard in typography.)

2. Be able to zoom arbitrarily. Scribus doesn't seem to support zoom levels more than 400%, so I can't work with even medium-sized text at all accurately.

3. Be able to easily set kerning and tracking on arbitrary text. The Scribus manual caims this is possible, but mucking around with the latest dev version (1.5.3), I couldn't figure out how to do it. (I did really well at totally fucking up my layout just by scrolling, through. Scribus is a bit too response in some ways.)

4. Be able to use OpenType features. Apparently Scribus 1.5.4 will include some of that. But to a typographer in this century, OpenType is essential, not optional.

Apologies to the Scribus developers, but being told that it's a capable publishing app is a bit like a C programmer being told that BASIC should be just fine for them -- hey, they're both programming languages, right?

And yes, I've attempted to use TeX (and LaTeX, and ConTeXT, and XeLaTeX, and...) to do high-quality typographical work. It's possible, but the amount of effort to undo Knuth's poor aesthetic choices (not to mention interface with archaic architecture) is significant, and frankly, not worth my time.

Grumpy typographer is grumpy.

My workstation is an 11" Macbook Air, and has been for years. For what I do -- mostly Ruby, some C, some shell -- it's perfect. I fullscreen everything, and switch between apps with cmd-tab. I avoid or have disabled most macOS GUI features. 4 cores is fine. 8GB is fine, though having a couple hundred open tabs in Safari slows things down a tad. If I need to do something requiring more screen space, like an InDesign layout or a SketchUp design, I just cable up an external monitor & keyboard. Simple, straightforward, no stress.

Ruby. Not Ruby+Rails, just pure Ruby. If you take away the Rails ecosystem, Ruby starts to feel like an old (but lovely) language. Many non-Rails gems (libraries) haven't been updated for at least five years, if not ten -- so I end up rewriting a lot of stuff myself. I enjoy it, actually. Quite peaceful.

There were versioning file systems in the 1960s (MIT's ITS among them, and I think Univac's EXEC 8, though I can't find a reference) [1]. Often, new writes to a file bumped a version (or cycle) count in the file system. I don't know, but I wouldn't be surprised if there were tools to do diffing and patching much like modern VCS systems.

[1] https://en.wikipedia.org/wiki/Versioning_file_system

Not so strange. It was way less common to push out software the way we do now. Software releases were generally pretty major events. Leased lines were often slow and very expensive. Even into the mid-eighties getting a software distribution or update via magnetic tape was the most common method. Even for software from user groups and other non-commercial sources were distributed on tape. (Source: I did Unix and Tandem programming the early 80s.)

So if we look at methods of tape distribution, even the very first edition of Unix in ~1971 had tap (an early ancestor of tar) [1] which saved & restored filenames, mtimes, modes, and owner info. You could argue that a tp/tar archive is a primitive packaging system.

[1] http://man.cat-v.org/unix-1st/1/tap

The other instance I can think of is the shar format [2] that was used to distribute software over Usenet from the early 1980s. Shar was basically a fancy text file that you piped through a shell (yeah, I know). Because binary compatibility was rare, most shar files resulted in a directory of source code, which you'd then compile -- basically, like a 'modern' tarball.

[2] https://en.wikipedia.org/wiki/Shar

This past summer, I ordered a container of household cleaner (16oz bottle with spray pump) from Amazon. Surprisingly, it arrived with no packaging whatsoever -- the bottle of cleaner was taped to a small piece of cardboard that contained the shipping label.

Not surprisingly, the bottle was empty upon arrival, its contents having leaked out during shipment.

I filed a complaint and they resent the product. The next shipment of the cleaner came wrapped in plastic bags, inside a traditional cardboard box (though no air cushions). I guess Amazon realized their experiment in minimization didn't work out all that well.

I live less than two hours west of DC, yet my only connectivity options are a 1.3Mbps DSL link or a ~128Kbps 1x/RTT cellular link. This is pretty normal for West Virginia and other mountainous and rural places in the US. The DSL link isn't too bad as long as I obsessively block all ads and trackers, never stream anything, and reset the router if I've pushed too much traffic through it. If I'm careful about managing TCP connections and very patient, I can get by with the 1x/RTT link; it's slow but steady.

I invite any networked application engineers to come spend a week developing here. You can go for peaceful walks in the woods and question your bad assumptions about always-on/always-fast networking!

Yes! I was just going to post almost the identical comment. I detest talking to computers, whether personal assistants like Alexa or Siri, or the voice-control systems on the other side of a phone call. Apparently computers don't much like talking to me, either, because they never understand what I'm asking. I usually resort to just saying 'representative' over and over again until I get through to a human... And yeah, it all feels incredibly stressful.

I've started using jq (https://stedolan.github.io/jq/) in pipelines to parse/transform JSON output from commands that support it. It has some XPath-like notations for specifying elements within the JSON data tree. It's not perfect, but it's a good start and useful right now.

Modern tools are offering the option to write out JSON. Grepping /usr/share/man and /usr/local/share/man on my macOS system reveals a good dozen or so commands that take JSON as input or generate it as output. (Their man pages generally document the schema, too.) Most of the tools I've written myself also have JSON I/O.

TCP/IP wasn't the official transport protocol until 1983. Before that was NCP (https://en.wikipedia.org/wiki/Network_Control_Program). I got on the ARPAnet in 1982, and remember the transition day.

FTP and Telnet were around by 1974. So was an early mail protocol (described in RFC 524, https://www.rfc-editor.org/rfc/rfc524.txt) which used FTP as mail transfer agent. The first SMTP-like mail protocol was probably MTP in 1980 (RFC 722, https://www.rfc-editor.org/rfc/rfc772.txt).

Go read some RFCs -- they're great sources of early Internet history! Start here: http://www.rfc-editor.org/rfc-index.html