Windows 11's built-in Weather app wastes more than 1 GB of RAM | Hacker News Reader

Windows 11's built-in Weather app wastes more than 1 GB of RAM

notebookcheck.net

671 pointsakyuu598 comments

My gaming PC that I built in January 2006 that IIRC I used to simultaneously run Battlefield 2, Trillian, Xfire, Thunderbird, and Winamp with a 1680x1050 monitor had 1 GB of total system RAM.

Fun fact, one of the XFire cofounders won Carmack's Ferrari at a Quake Tourney:

https://en.wikipedia.org/wiki/Dennis_Fong#/media/File:John_C...

take me back

Haiku OS is trying.

Trillian, good old days. Still remember my icq number

Think about all the performance you could have gained by instead running Trillian and Winamp on an old Thinkpad next to you with even less ram

Some of us still know how to write software like that. And enjoy doing it.

I made a little conference schedule app a few weeks ago for a conference I was at. I used my own rust UI toolkit, which calls in to cocoa to make use of native UI components. The resulting binary is about 500kb and it uses a couple megs of ram while running. It looks and feels like a totally native iOS app. As far as the OS is concerned, it is.

Even 500kb feels too big for what it is. I’m rewriting the core at the moment, and I think it’ll be more efficient as a result. But I’m still pretty happy with it.

Is your UI kit open source? I do think calling into the native OS toolkits is the way to go, when they exist.

I'm curious if you use winit for windowing, or something lower level that's just mac specific.

I ported the leptos rust web framework to run on native platforms. Currently it works on ios, macos and linux (GTK). Eventually want to also add support for windows and TUI as well. It uses taffy for layout - which gives you the same flexbox and grid layout engines that web browsers use. Components are all fully native for the platform, via their corresponding binding crates (objc, gtk4, etc).

UI library is here: https://github.com/josephg/leptos-native

And here's the schedule viewer app I made with it. It runs silky smooth on device: https://github.com/josephg/dweb-sched

The whole project is currently experimental & vibe coded. It's missing a lot of components, and it has bugs. I'm currently rewriting it by hand to do it properly.

SwiftUI’s diffing is such a mess that I wouldn’t be surprised if fine-grained reactivity of a toolkit binding UIKit like this worked better. Do you have decent support for long lists via UITableView yet? Edit: it seems so!

Yeah! I added it for my ios scheduling app.

I tried to learn SwiftUI a few years ago. XCode was horribly slow, and it would hang and crash all the time, even when working on small example projects. I'm excited by the thought that I can use any rust IDE to write UI code. Rust's compiler, toolchain and IDEs seem way more reliable.

The view! builder macro at the moment is designed to look like JSX, since it was ported directly from leptos. But I'm considering dropping the jsx and using a fluent API. Something like this:

    let count = RwSignal::new(0u32);

    let view = vstack().padding(16.0).gap(12.0)
        .child(label().text(move || format!("Count: {}", count.get())))
        .child(
            hstack().gap(8.0)
                .child(button()
                    .on_click(move |_| count.update(|c| *c = 0))
                    .text("Clear"))
                .child(button()
                    .on_click(move |_| count.update(|c| *c -= 1))
                    .text("-1"))
                .child(button()
                    .on_click(move |_| count.update(|c| *c += 1))
                    .text("+1"))
        );

Code is a bit less readable like this, but autocomplete and cmd+click all works out of the box in your IDE.

AI writes code like that, but people get pretty upset hearing it.

The program that I use to manage my small business, basically a GUI wrapper on an sql DB is a total delight to use, because everything happens instantly. Even opening it is instantaneous.

Modern software is such a bloated mess that you kind of get used to a 20 second start-up and a .25-1 second delay on every action. Then you use something that isn't bloated junk and it feels like actual magic.

What happens if you keep asking AI to rewrite it to use less and less resources?

It’s actually pretty good at this if you have some very specific constraints and objective.

I find I get great results from explicitly asking an LLM to write tests which profile memory and cpu usage. Then ask it to optimise to improve those metrics.

And a way for it to get actual measurable results / feedback loop, which is apparently quite tricky even for humans to get.

tbh, it probably works. I'm vibe-coding a thing and just told it to figure out why it runs so slow: put in some optimizations. It ran some tests and stopped loading an entire-something at opening because there's no value to doing that.

It does a pretty good job being put into a loop of "try to optimize for X" then "test and audit your code" then repeat.

This: https://news.ycombinator.com/item?id=49226923

Fans went crazy when loading the browser demo

just be aware of the exact prompt:

"memory usage is important": creates a 1TB binary

"take multiple steps": uses so much power, extreme global warming, it will just print "hot"

"think outside of the box": it will enslave you so you will not care about weather

> AI writes code like that, but people get pretty upset hearing it.

Yeah, people get upset when you spew out total bullshit.

I work as a performance specialist and "AI writes code like that" is utter nonsense. AI writes the same terrible performing code that was the mediocre developer standard on Stackexchange and other codebases it ate.

You still need a lot of vigilance and time to make well performing software and most software engineers just don't give a damn if we don't outright block their PRs/feature launches before passing performance tests.

LLM coding assistants have a bias towards writing standalone implementations instead of pulling in libraries to do a job, which does tend to sidestep probably the most common cause of bloated software: pulling in too many layers of abstraction. Most software can be pretty damn fast (at least as far as users are going to notice) without needing too much of a focus on optimization, but just by not accidentally screwing it up.

Just writing your own bloat is not the way to go though, especially when it makes the codebase quickly balloon...

performance specialist, really?

Yes.

>> AI writes code like that, but people get pretty upset hearing it.

To this day I never saw an AI write anything less than a 3Mb binary. Do you have specific examples in mind, and if so, can you share them?

Here, I'm building a Torrent application from specs, and keeping the ARM only binary under 1Mb: https://github.com/josusanmartin/rustorrent

It's fully vibecoded, and quite functional, although I'm still working out some bugs.

AI currently writes median-good code which is by definition better than the worst developers' code.

In order to push beyond that (e.g. architecture, size, performance), the human has to bring the constraints. There's only so much AI can/should default assume from "write code for me" (which I expect a lot of bad / non-HN developers are doing).

It is exciting that there's an opportunity for global improvement though! After the general model improvement pace slows, expect there will be a lot of room for code gen AI optimization, and if "write code for me" can be made to generate more efficient code... suddenly all AI-generated code (read: most code) will improve.

Shit code is out in the wild because the company decided to optimize for programmer labor cost instead of code efficiency. If instead apples:apples because AI code gen is being used both ways, everyone wins.

Feels like what I imagine were the early days of optimizing compilers, when I'm sure there were a large number of really bad assembly programmers out there.

AI doesn't get tired. I can tell it to profile the application and find quick wins and it usually does a decent enough job.

I am sure that's true if AI writes it, but what if YOU use AI to type it?

AI does this when it's not warranted, and even happily writes two functions with the same purpose.

Forty functions with the same purpose are still better than importing react.

What do you mean my hook to dynamically build <span contenteditable="true" style="border: 1px dashed #ccc; padding: 4px 8px; border-radius: 4px;">input your username here</span> with inline CSS is worse than using <input>? All I need to do next is to listen to form submit to build a new formdata object to POST to the server. Easy!

Yeah, hence why for one kind of like the way RAM prices are going, maybe it forces the industry to re-learn best practices and "bio-programming" instead of "fast-food programming".

I remember within the last decade noting that minesweeper from the windows store took more space than a pretty damn healthy Win98SE install (with minesweeper)...

Yeah, but minesweeper was like 95% of Windows 98.

Gray on gray is pretty resource hungry.

And you need code to handle device orientation, in case the PC Tower is flipped on the side.

I just set up a web server for a hobby project on a $10 Dell PC that has 2GB of RAM welded to the board. After booting Debian 13 it still has 1.6GB of free RAM.

In fact, that seems a lot. Back in ~1996 I was running one of the EFnet servers on a Compaq with 8MB of RAM.

I still miss Battlefield 2. There is really nothing like it today, not even close. The dynamics with squads and a commander and A+ physics and overall game balance remain unmatched for all FPS games.

Fortnite, PUBG, COD, all are disgraceful in comparison.

Check out BF2Hub. The community isn't big, but you can generally find a server or three with real players in it (just look for players with a ping; 0 ping means a bot).

I miss the squad gameplay of Battlefield 2 too. It hasn't been replicated since, in my opinion, and subsequent Battlefield titles changed the classes and made the available loadout options too flexible to require specialized play.

BF2 was great, BF3 was definitely better, not that there was anything at fault of BF2.

I disagree with Fortnite and PUBG, whilst PUBG is a little clunky it did usher in a completely new game style AND importantly introduced much better situational audio which other games didn't have.

I personally would attribute the better audio more towards Arma that PUBG was born from.

BF2 and Battlefield: Vietnam were my top 2 BF games. Loved the radio in BF:V and the ability to airlift stuff. Also, I really enjoyed the commander mode in BF2, that was ahead of its time.

>Completely new gamestyle

It might have popularized it, but PUBG was far from the first 'Battle Royale' game. Hell...I think it goes to those old Minecraft "Hunger Games' servers, but I'm sure it predates even that

Miss BF2 too. Sank way so many hours into that game as a kid. Still remember the wonderful loading music. 2142 was great too.

I'll never forgive EA for C&D'ing the community efforts to revive the servers. Fuck EA.

There is a game called Squad that has a lot of similarity to BF2 in terms of teamwork and coordination. It's a spiritual successor to the BF2 mod called Project Reality.

Before I built a gaming computer circa 2004 I daily drove my family's old beige box that had a 350Mhz Pentium II with 64MB of RAM and Windows 98. I remember running CDex (because ripping CDs was all the rage), Trillian, and ZDaemon all at the same time without a hiccup. What a time to be alive!

I was replaying Xenoblade Chronicles on my Switch 2 and the whole time I was thinking about how this ENORMOUS, open world game originated on the Nintendo Wii, a console with only 88 MB of RAM.

With an OS the PC requeriments for that game under Windwos XP would have been like 256MB/384MB.

And I bet you that I could still fit an XP-era weather app or widget on top of XP and Xenoblade inside that 256/384MB of RAM.

Super Mario Brothers is none of that, but fits in a 40kB ROM and a few kB of RAM.

Atari 2600 titles are between 1 and 4Kb and have 128 bytes of RAM. Still enough for some quality entertainment back in its time.

They're pretty seriously limiting though when you actually look at those games. The GameCube/PS2 is probably the era where hardware was finally good enough to make the game you wanted.

Some of those games are remarkably fun and addictive though. It's difficult to take an arbitrary spec and say that's 'good enough'. For some it's too much, others still want more. Depends on the kind of games you want.

2 years ago I stated that we should stop worrying about software consuming a lot of ram.

I had just built my pc with 128gb of ddr5 ram spending less than an average android phone (I think like $300).

I would like to retract that statement. Thanks.

On the flip side, high 5 for getting 128gb of RAM at exactly the right time!

The pricing differential is just absurd now. I expanded the memory on my math clusters about 2 years ago so I would have 4 machines with 1.5TB of DDR4 memory each. Back then a 128GB DDR4 DIMM could be found for $150 used. Now those same DIMMs are $600-$800 used! I think the RAM in my homelab is worth more than all of the other hardware combined.

  I stated that we should stop worrying about [X] consuming [finite resource].

Why would you ever say something like this? When was that ever true?

It's true when [finite resource] is indistinguishable from [infinite resource], meaning it's abundant, cheap, and can be used recklessly with no impact.

Aside from air, ocean water, sunlight, and a few types of rocks, I don't know if that's ever the case. Pretty much as soon as something is declared "free", people will consume so much more than you could have ever imagined.

I didn't say it was actually infinite, just that it felt infinite. When it feels infinite, people will abuse it, making it feel finite again the hard way

this post was sponsored by SK Hynix

In 2018 when Windows and macOS used 2GB just after boot, I tried Arch Linux and with a neat window manager (dwm) a clean boot was using just 300MB, that means our OS is wasting just too much RAM for nothing. This year with Fedora Atomic 44 + Niri is using 800MB, so I can give a second life to my old device from 2013.

That's because programmers in 2006 didn't understand programming. They didn't understand how to make their software better.

Real programming means writing your own javascript glue, pulling in hundreds of supply-chain-compromised js libraries that you never inspect or profile, and running the whole thing in a browser engine, while making sure to store all state in the cloud.

The modern breed of programmers who don't understand programming have switched from C and C++ to Rust and Go, so they're on the right track of using more resources to improve the developer and user experience, but they haven't gone nearly far enough. They still do dumb things like write efficient code, and profile and put effort into reducing binary and resident size. They should trust in javascript and the browser and the internet, like all good programmers do.

Zig programmers have completely lost the plot. They're of the type that tries to write "hello, world" manually rather than pulling in a third party library so they can efficiently call helloWorld(). Writing single-binary apps that fit on a floppy? Who even cares? What even is a floppy? How do they call themselves programmers without css and advertising telemetry?

username checks out

rust programs are a lot of times faster and orders of magnitude safer than C and C++ counterparts... where is your data to support your assertion that rust programs use more resources than C and C++ programs?

>rust programs are a lot of times faster [...] than C and C++ counterparts

Troll post? Or has fanboyism really gone this far?

It's often basically true though - the guarantees that rust can make wrt to lifetimes and memory allocation clearly enable programs to allocate less and be more aggressive with what they do allocate (all while being a fairly high-level language - I don't know if most rust programmers actually know what memory safety is at this point)

I'm really not a huge fan of rust as a language but it is clearly delivering results in that e.g. I find myself actively hoping that people rewrite web tooling in rust and so on. C++ is a mess that should be allowed to die.

> it is clearly delivering results

Yeah, there are some results in Firefox and some results in Mesa and some results in the linux kernel, but that's about all.

Rust is much less likely to have heap leaks.

Some programmers import a sarcasm library while others could write their own.

Truly poor quality bait here.

2026 programmers also look down on 2024 programmers, these guys didn't understand you can get an intern to vibe code the hole thing in a week and run it in kernel mode on half of the machines in the world the following week (after another mandatory reboot).

2006 programmers - smooth brained - they don't understand now you can just have an 'agent' code for you using piles of JS and massive dependencies. if the app breaks then the agent can fix it for you.

Dang... I use zig at work to write single binary apps and I know what a floppy is. I feel personally attacked.

Back then we had constraints. That made us better programmers. We had to think about every database call and network call. No one cares about that now until it compounds to broken software - like Windows.

An amazing thing I was reminded of just yesterday is that COD4:Modern Warfare ran on the PS3, with 256MB RAM.

Putting aside the fact that it is horribly bloated. Accurately measuring RAM usage is tricky, there are several measurements, and no "right" one.

It is clear from the article that what eats up so much RAM is not the weather app itself but the framework it runs on. There is a "Renderer", a "GPU Process",... eating most of it.

The thing that the task manager doesn't tell you is whether or not these are shared components. It may be that the 662 MB used by the "Renderer" is shared between many Windows components, so killing that Weather app may not reclaim as much space as you may hope, instead, it would require killing every user of the component, some may be core system apps.

In addition to the distinction between private and shared memory, there is also the distinction between actual RAM usage and and virtual memory. It is possible for a process to memory map a 100 GB file. If you look at the address space, it will take 100 GB more of virtual memory, even though it may be actually zero physical RAM, but it is not always zero either, the parts of the file that are currently accessed take up some space, which may later be reclaimed by the OS by committing the page to disk.

Even the most obvious "I do a big malloc()" kind of memory use is not that obvious, the OS can overcommit, put stuff into swap, use memory compression, etc... And it can do that even if the system is not overloaded, as to make more space for the disk cache for instance.

So seeing "1 GB" in the task manager is just a vague hint of how it may affect performance. And not all "task manager" tools give the same value for the same program (so Windows vs Mac may be misleading). "Process Explorer", a more advanced version of the Windows task manager can give a lot more details, with different values of memory usage depending on what you are looking at.

