8 ms·

> In many cases, this software doesn't even do anything that is functionally different from 10 or 20 years ago, but it still consumes many more resources. Whic

by dahart 5y ago

> In many cases, this software doesn't even do anything that is functionally different from 10 or 20 years ago, but it still consumes many more resources. Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Nah, having lived and written code through the last 20 years, I think this often repeated argument just isn’t true at all. I can see why it’s easy to jump to this conclusion and easy to believe, if you don’t know or don’t pay attention what’s under the covers. It’s easy to forget about all the conveniences you’ve gotten used to along the way. You wouldn’t agree the functionality is the same if you tried using software from 20 years ago. One easy to overlook difference is displays. It’s easy to forget that 20 years ago we had 800x600 screens, 24 bit color was not ubiquitous, and 60hz monitors were practically non-existent. Today 4K is normal, and combined with refresh rates and colors, we’re pushing upwards of 2 orders of magnitude more data to our screens. We have much better compositing, much better text and graphic rendering, better antialiasing, all around higher quality and faster rendering. YouTube and Netflix didn’t exist 20 years ago. Browsers were incredibly slow and couldn’t support streaming video or anything but the smallest of applications written in JavaScript. Localization didn’t exist, web analytics wasn’t really a thing, browsers didn’t run background tasks. > A world where some websites still don’t work properly across web browsers This specious framing might have you believe that web portability hasn’t improved that much, while in reality the difference in support for web standards has changed dramatically in the last 10 years. Supporting IE6 was a real and widespread problem for businesses compared to the few minor corner cases that are left.

mirker 5y ago
> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Operating systems, particularly Windows. Given fixed hardware, you cannot expect an operating system to continue working indefinitely.
- moonbug 5y ago
  Whyever not.
  - mirker 5y ago
    Windows 95 needed 4MB memory. Windows 7 needed 1GB. Try running Windows 10 with less than 4GB. They all run processes, do they not?
- 9wzYQbTYsAIc 5y ago
  Windows is not functionally the same between branded versions. Even if the NT kernel was shared across some branded versions over time, for example, new features were added and underlying functionality were changed.
  - mirker 5y ago
    The question is how much those features were worth in terms of cost (is a feature bloat?). If you don’t have a cost constraint, then yes, you have feature diversity but the cost for any feature can be arbitrarily high.
miltondts 5y ago
> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Here is one concrete example: visual studio startup and debugging. Source: https://youtu.be/GC-0tCy4P1U https://youtu.be/GC-0tCy4P1U Maybe I could start collecting examples. I never did because it is so obvious. I mean, have you never updated android/iOS/windows on the same hardware? Regarding the "exactly" part in you sentence. Why would more features equal less performance? The only possible reason I can see this happening, is if you have features that run in parallel. Otherwise it's just another callback/if etc. That is, something to be triggered by the user that should have imperceptible impact (slightly more pressure on the instruction cache) on the performance of other features.
- shuntress 5y ago
  > Why would more features equal less performance? "More features" can include things that were not feasible in the '90s. Things that inherently consume more resources. Icons/images are a simple example. Of course good software can get plenty done with 16x16 images. Good software may get all that done and more with access to more memory for higher resolution images and more CPU cycles for image manipulation.
- dahart 5y ago
  > Why would more features equal less performance? […] Otherwise it's just another callback/if etc. Wait, really? Are you serious? Adding features historically is - by far - the single biggest cause of bloat and losing perf on a given fixed hardware configuration. I have no idea why you’re suggesting that unnamed “features” are “just another callback/if”. What features are you talking about, why are you assuming how they’re implemented? I don’t think Visual Studio is representative of most software, nor a reasonable demonstration of your argument above against clean code practices. That said, I’ve been using Visual Studio for 20 years, and in my experience it’s significantly faster now to start up than it used to be. The functionality has also changed, so it’s not an example of functionality staying the same while resource usage increases.
  - fouric 5y ago
normac2 5y ago
So the idea that performing the same daily tasks on modern hardware feels about the same speed as before (and sometimes slower), doesn't have a ring of truth to you?
- djur 5y ago
  No. Modern computers seem considerably faster to me than the ones I was using in the '90s and early '00s, especially computers that are 4-5 years old running recent software. I remember a lot of choppiness and spinning hourglasses which are much less common today.
  - loonster 5y ago
    We have SSDs now. That alone made a huge improvement.
  - normac2 5y ago
    That's how I remember the late 90's and early 2000's specifically, which I think was an especially dark age for the speed of the overall software + hardware combo. but if we go a bit more recent (say 2005 to today) I mostly haven't perceived a gain in speed. That said, I think in the last very few years it's turned around a bit, mainly due to SSDs. In my experience most times that software is painfully slow (in any era) it's because you have too many things open and you're swapping. And SSDs provide acceptable speed even when swapping. In other words, I find modern machines to be roughly as slow as ~2005, but only up to the very recent years when SSDs have become the norm. Now I'm starting to finally feel things being faster overall.
  - randomswede 5y ago
    My daily-driver linux UI (fvwm something or other, whatever the fvwm that comes with Debian 10) is noticeably slower than my daily-driver linux UI as per 1997-2002 (gwm). Which is somewhat ironic, as gwm was basically an interpreter with a bunch of built-in X11 manipulation primitives. But, back then, getting the "desktop context menu" up too approximately no perceivable time, whereas these days I notice time passing. I don't think that is because my reflexes have improved massively in the last 20 years.
