4 ms·

> Now we measure things in GB units. 1000X bigger, but what was gained? Functionality and graphics. For instance 'dict.words' alone on Linux is 4.8MB. Arial U

> Now we measure things in GB units. 1000X bigger, but what was gained? Functionality and graphics. For instance 'dict.words' alone on Linux is 4.8MB. Arial Unicode is a 20MB-ish font. The icon for an application I work on is 400K. The Google Crashpad handler for handling crashes is somewhere around several MB. A 4K true color display is 138 times larger than 640x480x16 colors.

MonkeyClub 2y ago
>> Now we measure things in GB units. 1000X bigger, but what was gained? > Functionality and graphics. And massive amounts of telemetry. But now functionality is moving to the cloud, we'll just be stuck with gigabytes for graphics and telemetry.
berkes 2y ago
Let's ask the question differently: what problems were solved? With your examples, it could be: - introduce global spell checker. - have emoji? - fix blurry icons? - being able to search through crash logs? - not having to switch between windows. Do we need GBs instead of MBs for that? Why? Was that problem not fixed already? Could we not fix it in a way that didn't demand magnitudes more resources? I'm asking, because I highly doubt that there's a technical reason that requires an improved piece of software or a solved problem,to require magnitudes more resources. Sure, slack is far superior in UX to IRC. But could we really not get that UX without bloatware hogging my CPU, taking hundreds of MBs installation size and often biting off significant chunks of my memory? Is that truly, technically impossible?
- dale_glass 2y ago
  > Let's ask the question differently: what problems were solved? A few more: * Seamless internationalization. If you're a native English speaker you probably never experienced the "fun" of dealing with French and Russian in the same text document. Pre-Unicode supported English + one other language, if that other language wasn't too weird. * Lots of tiny life quality improvements. Eg, not seeing windows repaint costs a LOT of memory. Every window is present in RAM even if not being looked at so that when you switch to it you never see it paint. * Stability. Windows 9x tried to be frugal by keeping a copy of everything in system32. That was called "DLL hell". So the current standard is that the app just packages every framework, so you may have a half dozen copies of Qt easily. > Do we need GBs instead of MBs for that? Why? Well, let me look at my AppImage: 3.8 GB total. 2.3 GB of dependencies. 2.1 GB is libnode, 128 MB is Qt Webengine. 1.4 GB application. 126 MB of JavaScript and UI images. The rest is mostly code.
  - berkes 2y ago
    My point is that we are improving the experience. But that the "cost" to do so, isn't what's technically required to improve it. You can achieve all these improvements, solve all these problems, probably without much more resource usage. Or negligible added resource usage. Therefore my conclusion is that the reason e.g. slack usage x1000 what my old IRC or Jabber cliënt used, isn't technical. It's a deliberate choice made for reasons of budget, time to market or another trade-off. I'm certain that Slack could build a client that does all what slack does, in a client that's hundred(s) of times snappier, smaller, less CPU and memory using. But probably not with their current pace, budget, team or wages.
    - dale_glass 2y ago
      > Therefore my conclusion is that the reason e.g. slack usage x1000 what my old IRC or Jabber cliënt used, isn't technical. It's a deliberate choice made for reasons of budget, time to market or another trade-off. That was never not the case. Jabber makes a big usage of XML, which back in the day was very much seen as overkill. It requires a pretty complex parser, and increases the amount of data considerably. They could have gone with a much more compact binary protocol with ID/length/value pairs, where there's not even field names, but say, a 16 bit integer where IDs are allocated from a central registry. Even going back to DOS, you could shrink a program with measures like outputting "Error #5" instead of "File not found", and require the user to look up the code in a manual.
  - goalieca 2y ago
    I don’t know about nextstep but macOS had all this stuff when I first used it 20+ years ago. It featured compositing rendering, had the apps, supported ppc/x64 in an app image, had a microkernel. I even remember it got an emulator for running ppc code on an x64. The newest macOS still needs more memory and suffer bloat but 8GB is still perfectly useable if you avoid google chrome. 8GB is also perfectly usable for Linux too.
    - skydhash 2y ago
      My SO's laptop is an intel MBA with 8GB of ram. Everything's fine until Google Chrome starts (some work tools). Even if the cpu is not as efficient as the m-series, it runs quite well, even with the tropical weather. But launch Chrome and you have a toaster.