> the 662 MB used by the "Renderer" is shared between many Windows components

Fine, shutdown the weather and stock ticker apps.

> It may be that the 662 MB used by the "Renderer" is shared between many Windows components

From the screenshot in the article, this is the memory usage of the Renderer process spawned by the Weather App. I find it very unlikely that some other app (say, the Copilot app) can then piggyback on Weather Renderer process. Do you have a source for this?

> killing that Weather app may not reclaim as much space

Closing the weather app on my PC does in fact kill all child processes and frees up around 1GB of committed RAM. Are you not seeing the same?

I am not on Windows 11 so I can't really tell. And even if I did, I may be in a different situation than yours, we may not be running the same apps so what is shared can be different.

As for the "piggybacking" it is not really piggybacking, it is how shared libraries work (emphasis on the "shared"), aka. DLLs on Windows. For instance, if 2 to processes load "library.dll", it will be only loaded once, and the read-only parts of the library will be shared between the processes and it is one of the big advantages of shared libraries over static linking. A major part of the Weather app bloat comes from the browser engine it comes with, something many apps do today, and it would be reasonable to think that 2 apps using a browser engines have components in common.

Anyway, if you run Process Explorer and check the weather app process, it will tell you which is which.

This, by the way is a big reason why modern apps are often so bloated. The real problem is not just that so many apps are using browser engines or other huge dependency chains, it is that they all ship with their own version instead of using what is available on the system, so you have 10 different browser engines loaded in RAM even though a single one would be enough. Traditional Linux distros do it right, but now we have containerized application that break sharing. I understand the convenience, as you don't have to deal with shared library update that break the app, but the cost in both RAM and storage space is significant.

Additional constraint here: it's not just browser version. Processes have to refer to the same disk location for sharing to work. Given that each ships the full set of dependencies disk location will never match (except for their own child processes).

> The thing that the task manager doesn't tell you is whether or not these are shared components. It may be that the 662 MB used by the "Renderer" is shared between many Windows components, so killing that Weather app may not reclaim as much space as you may hope, instead, it would require killing every user of the component, some may be core system apps.

It is the other way around, shared memory causes Task Manager to _underestimate_ memory usage. Task Manager's default views report the process private working set, no shared memory included. This means that 662MB is the _minimum_ amount of memory commit that would be released by ending the process.

> the OS can overcommit

Windows does not allow overcommit by default. It may compress or optimize memory allocations to reduce the physical working set, but the kernel will start failing memory allocations once physical + swap is exhausted regardless.

> It is clear from the article that what eats up so much RAM is not the weather app itself but the framework it runs on. There is a "Renderer", a "GPU Process",... eating most of it.

You say tomato we say tomahto

At the end of the day bloated app is a bloated app its consequences are the same.

10 apss using 100mb each plus 600mb shared use less ram than 10 apps using 200mb each.

Tis not shared

Still goddamn bloat. No amount of sharing will change that.

The weather app itself and the framework it runs on are the same thing when talking about resource usage.

Not when the "framework" resources are shared between multiple apps using the same framework. This doesn't seem to be the case here though.

Separate Renderer and GPU Process is just typical webview2/electron

It used to be shared, but vast amount of insidious attacks like Heartbleed forced web engine developers to force strict isolation between everything

Only working memory (the writable part) has to be isolated between users of a shared component. Modern OSes and MMUs do it well. 2 processes using a shared OpenSSL library won't be able to peek at each other. At best, one process may be able to see that the other is using the library by doing some performance analysis, but working data never crosses border (barring a hardware or kernel-level bug).

It is not a problem of data going across process borders, it is about guaranteeing that each dependency is at the version for which the app has been tested with. From a security standpoint, it has pros and cons. The pro is that it is easier to qualify, and it makes the app less susceptible to system-level attacks and regressions. The con is that should a vulnerability be discovered in a dependency, it won't be fixed by a system update, you have to integrate the fix yourself and make a new release.

> It is clear from the article that what eats up so much RAM is not the weather app itself but the framework it runs on. There is a "Renderer", a "GPU Process",... eating most of it.

Got a bit confused by this, because nowhere in the article are the words "Renderer" or "GPU". Regardless - all processes that comprise the app are the app, not just the parent process.

When I run it locally and check in procexp it has 8 webview subprocesses and all together it's using similar if not higher levels of memory than claimed in the article. Private Bytes is over a GB in total. I expect the webview processes are sharing memory for DLLs though.

> It may be that the 662 MB used by the "Renderer" is shared between many Windows components, so killing that Weather app may not reclaim as much space as you may hope, instead, it would require killing every user of the component, some may be core system apps.

Bet one’s ass that “Renderer” sub-process is embed browser engine allocating working memory for rendering of web app page layout.

Easy workaround for this:

1. Install uBlock Origin in Edge.

2. Start Edge, browse to MSN Weather.

3. Click the "Add an Application" button in the address bar to get a Start Menu icon for the page.

4. Delete the in-box Weather app icon.

Now you get the same Weather app in about 130MB of RAM, with no ads. It's not as nice as a native app, of course, but it's 1000% better than the useless ads and MSN feed that you can't block from the built-in Weather icon.

(Also, go into Widget settings and turn off "Discover / Microsoft Start feed". Same crap, different surface. Get rid of it.)

1. install ublock origin on Firefox.

not even being annoying, edge is removing manifest v2 very soon, breaking proper ad blocks just like chrome

Firefox doesn't support PWAs on desktop and removed their previous self-designed equivalent years ago. It's the reason Brave is still running in the background on my machines.

>Firefox doesn't support PWAs on desktop

Are you sure? I still see the "add tab to taskbar" option in the address bar and clicking it open the tab in a new window and shows a popup to pin the tab to the taskbar.

Hmm, after looking around a bit, it looks like they added it (back) to Firefox for Windows, but not for other desktop platforms. Maybe one day.

I wonder how this approach is having such an high reduction in memory usage compared to what’s stated in the article. I would assume both use the exact same WebView here.

The only explanation here that I can think of would be that the “Add an application” starts it under an existing Edge process which shares it’s memory instead of completely isolated.

Yes, using an already-running Edge instance saves a bunch of memory. Also, this approach has the advantage of allowing all of your browser extensions to modify your Web-App experience. WebView2 doesn't relay Edge extensions.

WebView2 has some memory optimizations across several WebView2 instances, so it should save memory once you have multiple WebView2 apps running.

waiting for a quick simple straight forward tool on github that takes care of this... Anyone?

https://github.com/pbatard/rufus/releases

https://unetbootin.github.io/#distros

The weather app isn't a native app either:

> According to Windows Latest, the high memory consumption is due to the fact that Weather is not a fully native Windows application. Instead, it is essentially an MSN Weather web app built on Microsoft's WebView2 framework. Task Manager shows multiple Chromium-based subprocesses running simultaneously, which contributes to the unusually high RAM usage.

If you have Edge or Chrome open (or anything else that similarly uses Chromium) then the incremental increase in RAM usage from the Weather app is likely much smaller than the headline 1GB.

Shared memory is a separate column, so no

> Easy workaround for this

Wipe Windows from your machine. Use Arch Linux. Problem solved.

I too want to shout how it's the Year of the Linux Desktop but I've been fighting mate-clock-applet recently. It has a memory leak, somewhere, and it slowly consumes RAM.

Normally though it's ~65 MiB for both clock & weather.

Also mate-screenshot is leaking RAM/processes. About ~40 MiB leaked per screenshot.

These things do tend to get fixed over time, though.

Been using Gnome on Arch, it's been unbelievably stable

The most-difficult part of installing any Linux distro is getting the motivation to create the boot media. Luckily for Ubuntu (I'm running v26) you can use an old HD or USB and then [your flavor of LLM] to then walk you through the steps on how to make the media bootable (at least: that's what I did). I am a bluecollar electrician (yes, it took me a few tries; yes, I accidentally fucked up my first few OS's doing stupid not-recommended shit).

----

Highly recommend Ubuntu; I've dabbled in the past, but the fact that AMD and nVIDIA drivers are pre-installed, in a user-friendly GUI installer... is what has helped me make Linux my main desktop (over the past half-year). Bought a Microcenter prebuilt and never even booten Win11 (straight to Ubuntu installer).

Over the past three decades, I have really tried to like several Linux'es, but have always reverted to (e.g:) Win7 or MacOS. Being able to run local LLM-models is what led me to Ubuntu (RX580->VEGA64->5070Ti)... it's been a journey =P

Agree with this. As much as Ubuntu is derided for several reasons, it just works. I tinkered with different distros for years, and while it was super fun, I wasn't very productive. Ubuntu and Fedora are the only distros where stuff just worked for me.

I've been using Ubuntu since around the time you needed an invite to create a Gmail account. Back then it was a breath of fresh air, because the install was batteries-included and Canonical's help forums were genuinely useful.

Ubuntu is bloated now but still just about OK despite:

* Snooping on users. * Forcing people to install Snaps. * Relentlessly promoting systemd, which turned out to be a giant mistake. * Pointless fiddling about with the desktop in every release. * Canonical having a universe-class egomaniac for a CEO, even by South African tech-billionaire standards.

But if Ubuntu has been treading water for 25 years, that represents an improvement over the titanic disaster that is Windows 11, and the walled-garden den of developer hostility that is Apple.

Sidenote: "AMD Drivers", in the sense of "something you have to download and install manually", are not a thing any more, fortunately. It's just nvidia now.

In Debian, even nvidia drivers are part of the OS repositories, albeit in the non-free category which is not enabled by default. I would be surprised if Ubuntu did not have them too.

What if they had usb drives with Linux installers in blister packs at electronics stores?

I would have paid $19.99USD for this. For serious.

Seems like an obvious fundraising avenue (for Ubuntu Foundation).

Bootable media isn't that difficult. You need the right tool. Not sure what's current on Windows; I used Etchdroid recently. And you need a spare USB drive. That's the most annoying part. And you need to download the OS. And then you use the tool to put the OS on the drive.

I find that Rufus (https://rufus.ie/en/) is excellent for writing USB disks. I believe it's Windows/DOS only, but even as a Linux user for several decades, I boot into Windows just to run it if I need to burn an installer.

On Linux if you're comfortable with the command line use "sudo dd"

I've tried that previously (or sudo dcfldd to give better feedback), but it doesn't always seem to work for ISOs. Ironically, I've had issues writing Linux ISOs onto a USB stick under Linux, so nowadays I just use Rufus which has never failed me.

I've installed a few SBCs and they don't tend to have an issue booting, so I do use dd/dcfldd for those. I wonder if it's because they use SD cards that they don't have an issue.

Doesn't help if in the end most GUI applications even on Linux, are Electron junk like this weather app, as this lack of respect for the user is everywhere.

"I know web, I deliver packaged web".

Yeah but instead of “hostile OS, hostile applications, subpar applications”, you can reduce it to just “occasionally subpar applications”.

Getting off a hostile OS should be such an obvious choice we oughtn’t need to specify it, but here we are.

"Now you get the same Weather app in about 130MB of RAM"

What a wonderful world we have created where the fix for a 1GB RAM guzzler reduces it to a mere 130MB.

Now I could start off with my old ZX80 or even my C64 (which is doing fine, thanks, and sports a USB "drive" next to its Quickshot II) but I think my first 80486 is a realistic comparison.

That ran at 25MHz, had a maths co-pro in it had 4MB RAM, a 20MB IDE HDD and I think the Orchid graphics card had 0.5MB RAM. The monitor was of course a 14" CRT VGA. OK so late 1980s!

However, that thing could run Win 3.1 and Word 2 and I think I managed to wedge a dodgy copy of Quark Express on it. I could play F117 and other games on it.

Oh well, lets see what this Linux box has on it:

/usr/bin/inxi - 1.4MB

    $ inxi -w Yeovil,UK
    Weather:
      Report: temperature: 16.05 C (61 F) conditions: scattered clouds
      Locale: Yeovil, UK current time: Mon 10 Aug 2026 01:16:05 BST
        Source: OpenWeatherMap.org

Obviously, I could install a Flatpak to do that instead and waste far more resources 8)

What inxi commnd shows a map of pollen concentration, weather alerts, and air quality? How do you generate a graph comparing this year's temperatures to the previous yeas' average climate?

Comparing inxi to Windows Weather is like comparing vi to Autodesk. You can make 3d graphics for sure, but it's not exactly comparable.

When I run inxi -w, I get this:

    Weather:
     Message: Error: Your access to this resource has been blocked. Automated
       requests or excessive use are not permitted. This is clearly stated in
       both the help menu and man page. If you want a CLI weather tool for
       routine use, try wttr.in, or use a weather widget. Remember, you never
       had a "right" to this feature, it was just a little easter egg, mostly
       for sys admins, which has instead been consistently abused. If you want
       to know your local weather, look out your window, there it is.

Looks like something in my powerline config somewhere must be querying too much? I can't find anything on my systems, must be a very old misconfiguration on my end. I still think I prefer the Microsoft tool.

> Your access to this resource has been blocked.

Do you have VPN enabled?

Nope. Getting the same error. On the very first usage.

No, but my ISP's IP range once belonged to a business hoster. Wikipedia blocks my IP for that reason too. I'm guessing it has something to do with that, because I can't find inxi references in my config files.

Reminder that all Chromium browsers are hostile to adblockers and are actively removing them.

Use Firefox with uBlock Origin, do not use Chrome, Chromium, Edge, Brave, Vivaldi, etc.

Doesn't Brave have an inbuilt ad blocker?

it does, and works almost as well as ublock for most things, but isn't nearly as flexible.

Brave has a workaround to make some v2 extensions work, including ublock origin

He's talking about the built-in adblocker

A better workaround is to install Linux. My entire operating system, which includes Niri window manager and Dank Linux running a weather app, among many other things takes less around 1 gig of ram.

Yes, switching operating systems is a reasonable alternative to switching weather apps

Another easy workaround:

1. Install Linux with KDE

2. Turn on weather report widget

3. Enjoy :)

PS: You've also solved the mandatory account requirement, adds all over the OS, "Copilot" everywhere, Edge constantly coming back and much more <3

For the Windows look and feel, I recommend Mint + Cinnamon. It took me about 15min to not miss anything on Windows and was shocked how I had forgotten how clean a system can be.

Mandatory Windows accounts can still be circumvented with a console command for Win 11 installations, but the overall enshitification package just got worse and worse.

Cinnamon is X11, but it works very well.

Yeah I love KDE especially because it doesn't force a certain look and feel, it's super configurable out of the box and even more if you install themes and plugins (which I don't even do).

> Mandatory Windows accounts can still be circumvented with a console command for Win 11 installations

Heard that's patched too

Did it the day before yesterday with a fresh win11 image from Microsoft (no rufus magic or anything). You can press shift + f10 and run a command I don't remember. It restarts the install process and lets you create a local account while it still patches the system before the first start (no fiddling with internet connections required). At least that still works.

At least for an install in vbox under Mint :)

oobe\bypassnro it is.

But there's been some talk about them removing it though there was a more cryptic one as a replacement. Still seems to work on recent versions though.

It was in insider builds yes but it still seems to be 'live' in production builds.

The writing is on the wall though.

> Cinnamon is X11, *so* it works very well.

FIFY

Is that still the case on Linux as well?

I'm on FreeBSD and yes there's still many bugs and nasties in Wayland. It works technically but it's not great, at least alongside KDE.

But I thought on Linux it was a lot further along now.

As much as I hate the weather app myself, this isn't an equivalent solution. The weather app shows the temperature in the taskbar itself, without opening anything. Also, I don't keep my browser open 24/7, so it's more than just loading a single extra tab, you need to wait for the browser process itself to start up.