erik 5y ago
> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Compare basic document editing in Office 365 with Office 2000 running on Win2k. Sure, 365 has loads of additional functionality, and your data follows you across devices. But the base user experience is largely worse. > It’s easy to forget that 20 years ago we had 800x600 screens, 24 bit color was not ubiquitous, and 60hz monitors were practically non-existent. This was maybe the case in the mid-90's. But by the late 90's 1024x768, 85hz, and 24 bit color were standard. 1280x1024 and even 1600x1200 were not uncommon.
- dahart 5y ago
  > Sure, 365 has loads of additional functionality Right, so you’re agreeing with me and disagreeing with @miltondts? UX isn’t what we were discussing. > This was maybe the case in the mid-90’s. “In the PC world, the IBM PS/2 VGA (multi-color) on-board graphics chips used a non-interlaced (progressive) 640 × 480 × 16 color resolution that was easier to read and thus more useful for office work. It was the standard resolution from 1990 to around 1996. The standard resolution was 800 × 600 until around 2000.” https://en.wikipedia.org/wiki/Display_resolution#Evolution_of_Standards https://en.wikipedia.org/wiki/Display_resolution#Evolution_o...
  - blihp 5y ago
    One problem with that entry: the PS/2 only ever had a minuscule share of the market. In the clone world, which was the lions share (think Dell, Lenovo etc of today), resolutions were all over the place. So 800x600 was often the minimum resolution many developers were targeting for things like dialog boxes etc in that timeframe. It's a fiction to say there was a standard during that time, there were many. From SVGA (800x600) on, it was more a combination of user preference, monitor capability and any minimum software requirements as to what resolution a given user would run. Unlike digital LCDs of today, analog monitors didn't care what resolution you ran them at as long as they could handle the horizontal/vertical frequencies you were throwing at them and the phosphor mask had the resolution needed. (and if it didn't have the resolution, the picture would just look progressively more blurry as you jacked up the resolution being sent to it)
johndough 5y ago
> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Everything that uses NVIDIA drivers on Linux, e.g. through OpenGL. Just bringing up an empty window takes over a second these days, while it was <200ms just a few years ago, even with spinning metal disks instead of SSDs.
aidenn0 5y ago
> 60hz monitors were practically non-existent ?? 60Hz progressive scan was fairly standard for SVGA 20 years ago; people looked for 70+Hz displays because they were bothered by the flicker (my college roommate in 2001 ran at 1024x768@75Hz rather than 1280x1024@60). 800x600@60i was the bargain-bin monitor even in the late 90s. By 2001 you could get a used 800x600@60p or 1024x768@60p monitor for nearly free if you lived anywhere that had companies upgrading to higher resolution.
- nsxwolf 5y ago
  The 75 hz trick was such a lifesaver in offices with fluorescent lighting.
seniorThrowaway 5y ago
>Localization didn’t exist, web analytics wasn’t really a thing, browsers didn’t run background tasks. Maybe the question to ask is how much of this is to the benefit of the end user versus building ever more sophisticated adtech.
- dahart 5y ago
  I think localization & background tasks are more or less 100% to the benefit of the end user. Web analytics was just an example of more functionality that goes unnoticed because it’s not hurting performance. I’d agree analytics is building more adtech, though I feel like that’s a cynical glass-half-empty framing. Analytics have also helped huge numbers of sites to improve UX by understanding how users behave and where they get tripped up.
deckard1 5y ago
> 20 years ago we had 800x600 screens My iiyama VisionMaster was doing 1600x1200 @ 90Hz and running Quake 3 just fine back in 1999/2000. > better compositing, much better text and graphic rendering, better antialiasing, all around higher quality and faster rendering. Thank you Nvidia, I guess? They have been carrying the water since the late '90s when everyone else dropped the ball. But let's get something straight. When we went from CRT to LCD/LED we weren't picking visual fidelity. We, as a consumer base, picked convenience. Thin and light vs. great colors, contrast, viewing angles, refresh rates, etc. My first LCD was in 2004. It was an expensive top of the line brand. I took it home and the ghosting was incredible. Massive input lag. If you were sitting in your chair and just leaned back, all the colors would shift on the display. The viewing angle was nonexistent. I took it back the next day. We are just now getting to the point of matching a CRT from the '90s. And you may have noticed we still don't have OLED on the desktop. Around that same time we all got stuck with perhaps the worst crime against monitor tech: 16:9 aspect ratios. Not only is that aspect not "cinematic" (theatrical 16:9 does not exist), but we're leaving tons of resolution and screen space on the table. Because your monitor will always have the same footprint due to the width, we could have much better vertical resolution if we stuck with 4:3. Consumer TV fads really hurt the computing industry. > support for web standards has changed dramatically in the last 10 years. Yeah well, Webpack, Babel, and numerous polyfills all say otherwise. We're only just now dropping support for IE11 everywhere. Maybe that's the light at the end of the tunnel? But I have my doubts. The incentives are too high for the web to fully standardize. Embrace-and-extend will continue. Developing for the web has never been more complex than it is today. The other bit of sad news is that the web is no longer open. HTML5 is not an open technology. It requires proprietary DRM which only a few companies allow you to use. > web analytics wasn’t really a thing I'm going to shed no tears when Google Analytics finally dies.
- dahart 5y ago
  > perhaps the worst crime against monitor tech: 16:9 aspect ratios. Not only is that aspect not "cinematic" (theatrical 16:9 does not exist), […] we could have much better vertical resolution if we stuck with 4:3. I’m confused by this. Film aspect ratios are even higher than 16:9, at 1.85:1 and 2.39:1. I don’t understand why you complained about 16:9 being not cinematic while suggesting 4:3 is better, could you elaborate?
SECProto 5y ago
> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? From this end user's perspective, Google Chat is functionally no different than ICQ or MSN Messenger were 20 years ago. Notifications show up on my phone screen instead of my windows 95 screen. And now we call them emojis and there are more of them. And Google chat has more lag (~1400ms) when I open a chat window from my contacts list. All while the functionality of getting some text from myself to my friends has stayed identical (actually decreased - I can't use custom fonts/bold/etc on the modern version)
- dahart 5y ago
  Is Google chat using more resources and draining perf? The UX of a chat app is somewhat of a straw man here. None of the chat apps you mentioned “can barely fit in a single machine” or “destroys performance”.
  - dijit 5y ago
    ahem slack? But realistically Google chat uses more ram than the PC I used MSN messenger on even HAD. And msn was “hoggish” for the time.
    - dahart 5y ago
      Slack is vastly more functionality than MSN messenger. How do you know the RAM usage of gchat? I agree Chrome uses more (and again it’s a completely different ballgame than it used to be) than but where are you getting the chat specific app metrics?
      - dijit 5y ago
        > Slack is vastly more functionality than MSN messenger. I don't buy that. Because you can attach bots? or make calls, custom emoji? (you can do all of these on MSN) and more (like theme customisations and font changes!) > How do you know the RAM usage of gchat? You can see each tab's memory usage with Safari on MacOS as it's tied into the Activity Monitor. Google Cloud Console uses 989MB for me, for instance.
