Almost everything on computers is perceptually slower than it was in 1983 (2017) • Hacker News Board

Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)

#351

Post by TeMPOraL » Thu, Feb 20, 2020, 8:30 AM UTC

Arnt wrote: post #207

gsich wrote: post #184

Earlier quoted context omitted.

I am sure that Microsoft Autoroute was available for that era. It probably was also faster then Google Maps is today.

Apparently Microsoft Autoroute was first released in 1988, covered several dozen countries, and could be obtained by ordering it. Thus using it for the first time would involve a delay or at least a day in order to order, receive and install the program. After that, starting it should be quick, but I can't tell whether it required inserting the CD into the drive. Even if the appliocation is already installed on the P…

It's not the "looking up a thing" part that would be faster. It's the "looking up the next thing", the "and the next after that" parts that would be.

Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)

#352

Post by TeMPOraL » Thu, Feb 20, 2020, 8:38 AM UTC

pwthornton wrote: post #307

TeMPOraL wrote: post #66

Earlier quoted context omitted.

Huh. I'd say the examples are perfectly good and on-point. While dealing with autoexec.bat and random BSODs wasn't fun, it's entirely orthogonal to the fact that a DOS-era POS still offers orders of magnitude better UX than current-era browser POSes, or than most web apps for that matter. It also doesn't change the fact that Google Maps is very bad at being a map . It's entire UI flow is oriented for giving turn-by-t…

In no way shape or form does DOS-era UX beat current-era UX (there may be specific programs that do so, but writ large this is incorrect). Getting away from command lines is one of the core reasons that computing exploded. Getting farther away from abstraction with touch is another reason that computing is exploding further. Command-line systems simply do not map well to a lot of users' mental models. In particular,…

> Command-line systems simply do not map well to a lot of users' mental models. In particular, they suffer from very poor discoverability.

I don't want to push too hard into one extreme here, but I believe modern design makes a mistake of being in the other extreme. Namely, it assumes as an axiom that software needs to be fully understandable and discoverable by a random person from the street in 5 minutes. But that only makes sense for the most trivial, toy-like software. "Click to show a small selection of items, click to add it to order, click to pay for order" thing. Anything you want to use to actually produce things requires some mental effort to understand; the more powerful a tool is, the more learning is needed - conversely, the less learning is needed, the less powerful the tool.

It's not like random people can't learn things. Two big examples: videogames and workplace software. If you look at videogames, particularly pretty niche ones (like roguelikes), you'll see people happily learning to use highly optimized and non-discoverable UIs. Some of the stuff you do in 4x or roguelike games rivals the stuff you'd do in an ERP system, except the game UI tends to be much faster and more pleasant to use - because it's optimized for maximum efficiency. As for workplace software, people learn all kinds of garbage UIs because they have no choice but to do so. This is not an argument for garbage UIs, but it's an argument for focusing less on dumbing UIs down, and more on making them efficient (after all, for software used regularly at a job, an inefficient UI is literally wasting people's lives and companies' money at the same time).

Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)

#353

Post by TeMPOraL » Thu, Feb 20, 2020, 8:41 AM UTC

shadowgovt wrote: post #232

abraxas wrote: post #215

Earlier quoted context omitted.

Yes but the flip side of it is that it takes more time now to restart an Adobe application than it took to reboot the machine in the 1980s

The time that matters isn't how long it takes to restart the app; it's how many hours of changes just got eaten because the app crashed and the data was either resident in memory only or the crash corrupted the save file (the latter scenario, again, being more common in the past where correctly shunting the right bytes to disk was a dance done between "application" code and "OS toolkit" code, not the responsibility o…

OTOH, lower runtime performance of modern apps eats into how much people can produce with them - both directly and indirectly, by slowing the feedback loop ever so slightly.

While there are couple of extra layers of abstractions on our systems that make them more safe and stable, hardware has accelerated far more than just to compensate. Software of today needs not to be as slow as it is.

Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)

#354

Post by TeMPOraL » Thu, Feb 20, 2020, 8:43 AM UTC

thewebcount wrote: post #270

TeMPOraL wrote: post #66

Earlier quoted context omitted.

Huh. I'd say the examples are perfectly good and on-point. While dealing with autoexec.bat and random BSODs wasn't fun, it's entirely orthogonal to the fact that a DOS-era POS still offers orders of magnitude better UX than current-era browser POSes, or than most web apps for that matter. It also doesn't change the fact that Google Maps is very bad at being a map . It's entire UI flow is oriented for giving turn-by-t…