If you want to load weather in a browser from the taskbar instead of having it available without having to open another application, I'd recommend using dillo or some such to load wttr.in or similar. A single http request that loads fast from a comparatively simple application that also loads fast. You might even be able to load it as a .hta file.

As embedded guy, sometime i wonder what those web devs are doing. A simple app that consumes multiple magnitude more RAM than the entire system i usually working with(~1MB). I assume it just does some HTTP query and render it on the screen, why the heck 1GB of RAM ?

Just the absolute laziest implementation

There's a bunch of other requirements you need to meet and no one cares about RAM consumption. So you do it the most time efficient way, not the most memory efficient.

Before you scorn, doing it the opposite way, taking more to use less memory, makes you less promotable, not more.

And this is why Windows will have it's lunch eaten by Linux.

I’ve read this sentence for more than a decade now.

Honestly it just reveals a poor theory of mind regarding the average consumer.

Why exactly? Because all the people who really care about good software will switch over? All 1% of the market?

Most people don't care about most things. I don't think much about the vast majority of products I use, because there's only so many things I can track closely. Same goes for everything else. Most people won't look and won't care.

I've heard SO MANY people who wouldn't usually care about such things say unprompted that they hate Windows 11. The ads, the nagging, the unbelievably slow performance for things that used to be instant, the terrible taskbar, etc etc.

I think they've finally made it so shit that people actually care and will look for alternatives.

Maybe it won't happen today, maybe not in the next 5 years, but it will happen.

When?

I wonder when this praised day will come. When did we hear this first? Is 20 years ago too soon?

Perhaps no one cared about RAM consumption, but RAM is expensive again.

In this specific case, is your Weather app important enough to waste 1GB on your users' PCs? Most PCs only have 16 GB.

>> is your Weather app important enough to waste 1GB on your users' PCs?

I agree. I don't want or need a weather app on my machine.

Did not ask for it and I do not use it. Why should it be using any of my RAM?

More and more parts of the windows eco-system is now generated by AI and reviewed by AI, humans are only involved in testing (source is a familly member who works for microsoft). Not sure if it's the case for this app, but there might be no dev to blame here.

There's probably multiple devs, which is part of the problem.

Ironically AI could likely do better than this if prompted right.

My /dev/random could do better if queried correctly

Because that html page needs a full browser to render and browsers have accumulated decades of bloat for everything from webgpu to drm. There's a reason we can't write new web browser from scratch, and why some people are excited for protocols like gemini that you can hack a user agent over a weekend.

I spent some time this morning thinking I was wasting memory using an immutable vector type in c# (RRB tree). It made things a lot easier and probably safer, but it ended up using about 1 MB more memory and "wasting" a couple of hundred ns. Then I read about stuff like this and I feel better about myself.

Embedded dev here too. I work in 32KB RAM and even that's massively overspecced for my current usage. I can't imagine what kind of data I'd need to store to fill up a GB

They're pointing to macOS and saying it uses 5 times less RAM there, but is 230MB for a weather app really something to be proud off?

Here is an example of one built using Real Basic on Mac Os system 7+. Probably uses less than 1MB.

https://tinkerdifferent.com/threads/snazzy-weather-a-snazzie...

And what's funny was at the time, REALBasic apps were seen as "bloated"

Yes, and this app looks like shit

1. This is subjective 2. It's unclear that "better UI" (by how much) is worth 100x memory usage

The thing with ram is that once you can fit everything you want into the space you have available there is little benefit in optimizing further or getting more space. 1gig -> 230MB may be a large enough reduction that it goes from "too big" to "small enough".

2025 and 2026 have proven that to be vastly untrue. It was never true. If it was anything, it was rampant laziness.

I wonder why it uses 200+ on Mac. It looks like a native (ish) application.

Has a bunch of visualizations and stuff. It might all be graphical assets?

> It looks like a native (ish) application.

Emphasis on the “ish”. It’s an iOS app ported to the Mac (Catalyst), just like Messages, Voice Memos, Clock, and basically every other consumer-focused stock app on the Mac these days.

For comparison, I installed Gnome Weather and KDE Weather on my Linux system. Gnome Weather uses 150MB and KDE Weather uses 270MB (edit: more like 220MB, seems like 50MB was used in setup but never freed until I restarted the app).

The people who develop this stuff don't know what it's like to have 64 MB of memory. They grew up with 4+ or 2+ if they've been poor. Their dev machines probably have 64 GB. 500 to them is a rounding error. That's why they are proud.

This took me down a rabbit whole. Why can a simple single purpose app not be just a couple megabytes if not less? The popular options are electron 100MB+, or embedding python3 in your executable which is at least 40MB.

But if you build it natively, you should have all of Microsoft tools at your disposition, dlls and such. In theory, this should allow you to make a 1 mb app or less. But in practice, it's the worse option.

The visual assets alone will be tens of megabytes.

Do all visual aspects of a weather app need to be loaded at once? Is the cost penalty loading a hundred kilobytes per image from disk really unacceptable?

Even if the app is no longer using that memory it is not released until Windows thinks another app needs it.

And then people complain about how unresponsive applications are, all these little stutters as things pop in.

Our storage can transfer Gigabytes of data, do hundred thousand operations every second. The hardware is more than capable. If your software stutter when streaming few hundred KBs of data, it's on you.

Bandwidth and latency are two different things. The latency of handling things in system memory is still pretty different than the latency of handling stuff on SSDs.

Still, it should not be more than few miliseconds, it's solid state.

Im pretty sure most of the latency come from the software.

Should be able to get by with using system graphics

Why, though? You need some icons and some map imagery, not 4K texture maps

Its 2026. You need 4k assets for job security.

Well, for example, Apple Weather has several different animations that are displayed behind the temperature for various weather conditions, such as rain, window, and snow, and those will need to be hi-DPI animations.

For a weather app, you should be able to get by with a couple base vectors you modify based on conditions.

On disk yeah, sure. But you're gonna render them into a pixel buffer which lives in memory.

How did applications do it before? Like in the 90s or 00s

They had fewer graphics, and much lower resolution screens.

Windows 98 SE kind of went overboard with the graphics (remember Active Desktop?), and a common screen size at the time was 1280x1024. But if you run modern stuff at 1080p (60% more pixels) or 720p (fewer pixels), you're not going to see comparable memory use.

Windows 98 wasn't composited, which makes a huge difference.

And to be clear, there's a ton of unnecessary bloat today as well. It's just that even a lean and mean highly hand optimized native app is gonna be way bigger today than it was then, due to compositing, higher resolution assets, higher resolution screens and different design sensibilities. But most apps aren't lean and mean highly hand optimized native apps so.

Compositing means you can excuse an extra dozen megabytes per megapixel of window size. The window in the article is less than a megapixel. That factors in the relevant part of screen resolution too. High resolution assets should scale alongside window size too, adding a fraction of the above dozen megabytes.

And I'm saying 98SE already had image-heavy design sensibilities all over.

You don't have to highly hand optimize to run a weather UI in a lean way.

> and a common screen size at the time was 1280x1024

Maybe if you were really rich and only used high end desktops. A lot of the computers I used back then were still 800x600, fancier ones were 1024x768. If you happened to also have a 2D accelerator card you'd potentially have 1280x1024. And lots of apps purposefully ran at a much lower color depth, it was common for games to run at 8 or 16 bit color mode.

I saw a lot of computers set to 800x600 but I don't recall any that couldn't be switched to at least 1024x768. Which is still quite close to 720p for making this comparison.

And yeah lots of fullscreen-ish things ran in lower color, but this is about desktop mode and I never saw a desktop mode that struggled based on color depth.

Cheapest local brand 15" CRTs could do 1280x1024 in early 2000s. because you weren't limited by the panel unlike LCDs.

You'd need better than perfect vision to be able to make use of it, though.

It's less of a question of if you could get a CRT that could do it versus having a PC with the video RAM and drawing performance to do it effectively at high color bit depth. Tons of extremely common desktops at the time shipped with only 2-4MB video memory with their integrated graphics chipsets. You're not doing 1280x1024 at 32-bit color with 2MB of RAM.

Early 90s maybe. By the end of the 90s and definitely early 2000s CRT screens were 1024×768 for the cheap crap and 1600×1200 for the high-end (with 1280×1024 as a mid-range).

Yeah sure you can take a machine with only 4MB of video memory and try to draw a 1600x1200 CRT, but you're not going to be able to have that many colors.

It often wasn't a limitation of your monitor, it was a limitation of your video adapter. Rattling off some common specs of monitors isn't telling the full story of what most random people were actually experiencing.

I still remember having to upgrade our main home desktop at the time of Warcraft I I'd release because it didn't have enough video memory to meet the 8MB minimum needed. That was in 2002 on a machine purchased with XP, a Pentium 4 HT with 512MB of system memory. Not necessarily a low end machine, but obviously not a gaming PC at the time and much newer than many systems sold for Windows 98.

That’s a ridiculously unbalanced system and I very much doubt it was the norm. Even the cheapest systems in early 00s that came with a Celeron and 128 MB RAM had something like a TNT card with 32MB ram, that’s if not a bottom of the barrel GF2 with 64

WAY lower resolution screens so pixel and frame buffers were a tiny fraction of the size, non-composited graphical environments which meant there was one fewer frame buffer per window, and a visual style which typically emphasized large pictures/animations less.

Pictures and frame buffers. If you're running fullscreen at 4k, you're probably gonna take two roughly 3840x2160x3 byte frame buffers for the window. Your designers want a background image which moves as you scroll in some parallax style; that's over 3840x2160x3 bytes more for the pixel buffer backing the image layer. And let's say roughly 50% of your screen is text with subpixel (aka full color) anti aliasing; that means another 3840x2160x3x0.5 bytes for the pre rendered text.

3840x2160x3x3.5. That's 87MB, in pixel data only. And it's a very minimal example; for the parallax image, you're gonna want the image to be significantly taller than the window; you're gonna want a ton of smaller (tho still high DPI) images for icons; a few different font atlases for different font faces you've loaded at once; maybe pre rendered pixel buffers for all sorts of UI components; etc.

And lord help you if your designers want any part of this to be animated.