caeril 5y ago
Terminal emulation and text editors are the obvious ones, notably because DISPLAYING TEXT should be trivially fast in a world of multicore multigigahertz processors and GPUs with ridiculously fast shaders. Casey Muratori has been running down the insane failings of terminal emulation lately: https://twitter.com/cmuratori/status/1405342954194051073 https://twitter.com/cmuratori/status/1405342954194051073 https://twitter.com/cmuratori/status/1405347255511486464 https://twitter.com/cmuratori/status/1405347255511486464 Chaser: https://twitter.com/cmuratori/status/1405356794495442945 https://twitter.com/cmuratori/status/1405356794495442945 This is to say nothing of the fact that VSCode is the most popular editor on the planet and that the very notion of allocating several gigs of ram to embed a web renderer ( one that is constantly having to be patched for the annual round of UAF vulnerabilities ) in order to DRAW TEXT is the very height of inefficient idiocy.
- dahart 5y ago
  That’s a completely different issue than what parent suggested. Terminals aren’t using more resources, they are just going slow - on any hardware, due entirely to lack of devs engineering for perf. Since Casey’s posts, a bunch of terminals and editors have upped their game, started using the GPU for rendering, and are now both faster and more efficient. > allocating several gigs of ram to embed a web renderer […] is the very height of inefficient idiocy. No doubt theres bloat around, but I think you don’t understand web browser allocation strategies. Chrome, Firefox, and Safari are allocating enormous chunks of ram for both caching purposes, and rendering efficiency. It’s extremely difficult to know how much memory is really needed for any given app, you cannot make the assumption that the RAM reported for any given app or page has anything to do with how much the page itself asked for. You also lack justification for calling memory use idiocy if you aren’t running out of memory. As long as there is free memory in the system, it’s fair game, and does not represent inefficiency.
  - fouric 5y ago
    > Terminals aren’t using more resources, they are just going slow "Going slow* is using resources. Clock cycles are a resource. > No doubt theres bloat around, but I think you don’t understand web browser allocation strategies. Using a web rendering engine to render a text editor is still bloated and inefficient. It doesn't matter if web browsers are intrinsically expensive - building a text editor using webtech is the incorrect design decision. > You also lack justification for calling memory use idiocy if you aren’t running out of memory. It should be obvious that the people here aren't complaining about applications that take a trivial amount of memory. In 2021, nobody cares about a text editor that consumes 8 MB of memory. People are complaining about applications that do take up a significant amount of memory and cause you to run out. Mozilla's Firefox hardware report[1] says that just under 25% of Firefox users have only 4 GB of installed RAM. If running on Windows, probably half of that is consumed by the operating system. Suddenly, a 400 MB Electron app is consuming a full fifth of your available memory. That's a real problem, especially for folks that either (1) don't have much money and can't afford a newer machine or (2) want to try to conserve the environment by not spuriously buying new hardware when the old stuff should work. > As long as there is free memory in the system, it’s fair game, and does not represent inefficiency. Maybe by your definition of "inefficiency". Most of the people in this thread are (apparently) using it to mean "using significantly more resources to provide functionality than are intrinsically necessary". This is a much more reasonable definition given that you don't actually know how many resources the user has. [1] https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware
fouric 5y ago
> Which software exactly is functionally the same yet consumes more resources? This is irrelevant, as it's extremely difficult to find any two pieces of software that are "functionally the same", regardless of their age of release or performance - and, moreover, because we're programmers, we can make informed estimates about the minimum performance impact of most features without just guessing. For instance, string localization should have no perceptible performance impact - it's literally just a key-value lookup (O(1) with a hash table). The additional features that Spotify provides over Audacious (a local Linux music player) are either not intrinsically computationally expensive (fetching audio over a network) or are done server-side (playlist recommendation). Discord has no technically valid reason to be taking up 15% of a CPU core while sitting in the background. And so on. > Today 4K is normal, and combined with refresh rates and colors, we’re pushing upwards of 2 orders of magnitude more data to our screens. We have GPUs that now do all of our graphics rendering work for us. The features implemented by Spotify, Slack, Discord, and Visual Studio Code do not intrinsically require enough graphical resources that they should stress even an older integrated GPU, let alone take 5 seconds to start up on CPU and RAM that are, similarly, one to two decimal orders of magnitude faster than what we had two decades ago. > YouTube and Netflix didn’t exist 20 years ago. Browsers were incredibly slow and couldn’t support streaming video or anything but the smallest of applications written in JavaScript. Localization didn’t exist, web analytics wasn’t really a thing, browsers didn’t run background tasks. None of this is relevant to applications. Browsers were slow back then? Fine. Browsers are faster now? Also fine. That's still irrelevant to the fact that many applications are slower now, on much faster hardware, than they were then.
- dahart 5y ago
  > This is irrelevant, as it's extremely difficult to find any two pieces of software that are "functionally the same" Yes, indeed. You're illustrating is why the post I replied to is a straw man argument. Most software, as you say, is not functionally the same anymore. > string localization should have no perceptible performance impact Yes, my argument was that we got localization without a noticeable perf impact. But it does consume memory, bandwidth and code size, and as you correctly point out, a small amount of compute. I would venture to suggest that rendering Asian fonts is a tad more involved than an O(1) hash table lookup. Localization is just one of hundreds of features we have standard now that we didn't have 20 years ago.
mdoms 5y ago
We don't even need to look 20 years in the past. Software performance has degraded significantly in just the past handful of years. Compare web applications like Facebook, Jira, Twitter and Reddit to the exact same websites 5-7 years ago. They have all implemented horrendously over-engineered, buggy and most importantly dog-slow single page apps to offer the same basic service.
badsectoracula 5y ago
> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Instant messaging. Even if we ignore applications like the original MSN Messenger, Trillian, etc, the original Skype before Microsoft's acquisition was much faster. Sure, it wasn't as fast as it could be - but still didn't had an entire browser wrapped around it nor needed checks 350MB of RAM and 7 background processes just to display an icon on the tray so i can send text messages and perhaps the occasional video call once every two years. And to be honest? I do not really find it that weird if a program needed some extra resources to make a video call - which is why LoadLibrary and (especially) FreeLibrary exist. But in practice that is never done or when it is done it is piled on top of an overengineered system to the point where it loses any benefits under the weight of the architecture astromancy. > if you don’t know or don’t pay attention what’s under the covers. Or don't care. Don't forget the don't care part! It is very important because a lot of the bloat is presented as "functionality" (which, assuming most people even care - and that assuming they'd know what they "pay" for it - often doesn't even need to be as heavy and bloated as it is). > One easy to overlook difference is displays. Aside from resolution, physical dimensions and thinness, displays are worse nowadays. Compared to CRTs they have bad contrast, often bad colors, increased latency (even the ultra-fast 144Hz+ ones), a fixed resolution with awful results if you try to use anything but the native, etc. Note that i'm writing this from a 165Hz 27" 2560x1440 monitor BTW with a few CRTs next to me connected on older systems. And BTW > It’s easy to forget that 20 years ago we had 800x600 screens, 24 bit color was not ubiquitous, and 60hz monitors were practically non-existent. That'd be 30 years ago, not 20. 20 years ago was the year 2001 :-P. While 800x600 was indeed common, it was pretty much as common as 1024x768. And monitors at 60Hz were not common because those would hurt your eyes - even standard VGA released in the 80s runs at 70Hz. But by 2001 pretty much every monitor was able of 85Hz and several went much higher (e.g. 120Hz for mine). > Today 4K is normal 4K is a tiny minority that is barely a blip in statistics. Here, check this: https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware This is Firefox's hardware statistics. The most common resolution, by far, is 1920x1080. The next most common? 1366x768! Both make about 64% of every web capable computer out there! And the resolutions after that are actually lower than 1920x1080 until you reach at around 2% for 2560x1440. Even among games where 4K has meme status, in Steam Hardware Survey you can see that only around 2.44% have a 4K monitor. There are more than three times more gamers using monitors less than 1080p that aren't 1366x768 or 1360x768! There will be several years before 4K becomes a normal on the desktop. Right now it makes way more sense to think about something like 1366x768 than 4K.
deleted 5y ago
[deleted]