> a DOS-era POS still offers orders of magnitude better UX than current-era browser POSes, or than most web apps for that matter. As someone who helped with the transition from crappy text-only DOS interfaces on POSes to graphical interfaces on POSes, I have to disagree. Learning those interfaces was terrible. I don't know where the author gets the idea that even a beginner had no trouble learning them. I worked at N…

For a software that's used professionally, it does not matter how easy it is for a beginner to learn. That's an up-front investment that needs to be made once. What matters is the ongoing efficiency and ergonomy of use.

Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)

#355

Post by TeMPOraL » Thu, Feb 20, 2020, 8:51 AM UTC

MadWombat wrote: post #301

TeMPOraL wrote: post #66

Earlier quoted context omitted.

Huh. I'd say the examples are perfectly good and on-point. While dealing with autoexec.bat and random BSODs wasn't fun, it's entirely orthogonal to the fact that a DOS-era POS still offers orders of magnitude better UX than current-era browser POSes, or than most web apps for that matter. It also doesn't change the fact that Google Maps is very bad at being a map . It's entire UI flow is oriented for giving turn-by-t…

> and didn't have to write CSS hacks for electronics stores could you explain that?

Sure. Most popular on-line stores seem to adopt the "material design" pattern, in which an item on a list looks like this:

  +---------+   ITEM NAME          [-20% OFF][RECOMMENDED]
  | A photo |
  | of the  |   Some minimal description.       PRICE (FAKE SALE)
  | item.   |   Sometimes something extra.      ACTUAL PRICE
  |         |   
  +---------+        [ADD TO CART]

I started to write userstyles that turn them all into:

  ITEM NAME Some minimal description ACTUAL PRICE [ADD TO CART]
  Sometimes something extra (with a much smaller font).

The userstyles get rid of the photos and bullshit salesy disinformation, reduce margins, paddings and font sizes. This reduces the size of the line item 5-6x while preserving all the important information; it means I can now fit 20-30 line items on my screen, where originally I was able to fit 4-5. With refined enough search criteria, I can fit all results the screen, and compare them without scrolling.

Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)

#356

Post by ryanlol » Thu, Feb 20, 2020, 9:08 AM UTC

TheRealPomax wrote: post #346

ryanlol wrote: post #75

Earlier quoted context omitted.

I run xmonad on Debian bullseye with 5.5.3-grsec kernel, it’s definitely snappy. There’s no perceptible input lag, even when testing using the iPhone slo-mo thingy. I mostly use Chromium, electrum, signal-desktop and urxvt. Everything goes to shit as soon as you install one of those “desktop environments” though.

The thing is, the only thing that makes a computer pleasant to use, as opposed to merely functional, is that "desktop environment".

How come? All I see is loads of unnecessary fluff.

I for one find xmonad & co extremely pleasant to use even if there’s a slight learning curve. I really don’t see what Cinnamon, Gnome & co. have to offer (except to users who aren’t very technically oriented, who’d probably be more productive on OS X or Windows anyway)

Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)

#357

Post by C4stor » Thu, Feb 20, 2020, 9:33 AM UTC

ehsankia wrote: post #245

RHSeeger wrote: post #206

Earlier quoted context omitted.

The page in question discusses latency in terminals, not how it compares to performance of previous generations. That being said, it also seems to have to pull in the 99th percentile behavior in order for the timings to be an issue, and even then it's not horrible; it doesn't get actually "bad" until you consider the worst performance (99.9th percentile) of the worst performer (st). It seems overly picky to me.

Also, almost all performance issues come due to features, which nostalgia about the past always ignores. Some specific tasks may have been tangentially faster, but you also had orders of magnitude less features available, and said feature make your overall workflow much faster. None of these people would actually give up on their zsh/autocomplete/fzf/custom git-integrated theme for a few ms better latency.

Let's face it,none of those are compelling reasons for more latency when at the same time the computing power available has ballooned to its current level. Adding auto-complete given processors litterally orders of magnitude faster should have been feasible without getting slower.

Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)

#358

Post by webmobdev » Thu, Feb 20, 2020, 10:16 AM UTC

TheRealPomax wrote: post #19

mfer wrote: post #18

Earlier quoted context omitted.