- Rury 2y ago
  The problem is that everyone here is looking at it from a software design standpoint, not a software development standpoint. Once you look from the latter it's obvious why things are the way they are: businesses are trying to cheapen out on software development costs. As a result, software quality cheapens. For example, if disk space is abundant and very cheap, and optimizing software to use as little as disk space as possible is relatively more expensive than throwing more disk space at the problem, you shouldn't be surprised that software starts using more disk space than necessary, because what's being optimized is software development costs.
giantrobot 2y ago
While plenty of software is overly fat, you hit the nail on the head. A Word document isn't just text and some formatting sigils. Editing isn't just appending bytes to the end of a file descriptor. It's a huge memory structure that has to hold an edit history so undo and track changes works, the spelling and grammar checker needs to live entirely in RAM since it runs in realtime as you edit, and the application itself has thousands of not millions of allocated objects for everything from UI elements to WordArt. The rendering engine needs to potentially hold a dozen fonts in memory for not just the system but any specified but not immediately used fonts from the base document template. It's not like Google Docs is any lighter on RAM than Word. Features require memory. Fast features are usually going to require more memory. People can use AbiWord if they want a much slimmer word processor. They could also just use nano and Markdown if they wanted even slimmer. But a lot of people want document sharing over the Internet with track changes, grammar checking, and the ability to drag in and edit an Excel spreadsheet. The features used in native software follow a bathtub curve. But not just one but several. No two groups necessarily use the same sets of advanced/uncommon features.
- ptx 2y ago
  > the application itself has thousands of not millions of allocated objects for everything from UI elements to WordArt There are ways to optimize those things, though, which developers might not be bothering with anymore. The Design Patterns book used a word processor as the example when explaining the flyweight pattern for efficiently representing lots of objects. OLE objects like WordArt support different states[0] and don't necessarily have to be active at all times. [0] https://learn.microsoft.com/en-us/windows/win32/com/object-states https://learn.microsoft.com/en-us/windows/win32/com/object-s...

MonkeyClub 2y ago

>> Now we measure things in GB units. 1000X bigger, but what was gained? > Functionality and graphics. And massive amounts of telemetry. But now functionality is moving to the cloud, we'll just be stuck with gigabytes for graphics and telemetry.

berkes 2y ago

Let's ask the question differently: what problems were solved? With your examples, it could be: - introduce global spell checker. - have emoji? - fix blurry icons? - being able to search through crash logs? - not having to switch between windows. Do we need GBs instead of MBs for that? Why? Was that problem not fixed already? Could we not fix it in a way that didn't demand magnitudes more resources? I'm asking, because I highly doubt that there's a technical reason that requires an improved piece of software or a solved problem,to require magnitudes more resources. Sure, slack is far superior in UX to IRC. But could we really not get that UX without bloatware hogging my CPU, taking hundreds of MBs installation size and often biting off significant chunks of my memory? Is that truly, technically impossible?