by dahart 5y ago

mirker 5y ago

> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Operating systems, particularly Windows. Given fixed hardware, you cannot expect an operating system to continue working indefinitely.

moonbug 5y ago
Whyever not.
- mirker 5y ago
  Windows 95 needed 4MB memory. Windows 7 needed 1GB. Try running Windows 10 with less than 4GB. They all run processes, do they not?
9wzYQbTYsAIc 5y ago
Windows is not functionally the same between branded versions. Even if the NT kernel was shared across some branded versions over time, for example, new features were added and underlying functionality were changed.
- mirker 5y ago
  The question is how much those features were worth in terms of cost (is a feature bloat?). If you don’t have a cost constraint, then yes, you have feature diversity but the cost for any feature can be arbitrarily high.

miltondts 5y ago

> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Here is one concrete example: visual studio startup and debugging. Source: https://youtu.be/GC-0tCy4P1U https://youtu.be/GC-0tCy4P1U Maybe I could start collecting examples. I never did because it is so obvious. I mean, have you never updated android/iOS/windows on the same hardware? Regarding the "exactly" part in you sentence. Why would more features equal less performance? The only possible reason I can see this happening, is if you have features that run in parallel. Otherwise it's just another callback/if etc. That is, something to be triggered by the user that should have imperceptible impact (slightly more pressure on the instruction cache) on the performance of other features.

shuntress 5y ago
> Why would more features equal less performance? "More features" can include things that were not feasible in the '90s. Things that inherently consume more resources. Icons/images are a simple example. Of course good software can get plenty done with 16x16 images. Good software may get all that done and more with access to more memory for higher resolution images and more CPU cycles for image manipulation.
dahart 5y ago
> Why would more features equal less performance? […] Otherwise it's just another callback/if etc. Wait, really? Are you serious? Adding features historically is - by far - the single biggest cause of bloat and losing perf on a given fixed hardware configuration. I have no idea why you’re suggesting that unnamed “features” are “just another callback/if”. What features are you talking about, why are you assuming how they’re implemented? I don’t think Visual Studio is representative of most software, nor a reasonable demonstration of your argument above against clean code practices. That said, I’ve been using Visual Studio for 20 years, and in my experience it’s significantly faster now to start up than it used to be. The functionality has also changed, so it’s not an example of functionality staying the same while resource usage increases.
- fouric 5y ago

normac2 5y ago

So the idea that performing the same daily tasks on modern hardware feels about the same speed as before (and sometimes slower), doesn't have a ring of truth to you?

djur 5y ago
No. Modern computers seem considerably faster to me than the ones I was using in the '90s and early '00s, especially computers that are 4-5 years old running recent software. I remember a lot of choppiness and spinning hourglasses which are much less common today.
- loonster 5y ago
  We have SSDs now. That alone made a huge improvement.
- normac2 5y ago
  That's how I remember the late 90's and early 2000's specifically, which I think was an especially dark age for the speed of the overall software + hardware combo. but if we go a bit more recent (say 2005 to today) I mostly haven't perceived a gain in speed. That said, I think in the last very few years it's turned around a bit, mainly due to SSDs. In my experience most times that software is painfully slow (in any era) it's because you have too many things open and you're swapping. And SSDs provide acceptable speed even when swapping. In other words, I find modern machines to be roughly as slow as ~2005, but only up to the very recent years when SSDs have become the norm. Now I'm starting to finally feel things being faster overall.
- randomswede 5y ago
  My daily-driver linux UI (fvwm something or other, whatever the fvwm that comes with Debian 10) is noticeably slower than my daily-driver linux UI as per 1997-2002 (gwm). Which is somewhat ironic, as gwm was basically an interpreter with a bunch of built-in X11 manipulation primitives. But, back then, getting the "desktop context menu" up too approximately no perceivable time, whereas these days I notice time passing. I don't think that is because my reflexes have improved massively in the last 20 years.

erik 5y ago

> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Compare basic document editing in Office 365 with Office 2000 running on Win2k. Sure, 365 has loads of additional functionality, and your data follows you across devices. But the base user experience is largely worse. > It’s easy to forget that 20 years ago we had 800x600 screens, 24 bit color was not ubiquitous, and 60hz monitors were practically non-existent. This was maybe the case in the mid-90's. But by the late 90's 1024x768, 85hz, and 24 bit color were standard. 1280x1024 and even 1600x1200 were not uncommon.