(I'm playing a bit fast and loose with what lives on the GPU and what lives on the CPU here. On many systems, they share a memory pool anyway. But on systems with discrete GPUs, most of this is gonna be video memory. Though applications may wanna store CPU-side copies as well for various reasons.)

>Your designers want

Sometimes, you need to tell the designers NO. Moving background images don't help people figure out what the weather is going to be.

Honestly if the image is of the current weather it kinda does. I don't mind e.g Apple's weather app design at all

You probably have a SVG renderer in memory already, and you already have a frame buffer and/or compositor buffer(s). Why should adding a graphical representation of the weather require more than a few KiB?

Because a big picture looks pretty sometimes?

Not sure what you think "having an SVG renderer in memory" means exactly, typically the way an SVG renderer works is that you give it a huge chunk of memory and ask it to draw pixel data there from the SVG file. So even though the SVG is small on disk, rendering a 1000x1000 image from an SVG is gonna need a 1000x1000x3 byte pixel buffer (assuming no transparency or HDR shenanigans)

> 1000x1000x3

Cool, that's 3 MB

Which, if you'll do the math, is more than a few kB

That still leaves a couple hundred megabytes spent on..?

In a composited window system (i.e., any Mac since Mac OS X and Windows since Vista [I think]), rendering from an SVG would have to occur in a window buffer owned by the application, so it wouldn't save any appreciable amount of memory, assuming the buffer is the size of the window. The days of having an application draw directly into the framebuffer are well in the past.

And sometimes your engineers need to be a LOT less stingy. 1GB is clearly overkill for an app such as this, but ~300MB is perfectly acceptable if it works well, looks good and does what it should do.

There is such a thing as overdesign, but when you’re building a modern application, you must trust your designer’s sense of aesthetics and knowledge of UX patterns—two things engineers are often notoriously bad at.

Dunno. Many designers are pretty bad at UX. They’re OK at aesthetics, but that’s not the same thing.

> ~300MB is perfectly acceptable if it works well, looks good and does what it should do.

No it isn't. It isn't a word process for gods sake. It has one literally one job and 300 MB is like an order of magnitude off for that. This mentalty is the slippery slope that led us to the situation in the OP today.

You're off by 2 orders of magnitude if you think that a not completely incompetently coded weather app genuinely needs that kind of resources - even allowing for aesthetic choices and modern UX patterns.

gp was talking about 87MB without animations how do you end up at your estimate?

Ah yes, Microsoft is famous for good modern UI/UX.

Many people enjoy a tasteful weather app. Granted a “minimal” UX toggle would be easy to add to reduce memory for those who cared.

I think the issue is with the recent definition creep of “tasteful.” Seems you might have the same mindset if you consider “minimal” to be the other option.

Sometimes, you have to realize Hacker News is full of nerds that care about stuff nobody else cares about. Looks are so fucking important for many normal people. There's people that decide for or against a phone simply because it comes in a fun color.

They don't know why nerds care, but they will find out when they have to replace their PC just to have enough RAM to run a weather app.

But they won’t make the connection

Flashy beats functional nine times out of ten

Just look at the automotive industry

Looks _are_ important. But "have everything animated" is not always best.

Assuming the app even works - since we're talking weather, allow me to offer an XKCD

https://xkcd.com/937/

Good point. Though 4k image assets mean more that they look in 4k, not that their size is 4k. It might not be 87mb, but still way more than the couple mb I suggested.

> i'm playing a bit fast and loose with what lives on the GPU and what lives on the CPU here. On many systems, they share a memory pool anyway. But on systems with discrete GPUs, most of this is gonna be video memory

Yeah this is irrelevant here, windows doesn't share both in 99 of the case.

DWM quite literally does that all the time. For the general case it allocates GPU memory, but also swaps to system RAM or uses it as a synchronization mechanic when you have one screen on an igpu and the other on a dgpu.

What do you mean by "windows doesn't share both"? Windows doesn't get a say, Intel iGPU systems literally don't have video memory

IGPU systems on Windows usually set aside a fixed pool of memory for the graphics usually set by the platform. As in, if you need more video memory you need to go to the BIOS and reconfigure it. When you look at total system memory available in Windows it's the total installed minus however much you defined for the video memory. If you need to have the GPU mess with something you still have to a copy it from the system side to the GPU side. Applications can run out of video memory while still having available system memory.

It's only been somewhat recent that I've personally seen much hardware that allows for that reservation to be dynamically defined, and not with any Intel integrated graphics so far.

Iris Xe in 12th-gen do this, no idea since when it's added. There's still a minimum configurable shared allocation option in the BIOS, probably for legacy OS, but after booting Windows it can take up to 8 GB of the system RAM.

??? Fast and loose is an understatement, at best it's a view from a rendering engineer that thinks all software acquires a DXGI swap chain and handles buffering itself, but it's flat out wrong and over two times too high at the very least.

* Not every app is full screen (especially not a weather widget.)

* Very few people actually have a 4K display. 1080p and 1440p cover over 75% of users already.

* You do not allocate a separate buffer for the main content and the parallax, applying a different transform does not need a dedicated buffer, just something the size of your asset. It can be a 640x480 upscaled asset for all you care.

* You also don't allocate a dedicated buffer for text rendering/hinting. Your text rendering engine keeps a texture atlas in a buffer which is eventually maaaaaybe reach a 4k texture if you display a TON of various glyphs, realistically they won't. DirectWrite will also share this atlas with other executables unless you explicitly ask for isolation.

* On windows, you write to DWM, which keeps a single buffet for all your windows. Every window does not pay that memory price. I'm pretty sure most compositors do something similar.

* I never said all software handles the swapchain itself. The front and back buffers are obviously not usually allocated in user code. But they're allocated nonetheless and contributing to memory usage.

* Not every app is fullscreen, but I was using a maximized app as an example. If you make the window smaller then yeah obviously the numbers get smaller proportionally.

* A ton of people have 4k displays, it's difficult to find a moderately high end laptop without a 4k display these days. In any case, that was the hypothetical example I used.

* If you have a window that's roughly 4k resolution, and you want a background picture which fills the entire window, that's gonna be a roughly 4k resolution pixel buffer (unless you stretch a smaller image, but that looks ugly).

* Depends on the text renderer. I have mainly used pangocairo, which is based around CPU rendering text to a pixel buffer. I know that this is the typical recommendation for handling high quality rendering of longer pieces of text with Canvas on the web too. Maybe a typical win32 app actually does render each glyph fresh every frame from a font atlas, I'm not familiar with Windows APIs specifically. I apologise for the inaccuracy if that's the case.

* I'm pretty sure you're wrong here? If DWM has only one buffer which all windows share, how does it handle the case where a partially obscured window goes unresponsive for a bit as the user removes what obscures it? In old school non-composited X11, the answer is that the X server paints in the newly revealed area with grey pixels and asks the window's process to re-render that region, causing a lingering grey region if the app is frozen. Preeeetty sure that Windows 11 doesn't do that. But do you have documentation on this?

>it's difficult to find a moderately high end laptop

Terrible news for you, people work on dogshit dells given by their company and netbooks, not high end laptops. Macbook Pros, high end laptops, etc are exceedingly rare. (And can also deal with the high memory usage by virtue of having more memory).

>you want a background picture which fills the entire window

Which you rarely do, and also you don't develop for either, you're going to have a 1080p image at best, and then a bug report from that one client saying "background is blurry" in your backlog for the next 5 years.

>I have mainly used pangocairo, which is based around CPU rendering text to a pixel buffer.

Then you're using it wrong/using the wrong tool. Re-paying text layout at every render is already painful and it should be cached, your font rendering should absolutely be in a texture atlas.

>If DWM has only one buffer which all windows share

Slightly inaccurate in my answer there, but DWM only keeps one final composition buffer, which it handles itself from the various windows (that do have their own buffer, but only for their size and are only kept active if the window is visible.)

Are you disagreeing just to disagree? My numbers are obviously not going to fit every app in every situation, but I think they illustrate a perfectly realistic use case

For the text rendering thing, I think we're talking past each other? Nothing I mentioned implied redoing layout every frame? You render to a pixel buffer, upload that pixel buffer to the GPU, then just draw that texture every render.

For DWM, it sounds like you agree it has one shared composite buffer (which I didn't count in my calculations) and one front buffer and one back buffer per active application. Exactly as I said

In reply to user well_ackshually:

> Are you disagreeing just to disagree?

Let’s maybe ease up on the designers, there. It’s not like they are the sole cause of bad decisions and developers always do everything right if not for their pesky demands. There are order of magnitudes more shitty apps caused by bad programming than by a designer wanting a larger image.

Plus, if you’re doing everything designers ask without questioning or collaboratively discussing the tradeoffs, there’s a non-zero chance that could be a you problem.

It wasn't actually meant to be a slight against designers, the choice to have a big background image is sometimes perfectly fine. You're a bad developer if you argue against it because it'll use some small amount of extra memory that your users aren't gonna notice.

On GPU, won't it be like BC3 compressed texture?

Hardware texture compression formats aren't really great for UI and result in visible artifacts, even with a good compressor -- mostly flat areas or gradients divided by sharp edges makes the compression loss more visible. BC3/DXT5 in particular can only encode interpolated colors between two endpoints in each 4x4 block, so two colored regions divided by a line in a third color gets smashed.

Alternate encodings like YCoCg tend to do better.

It can, but you have to know what you’re doing and you have to know it very well.

Looking at the opposite extreme, the guy that originally wrote the windows task manager (the thing that popped put when you pressed ctrl+alt+canc) posted a video about cloning the windows basic text editor in a 3kb binary: https://youtu.be/OG91c7xsNMc

Needless to say, the guy knows what he’s doing.

A lot of these applications run in Electron or similar libraries where a whole new browser instance, with all its overhead, is stood up for each application. The simplest answer is we need to stop trying to use web technologies as a one-size-fits-all GUI toolkit.

Chromium is actually fairly efficient when shared across multiple applications. If the webview2, which is probably what the weather app uses, would not create a whole browser per application but rather just the renderer process and the rest shared system wide it would be a couple hundred megs at most.

> This took me down a rabbit whole.

The rabbit was too hungry to even stop to chew you?

Beware the rabid rabbit and don't let your whole near his hole . . .

Haha, and it's far too late to edit!

I embed lua when I need it. 200 to 400kb and we're off. And it's infinitely easier to interoperate with c than python is

it can be. you just need competence and incentive for it.

see File pilot as an example of what is possible when competent software engineer attempts it

As time goes on, I become more and more convinced that OSes need some sort of OS level GC pool which all GCed languages play in rather than having the language runtime provide the GC.

A major part of why these sort of simple applications are taking gbs of memory is because the GC wants to simply grow as much as it can to avoid pauses/jank. There might be 10% of the memory which is actually live in that 1gb. But because it allocates fast enough, the extra headroom is needed.

Even if it isn't the case that the GC is universal, having a shared GC amongst runtimes would be a boon in general. If I have 3 JVMs running, I might give them all 1gb of memory even though really each of them only needs 200mb to get their job done. The extra headroom is for when a burst happens. If I could combine all 3 into 1, I could save a lot of allocation overhead and general memory.

This does sort of exist in java (war deployments), but there are limitations that make it unappealing. For example, each of the JVMs have to be the same version.

Which is what OSes implemented in system languages with automatic memory management usually do, it is an OS service.

Oberon example,

https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...

Active Oberon example,

https://github.com/btreut/a2/blob/master/source/GarbageColle...

Bare metal Java, Go, .NET, Erlang, OCaml,... with bare metal deployments naturally have the runtime take the OS role.

Smalltalk: https://github.com/pavel-krivanek/BarePharo

The ram usage in this case is an order of magnitude lower if you install ublock in edge, as other comments have noted. Why would a system level GC affect wasteful adtech?

Any marginal efficiency gains will be wiped out with more adslop. Nathan's law.

> A major part of why these sort of simple applications are taking gbs of memory is because the GC wants to simply grow as much as it can to avoid pauses/jank. There might be 10% of the memory which is actually live in that 1gb. But because it allocates fast enough, the extra headroom is needed.

There’s very minimal state for a weather app. You should be able to sweep the whole thing pretty fast. You could probably statically allocate most of that state.

> There’s very minimal state for a weather app.

Except when it uses some kind of browser engine to render its UI?

This is far from trivial. Consider the WasmGC proposal, which had a somewhat similar goal.

Then C# came and said "we can't use it, we have different needs". So did Go.

> Then C# came and said

It's worse than that. The WASM GC standards team was warned in advance that the proposal wouldn't work for .NET, and they moved forward with it anyway:

https://github.com/WebAssembly/gc/issues/77

They were also warned about Go (though I'm not sure if they ever actually consulted with golang devs):

https://github.com/WebAssembly/gc/issues/36

More links:

https://github.com/dotnet/runtime/issues/94420

https://github.com/golang/go/issues/63904

No interior pointers, no embedded arrays, and only a subset of Java definitely seems like an odd target. I would have expected at least two different full languages with acceptable porting overhead to be the MVP.

I believe the MVP was chosen specifically to have the same features as JavaScript, so that browser engines can implement it without major changes. So not really an odd target.

These RAM prices weren't anticipated so there's been little time for software to adapt. Better monitoring could be a solution but this kind of thing wants to stay hidden.

Running the GC more often wouldn't save much. Dynamic programming languages simply allocate more objects and heavier objects especially with how we use them.

That's what the OS VMM subsystem provides... abstraction and management of the memory hierarchy to decide what RAM to use and what RAM regions gets discarded or swapped to/from disk.

If an OS were built entirely around a single instance of HiPE/BEAM similar to LING, it might be possible. For efficiency of apps, ditch GC where possible and use precise memory allocation. When that's not possible, use thread-local, immutable storage pools of objects like BEAM so GC can be concurrent and parallel. The messiest way is to do it like the JVM and other systems that throw all objects into a single pool and require pausing the world and expensive graph walks to clean up.

And it also ads on it.

Really Microsoft? Do you really need all the ads revenue from the weather app?

What’s next? Ads on the start menu?

> What’s next? Ads on the start menu?

They already exist: https://www.howtogeek.com/windows-11-start-menu-ads-how-to-t...

Don't they even had it earlyer and even let the DNS expire, so someone else could spam the startmenu?

Patent was being sarcastic. Everybody heard about (or had the displeasure of seeing) those ads.

Microsoft absolutely doesn't need it, but I'm guessing the weather app team (or the core filler apps team or whatever team is responsible for it) needs it to juice a metric to make some middle manager happy.

And it makes the middle manager happy because it lets that middle manager report better numbers to their superiors again.

Etc.

It's why all large dysfunctional organisations do self destructive stuff like this.

“What value are you bringing to the company?” translates to “if you’re not printing money, you lose your job.”

Any manager who doesn't push back when given a perverse incentive should be fired. They are not leaders, they are followers... And not even very good followers.

Yet they're the ones who get promoted because their KPIs are the best.

Fired by whom? Where do you think these perverse incentives are coming from?

Typically from C-levels who offer intuitive seeming, but internally inconsistent goals. For example, "We need to increase sales and decrease spending" might be two inconsistent goals if the only way to increase sales is to increase spending.

A bad manager will accept these inconsistent, and mutually exclusive, goals as if handed down on high by the gods and find counter-productive ways to save money or increase sales - even at the expense of actual profit. There is always a way, if you don't care about the actual outcome. These people will Goodhart the company into a terrible position, as long as it means they meet their arbitrary KPI's and get their full bonus.

A good manager might instead gather some data, then come back to the executive the next day with a data backed explanation showing why meeting both goals might be possible, but still wouldn't be advisable due to the negative externalities. A good executive will actually listen, because it's backed with real data they didn't have when they made the call.

Unfortunately if either the manager OR the executive are bad or thinking with their ego's... The entire thing falls apart. Which is why it's so very common.

I once worked on a project where the goal was to improve the reliability of MS Teams. The skip level manager was not happy when we said we cannot estimate what the revenue gain would be because it can't be measured.

This risks getting into the Fisherian/Bayesian stats wars again, but it would be possible to project a revenue gain, even in advance of making the change. You'd do this in terms of improved customer retention, lower cost of future customer acquisition, increased price a Teams license could sustain based on a rep for higher reliability, etc.

Obviously it's not a change that you'd be able to pin a specific human decision-maker (who was marginal on Teams) down as to this change being the difference between a sale or not, but nor is the change in revenue going to be a random number uniformly distributed in (-∞,∞).

If the change was revenue-neutral, the skip level would probably have been justified in seeing if the teams working that project could have found something to do customers actually care about instead.

How do you estimate the improved customer retention and improved future customer acquisition of something as nebulous as, "this does very little on its own but is a tiny part of making Microsoft software feel more robust in general"?

There's probably various methods, but if you don't already have quantitative estimates, you'll probably end up polling SMEs you'd trust for this on how much increase in retention and decrease in acquisition costs you'd expect for a notational more robust Microsoft. Average those out.

Even 5 people is enough to significantly narrow the uncertainty (at least, as compared to the prior hypothesis that the true change in odds is somewhere from -1 to 1).

And like a good spam filter, you don't need to be perfect, you just need to be able to turn your initiatives into a forecast of future changes if implemented, and then measure what actually does change for those initiatives you do implement. Even simple linear regression models can be useful in tracking results compared to forecasts.

Most people would probably expect that the improvement is close enough to zero to be nearly indistinguishable from it. And this is why most enterprises don't invest much in reliability work like this, because it doesn't actually seem to move the needle for customer purchasing.

They do. Never forget, Microsoft's goal is to squeeze as much money from you as possible.

That’s the goal of every publicly-traded corporation in a mature market. Wall Street demands ever-increasing returns and they can’t grow their customer base much so cost-cutting and fleecing existing customers are the only levers to pull.

Yeah it is actually really sad when a company the size of MS still bows down to the great god Advertising!

Avert ye eyes for there are no morals in these bad lands of Redmond!

All the comments excusing the RAM usage "because high-resolution screens require pixels" are missing the fact that there's this thing called GPU memory. Which is where pixels data should be. There's no way you need to store fullscreen 4K images for a weather app on anything else than the GPU: use scalable icons, render them on the GPU. No need to use actual RAM: the GPUs have had their own RAM since times immemorial and GPU rendering is a thing too.

Lots of iGPUs just end up being backed by system memory. But even then, this is a ridiculous hand wavy excuse. A 4000x2000 RGBA buffer is 32MB. That only explains 2.7% of the weather app's devastating memory footprint.

They don't want you to remember that Windows XP's minimum system requirements specified 64MB of RAM. This weather app uses 20 times more memory than an entire operating system from 25 years ago.

What's worse is that the previous version of the same Weather app was fully native on Windows 10. Why would you take a perfectly working app and downgrade it like this?

Well, this is Microsoft and Windows; it would be weird if it got better.

Yeah, people are acting like it's not been decades of microsoft pumping out spaghetti code at industrial scale.

Windows improves every other version. Windows 11 is bad, Windows 12 will be better

In a parallel universe Microsoft would have never killed Windows phone and they would have been forced to keep these apps a little more memory/performance friendly.

They probably needed an electron web app that could run the (likely ~8MB+) javascript bundle loaded by their ad provider.

Sad reality aside; when the new app released I was using an old AppxBundle of the last good version downloaded from a microsoft store archive website. Later I fully uninstalled the app as it got annoying to cancel the autoupdate for that specific app. I use a random website now.

I hesitate to make this sound positive, but to their credit, the leadership at Microsoft who likely steered the weather app towards using the web stack at least correctly identified a major problem: there is not a single good native UI framework for Windows today.

Jeffrey Snover, creator of powershell, explained it decently well here: https://www.jsnover.com/blog/2026/03/13/microsoft-hasnt-had-...

Was switching to webviews the right solution to that problem? Absolutely not. But at least we can admit they were in a difficult position.

At the time this bloated weather app was probably developed, the choice that most of the rest of the shell and in-box apps were making was C++/WinRT paired with System XAML (i.e. Windows::UI::Xaml aka WinUI 2 aka UWP XAML) via the still-marked-as-experimental-in-2026 islands API (DesktopWindowXamlSource) like the taskbar/control center/file explorer/etc. Or worse, actual UWP, such as the Start Menu, Settings app, or Notification Center. This can have a decent-ish memory footprint - Control Center, for example, uses about 150MB of commit and 30MB of working set. Still not good, but not atrocious either. But even for this mediocre level of performance and efficiency, you end up paying a very high cost in terms of development time and expertise required. This stack "just works" like 70% of the time, but the other 30%, you're scratching your head figuring out where you forgot to hold a strong reference across a co_await boundary. Or figuring out why a XAML ListView corrupted its recycling pool in korea because window messages reentered a nested message loop started by XAML's outbound RPC call that's only made in the TextBlock code for east asian languages. You get a razor thin veneer of user-friendliness, i.e. MVVM, x:bind, co_await ("hey, this is just like C# + WPF!") on top of a 60% finished UI framework and a terrible programming language feature which is quite possibly one of the leakiest abstractions in the history of the world (C++ coroutines). The fact that Raymond Chen managed to write a blog series on C++ coroutines in Windows that is 60 posts long is damning: https://devblogs.microsoft.com/oldnewthing/20210504-01/?p=10...

On top of all this, Microsoft's status in the industry has dropped. And they have absolutely no structured technical training program for new employees. I guess just pray you get paired with a decent mentor. So, young employees fresh out of undergrad who are asked to work in these codebases are super unproductive and make mistakes on a regular basis that cause inscrutable memory corruption bugs.

For a time, leadership was wildly flailing around trying to find some alternative to this madness. At the time when this bloated weather app was developed, the hot idea was that we should be switching to the web stack for native experiences. There was some low effort hand waving about how WebView2 would be continuously improved, we would mitigate the memory footprint by sharing webviews, etc.

My position is that there's no reasonable choice for building efficient native UX on windows today except by targeting a lower level graphics API like DirectX, Vulkan, OpenGL, or even software rendering in GDI, rather than a GUI framework. Most serious software on windows ends up going down the route of literally building their own UI framework, i.e. web browsers, office, adobe suite. If you don't mind the dated look/functionality of win32's stock common controls, that's also a decent option. I've heard that Qt is okay, but haven't tried it.

One final note: if anyone is earnestly wondering whether WinUI 3 is perhaps, finally, an end to all the bloodshed, my take is: no It is (currently) UWP XAML wearing a trenchcoat, plus a needless namespace change that broke compat, plus the baffling choice to run a copy of the compositor in-process in order to - wait for it - be able to ship WinUI 3 apps downlevel to Windows 7 and have acrylic work correctly!!! (to their credit, they have signaled that they are reversing this decision and moving back to the system compositor). WinUI 3 has the potential to be good, but appears to be too underfunded to achieve its potential.

org_chart_with_guns.jpg

> By comparison, Apple's native Weather app on macOS reportedly uses less than 250 MB of RAM

That's also bloated, couldn't they find a better comparison to illustrate the egregious waste?

It’s an equivalent app to make a comparison with, one from an OS company.

But yeah, I still remember when a weather app would take 10 MB and I was complaining (1999)

10 MB is ridiculously overbloated. 1 MB or something in that vicinity should be more like it.

How much money are these companies going to make by reducing their weather app to 1MB, or 10MB? How much is it going to cost them to get there?

The world doesn't run on personal aesthetics, when nobody is willing to pay for them.

The MacBook Neo has only 8GiB of RAM. This is widely decried as not enough. The RAMpocalypse means that 8 GiB is going to have to be enough or else it'll eat into Apple's margins. The Neos are wildly popular though because people have used it and 8 GiB is fine. So while the singular weather app being smaller itself isn't material, in aggregate, macOS being more efficient is something that lets Apple sell a lower spec product while still justifying a higher price and thus better margins for Apple.

Let's not ignore the new "windows copilot laptops" that come with 4GiB.

https://en.gamegpu.com/news/zhelezo/defitsit-pamyati-zastavi...

Insanity. 4GB was often not enough even back in late Windows 7 era.

4GB is completely fine in Windows 7.

Not to mention that on 32-bit without PAE, that was all you could get. Nothing more.

I thought you were limited to 3GB without PAE, since you needed at least 1 GB dedicated to memory-mapped I/O? I was never a PC guy though so I could be mistaken.

> The MacBook Neo has only 8GiB of RAM. This is widely decried as not enough.

Bwahahah!

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

I really didn't want to link that thread but I guess it would show it the best way: https://news.ycombinator.com/item?id=47331863

Apple has been using the "macOS is more efficient" excuse since the early 2000s to justify skimping on RAM.

These days we have an AI system to do exactly this kind of optimization, too expensive for humans, and too cheap compared to consuming expensive modern hardware

Can AI optimize? All signs point to it writing extensive amounts of unnecessary code

Hey, just a few more years of rising memory prices and it'll actually be a marketing term how much RAM something uses.

10 MB is not too bad for a GUI app. If the app is full screen, display is FullHD and has 8 bit depth, that's almost 8 MB memory for the back buffer alone. Enable HDR and pixels become 8 bytes RGBA16_Float instead of 4 bytes BGRA8_Unorm, twice as much memory.

This is only relevant if we assume CPU rendering. The article described system RAM use, not video RAM use. Task Manager doesn't combine the two.

They clearly spent it on maintaining their independent Chromium instance instead.

True, but many modern computers are using unified memory. On such systems all memory is almost equal, despite often reported differently.

For example, on my 5 years old laptop with integrated AMD GPU, windows 10 calculator in default state uses 33 MB system RAM, 9.6 MB dedicated VRAM. Maximized to FullHD screen, same app uses 36 MB system RAM, 13 MB dedicated VRAM. Maybe the OS counts VRAM as active private working set, maybe the app uses more than 1 buffer.

Regardless of the reason, it’s IMO unrealistic to expect a modern GUI app to consume less memory than required for the frame buffer for its window.

> many modern computers are using unified memory.

Not really true. Even machines with integrated graphics in Windows aren't truly using a fully shared memory pool. Usually the hardware reserves a chunk of the system memory for the iGPU.

“aren't truly using a fully shared memory pool” I think with AMD iGPUs I have here (GCN 5.1 and RDNA3 generations) it’s actually unified, at least on Windows 10. The difference between the reserved portion and the rest of the memory is cosmetic.

From Vulkan API POV, the reserved portion has device local and multi instance heap flags, the main heap doesn’t. However, the memory type is identical across all heaps, all of them have device local, host visible and host coherent property flags. And I can confirm VMA library from Vulkan SDK successfully allocates way more device visible memory than the size of that reserved portion.

Before Windows Vista, Windows apps normally didn't have framebuffers. There was one framebuffer for the whole screen, and apps drew into it. That's why dragging another window over a non-responsive window left a "slime trail" - the non-responsive window wasn't redrawing parts of itself when the window covering them moved away.

Before Vista, we did not have window previews in task bar and alt+tab. We didn’t have a good multimedia framework based on the hardware codecs: media foundation arriving with Vista wasn’t a coincidence. It was hard to capture and encode desktop for screen recording and presentations: despite MS only added desktop duplication API in Win8, technically Vista and Win7 graphics stacks could already do that, MS just neglected. Also, these aero translucency visuals in Vista and Win7 were nice, until Win8 ruined everything.

All that stuff would be hard to impossible with the older GDI architecture and no desktop compositor process.

One thing shared between old software rendered desktops and modern videogames is that they shunned these intermediate 'composited' screens. On the desktop, there used to be the screen, and basically windows used to draw on top of each other, there was no intermediate buffer for the whole window to draw itself to, which would then be smushed together with all others.

Video games are the same (mostly) - everything is rendered in screen space for performance reasons, it's very, very rare, that you would render something into a temporary buffer then composite it on top of the rest of the scene - you would need exceptional reasons for that.

Maybe it's time to get back to the olden days of display servers - where applications would push a list of render commands to the 'display server', which would consist of rendering primitives, which would then take these commands and construct the whole UI on the screen, without the intermediate steps of each app drawing into its own little buffer.

You could always fall back to drawing your own applciations, then asking the display server to composite that, but that would pretty much be the exception, not the norm.

This would really help responsiveness. Keypress to pixel is a huge issue in these bloated frameworks which are running on top of bloated OS

There’s a reason why all modern desktop environments are designed the same way: power efficiency when multitasking.

Imagine you have 3 windows visible at the same time: a videogame rendering at the refresh rate of the display 144 Hz, a video player rendering frames at 30 Hz, and a text editor rendering blinking cursor at 2 Hz. Because the videogame wants to deliver frames at 144 Hz, the desktop compositor has to deliver the entire desktop at 144 Hz. Asking the video player and especially the text editor to also deliver frames at that frequency would be wasteful. Irrelevant for desktops with fast discrete GPUs, but directly translates to battery drain on laptops.

I don't think this is any better for power efficiency? You're taking the modern system as an axiom, which it isn't. The old system didn't "deliver frames at" any specific rate. The graphics chipset sent to the monitor whatever was in the framebuffer at a specific rate, and windows updated whenever they wanted to. The text editor didn't "deliver frames at 144Hz" or any other Hz - it updated some of the pixels in the framebuffer when you pressed a key.

It cost nothing to not change the pixels when you didn't press a key, no matter whether you weren't pressing keys at 60Hz or you weren't pressing them at 144Hz.

Most games haven't rendered directly into the "screen buffer" for 15-20 years.

Vast majority of titles use deferred rendering, and lighting is done off screen too. Usually the only thing done to the "screen buffer" is a final post-process pass or a copy.

It's one possible rendering pipeline. Is it really most games?

Regardless, video games normally update the entire screen (or window) every frame, because the screen is so dynamic. This is unlike Microsoft Excel which has a mostly static screen. Building Excel as if it's a video game is going to waste resources.

Deferred renderers work differently from compositors. They still build up the entire displayed frame in screen space, except they dont write into a color buffer like directly, but produce a bunch or intermediate buffers, called G-buffers. Then they have a postprocess pass when they resolve these buffers into the final image.

This is called 'compositing' but its similar in name only. It's a fairly efficient process where each color pixel is produced by reading these buffer targets and producing a final color in a shader.

This is entirely different from what composited apps do, where they build up the app's background into a texture, and push that onto the screen, with potentially multiple screen's worth of windows living in memory. This would be equivalent in video game terms to rendering every character and object in the level as 'stickers' and then making the final image of these cutouts, which would consume tons of RAM uselessly, and would force us to render crazy amounts of detail that would never get shown.

2 bit 160x144px ought to be enough for anything

Look at Richie Rich over here with his 2 bits!

The KDE Plasma weather app takes in maximum 1MB.

I'm not sure if you're reply hunting or we talk about different apps but how would you fit the Qt runtime, Javascript runtime, font cache, graphics, networking libraries, etc in this limit? This can't physically be under 70 MB, and more like 100-200+ MB.

Many of those things are already in memory just from running an empty desktop.

Sibling comment called it: these are dynamic libs used by the desktop, so the incremental RAM usage is low. That's a good approach! Makes me wonder what the heck MS is doing to get their app to add an incremental gig to memory usage.

Correct.

DLLs are hopefully shared. But when you run a JavaScript interpreter and load some JavaScript library, in several different processes, that is not shared. Each process gets an independent copy of the library because from the kernel's perspective it's data.

The JavaScript interpreter is shared too since the Plasma Weather app is loaded as a shared library plugin into the Plasma process and uses the functionality already loaded and present in RAM. The same concept is used with background services which run in the kded process. There is no need to have a set of full web browser processes per service.

I mean, you're getting dumped on for this, but it seems about right?

For an extreme example:

    curl https://wttr.in/

Inside of a conky widget would do the trick, I think.

https://github.com/brndnmtthws/conky/wiki/Lua:-Shell-Integra...

LOL. it's a beautiful!

I think you guys on HN can be a bit out of touch maybe? On my linux machine (measured with tux-manager):

  nautilus                            177 MB
  kitty                               150 MB
  alacritty                           107 MB
  mpv --idle --force-window           160 MB
  winit empty window + OpenGL context 100 MB
  tux-manager                         69  MB
  hexchat                             55  MB
  gnome-terminal                      47  MB
  st                                  12  MB
  xterm                               12  MB

All these apps are what you would consider native, good apps. Written with Qt, GTK, some in low level langs like C\C++, Rust as well. There is of course different ways to measure the usage and maybe some more testing needs to be done, but stuff like 1-10 MB seems completely unrealistic. I think any empty Qt/GTK app eats 40 MB at least. Only thing that even gets close is st at 12 MB. And mind you it's a terminal (which is 1000x simpler than any modern GUI app, doesn't load any assets etc) and it doesn't even use any GPU accel (which itself seem to add a lot of baseline cost).

Honestly I was a bit surprised myself. I have a Rust winit + ash vulkan hardcoded triangle demo app and it eats 86 MB (the binary itself is 5.5 MB). I would love to know, if anyone could explain why GPU accel seems to eat up so much RAM. Like yeah, there are a bunch of images that live on swapchain, but they should all be in VRAM. Outside of that I don't see what would require MBs worth of overhead.

Yes these are all very, very complex applications though.

But I agree: using more memory is good, actually, because it means more stuff is being cached. Nautilus is probably pre-indexing directory structure so it doesn't have to read disk every single time you open your home folder. That's good. Oh, and thumbnails. Thumbnails are incredibly expensive memory wise, but very useful!

Also modern apps have A LOT built-in. Tons of font management stuff, accessibility, they work on many different environments. I mean, look at everything that goes into a modern terminal emulator.

But... a weather app is much simpler, IMO, than Nautilus or Kitty.

Counterpoint: Nautilus is both slower and less stable than Windows Explorer on large folders, even though the Linux filesystem is much faster. These super-indexed desktop linux search functions are also dog slow, while `grep` and `find` in the terminal are much faster (for searching inside files), and those certainly don't cache anything.

Thunar is very fast compared to Nautilus.

Windows Explorer crashes for me about ~3 times a day at work, and takes down the taskbar with it, so not sure about more stable. I don't use Nautilus though because it's pretty bare bones compared to Dolphin. Also:

> These super-indexed desktop linux search functions are also dog slow

Baloo-indexed KRunner on Plasma is instant. I index my entire home folder, including hidden files, and I can substring search with imperceptible latency. I can't speak to other search implementations, but yes KRunner + Baloo is much faster than grep.

I'm pretty sure you have a plugin installed for Explorer that makes it crash - while Explorer is far from a perfect piece of software, its not even close to this bad, but it's pretty easy to extend it with COM objects that then run inside the process, that can and do crash the whole thing.

It's a work computer, and from what I see there's no visible plugins. But corporate IT always does some fuck shit (that's a technical term), so I wouldn't be surprised.

I recommend you install

https://learn.microsoft.com/en-us/sysinternals/downloads/pro...

And take a look what DLLs have been loaded into your explorer.exe. Look for non Microsoft-signed ones.

> Nautilus is probably pre-indexing directory structure so it doesn't have to read disk every single time you open your home folder. That's good

No it isn't good, and no it probably doesn't because it is kernel's job. I'd rather they don't do double caching, and it's actually worse if they do.

Syscalls are expensive. It's not double caching, it's layers of caching. The kernel caches inside kernel memory space, sure, but you still need a syscall to reach that. Every application has layers of caching, it's very normal. This isn't even the top layer of cache, because of course the CPU itself has multiple caches.

But, for example, in a web application you will commonly cache requests. But then the database also has a cache. And then the filesystem the database is on also has a cache.

These apps have codebases going back to the 2000s when having 256MB ram total was a big deal, yet these apps could contend with that (while offering pretty much identical functionality). I remember one of the big arguments for GTK against Qt was that C++ relied heavily on templates, thus every C++ app would have their own copies of the same functions in RAM, while GTK was C, and a lot of those library pages could be shared. Qt even did some nonstandard tricks to cut down on this duplication, which was unpopular with the C++ people.

AFAIK, Qt's C++ extensions (moc, meta-object compiler) have nothing to do with how it reduces template bloat from containers, which is by moving some type-independent implementation parts to shared methods.

My Windows 98 install got ten times faster when I went from 32 MB of RAM to 48 MB of RAM.

A fresh boot of my Windows 98 install at the time, once everything was loaded and settled, used up 27 MB of RAM, meaning that after 5 MB of allocations someone was getting paged out somewhere. That extra 16 MB made a world of difference.

Do bear in mind, though, that we're dealing with a lot more than we were back then. Our hardware is more complex, with more and more complex drivers needed to manage more things. Accessibility is different, screens are larger (my monitor now has 27 times the pixels as my monitor then) meaning more memory required for larger textures which are now composited in hardware rather than re-rendered every frame.

I agree with others that things are ridiculous these days, but it's also easy to see that our expectations also need to adjust somewhat. Still, using a webview for displaying the weather... I get why they do it, but it's a scourge. It's emblematic of their care for the customer, which is nonexistent.

Casey Muratori has complained about the hardware driver overhead, because it is possible for hardware to have standard interfaces without needing a device-specific software translation layer, especially for more basic modes (like framebuffer).

In the 2000's 256MB were the bare minimum, my PC in 2002-3 had that.

> I think any empty Qt/GTK app eats 40 MB at least.

Classic GTK is (much) better (RSS on Linux):

  GTK2 14 MB
  GTK3 24 MB

Once it was decided that a desktop application must have fancy animation effects (like on smartphones) and be rendered completely on GPU things got very different:

  GTK4 98 MB

GTK used to be considered the bloated option along with QT. My first Linux box had 128MB of ram and it was screaming fast.

At one point I ran graphical linux on a 20 mb ram laptop although admittedly that was very tight.

I also remember running nt4 with photoshop, word, and my IDE (borland delphi) all at the same time and comfortably in 128 mb of ram.

What was the lean option?

There were a number of smaller libraries closer to the X11 primitives for drawing. Motif was one that i recall which powered opencde and like environments. We had used it for an industrial control system. I ended up using fluxbox as my windows manager for a while which has its own toolkit for decorating windows and drawing menus. It was quite a bit lighter than gnome and pretty much thinly wrapped XFT (fonts), and xlib for drawing, etc.

> mpv --idle --force-window 160 MB

That's still a HUGE amount when you remember mplayer (which mpv was based on) ran on PCs that has had less RAM than that.

Yeah, most of modern Linux wastes memory too. 100MB for a blank OpenGL context? Ridiculous.

Even 1MB is too much. I expect a modern weather app to be <20K.

You'll blow past that if you include any graphics at all.

`ansiweather` needs like ~6.28 MiB (measured with `/usr/bin/time -l` on OS X), but it's a bash script that invokes cURL, so there's certainly various overheads there too.

One probably could get this down way below ~1 MiB with a properly tuned straight executable written in C (best not to use any of the "modern" stuff like Rust and Go, their default binary sizes for outputting "Hello, world!\n" are already extreme :-) )

By default anything needs at least 532480 bytes RSS on OSX (I tested it with the most minimal C hello world), so that's a threshold one probably can't beat on OS X at least. We probably could kill that value on Amiga OS with the exact same functionality. :-)

On Linux you can bypass libc and use as little memory as you like. When you don't use libc and don't use dynamic loading there is no strict lower bound although you still start with a certain default stack size.

Unrelated, but it reminds me of this C64 demo [1] I posted earlier this week: the whole thing in 17.8 KB.

[1] https://news.ycombinator.com/item?id=49205592

10MB to tell me the weather from a remote server...

Let's remember that the sprawling world of Legend of Zelda SNES (a Link to the Past), including all graphics, music, code and dialogue was 1MB.

What else might that weather app be doing to justify the memory footprint? MS might suck at memory efficiency, but you can't claim they'd ever miss an opportunity to monetize their users. How can a weather app make MS money? MS has asked themselves this, so maybe we should too.

You're right that it's a matter of incentives, but it's because of cost not revenue.

It's bloated not because of a sneaky plan to include revenue generation. It's cheaper to make it bloated because quality is costly. They can externalize costs to users and nobody cares.

I play videogames. As soon as it became technically feasible to patch games we began to see videogames come out with first day patches.

When you take away the constraints the slop emerges. You could not make mistakes in software when it was all printed on CDROMs and DVDs.

I remember playing The Elder Scrolls: Daggerfall in the 1990s. It came on CD and was very buggy, and I would periodically call Bethesda and they would send me the newest patches on a floppy disk.

1MB is about the lowest memory usage you can get on Windows 7, because of reasonable tradeoffs made in the operating system to things like buffer and stack sizes. The OS creates a few threads for you, those threads have stacks and they didn't optimize the allocation size of those stacks - they used a currently reasonable default.

Depends on the app/framework but typically phantom threads don’t get started. Also, those stacks aren’t materialized until you write something - they’re all CoW’ed pages from a sentinel 0-filled page the kernel keeps around just for this purpose.

It's been a while, but I believe Windows initialises an internal thread pool & parallelises (some parts of) process start / module loading

You’re right. I hadn’t realized that Windows creates a hidden thread pool under the hood for parallelized DLL loading.

The stacks are allocated gradually, but there's a minimum few committed pages for each thread and there can be a lot of threads. The graphics driver alone will typically spawn a thread per CPU core unless you specifically disable threading optimizations, and that's separate from the thread pool.

I prompted my own windows taskbar weather app in rust with radar and forecasts and it's 233 kB.

https://github.com/derac/WeatherTray

I use Linux now, so you're on your own if there are issues. It might require some windows library to be installed but I don't recall. I ran it for a long while on win11.

That's embarrassing.

Not your app, it rocks.

Microsoft. It's like some decision-maker thinks it's OK to waste memory as long as it's someone (everyone) elses' memory, but it really adds up if you know anything about scale.

But what they're also doing is a non-businesslike under-utilization of their own resources.

Which is disgraceful in itself on top of that.

They're supposed to have much better AI than average and nobody even bothered to ask ChatGPT why in the world weather should take more than kilobytes?

And if their AI can't do it autonomously in under a megabyte it should be able to give a plausible explanation why not by now, and at least it would be orders of magnitude better than a gigabyte.

I assume yours went smoothly as prompted and it surely is an excellent example :)