dale_glass 2y ago
> Let's ask the question differently: what problems were solved? A few more: * Seamless internationalization. If you're a native English speaker you probably never experienced the "fun" of dealing with French and Russian in the same text document. Pre-Unicode supported English + one other language, if that other language wasn't too weird. * Lots of tiny life quality improvements. Eg, not seeing windows repaint costs a LOT of memory. Every window is present in RAM even if not being looked at so that when you switch to it you never see it paint. * Stability. Windows 9x tried to be frugal by keeping a copy of everything in system32. That was called "DLL hell". So the current standard is that the app just packages every framework, so you may have a half dozen copies of Qt easily. > Do we need GBs instead of MBs for that? Why? Well, let me look at my AppImage: 3.8 GB total. 2.3 GB of dependencies. 2.1 GB is libnode, 128 MB is Qt Webengine. 1.4 GB application. 126 MB of JavaScript and UI images. The rest is mostly code.
- berkes 2y ago
  My point is that we are improving the experience. But that the "cost" to do so, isn't what's technically required to improve it. You can achieve all these improvements, solve all these problems, probably without much more resource usage. Or negligible added resource usage. Therefore my conclusion is that the reason e.g. slack usage x1000 what my old IRC or Jabber cliënt used, isn't technical. It's a deliberate choice made for reasons of budget, time to market or another trade-off. I'm certain that Slack could build a client that does all what slack does, in a client that's hundred(s) of times snappier, smaller, less CPU and memory using. But probably not with their current pace, budget, team or wages.
  - dale_glass 2y ago
    > Therefore my conclusion is that the reason e.g. slack usage x1000 what my old IRC or Jabber cliënt used, isn't technical. It's a deliberate choice made for reasons of budget, time to market or another trade-off. That was never not the case. Jabber makes a big usage of XML, which back in the day was very much seen as overkill. It requires a pretty complex parser, and increases the amount of data considerably. They could have gone with a much more compact binary protocol with ID/length/value pairs, where there's not even field names, but say, a 16 bit integer where IDs are allocated from a central registry. Even going back to DOS, you could shrink a program with measures like outputting "Error #5" instead of "File not found", and require the user to look up the code in a manual.
- goalieca 2y ago
  I don’t know about nextstep but macOS had all this stuff when I first used it 20+ years ago. It featured compositing rendering, had the apps, supported ppc/x64 in an app image, had a microkernel. I even remember it got an emulator for running ppc code on an x64. The newest macOS still needs more memory and suffer bloat but 8GB is still perfectly useable if you avoid google chrome. 8GB is also perfectly usable for Linux too.
  - skydhash 2y ago
    My SO's laptop is an intel MBA with 8GB of ram. Everything's fine until Google Chrome starts (some work tools). Even if the cpu is not as efficient as the m-series, it runs quite well, even with the tropical weather. But launch Chrome and you have a toaster.
Rury 2y ago
The problem is that everyone here is looking at it from a software design standpoint, not a software development standpoint. Once you look from the latter it's obvious why things are the way they are: businesses are trying to cheapen out on software development costs. As a result, software quality cheapens. For example, if disk space is abundant and very cheap, and optimizing software to use as little as disk space as possible is relatively more expensive than throwing more disk space at the problem, you shouldn't be surprised that software starts using more disk space than necessary, because what's being optimized is software development costs.

giantrobot 2y ago

While plenty of software is overly fat, you hit the nail on the head. A Word document isn't just text and some formatting sigils. Editing isn't just appending bytes to the end of a file descriptor. It's a huge memory structure that has to hold an edit history so undo and track changes works, the spelling and grammar checker needs to live entirely in RAM since it runs in realtime as you edit, and the application itself has thousands of not millions of allocated objects for everything from UI elements to WordArt. The rendering engine needs to potentially hold a dozen fonts in memory for not just the system but any specified but not immediately used fonts from the base document template. It's not like Google Docs is any lighter on RAM than Word. Features require memory. Fast features are usually going to require more memory. People can use AbiWord if they want a much slimmer word processor. They could also just use nano and Markdown if they wanted even slimmer. But a lot of people want document sharing over the Internet with track changes, grammar checking, and the ability to drag in and edit an Excel spreadsheet. The features used in native software follow a bathtub curve. But not just one but several. No two groups necessarily use the same sets of advanced/uncommon features.

ptx 2y ago
> the application itself has thousands of not millions of allocated objects for everything from UI elements to WordArt There are ways to optimize those things, though, which developers might not be bothering with anymore. The Design Patterns book used a word processor as the example when explaining the flyweight pattern for efficiently representing lots of objects. OLE objects like WordArt support different states[0] and don't necessarily have to be active at all times. [0] https://learn.microsoft.com/en-us/windows/win32/com/object-states https://learn.microsoft.com/en-us/windows/win32/com/object-s...