dahart 5y ago
> Sure, 365 has loads of additional functionality Right, so you’re agreeing with me and disagreeing with @miltondts? UX isn’t what we were discussing. > This was maybe the case in the mid-90’s. “In the PC world, the IBM PS/2 VGA (multi-color) on-board graphics chips used a non-interlaced (progressive) 640 × 480 × 16 color resolution that was easier to read and thus more useful for office work. It was the standard resolution from 1990 to around 1996. The standard resolution was 800 × 600 until around 2000.” https://en.wikipedia.org/wiki/Display_resolution#Evolution_of_Standards https://en.wikipedia.org/wiki/Display_resolution#Evolution_o...
- blihp 5y ago
  One problem with that entry: the PS/2 only ever had a minuscule share of the market. In the clone world, which was the lions share (think Dell, Lenovo etc of today), resolutions were all over the place. So 800x600 was often the minimum resolution many developers were targeting for things like dialog boxes etc in that timeframe. It's a fiction to say there was a standard during that time, there were many. From SVGA (800x600) on, it was more a combination of user preference, monitor capability and any minimum software requirements as to what resolution a given user would run. Unlike digital LCDs of today, analog monitors didn't care what resolution you ran them at as long as they could handle the horizontal/vertical frequencies you were throwing at them and the phosphor mask had the resolution needed. (and if it didn't have the resolution, the picture would just look progressively more blurry as you jacked up the resolution being sent to it)

johndough 5y ago

> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Everything that uses NVIDIA drivers on Linux, e.g. through OpenGL. Just bringing up an empty window takes over a second these days, while it was <200ms just a few years ago, even with spinning metal disks instead of SSDs.

aidenn0 5y ago

> 60hz monitors were practically non-existent ?? 60Hz progressive scan was fairly standard for SVGA 20 years ago; people looked for 70+Hz displays because they were bothered by the flicker (my college roommate in 2001 ran at 1024x768@75Hz rather than 1280x1024@60). 800x600@60i was the bargain-bin monitor even in the late 90s. By 2001 you could get a used 800x600@60p or 1024x768@60p monitor for nearly free if you lived anywhere that had companies upgrading to higher resolution.

nsxwolf 5y ago
The 75 hz trick was such a lifesaver in offices with fluorescent lighting.

seniorThrowaway 5y ago

>Localization didn’t exist, web analytics wasn’t really a thing, browsers didn’t run background tasks. Maybe the question to ask is how much of this is to the benefit of the end user versus building ever more sophisticated adtech.

dahart 5y ago
I think localization & background tasks are more or less 100% to the benefit of the end user. Web analytics was just an example of more functionality that goes unnoticed because it’s not hurting performance. I’d agree analytics is building more adtech, though I feel like that’s a cynical glass-half-empty framing. Analytics have also helped huge numbers of sites to improve UX by understanding how users behave and where they get tripped up.

deckard1 5y ago

> 20 years ago we had 800x600 screens My iiyama VisionMaster was doing 1600x1200 @ 90Hz and running Quake 3 just fine back in 1999/2000. > better compositing, much better text and graphic rendering, better antialiasing, all around higher quality and faster rendering. Thank you Nvidia, I guess? They have been carrying the water since the late '90s when everyone else dropped the ball. But let's get something straight. When we went from CRT to LCD/LED we weren't picking visual fidelity. We, as a consumer base, picked convenience. Thin and light vs. great colors, contrast, viewing angles, refresh rates, etc. My first LCD was in 2004. It was an expensive top of the line brand. I took it home and the ghosting was incredible. Massive input lag. If you were sitting in your chair and just leaned back, all the colors would shift on the display. The viewing angle was nonexistent. I took it back the next day. We are just now getting to the point of matching a CRT from the '90s. And you may have noticed we still don't have OLED on the desktop. Around that same time we all got stuck with perhaps the worst crime against monitor tech: 16:9 aspect ratios. Not only is that aspect not "cinematic" (theatrical 16:9 does not exist), but we're leaving tons of resolution and screen space on the table. Because your monitor will always have the same footprint due to the width, we could have much better vertical resolution if we stuck with 4:3. Consumer TV fads really hurt the computing industry. > support for web standards has changed dramatically in the last 10 years. Yeah well, Webpack, Babel, and numerous polyfills all say otherwise. We're only just now dropping support for IE11 everywhere. Maybe that's the light at the end of the tunnel? But I have my doubts. The incentives are too high for the web to fully standardize. Embrace-and-extend will continue. Developing for the web has never been more complex than it is today. The other bit of sad news is that the web is no longer open. HTML5 is not an open technology. It requires proprietary DRM which only a few companies allow you to use. > web analytics wasn’t really a thing I'm going to shed no tears when Google Analytics finally dies.

dahart 5y ago
> perhaps the worst crime against monitor tech: 16:9 aspect ratios. Not only is that aspect not "cinematic" (theatrical 16:9 does not exist), […] we could have much better vertical resolution if we stuck with 4:3. I’m confused by this. Film aspect ratios are even higher than 16:9, at 1.85:1 and 2.39:1. I don’t understand why you complained about 16:9 being not cinematic while suggesting 4:3 is better, could you elaborate?

SECProto 5y ago

> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? From this end user's perspective, Google Chat is functionally no different than ICQ or MSN Messenger were 20 years ago. Notifications show up on my phone screen instead of my windows 95 screen. And now we call them emojis and there are more of them. And Google chat has more lag (~1400ms) when I open a chat window from my contacts list. All while the functionality of getting some text from myself to my friends has stayed identical (actually decreased - I can't use custom fonts/bold/etc on the modern version)