> It's like some decision-maker thinks it's OK to waste memory as long as it's someone (everyone) elses' memory

My friend, you're giving them way too much credit.

Nobody, especially no decision-maker involved with this, has ever spent a single thought anywhere near any concept related to memory.

It just literally never crossed anyone's mind.

They're supposed to have much better AI than average

I suspect there will be a bit of revelation once people realise how much better AI can make software if prompted correctly. Of course a lot of slop will always exist, but things like https://news.ycombinator.com/item?id=49226923 show that it can be a powerful force multiplier if used right.

Not trying to excuse the Windows app's memory usage, but these are vastly different apps. Your app is nice, don't get me wrong, but it doesn't have anywhere near the same number of features as the default weather app. In some ways that's a pro for the Windows weather app (animated radar, easy to pan around in the radar view, extra map modes, lots of graphical elements to the presentation), in some ways yours is better (ad-free, for example).

Don't get me wrong, I imagine one could get close to the same featureset while using <600+ MB of RAM, but an app that just shows a table of numbers and a static PNG for a radar isn't really the same.

FWIW, while your compiled binary is 233kB, when its running its using 2.5-4.5MB.

250 MB is exactly the sort of bloat you'd expect from this sort of daft web-browser-wrapper application, and Apple get it there. 1.2 GB, on the other hand, is 5x as much, and completely insane even when you start off with daft as your starting point.

