Maybe your association would be different / the terminology would make more sense if you were online in the early 90s?

BUT, it was definitely possible to do what you're describing with some combination of a dialup shell account, a terminal program like qmodem and something like https://en.wikipedia.org/wiki/Slirp

I think running SLiRP on the Linux box and a SLIP client on the IBM AT was probably a stretch, but it's certainly possible. At that point it probably would have made more sense to grab an NE2000 NIC and throw the IBM AT onto the coax network.

Most network software for DOS was LAN-oriented, like Novell or NetBIOS. Just drive mapping and printer redirection. I'm not aware of a TCP/IP connectivity suite being available for DOS in that era, and I'm not sure how it would have worked given that DOS provided no networking libraries to hook into.

Oh I wasn't trying to reverse-engineer his network from that comment, just saying that this was a thing that was possible and that people did at the time.

I agree it's highly unlikely that the AT was running slirp. Wikipedia says an AT was a 286, so it wouldn't have been linux. Not even sure what the options would have been. Minix? Xenix?

QModem ran on DOS, so the AT wasn't running UNIX. It's almost certainly being used as a terminal.

I can confirm that they did run Minix OK, although I remember the network support was iffy at best. We never got it to work at any rate. XENIX would have been hard to get your hands on. I think QNX would run on an AT as well, although my memory might be playing tricks on me there.

Xenix definitely ran on a 286. I can't say re: Minix-- I never have used it (though I probably should just to have the experience). I believe there was a Crynwr SLIP packet driver.

I was online in the 90s and I did have a 286 PC. Thus my questions. (That PC was running DOS and didn't have much of a chance to have IP connectivity.)

That's precisely what QMODEM does? What do you think it does?

QMODEM didn't connect to the Internet. It had no IP stack.

It could connect you to a machine that had Internet access. Some ISPs offered that as a service (you'd get some kind of BBS-like interface or - if you were lucky - a UNIX shell), but that's not the same thing.

QMODEM was essentially just a terminal emulator that used a serial port and understood how to control a modem.

Indeed, I was there, I know. As a starving college student, using QModem for part of it.

> that's not the same thing.

I think your definition of "connect to the internet" make sense today, but would be ridiculously narrow when applied to the QModem era given the computing landscape at the time. Where do you draw the line? Using a tty style terminal connected via serial to a unix box connected via ethernet? How about SLIP/PPP?

I guess my problem with your definition is that you end up saying that a very large percentage of people who were online at the time were using the internet through computers that were not "connected to the internet".

Until the mid-90s the internet was predominantly text anyway, so it's not like you were missing out on a whole lot if you were "only" using a terminal.

My definition of a computer being on the Internet is the computer has an IP stack that can route directly to other networks. In this scenario, the Linux box at the other end of the serial cable was on the Internet. The machine running QModem was not.

However, the user running QModem was on the Internet.

Exactly.

After all this discussion here my conclusion is that "connecting to the internet" is an ambiguous term.

It can mean "have IP connectivity, i.e., IP packets routed to and from the internet" in which case the described PC was not "connected to the internet with QMODEM". It didn't do anything IP.

It can mean "have a terminal that can interact with information from/to the internet" in which case the PC was indeed "connected to the internet with QMODEM".

To me, the second meaning is quite the stretch, but apparently to others it's fine.

Yes, I think it's a very ambigious term.

My problem with your definition is that it doesn't take into account the reality of connectivity at the time (at least in my experience of the early 90s) - not a whole lot of machines had IP stacks that were connected via ethernet/isdn/t1/etc and online all the time. Certainly you'd have to be pretty special to actually own one or have one at home. Connecting over some kind of tty or dialup was extremely common.

So using your definition, a sizeable percentage (possibly even a majority?) of people who were online and doing things on the internet during the QModem era were doing it through computers that were not "connected to the internet". Which seems obviously silly.

So you're here telling people who were actually using these APIs that we're wrong to be upset, because LLMs? Awesome, super helpful, thanks

LLMs require data, as I'm sure you know. This is locking up what was previously an interesting source of data, which undermines your argument over the long term

Can you do anything aside from low-effort shitposting?

Disagreeing with folks on this thread is not shitposting. Please don’t be an asshole and accuse me of “shitposting” merely on account our disagreement.

Before he was a food writer he worked in a number of fairly high-end restaurants in Boston (which he talks about occasionally on his Youtube channel), and then he opened his own restaurant in 2017ish. Not sure how that's "not a chef"

I simply didn't realize he had ever run a restaurant.

I feel like you have an overly restrictive definition of "chef". Owning a restaurant doesn't make you a chef, cooking food professionally does. Even if he never set foot in a restaurant kitchen, the man cooks food all day long for his job. That makes him a chef.

I have a chef's definition of a chef. You're welcome to use whatever one you prefer though.

Uhh.. damning praise. I think that can be rephrased as: "It's pretty, but despite being almost the simplest thing you can imagine, it still has ridiculous, unnecessary usability problems"

Same! At first I thought it might be a Firefox problem, but it's equally broken in Chrome.

Predictably it's a React site, using some widget library (MUI) that is going out of it's way to provide a text input that is inferior to what's built in to any modern browser. Great!

Seconded! I would highly recommend NTS. Their archive is great, dives into almost anything you can think of

Been listening for a couple of hours or so. Love it, cheers.

I didn't downvote this post, but I don't find it hard to see why someone would:

* making incredibly general hand-wavy statements implying vscode is always perfectly lag-free and emacs is terrible

* generally condescending and hostile tone: "if you invested the time.." "you saw fit to reply with"

* some ranting and name-calling about a previous negative experience this person has had, which has nothing to do with anyone in this thread. (given the general tone of this post, i'd say there's a good chance that it was just this person deciding to abuse some unpaid emacs/lsp volunteer/maintainer and they rightfully said "go fuck yourself")

* sadly, there is actually useful information contained in this post, but it's sort of structured as an inverse "shit sandwich" - some ranting and negativity, some useful and relevant information, and then more ranting and name-calling. which, i think, tends to mean most people are just going to ignore it or downvote. not really a constructive contribution to the discussion, despite actually having something useful to say

Yeah, makes sense. Parts of it resonated with me, but it's also a bit too rude.

> VS Code in its current state has no perceptible input latency on modern hardware, easily verifiable.

"easily verifiable"?!!? This is a ridiculous statement - lots of VSCode responsiveness is dependent on which language servers you're using, and some are definitely faster than others. Sounds like you're extrapolating from the languages that you personally use?

The golang LSP has had widely documented performance problems on large codebases on and off over the past 2ish years (mostly resolved at the moment AFAIK), but it was severe enough that a large percentage of my group at work switched to Goland (Go IDE from Jetbrains) because it was much, much less laggy on our larger projects than VSCode.

Zelle doesn't support all banks - the call to action on their home page is even "See if your bank offers Zelle". My credit union, sadly, does not. So it's not really comparable to EU IBAN transfers.