dahart 5y ago
Is Google chat using more resources and draining perf? The UX of a chat app is somewhat of a straw man here. None of the chat apps you mentioned “can barely fit in a single machine” or “destroys performance”.
- dijit 5y ago
  ahem slack? But realistically Google chat uses more ram than the PC I used MSN messenger on even HAD. And msn was “hoggish” for the time.
  - dahart 5y ago
    Slack is vastly more functionality than MSN messenger. How do you know the RAM usage of gchat? I agree Chrome uses more (and again it’s a completely different ballgame than it used to be) than but where are you getting the chat specific app metrics?
    - dijit 5y ago
      > Slack is vastly more functionality than MSN messenger. I don't buy that. Because you can attach bots? or make calls, custom emoji? (you can do all of these on MSN) and more (like theme customisations and font changes!) > How do you know the RAM usage of gchat? You can see each tab's memory usage with Safari on MacOS as it's tied into the Activity Monitor. Google Cloud Console uses 989MB for me, for instance.

caeril 5y ago

Terminal emulation and text editors are the obvious ones, notably because DISPLAYING TEXT should be trivially fast in a world of multicore multigigahertz processors and GPUs with ridiculously fast shaders. Casey Muratori has been running down the insane failings of terminal emulation lately: https://twitter.com/cmuratori/status/1405342954194051073 https://twitter.com/cmuratori/status/1405342954194051073 https://twitter.com/cmuratori/status/1405347255511486464 https://twitter.com/cmuratori/status/1405347255511486464 Chaser: https://twitter.com/cmuratori/status/1405356794495442945 https://twitter.com/cmuratori/status/1405356794495442945 This is to say nothing of the fact that VSCode is the most popular editor on the planet and that the very notion of allocating several gigs of ram to embed a web renderer ( one that is constantly having to be patched for the annual round of UAF vulnerabilities ) in order to DRAW TEXT is the very height of inefficient idiocy.

dahart 5y ago
That’s a completely different issue than what parent suggested. Terminals aren’t using more resources, they are just going slow - on any hardware, due entirely to lack of devs engineering for perf. Since Casey’s posts, a bunch of terminals and editors have upped their game, started using the GPU for rendering, and are now both faster and more efficient. > allocating several gigs of ram to embed a web renderer […] is the very height of inefficient idiocy. No doubt theres bloat around, but I think you don’t understand web browser allocation strategies. Chrome, Firefox, and Safari are allocating enormous chunks of ram for both caching purposes, and rendering efficiency. It’s extremely difficult to know how much memory is really needed for any given app, you cannot make the assumption that the RAM reported for any given app or page has anything to do with how much the page itself asked for. You also lack justification for calling memory use idiocy if you aren’t running out of memory. As long as there is free memory in the system, it’s fair game, and does not represent inefficiency.
- fouric 5y ago
  > Terminals aren’t using more resources, they are just going slow "Going slow* is using resources. Clock cycles are a resource. > No doubt theres bloat around, but I think you don’t understand web browser allocation strategies. Using a web rendering engine to render a text editor is still bloated and inefficient. It doesn't matter if web browsers are intrinsically expensive - building a text editor using webtech is the incorrect design decision. > You also lack justification for calling memory use idiocy if you aren’t running out of memory. It should be obvious that the people here aren't complaining about applications that take a trivial amount of memory. In 2021, nobody cares about a text editor that consumes 8 MB of memory. People are complaining about applications that do take up a significant amount of memory and cause you to run out. Mozilla's Firefox hardware report[1] says that just under 25% of Firefox users have only 4 GB of installed RAM. If running on Windows, probably half of that is consumed by the operating system. Suddenly, a 400 MB Electron app is consuming a full fifth of your available memory. That's a real problem, especially for folks that either (1) don't have much money and can't afford a newer machine or (2) want to try to conserve the environment by not spuriously buying new hardware when the old stuff should work. > As long as there is free memory in the system, it’s fair game, and does not represent inefficiency. Maybe by your definition of "inefficiency". Most of the people in this thread are (apparently) using it to mean "using significantly more resources to provide functionality than are intrinsically necessary". This is a much more reasonable definition given that you don't actually know how many resources the user has. [1] https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware

fouric 5y ago