Apple weather is fully native from what I understand. I suspect the 250MB comes from the video backgrounds they play. Arguably that would be a reasonable thing to sacrifice on low memory systems, you'd barely notice.

I was able to do some tests with AI agent help and got:

- ~45 MB on buffers for animated backgrounds

- ~10 MB used for the Swift language runtime (runtime type information)

- ~44 MB used for system libraries: libSwiftCore, CoreFoundation, libobjc, Metal, VFX

- ~21 MB used on GPU buffers (GPU memory is also part of used system memory because of unified memory)

- ~6.3 MB for the weatherd daemon that actually collects the weather info and makes it available to the weather app and to widgets

- ~6.2 MB used for the display color pipeline (to handle color gamuts proprtly)

- ~7 MB runtime caches (shader compiler cache, libobjc cache, etc.)

- ~1-2 MB used for particle effects

- ~34-40 MB of memory as general heap memory that was otherwise unaccounted for (this seems to mostly be stack memory and threading-related stuff, and the actual application logic)

Overall the app is relatively optimized

Relatively optimized? typo?

I think this depends on perspective. Compared to an Electron app, it's significantly better. Compared to a hand-optimised app implemented in a low level language it's not great.

I've not done a lot of Swift/iOS/macOS, but I have a passing familiarity. These numbers are basically what I'd expect for a normal app. In other words I think the relative optimisation comes from the fundamentally better technology choice rather than from being particularly careful about performance.

Yea this is what I meant. I guess a more accurate phrasing would be "feels reasonably optimized." Qualitatively in terms of (lack of) graphical stutters and whatnot the macOS one feels very smooth.

Nice find and summary. Of I'm not surprised to see the ~75MB for the high graphical fidelity of the app.

I am however surprised that 10MB is Swift language runtime - with ABI compat this is supposed to be shared, and that the weather daemon is >6MB (surely this is just a simple API client?!).

Oh yea, something worth mentioning is that my analysis did not consider what memory was shared or not. That might influence the actual numbers. I believe the amount of memory used by the weatherd daemon also includes code and not just the heap memory, so the libraries that weatherd loads would be included in that.

I built a weather app for myself fetching ECMWF ensemble forecasts for my home location. Running the service is 60mb plus data 39mb and another 2mb for the spaghetti charts showing temperature, clouds, precip, wind over 10 days. What do I need to do to fill the other 900mb?

Run those things as an electron app? Add on analytics, location tracking and data exfil and you'll be fairly close

My entire kde "plasmashell" which includes my wallpaper and the various widgets installed (including a weather widget) uses 560MB for a screen with 5120x1440 pixels.

That's still 26x more than the size of the display buffer, I would never settle for such bloat /s

To add in the fun, “noctalia” process which is the shell, widgets (including weather :), wallpaper, app launcher, dock etc for my niri-wm setup is using 52MB.

The most lightweight solution I can think of is:

   curl wttr.in

That's basically my weather app. Though, I made it fancy at 7 lines of bash which takes location arguments and pipes into jq for display.

The article now says for me "By comparison, Apple's native Weather app on macOS uses roughly five times less memory under similar conditions."... which is not exactly the same wording.

Edit: I see the "250MB" line later in the article. This article is itself bloated for repeating nearly the same thing again.

https://github.com/dglent/meteo-qt

It is using 122.7 MB at present.

Thank you. And it is a shame I had to scroll down this far in the comments for someone to point out the obvious. Even a weather app that uses "only" 250MB of RAM should never have been delivered by a semi professional software shop - 250MB is enough to store whatever they can display in full screen on a 5k display as a bitmap - 5 times.

It was the top comment for a few hours. Others have discussed why it makes sense for apple to ise 250 mb in a weather app (heavy graphics and animations). Someone did an audit on the app.

I checked this on my computers:

On Windows 10 the Weather application uses 2-4MB when not active, which climbs to around 490-550MB when active. On Windows 11 the Weather application doesn't appear to be running at all when not active and it climbs to about 540MB when active.

No where near the results presented in the article, however:

The amount of memory used could vary by region and provider used to get the weather data, so in my region it would only use half a gig, in the USA it could use a lot more.

Half a gig is still too much for a Weather application to use, even with all the images and animations that it has I would estimate it only needs to be half as big at most.

I'm puzzled by why Microsoft made this into a Web based application since they could have written something much more efficient with native code, it's not as if they needed to target multiple different operating systems, just Windows and now just a single version of it.

> I'm puzzled by why Microsoft made this into a Web based application

The number and availability of native UI programmers compared to web devs is a rounding error.

If any place should be mostly filled with native application developers it should be Microsoft. No test engineers any more but there should be plenty of native application developers.

That would be nice, but I think the fact that they can pay web devs much less than native guys is probably a big factor in addition to the number of available applicants.

This article seems to be underestimating how much RAM a weather app should take. A well thought-out, native Weather app wouldn't take more than 100 mb of RAM.

I am pretty sure xfce4 weather plugin takes a lot less.

Looks like about 30 MiB with a quick test.

And that includes gtk3 bloat I am assuming, gtk2 would be even better. But 30MB for a weather app sounds acceptable to me.

This has strong "How much could a banana cost? 10 dollars?" vibes.

Back in my day 100MB was all you had for all your compute, and somehow programs still ran.

LumiWeather for AmigaOS runs on 2 MB RAM.

ESP32 in my OpenSprinkler pulls the weather (among a few more things it does) just fine and it has 520 kilobytes or RAM total.

Windows really I'd shitty for "assuming" unlimited ram, storage, processing, internet budget for them to get away with it.

They "could" make it easy but why bother? I assume next update will make calculator 1 gb download, 2gb ram resident and ADS

When RAM was $100 per MB that would be $10,000. You can do a weather app in much less provided you use native code.

Back in my days, I had to remove the mouse driver from autoexec so that microprose grand pirx had 600kb of ram to start

Had to get a ride to drive floppies with corrected config.sys and autoexec.bat files around to friends.

Things weren’t actually worse.

Personally, I have reverted back to sneakernet in a lot of what I do.

Good times.

> Back in my day

Back in my day systems used to be a lot simpler too. These “back in my mind” comparisons show a clear lack of understanding of the subject matter. 1996 apps are not the same as 2026 apps. Expectations are different. Design languages are different. Even the UX is entirely different.

1GB is clearly overkill, no question. But ~100MB to ~300MB is perfectly reasonable and you know it.

99% of apps have the same or less functionality today as they did in 2001, but are significantly slower and worse.

Functionality isn't everything. A human teller has the (more or less) same functionality as online banking, but I do love me some online banking.

I also like the weather icons being 4K and having some smooth anmiations.

Not to say that it's gone worse (it has IMHO) but comparing 25 years ago to know doesn't help much. Times were different back then. That's like comparing 1900 travel to today.

Yeah I wrote it a bit tongue in cheek, but even then I can't help but wondering where is all that memory needed.

My best guess is the GUI is somehow really heavy, wouldn't expect a simple console program that connects to some weather API to require that much RAM. But I never worked on apps like this, so no clear idea.

What is the weather app doing that it requires 100MB? For such a simple application, that seems excessive.

Mostly rendering. A bunch of images, text, UI elements. On a modern high resolution display it adds up quite quickly. You can surely cut it down a bit, but 100MB isn't absurd.

A weather widget using 8 bit color plus alpha on a 4k display show three full size images in 100mb. But I suspect that's not the ux we're talking about here, and a widget style system has no excuse.

https://wttr.in/ shows it's very possible.

The display on that page is literally broken for me, the boxes are all misaligned. It seems like it can't handle Japanese text correctly. Properly working localization in dozens of languages is one of those things that adds "bloat" to modern software that was missing in the bad old days.

Unicode doesn't require 100s of megs.

Apple's Weather app has an animated background, glassy views, and nice animations like water droplets on the glassy views when it's raining. So rendering all that on a 4k or more display at 10bit depth is going to consume a bit of RAM. However I guess it can surely be improved to make it consume less RAM.

Use an svg.

Or render everything using css, 100mb is someone not trying. 1gb is absurd abuse that only domestic violence victims put up with.

Quite a tasteless metaphor, no?

SVG is an on-disk format. It has to be rasterized, otherwise how do you have pixels? Each pixel takes up memory.

Vector icons. It can be fit under 50MBs.

Those still have to be rasterised to a pixel-based frame buffer at render/compositing time.

Yes but that space would have existed anyway for a window of that size regardless of its contents.

If I full-screen it in high enough resolution it can be excused for using 100MB temporarily.

The window in the article wasn't very big. At most it would have about 10MB of framebuffer, and the images on display would fit into 1MB uncompressed.

We can't excuse typical program waste with screen sizes. Especially when you can switch to 1080p or 720p and watch them still use massive amounts of memory.

I think this depends on your location, because in some places you really want to view a radar map. "Rain in $CITY" is practically useless for me. Still, the (static?) map in the depicted app shouldn't take 1GB.

My favorite '90s weather app was WetSock. The installer was 1.5MB, though I don't recall the RAM usage. It showed a sunny/cloudy/etc. icon in the system tray, with the temperature in a tooltip:

https://web.archive.org/web/20010210023051/http://www.softse...

https://web.archive.org/web/20070210195451/http://www.locutu...

You don't need anything more than https://wttr.in/ even with all the fancy terminal graphics.

Why would I like to know the weather in some other city?

What do you mean? It gets the weather for your city via your IP address, maybe you're on a VPN.

Your IP address doesn't automatically correspond to your city, even without a VPN.

Then add your city as an argument to the curl. It works well enough regardless and doesn't use hundreds of megabytes of RAM which is what the initial complaint was.

