System Recommendations
Intel Pentium® processor-based system, 60 MHz or higher
Windows* 95 or Windows NT* operating system
Half-duplex sound card with speakers or headset
Microphone for voice input
Client: Modem, 28.8 Kbps or faster
Server: ISDN or higher connection to the Internet
An Internet service provider that supports TCP/IP*
"real-time, multi-party audio chat over the Internet" was possible 24 years ago. Meanwhile, on a two-year-old computer, I still have frequent trouble getting Teams audio chats to work without stuttering and breaking up on a 50Mbps connection...
A lot of things are possible for very long times, but for some reasons that I cannot fathom, we decide to abandon nicely working things for flashy, less capable and closed systems.
I don’t see what closed systems have to do with it.
The big difference now is that someone with no computer experience can tap a touch screen and chat for hours using a device the size of a candybar wirelessly from the back of an elephant in rural south east asia.
Ease of use and decent software performance optimizations shouldn't be mutually exclusive. Just because we have touchscreen now doesn't excuse the shit show that some modern software has become.
I shouldn't need Apple M1 levels of performance just to browse the reddit frontend without issues.
> I don’t see what closed systems have to do with it.
That someone would have been using an equally easy to use user interface running on XMPP/IRC or any other open/interoperable and lightweight protocol with official extensions built by executing RFC mechanisms all had for years.
Instead we're using nice UI's running closed ecosystems on closed protocols and no optimizations since my smartphone's battery life, network limits and hardware capabilities be damned. Hardware is cheap, network is reliable. Let's move fast and break things until Hardware buckles and network clogs.
Internet was a network of networks. Now it's a garden of walled gardens.
> That someone would have been using an equally easy to use user interface running on XMPP/IRC or any other open/interoperable and lightweight protocol with official extensions built by executing RFC mechanisms all had for years.
Possibly so, but what relevance does this have?
We still can do all this with open protocols if we want to.
When I read comments like yours, I read them as a repudiation of pop-culture.
Instead of re-inventing proverbial wheels over and over, we could have done much more if we chose to improve the tools we had at that time.
> We still can do all this with open protocols if we want to.
Yet, we don't. Instead allow web to be centralized and fragmented. At the same time we're trying to decentralize it.
> When I read comments like yours, I read them as a repudiation of pop-culture.
I don't know where you're coming from (I'm not a native English speaker, I can't completely understand what you're trying to do), but I all I can say that, I do not support wasting that much computational power by not-optimizing and/or inventing inferior things and marketing them as superior.
I arrived to this point by hands-on experience. Giving a little more thought to something you develop or just planning a little ahead goes a very very long way in terms of efficiency an performance.
> I don’t see the point in that.
You may not, and I won't judge you for that. However, I see a more capable future with less effort down the road.
> > We still can do all this with open protocols if we want to.
> Yet, we don't. Instead allow web to be centralized and fragmented. At the same time we're trying to decentralize it.
This speaks to my point about pop-culture.
When you say ‘allow’ you are implying that there is someone who could disallow this if they do chose.
There isn’t. There are just millions of programmers who weren’t active in the historical era you are comparing to, making products for consumers who also were not around then.
This is a pop-culture. It’s what happens when computers become democratized.
> I do not support wasting that much computational power by not-optimizing and/or inventing inferior things and marketing them as superior.
It doesn’t matter who ‘supports’ this or not. This is what I mean by repudiating pop-culture.
> I arrived to this point by hands-on experience. Giving a little more thought to something you develop or just planning a little ahead goes a very very long way in terms of efficiency an performance.
Again- this is true, but it’s not really clear what relevance this has.
I don’t support the construction of ugly homes that are too small or cheaply designed for people to feel good about.
What is missing in my mind is not people like you and I ‘not supporting’ things: it’s an understanding of how to make things better.
This isn't real-time multi-party audio, but delayed/queue one-at-a-time audio (description describes it as like a text chat room with audio instead of text). Real-time multi-party is much harder.
It’s easy if you change the requirements. Buffers help with stuttering but cause delays. Less sampling and more compression help with bandwidth usage but cause lower quality.
By the way, you could participate in multi party audio check from an analog phone.
> Meanwhile, on a two-year-old computer, I still have frequent trouble getting Teams audio chats to work without stuttering and breaking up on a 50Mbps connection...
The difference is that back in the day people developed software to solve problems, where as nowadays software is mostly developed to "engage" customers, lock them in or provide job security to engineers by having them rebuild the same thing every year in yet more layers of Javascript libraries and frameworks.