> you can easily setup a command line interface or Linux system and move blazing fast. Maybe the HN crowd can but not your average or median computer users > I remember turning on the computer and waiting for the motherboard company logo to finish flashing I still have computers that take some time to boot. Issue is, I just rarely power off/on. Instead the computers go to sleep which if much faster to come out of. Of…

Nah, I still can't set up a linux that's both graphical and feels snappy to this day.

On recent distros, I've found MX (mxlinux.org) to be quite responsive. They are now also experimenting with FluxBox ( https://mxlinux.org/blog/mx-fluxbox-2-0-settings-now-availab... ) and that really makes it quite snappy as it is very light on resources.

Another distro I like is "Linux Mint Debian Edition" ( https://linuxmint.com/download_lmde.php ) that feels more "light-weight" than its Ubuntu derived counterpart Linux Mint.

Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)

#359

Post by kungtotte » Thu, Feb 20, 2020, 10:17 AM UTC

Arnt wrote: post #322

kungtotte wrote: post #293

Earlier quoted context omitted.

My current display does include a lot more data. It's also driven by a graphics card with more RAM than I had HDD space back in the day with a dedicated CPU that's also a whole lot faster than 133MHz. Every piece of hardware is better but software has bloated up to remove those speed gains, except when it comes to things like AAA games where they're still pushing the envelope. That's the only place you can actually t…

The increase in video RAM requires more of the CPU and GPU. Downloading and displaying a JPEG at today's resolution requires more of everything, not just video RAM. Anyway, If you come to over to the server side you can see other code that performs very differently than it could have back in 1983. Sometimes unimaginably different — how would a service like tineye.com have been implemented a few decades ago?

The point I'm making is that my desktop PC sitting in my office now does have more of everything compared to my 133MHz PC from 1995. Not everything has scaled up at the same pace, sure, but literally every piece of hardware is better now.

People talk about difference in resolution and color depth? 640x480x16 isn't that much less than 1920x1080x32. My current resolution has 13 times more data than my 1995 one, and my HW can handle refreshing it 120 times per second and fill it with millions of beautiful anti-aliased polygons all interacting with each other with simulated physics and dozens of shaders applied calculating AI behaviour, path finding, thousands of RNG roll, streaming data to and from disk and syncing everything over the network which is still limited by the speed of light. As long as I play Path of Exile that is.

Opening desktop software is perceptually the same as in the 90s. From launching to usable state is about the same amount of time, and it's not doing so much more that it can explain why current software takes so long.

If I can play Path of Exile at 120fps it's obviously not an issue of HW scaling or not being able to achieve performance.

Re: Almost everything on computers is perceptually slower than it was in 1983 (2017)

#360

Post by LargoLasskhyfv » Thu, Feb 20, 2020, 11:02 AM UTC

karatestomp wrote: post #74

serverQuestion wrote: post #41

Earlier quoted context omitted.

could you do that in the past though?

I've been using Linux since... oh, 1999 or 2000, and I've never seen a Linux GUI desktop I'd describe as snappy and responsive. The best I've ever achieved is "not incredibly clunky" and that only by ensuring the graphical interface basically did nothing but run the current application or two I had open. I've seen BeOS, QNX, and (Apple) iOS graphical operating systems/environments that were consistently, remarkably s…

I have to disagree. The comparison you make is unfair. I experienced QNX and Beos too. But what could you really do with it out of the box, compared to a full blown Linux-distro? The 'feeling' of snappiness is a matter of carefully choosen defaults IMO. Almost nobody does that anymore. So have this lowest common denominator, and mostly crappy tools to change them from within the GUI, or have to dive down in the cesspool of myriads of different config files in different formats and places, and in addition an explosion of complexity of subtle interactions of several subsystems.

Regarding the shitty hardware...

The f-ing fastest desktop experience i ever had was somewhere in the late days of KDE 3, across NetBSD, ArchLinux and Gentoo, on Pentium3@933Mhz with 512MB RAM, onboard I815 Intel graphics(edit: with the 'superspecial' 4MB VRAM Dimm-thingy), and some IBM Deathstars. With the same toned down look across all three systems, and toolkits, instead of the usual teletubbyfication.

What can i say? When your KDE 3 crashed you were holding it wrong, or it was somehow miscompiled, be it the optimization , or some libraries.

For me it was rock solid and lightingly fast, at least in my configurations.

The same can be seen nowadays with systemd and pulseaudio. They can be used if configured right. The question is if one wants to be hassled with that, if it isn't.

/endrant