That's a pretty crappy way to detect it seems, it thinks I'm in some city almost a thousand miles away, no VPN, purely direct connection,...

They also have a nice API where you can pull the raw weather data and fancy it up any way you like graphically. Great for building your own entirely custom weather widget for your desktop, webpage, app, or whatever. :)

Well it's comparing it to apple's weather app, which is a fair comparison I suppose. 100mb still sounds like at least an order of magnitude too high to me though.

It's just msn weather page. Can't they use one single browser for all their apps instead of one per app?

No, because you have to manage communication between different teams on "how" and "what" about the single browser, much easier to let every team do their "best" without any external interference

After seeing https://news.ycombinator.com/item?id=49226923 show up here, I'm now hoping someone will vibe-code a nearly identical-looking native app that takes a few orders of magnitude less RAM.

Personally I just use my government's website when I need to check the forecast.

I’ve used Wego [0] for roughly a decade. It’s been good enough for me.

Six years in, I had to edit the configuration file once (to switch weather backends because the default backend shut down). In January, it’ll be 10 years.

[0]: https://github.com/schachmat/wego

Yesterday I was running : NixOS, mango window manager, 5 instances of ghostty, 2 of those running fresh terminal editor, firefox with 5 tabs and I was at 2.37gb of RAM.

Please, Microsoft, PLEASE ! You can do BETTER ! Stop acting like an internship for every single feature you add ! Where's the money going ?

But will the earn more money by offering a better weather app?

They can, but they won’t. Microsoft is run by the most cutthroat sycophants you could possibly imagine. That money you mentioned is going to those aforementioned sycophants and shareholders.

You should view it as an invitation to write a better app, like that guy that wrote a windows terminal to replace the garbage Microsoft wrote.

Seems very wasteful to help MS make their closed system better.

I wish... If only explorer.exe was opensource. If only the whole userland was opensource. We can only dream.

It will be interesting to see whether OS and application developers start to face commercial pressure to debloat their applications.

For operating systems and their bundled applications, Apple's integration is an advantage here; the OS designers work for the hardware company and have aligned incentives. That doesn't mean they necessarily align with their customers, just that they are internally aligned.

Microsoft...do they even care about the snappiness of Windows desktops any more?

Rise in RAM price may have a silver lining.

That’s pretty amazing, credit to Microsoft. Modern-day weather models are pretty complex and running these kinds of simulations can be pretty demanding.

Was /s missed or this is AI generated counterpoint?

Every comment without an /s at the end is definitely 100% serious and unironic.

Ah... now I know that Microsoft is running full weather simulations on each user desktop... pretty neat.

you sound sarcastic

No /s so I wouldn't know.

it's not as dead-pan with an /s

imhho, I prefer the ambiguity, the increased hilarity, the increased mental work of considering whether a statement is in good faith or being sarcastic/sardonic, the opportunity to understand how people can be hurt and the motives of barbs and lashes and how to discern the distress and deeper needs of "violent" people, and eventually the remembered insights on how to better generate boundaries and equanimity

in the way of Buddhist psychology, phenomenological bracketing, non-violent/compassionate communication, Brechtian principles, deconstruction, clowning, DBT, etc

lol

though I know this doesn't scale to situations without a boundary, where you can get abuse just for existing. I would use /s in a commons that expects a higher standard of good faith/well-being interactions

(does thoroughly confusing or disrespecting people for a jape equate to an abuse? how much of memeing is not just legal but moral? these are rhetorical questions, you are allowed to save your mental labour on this for yourself, self-care is prime, though I hope you all have a appropriate levels of support)

Stuart Lee is my favourite comedian, they are masterful in playing with this

https://youtu.be/5S9QJXa5YP8 - Stewart Lee deals with audience latecomers (Basic Lee)

https://youtu.be/EclpMn-mK5E - Stewart Lee HITS OUT At Audience Behaviour (Basic Lee)

https://youtu.be/NtFJ1HT3gto - Stewart Lee on Stewart Lee fans (Basic Lee)

https://youtu.be/TrkPNwSRxtM - Stewart Lee on his Audience (Content Provider)

shout out to the somewhat similar subtitles use of: (!)

p.s. as an alternative to Windows, I always recommend folk use KDE, and a distro based on Arch btw

You missed the Clouding@Home announcement?

I also like the compatibility telemetry that uses all my CPU. Seriously, this is a problem since late Windows 7 or early Windows 10 I believe and I have seen so many systems wasting resources and running hot in summer for no reason at all.

Not only is this unwanted spyware, it is extremely inefficient spyware.

They just recently fixed an issue where the start menu would render slowly. The solution was to let the CPU utilization and frequency spike immediately when opening the start menu instead of slowly ramping up.

Of course, that means Microsoft just admitted that Windows 11 needs the full CPU speed of a modern processor to render the start menu, which, IMX, is something that they were able to do smoothly under Windows 95 running on a 133 MHz Pentium and 4 MB of main memory without any 3d acceleration.

you would think the simulation this would be called via API and get a json response, not be running on the client consuming 1.6 GB of RAM....

is this satire...

I would like to be assured that the author knows the difference between actual memory and setting aside paging space.

That still isn't a good look.

I’m not sure if you mean a good look for the process or for the author but paging space is just saying “gimme a gigabyte” like saying “gimme a plate” is at a barbecue. The resources themselves aren’t being used at that point.

On Windows over allocating virtual memory (commit charge) is still bad. Unlike on Linux, once the total commit charge hits your physical RAM limit + SWAP limit, Windows will start crashing your applications and refuse to allocate more virtual memory, even if that memory has not been touched yet.

This is also why it is very important to have plenty of SWAP space on Windows, even if you have 64 GiB+ of memory. Because applications love to over allocate commit charge.

As in it's sloppy.

If you're at a BBQ would you take 5 plates just because?

The author doesn't need to know the difference because the task manager is accurate by default. I can still offer you some reassurance:

- The Windows task manager's memory column is the private working set which is the actual memory used by the application minus shared memory (but only shared memory that is currently shared with other processes, not merely marked shared. I.E. it's similar to RES - SHR on Linux but it's more accurate)

- Windows doesn't overcommit memory. Memory that is reserved but unused (not touching all pages) by the app is truly wasted. I mention this because in your other comment you make it clear that you think this is happening. But Windows isn't Linux.

The memory isn't even the worst part, on my laptop it takes up to 30% of the 8 core 4 GHZ CPU. Anytime I'm browsing and my fans start blowing like a lawnmower, it's because I forgot to close my weather app and it's just blasting away at the processor. Doing what, I don't know... probably spyware in one of the insurance ads on the side?

RAM consumption has gotten crazy over the past couple of years. Consumers need to start calling software devs out for this, especially when there's such a severe shortage of RAM.

They could ask AI to refactor and debloat, since they can't be bothered with it because the incentives don't seem to align.

Last decade has been the worst, not even worth it for the eye candy like before.

Why does everything turn into a browser

Because Jamie Zawinski was right and also wrong. Everything evolves into a browser, which, yes, can also read email.

Why does everything turn into an app that includes a browser to display a web page?

Mainly due to extremely lazy developers and/or a generation of developers who only learned very very high level web languages and don't understand anything deeper and so are completely detached from actual memory allocations or resource usage. Since this is coming from Microsoft (which isn't new - the Vista clock widget would interrupt all the time, very inefficient), it just highlights how far from the tree the modern apples have fallen.

Apple Weather app can jump to 1GB on a mac if you click around a little with the wind gust direction particle effect in the map

This reminds me of the JetBrains Toolbox App, which is a tray/system utility used to keep IDE:s up-to-date and provide a good location to launch them from. Not much more than that. https://www.jetbrains.com/toolbox-app/

It is currently using 680 MiB RAM on Mac OS 26.6, this is more than Microsoft Teams is using on my system. How do a group of what should be a competent programmers with access to good tools even manage to bloat this up so much?

I think we have to translate '1GB' here. It sounds like so little since it is just one GB, when in fact it is 8,000,000,000 bits.

When was the last time you counted to eight billion and thought it would be a good idea to build an app that would require that many bits of information to tell someone the weather forecast for the next week?

And this comparison is somewhat unfair since all numbers from 0 to 8 billion can be represented with just 33 bits...

Shame, because it's genuinely a great map - ahem, optimizations aside.

I remember giving the app a second chance - after assuming it to be bloatware next to all the other default apps that came with Windows - but after seeing it redeem itself in benchmarks[1], I gave it a shot and quite like it. The iOS app was too rubbish to bother with, though.

I'm curious what could options there are for decent predictions. Especially with Dark Sky never having been much of an option for Europe. I see some of the people behind it have a new subscription-based iOS app to try, though: https://acmeweather.com/app.

Do people have any desktop weather apps that strike a nice balance between decent code and actually useful predictions? Future weather's likely to be anything but boring, unfortunately.

[1]: https://forecastwatch.com/awards/2026/

My country's agency for weather and water mgmt has consistently the best 48h forecast. Try looking for an equivalent in yours.

I don't want to "akshually" this, but on a stock[1] up-to-date Windows 11 x64 25H2 (aka: my desktop) Weather takes up around ~670MB of RAM at launch, not 1GB. While writing this comment it dropped to 450MB. All in all much lower than 1GB.

1: i.e.: not "debloated" or running a bunch of random customizer scripts.

That doesn't take away at all from the complete absurdity of this level of bloat. How is it not 450kB? Fine, a few high res icons and multi language support, let's make it 4MB, because to do it in 1 would take skilled coders.

> That doesn't take away at all from the complete absurdity of this level of bloat.

When the article compares that figure directly to macOS Weather.app's 250MB usage, yes it does. It brings the sensationalist comparison down from "5x" to 2x. Then you can question why both platforms take 250-450MB of RAM for a weather app, instead of just repeating the "windows so bloated" circle again and again.

Absolutely valid point! I am equally horrified by the Mac app being also this level of bloated. Apple does not get a free pass for this shit, especially as they market an 8GB laptop in 2026 insisting this is enough - least they could do is release a GB or 2 by paring down the most wasteful apps.

I can tell you're not on a 4k monitor then.

Remember the days when we complained about Java being a resource hog?

Now I am glad to get a Java or dotnet app.

I wonder if this is a fair calculation including the fact that multiple WebView apps should be sharing the same libraries in memory.

If you pay 0.5-1GB to load the edge/chromium libraries but that memory is amortized over N different apps the user is likely to run, then the ”1GB for the weather app” is an unlikely worst case.

Thanks, React and friends.

For comparison, the GNOME Weather app takes 80MB.

Which, in a way, is still a lot. I personally wouldn’t expect a weather app, no matter how fancy, to use more than 50MB, and that should be more than enough. One can get pretty far with just native UI controls, even eye candy wise.

I still run Windows 10 on my PC, and one night I spend about 3 hours with ChatGPT turning off all of the bullshit telemetry and other nonsense that Windows runs in the background. Total was about 2.5 GB of RAM, roughly.

Why is Windows like this? One would think the at the company whose value proposition is, allegedly, "optimize your productivity" would not do things like this with their operating system. When this PC dies, and I figure I've got a long while left given my penchant for refusing to spend money on computer hardware, I will not be booting a Windows system again. What a mess.

> One would think the at the company whose value proposition is, allegedly, "optimize your productivity" would not do things like this

The company's "optimise our productivity" trumps.

Reminds me this https://waspdev.com/static/images/2025-11-04/bloat.webp

This is what happens when you start a separate instance of Chromium everywhere.

Anything above 50MB RAM for this is shameful imo and reflect poor engineering.

In Windows group there used to be a review where you had to tell the board why the module you try to merge into main branch moved the baseline up by 100KiB.

I seriously wonder if the recent migrations between languages mande by major projects leveraging SOTA LLMs have started a new trend of a) making native apps more common, as opposed to Electron and stuff b) will help to optimize existing apps and remove the bloat.

The alternative is, of course, that most apps will end up being bloated even more specifically because of how we'll slowly transition into developing using LLMs only.

The only good thing that might come out of these extreme memory shortages is forcing careless developers to actually care about resources for once.

Anytime I go on the website, my fan start going crazy. But it is a good website with the most accurate forecasts, I feel.

Another annoyance is that tree planting initiative, I was able to plant like 10 trees, now they made it very difficult to be able to do 1 in a year. Microsoft, you cheapskates, you're destroying the environment, the least y’all could do is plant more trees in vulnerable areas.

In the 10+ years since I stopped using Windows, every time I hear news about Microsoft I never see a reason to not be glad of leaving :)

So start creating quality, convenient and easy to use tools for native development and then create that quality software. You can use free/paid LLMs/agents/AI or don't use any AI. If something feels wrong then change it via next agent iteration on manually by hand. People complain but do opposite things or nothing at all :(

Meanwhile I’m running Waydroid with Android 13 – _an entire operating system, with apps, running services, etc_ – on my laptop, in roughly that same memory footprint.

Where did it all go wrong? To think I really liked Windows 10 when it first came out, and thought it was a solid direction forward into modernising Windows.

The thoughtful vibe coders don't have a good answer for this because vibe coding makes it too easy to take the get 'er done approach.

The AI hypesters and hucksters don't care as long as number go up. Cyclically I believe the primary driving force behind agentic solutions is to send token use hyperbolic.

> A new report shows Windows 11's built-in Weather app can consume more than 1 GB of RAM. By comparison, Apple's native Weather app on macOS uses roughly five times less memory under similar conditions.

Can we also be talking about how the Mac version uses 200MB apparently!? Why is a weather app using any more than like 10-20MB or so of RAM!? Load a couple icons into memory, maybe some background image or pattern, and a tiny bit of text. Why does it need to be so big!? (I'll cut it some slack while it's syncing/downloading, but for a weather app that should be like 30s once an hour max)

For one thing, Apple Weather displays hi-DPI animations for weather conditions.

Yeah. Should be possible to do those proceduraly to save ram and some clever animation design to not use too much CPU.

Anyways it is a bad trade off for the users to make and most don't even know they areaking it.

I am using AI to rewrite every proprietary driver/companion soft I had still running on my Mac system.I am using 5/10% of the original application's RAM.I am getting more features.My background RAM usage halved after converting many of them to my own versions.

PC games were the last reason why I still used windows. Now that Proton works wonders in Linux, I hope I don’t need to ever come back again. Great times with 98, xp and win7 that were snappy, easy to install and with no slop

"Windows users are fundamentally willing to put up with more bullshit than MacOS or Linux users."

I read this circa 2010 and it stuck with me ever since. Also, have felt this way over the years, when I see Windows users work.

Super interesting; it's been exactly the opposite in my experience. MacOS/iOS users put up with whatever Apple is telling them they should love - Liquid Glass, right? App Store restrictions, right? Lousy AI, right? - whether it's true or not. Linux users are willing to put up with any amount of work - i.e. bullshit - to make their installations work just to get a UX that's almost as good as Windows from 20 years ago.

As for Windows, I like living in cities. If you live in a city long enough - at least through a couple of major macroeconomic cycles - you'll see it improve in some ways and some neighborhoods, get worse in some ways and some neighborhoods, then improve again, etc. Cycles. Windows found itself in a downturn the last few years, primarily due to the org structure that took Windows shell away from people who could really look after it, and, yes some of those execs have earned my permanent scorn, like a bad local politician would. Now there's a focused team making that neighborhood better. I'm here for the whole ride.

I'll use Linux on computers I don't have to log into very much, so I don't have that UX problem (case-sensitive command lines? Seriously? The 1970's called...). I'll never move to MacOS City; it's like wanting to live in The Villages. Manicured lawns with no soul.

So I live in Windows Town, it's not perfect, no city is, but it's always changing, always moving, going through ups and downs, and now it has a new "city council" that's making changes for the better. And I'm expert enough to make it great for me, and avoid the "neighborhoods" that suck.

This article highlights a problem that Windows has right now, and one which I agree with, which is shipping web apps instead of native. For now, I have a workaround for it:

1. Install uBlock Origin in Edge. 2. Start Edge, browse to MSN Weather. 3. Click the "Add an Application" button in the address bar so I have a Start Menu icon for the page. 4. Delete the in-box Weather app icon.

Now I have the same weather site, no ads, running in about 130MB of RAM.

Enjoy your choice of operating system. Live where you want. Sometimes your city has problems. Move if you want, but don't think you've permanently solved your UX issues if you do, you've just swapped them for different ones.

> Liquid Glass, right? App Store restrictions, right? Lousy AI, right?

Liquid Glass needs a lot of cleaning up but it’s fine. App Store restrictions mean very little for iOS users in general and next to nothing for Mac users. Lousy AI also means little to nothing on Mac and earns at max a shrug on iOS—you even have a handy little button to disable all Apple Intelligence shenanigans altogether which is something no Windows user can easily do with Copilot.

No, Apple users are most definitely not having to deal with the same level of bullshit Microsoft’s users are. And it’s not even close.

I mean, if the only things you can name are Liquid Glass, App Store and not-so-intelligent AI then it seems like Apple users are actually doing quite well?

It's impossible for every idea to be a hit. Liquid Glass was a miss and they backtracked on some changes and fixed some issues that people were vocal about.

I can name lots of things I can't stand about MacOS and iOS and Apple hardware, but that wasn't the point of the comment. Some of the things I can't stand about Apple are things that people used to Apple's stuff don't mind. Cool for you. But I'm still not moving to The Villages, ever.

> things that people used to Apple's stuff don't mind

... but that's what you said about Windows:

> Windows found itself in a downturn the last few years

> I live in Windows Town, it's not perfect, no city is

> [...] avoid the "neighborhoods" that suck

Really the original comment just reads like you wanted to rant about Apple users and MacOS and that's it. You didn't really give any strong arguments for why Windows is better than MacOS - and "it's not perfect" is not an argument when in the same post you say the exact same about your preferred OS.

Apple's Software Quality Crisis (eliseomartelli.it)

1196 points by ajdude on March 3, 2025 | 1213 comments

https://news.ycombinator.com/item?id=43243075

It’s still much, much better than windows. And Linux is better still.

> Linux is better still.

Linux as an operating system is easily better than macOS. Third party software is lacking though. There’s really nothing that compares to Bear, Things, DEVONthink, Transmit, etc. What I also missed in Linux was the prevalence of what Apple calls “x-callback URLs” [0]. They are incredibly useful and great for glueing different pieces of software together.

With some of Apple’s recent decisions, I do wonder if we’ll see this change in the future. Little Snitch put out a proof of concept for Linux. While it exposes itself as a fairly rough webpage, someone is thinking about it. Linux culture would need to accept paid software, though.

[0] https://x-callback-url.com/

>> Linux users are willing to put up with any amount of work - i.e. bullshit - to make their installations work just to get a UX that's almost as good as Windows from 20 years ago

I put in the exact same amount of effort to install a Linux distro on my laptop that I would have to install Windows.

1. Download the ISO 2. Write to a USB drive 3. Reboot 4. Run the installer. 5. ??? 6. Profit

And all for an experience with way less bloat, none of the bundled spyware, more consistent UI design (depending on which desktop you're using), and better perceived performance.

>>This article highlights a problem that Windows has right now, and one which I agree with, which is shipping web apps instead of native. For now, I have a workaround for it:

This is still a web app, it doesn't solve the problem of MS being too lazy or cheap to make real desktop apps for things. I mean this is the same company who thought taking the Start Menu of all things and re-making it with web crap was a good idea.

> I put in the exact same amount of effort to install a Linux distro on my laptop that I would have to install Windows

On Windows you have to add the step "figure out the secret incantation this week to not need to set up a Microsoft account"

> to make their installations work just to get a UX that's almost as good as Windows from 20 years ago

To be fair, that was the peak of Windows UI. Also, KDE Plasma is way ahead of Windows (any of them).

I agree, KDE Plasma runs circles around every UX available now or at any time in the past. And it's not even close.

I've tried using MacOS, and there are so many frustrating things you just have to put up with. Windows is much worse, but to be fair Windows was okay at one point. KDE is, out of the box, seamless, sensible, fast, and unbelievably feature-packed. But even if the default experience isn't your taste, it's trivial to customize it to work however you want. Whatever panels you want, where ever you want, with whatever widgets you want. WYSIWYG with point-and-click. And the windows, too. Window rules, KWin scripts (which are actually full-blown plugins), whatever you want. I want Steam to always open full screen on start up on my second monitor on the third desktop? Sure, I can do that, again point-and-click.

I truly cannot sign the praises of KDE enough. I think everyone who dislikes KDE has probably not delved deep enough. I can recreate the entire GNOME desktop in KDE in an hour. I can recreate MacOS in 30 minutes.

It's called a "monopoly."

As always, Captain Obvious is quick to respond.

I have 64GB of DDR5 Ram and a 64GB pagefile on a pcie 5 SSD and window 11 still runs like crap.

technically web apps should be light as air.

but complexity merchants make them weight as much as the sun.

Is Chris Titus's tool able to remove the built-in Weather app (I haven't had a Windows machine with admin right for too long to remember that)? If yes, do we see 1 more GB of RAM free after running that tool?

You don't need a tool, you can just right-click and uninstall.

Windows 11 is what made me switch back to dual booting, after 4 years being content with WSL. Everything is slow, everything's GUIs have two versions and it nags endlessly for a "Windows Account".

I'm not surprised. Everything Microsoft makes is web tech now.

And this isn't really new either, they've been pushing for everything web tech since the 90s no less. Remember Active Desktop?

It's because people became addicted to building apps using HTML and JS instead of writing actual programs that run on the actual OS and display their UI using native OS widgets.

The Weather app in Windows is more ads than weather, so it checks out.

What if we make all these apps obsolete with < 1mb options.

100 tools < 100mb.

That only nerds will use because the UI is only ASCII art on a black terminal screen?

Have you never used fully native software? All UI code is in the system DLLs that are already loaded with the OS so you can have a nice GUI program with no fuss and no extra memory requirements besides the little code your app requires. See Nirsoft utilities for an example.

I miss lightweight tools so much. Even on Linux, opening some apps feels slow and sluggish, maybe because of Snap or Flatpak containerization, I don't know.

It is a breath of fresh air to run older applications like pcmanfm or xfe or xfwrite in comparison to flatpak and snap applications. flatpak's on-the-fly decompression of a file tree to run the app doesn't help its performance.

I used to get weather info via telnet, the report was measured in bytes. Either we are getting 10^9 more weather data or this is a record amount of bloat.

At some point you just got to be amazed at it and celebrate.

Just opened it and what's even worse are the 'get rich quick' ads, distracting video ads, and of course LLM-gen ads. Uninstalled.

This is the type of discussion I come to HN for.

Some kind of weather app challenge would be fun. Vote for the best balance of features vs efficiency.

i used WKWebView highlightr wrapper around highlight.js for syntax highlighting on iOS, and the webview was the biggest memory line in the app

i mean webKit never handle viewport well when compare to firefox or chrome. it's willing to materialize a 10000*10000 texture when firefox and chrome will think that is too dumb and only load the visible part. It's not a good target if you want to compare windows and mac software quality.

Is that before memory leaks or after?

Also, I don't think Apple should be commended for using "only" 250 Mb of ram for that.

the main problem with windows is that its applications are integrated in windows and can not be disabled and replaced by better software trivially.

nor is there anyone incentivised to improve customer experience for windows. it baffles me how bad windows search is. there are multiple tools out there which do a far better job.

same for file explorer.

I think the main selling point of Windows Search is spying and manipulation. Turning off websearch just leaves a carcass.

reblog of https://www.windowslatest.com/2026/08/09/windows-11s-weather... which should be the link

How much does rainmeter take? I used to load tons of widgets on it in my old laptop. Ahh those were the days

...you know, I keep reading all this stuff about memory prices, and it does suck, but memory is still much cheaper per gigabyte than it was ~15 years ago.

Which matters because the things most consumers are doing on their computers haven't changed in the past 15 years. We browse the web, edit photos, message friends, and so on. AI generally runs on remote servers anyway.

For years, everyone kept saying it was fine that Electron used gigabytes of memory, because on modern PCs memory was plentiful anyway. Well, it's not plentiful anymore! Maybe it's time software developers actually used resources efficiently?

Hey, you even have an LLM to help you now!

But it's literally not cheaper than it was ~15 years ago? Right now RAM is the same price per GB as it was in 2007 and prices per GB look to continue to rise.

https://www.tomshardware.com/pc-components/ram/scientist-say...

>Right now RAM is the same price per GB as it was in 2007 and prices per GB look to continue to rise.

...when looking at nominal prices (ie. not adjusted for inflation). If you adjust for that the furthest back you can go to get that price is 2011. What's more is that because RAM prices are subject to boom and bust cycles, that price has also been reached in 2015. So just by tweaking two parameters we went from 19 years (2007) to 11 years (2015).

That is correct, DDR5 today is in real US$ slightly cheaper than DRAM was in 2011, 15 years ago.

For more than 15 years in the past, the price in real US$ of DRAM per GB was always higher than today.

During 2014, there was a brief price peak when DDR3 (the standard current then) was slightly more expensive than DDR5 is today.

Still, the fact that now the price per GB is the same as 15 years ago, is bad enough, and it can still become worse.

Nobody would like to use DDR3 right now though, you can get cheap DDR3 DDR2 if you want some

It physically will not fit a modern motherboard.

You can get an old mobo with an old CPU

Which will only support up to around 16-32GB anyways and most likely won’t be supported by Windows 11. You’re not really better off that way and I’m saying this as someone with a DDR3 setup in my closet and a ton of DDR/DDR2/DDR3 RAM sticks laying around.

15 years ago 4GB was comfortable and 8GB was abundant.

Today 8GB is bare minimum.

Exactly, isn't that nuts? Especially when we're now paying 15-years-ago prices per gigabyte. What are we getting for that additional space?

The sad thing is that usability of computers has not improved. More RAM has bought us absolutely nothing when it comes to UI/UX.

But we went from 1080p monitors to 5k monitors and so we are pushing 7x the number of pixels and at roughly twice the bits per pixel.

True, but I don't really think that accounts for the increase in memory usage.

No but it's the biggest one that's easy to forget.

Feature factory work increases the surface area of every API you touch, and the proliferation of pre-written APIs expands the number of APIs you touch. The combination of the two is not quite O(n²) but the exponent is more than 1, so it's still geometric.

51% of people are still on 1080p according to the July 2026 steam survey.

We had modern programming toolkits that traded some efficiency for ease of use 20 years ago, along with GPU compositing for maximum smoothness. And that's when Vista came out requiring a whole 1GB to run properly. And other than doubling for 64GB that didn't change through 7, 8, 8.1, 10.

Electron was never a great idea but more and more basic things keep moving to it and the result is a disaster. When you use it for several little things at once it turns from annoying waste into massive waste.

moder engineers.

The sad part is that we actually used to have better desktop RAD tooling than we do now. I’m thinking about Borland Delphi, C++ Builder, etc., it was pretty easy to make a decent desktop app.

You are destroying the subtle mechanism of corporate enrichment.

I don't really understand the "its cheaper now than xyz years ago"

Sure, but we're being screwed regardless. You should be disappointed that almost 2 decades on, pricing hasn't improved. You should be disappointed the reason memory costs so much is because of AI contracts that you cannot compete with.

>Maybe it's time software developers actually used resources efficiently?

At least anecdotally, I'm seeing more and more native apps being written. Sure most aren't first party products, sure some are AI generated but its better than having 11 electron apps on my computer running at the same time.

I want to upgrade to AM5 (thus DDR5). I currently have 64GB of RAM and most of the time in games (even "less demanding" games like CS2), I find my system using over 32GB of RAM. This is a Fedora system!

I think I could get away with 48GB, but 64GB is too far out of my price range.

Article title's wastes is not supported by the content which says only consumes.

I only see RAM usage drop by .7 by closing the app so it seems to be using about 700 Mo total. TBH I'm more worried about things I leave open and I think users simply need to be aware that leaving things open consumes lots of RAM, unless it's an unloaded tab or something well optimized.

strongly recommend FluentWeather

open source, no ads, seems like the perfect replacement

https://github.com/Gabboxl/FluentWeather

I grew up a total Microsoft fanboy but Windows today is sadly nothing but a bloated piece of spyware. It's like they rebuilt Clippy, called it Copilot, and somehow managed to make it shittier.

I run a machine that costs ~$40k so I don't expect this to happen overnight but at this point it's absolutely inevitable that Linux overtakes it in the consumer market.

Every little thing that made Linux inaccessible to a normal non techie is now solved by speaking to some model and having it configure/fix the thing.

Attention Hacker News: you are literally the people writing this code and these frameworks.

Get your shit together and be the change you want to see. Or stop whining.

The complete works of Shakespeare are about 6MiB. I hate that 100MiB is considered efficient for telling me if it's going to rain later.

Why does Windows 10 use 10GB of RAM if you have a total of 32GB?

And how come you cannot pretend to only have 4GB to make it use less?

I don't care about how slow the OS becomes, I care about software not crashing.

Most of the RAM being "used" is available to be reallocated to something more important, should the need arise.

No, because my apps crash = they are not able to allocate memory.

Windows uses 10GB, Chromium uses 10GB and leaks ~1GB per week... then I launch a game and that game crashes if I have left chromium open too long.

The odd thing things crash way before the total 32GB are used. Available memory is still 2-4GB. Probably it can't find a contigous space?

Even 250mb seems like a lot for this.

An app which could have been a website.

Is it not?

> Instead, it is essentially an MSN Weather web app built on Microsoft's WebView2 framework. Task Manager shows multiple Chromium-based subprocesses running simultaneously, which contributes to the unusually high RAM usage.

I don’t know if this is sarcastic. A lot of bloat in GUI apps is because they are built as websites with a bloated front end, dependencies, custom fonts plus the binary compiled code and the decompressed images cached by the browser.

It is literally the MSN Weather website packaged as a WebView2 app.

Thanks for the PSA. Uninstalled.

This is what traditions mean!

In the era of coding with frontier LLMs, it should take Microsoft 20 junior engineers, a couple seniors, a token budget and a month or two to fix most of this shit by building lean, native apps. Given that they can obviously spare this kind of resourcing, I truly wonder why they won't. Not that I give a crap - removed the last windows machine from my home ages ago at this point.

Yes it's odd that given the obsession with LLMs and how much native code they've been trained on, why on earth they can't actually ever seem to write a good native app using their own frameworks is baffling.

Having said that, the code for Windows Calculator is truly astonishingly over-engineered. I don't understand who "designs" stuff like that in C++. It's insanely engineered, so perhaps they have truly lost their ability to do anything well?

Microslop strikes again

the article opens with the fact that macOS uses 5 times less. The irony seems lost on the author.

I wouldn't find this post less ridicule-inciting than if the title was

"macOS's built-in weather app wastes more that 200 MB of RAM"

What's the status on automatic debloating (non interactive) scripts for Windows these days? With vibe coding I'd expect hundreds of those to exist by now. Something everyone would run after a clean install, to revert, disable or uninstall all the stupid defaults and enshitifications Microsoft added in the past decades.

Anyone can recommend one of those?

I likely unfairly judge (at a high-level) code security based on how much system resources applications waste. If your app, or OS uses that much resource to perform simple operations then you clearly lack understanding of what the code is doing. How then can I expect it to be secure?

how to disable it ?

Search for it in the Start menu, right click uninstall. You can do the same with most other preloaded apps, or use whatever powershell incantation to do it in batch.

- r/fuckmicrosoft material right there

Electron apps use lots of ram, news at 11.

I'm sure the memory pages compress well /s

Reply on news.ycombinator.com