> Which software exactly is functionally the same yet consumes more resources? This is irrelevant, as it's extremely difficult to find any two pieces of software that are "functionally the same", regardless of their age of release or performance - and, moreover, because we're programmers, we can make informed estimates about the minimum performance impact of most features without just guessing. For instance, string localization should have no perceptible performance impact - it's literally just a key-value lookup (O(1) with a hash table). The additional features that Spotify provides over Audacious (a local Linux music player) are either not intrinsically computationally expensive (fetching audio over a network) or are done server-side (playlist recommendation). Discord has no technically valid reason to be taking up 15% of a CPU core while sitting in the background. And so on. > Today 4K is normal, and combined with refresh rates and colors, we’re pushing upwards of 2 orders of magnitude more data to our screens. We have GPUs that now do all of our graphics rendering work for us. The features implemented by Spotify, Slack, Discord, and Visual Studio Code do not intrinsically require enough graphical resources that they should stress even an older integrated GPU, let alone take 5 seconds to start up on CPU and RAM that are, similarly, one to two decimal orders of magnitude faster than what we had two decades ago. > YouTube and Netflix didn’t exist 20 years ago. Browsers were incredibly slow and couldn’t support streaming video or anything but the smallest of applications written in JavaScript. Localization didn’t exist, web analytics wasn’t really a thing, browsers didn’t run background tasks. None of this is relevant to applications. Browsers were slow back then? Fine. Browsers are faster now? Also fine. That's still irrelevant to the fact that many applications are slower now, on much faster hardware, than they were then.

dahart 5y ago
> This is irrelevant, as it's extremely difficult to find any two pieces of software that are "functionally the same" Yes, indeed. You're illustrating is why the post I replied to is a straw man argument. Most software, as you say, is not functionally the same anymore. > string localization should have no perceptible performance impact Yes, my argument was that we got localization without a noticeable perf impact. But it does consume memory, bandwidth and code size, and as you correctly point out, a small amount of compute. I would venture to suggest that rendering Asian fonts is a tad more involved than an O(1) hash table lookup. Localization is just one of hundreds of features we have standard now that we didn't have 20 years ago.

mdoms 5y ago

We don't even need to look 20 years in the past. Software performance has degraded significantly in just the past handful of years. Compare web applications like Facebook, Jira, Twitter and Reddit to the exact same websites 5-7 years ago. They have all implemented horrendously over-engineered, buggy and most importantly dog-slow single page apps to offer the same basic service.

badsectoracula 5y ago

> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Instant messaging. Even if we ignore applications like the original MSN Messenger, Trillian, etc, the original Skype before Microsoft's acquisition was much faster. Sure, it wasn't as fast as it could be - but still didn't had an entire browser wrapped around it nor needed checks 350MB of RAM and 7 background processes just to display an icon on the tray so i can send text messages and perhaps the occasional video call once every two years. And to be honest? I do not really find it that weird if a program needed some extra resources to make a video call - which is why LoadLibrary and (especially) FreeLibrary exist. But in practice that is never done or when it is done it is piled on top of an overengineered system to the point where it loses any benefits under the weight of the architecture astromancy. > if you don’t know or don’t pay attention what’s under the covers. Or don't care. Don't forget the don't care part! It is very important because a lot of the bloat is presented as "functionality" (which, assuming most people even care - and that assuming they'd know what they "pay" for it - often doesn't even need to be as heavy and bloated as it is). > One easy to overlook difference is displays. Aside from resolution, physical dimensions and thinness, displays are worse nowadays. Compared to CRTs they have bad contrast, often bad colors, increased latency (even the ultra-fast 144Hz+ ones), a fixed resolution with awful results if you try to use anything but the native, etc. Note that i'm writing this from a 165Hz 27" 2560x1440 monitor BTW with a few CRTs next to me connected on older systems. And BTW > It’s easy to forget that 20 years ago we had 800x600 screens, 24 bit color was not ubiquitous, and 60hz monitors were practically non-existent. That'd be 30 years ago, not 20. 20 years ago was the year 2001 :-P. While 800x600 was indeed common, it was pretty much as common as 1024x768. And monitors at 60Hz were not common because those would hurt your eyes - even standard VGA released in the 80s runs at 70Hz. But by 2001 pretty much every monitor was able of 85Hz and several went much higher (e.g. 120Hz for mine). > Today 4K is normal 4K is a tiny minority that is barely a blip in statistics. Here, check this: https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware This is Firefox's hardware statistics. The most common resolution, by far, is 1920x1080. The next most common? 1366x768! Both make about 64% of every web capable computer out there! And the resolutions after that are actually lower than 1920x1080 until you reach at around 2% for 2560x1440. Even among games where 4K has meme status, in Steam Hardware Survey you can see that only around 2.44% have a 4K monitor. There are more than three times more gamers using monitors less than 1080p that aren't 1366x768 or 1360x768! There will be several years before 4K becomes a normal on the desktop. Right now it makes way more sense to think about something like 1366x768 than 4K.

deleted 5y ago

[deleted]