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.
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?
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.
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?
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.
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.
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.
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.
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.
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.
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!
> 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.
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).
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!
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:
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".
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.
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 remember within the last decade noting that minesweeper from the windows store took more space than a pretty damn healthy Win98SE install (with minesweeper)...
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.
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.
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.
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.
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).
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.
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
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.
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.
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!
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.
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.
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 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 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).
> 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.
> 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.
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.
You say tomato we say tomahto
At the end of the day bloated app is a bloated app its consequences are the same.
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.)
"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.
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.
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.
This is a narrative that MS, Google etc want you to believe. They gutted it for ads. That's what's happening. There are workarounds now, that's what the existing ad block options are. They are heavily kneecapped.
Plus, those workarounds will only continue to work (in as much as they currently do) for as long as Google suffers them to. Enshittification, as always, works in baby steps.
uBlock lite is already ineffectual in comparison to uBlock Origin. I understand that it's nonetheless good enough for many people, but it will get worse from here.
MV3 is severely limited in what it can do. One example that blew my mind is that chrome happily renders webpages immediately after application launch, while extensions are still loading.
Firefox, in contrast, doesn't let the network request fire off to the page until every extension is ready. So chrome is essentially screwing over the user, letting ads/ blocked content load, and intentionally degrading their experience, to make things appear slightly faster.
That's nothing to do with MV3 though, that was also true with MV2. The situation actually seems improved in MV3, because static (and dynamic, IIRC) DNR rules are initialized and enforced immediately, right?
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.
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.
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).
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.
> 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.
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.
> 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.
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.
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
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.
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.
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.
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.
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.
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.
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 ?
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.
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.
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.
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.
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.
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).
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.
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.
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".
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.
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.)
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.
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.
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.
> ~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.
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?
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.
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)
> 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.
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.
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.
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.
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.
??? 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
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.
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.
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.
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.
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.
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.
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?
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.
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
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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 :)
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.
- ~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)
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 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.
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.
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.
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 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.
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.
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.
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.
> 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:
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
`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.
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.
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.
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.
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.
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.
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.
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.
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?
That’s pretty amazing, credit to Microsoft. Modern-day weather models are pretty complex and running these kinds of simulations can be pretty demanding.
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.
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
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.
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.
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.
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.
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.
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.
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.
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:
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. :)
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.
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.
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?
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
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.
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.
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.
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.
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.
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?
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.
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.
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 :(
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.
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.
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.
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.
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 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.
> 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)
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.
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.
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 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.
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 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.
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.
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?
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.
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.
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.
>> 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 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.
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.
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
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.
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.
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 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.
...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?
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.
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.
>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).
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.
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.
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.
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?
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.
> 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.
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.
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?
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.
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.
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?
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.
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.
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?
Troll post? Or has fanboyism really gone this far?
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.
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.
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.
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?
It's fully vibecoded, and quite functional, although I'm still working out some bugs.
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.
"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
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.
I'm curious if you use winit for windowing, or something lower level that's just mac specific.
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.
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:
Code is a bit less readable like this, but autocomplete and cmd+click all works out of the box in your IDE.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.
https://en.wikipedia.org/wiki/Dennis_Fong#/media/File:John_C...
In fact, that seems a lot. Back in ~1996 I was running one of the EFnet servers on a Compaq with 8MB of RAM.
Fortnite, PUBG, COD, all are disgraceful in comparison.
I'll never forgive EA for C&D'ing the community efforts to revive the servers. Fuck EA.
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.
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
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.
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.
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?
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.
Bet one’s ass that “Renderer” sub-process is embed browser engine allocating working memory for rendering of web app page layout.
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 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.
You say tomato we say tomahto
At the end of the day bloated app is a bloated app its consequences are the same.
Fine, shutdown the weather and stock ticker apps.
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.)
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
Obviously, I could install a Flatpak to do that instead and waste far more resources 8)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:
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.Do you have VPN enabled?
not even being annoying, edge is removing manifest v2 very soon, breaking proper ad blocks just like chrome
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.
uBlock lite is already ineffectual in comparison to uBlock Origin. I understand that it's nonetheless good enough for many people, but it will get worse from here.
Firefox, in contrast, doesn't let the network request fire off to the page until every extension is ready. So chrome is essentially screwing over the user, letting ads/ blocked content load, and intentionally degrading their experience, to make things appear slightly faster.
Yet, I never see ads since ad blockers still have enough power to block ads.
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
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.
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
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.
Heard that's patched too
At least for an install in vbox under Mint :)
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.
FIFY
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.
> 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.
Use Firefox with uBlock Origin, do not use Chrome, Chromium, Edge, Brave, Vivaldi, etc.
or
https://unetbootin.github.io/#distros
Wipe Windows from your machine. Use Arch Linux. Problem solved.
----
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
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.
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.
Seems like an obvious fundraising avenue (for Ubuntu Foundation).
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.
"I know web, I deliver packaged web".
Getting off a hostile OS should be such an obvious choice we oughtn’t need to specify it, but here we are.
Before you scorn, doing it the opposite way, taking more to use less memory, makes you less promotable, not more.
In this specific case, is your Weather app important enough to waste 1GB on your users' PCs? Most PCs only have 16 GB.
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?
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.
Ironically AI could likely do better than this if prompted right.
https://tinkerdifferent.com/threads/snazzy-weather-a-snazzie...
Has a bunch of visualizations and stuff. It might all be graphical assets?
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.
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.
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.)
Sometimes, you need to tell the designers NO. Moving background images don't help people figure out what the weather is going to be.
https://xkcd.com/937/
Flashy beats functional nine times out of ten
Just look at the automotive industry
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.
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.
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)
Cool, that's 3 MB
Yeah this is irrelevant here, windows doesn't share both in 99 of the case.
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.
Alternate encodings like YCoCg tend to do better.
* 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.
* 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?
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.)
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
> Are you disagreeing just to disagree?
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.
The rabbit was too hungry to even stop to chew you?
see File pilot as an example of what is possible when competent software engineer attempts it
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.
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.
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.
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.
You'd need better than perfect vision to be able to make use of it, though.
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.
Im pretty sure most of the latency come from the software.
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 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.
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.
Then C# came and said "we can't use it, we have different needs". So did Go.
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
Any marginal efficiency gains will be wiped out with more adslop. Nathan's law.
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.
Except when it uses some kind of browser engine to render its UI?
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.
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.
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.
The number and availability of native UI programmers compared to web devs is a rounding error.
Really Microsoft? Do you really need all the ads revenue from the weather app?
What’s next? Ads on the start menu?
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.
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.
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.
They already exist: https://www.howtogeek.com/windows-11-start-menu-ads-how-to-t...
Avert ye eyes for there are no morals in these bad lands of Redmond!
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.
That's also bloated, couldn't they find a better comparison to illustrate the egregious waste?
But yeah, I still remember when a weather app would take 10 MB and I was complaining (1999)
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.
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 :)
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.
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.
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.
- ~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
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?!).
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
Classic GTK is (much) better (RSS on Linux):
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: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.
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.
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.
They clearly spent it on maintaining their independent Chromium instance instead.
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.
All that stuff would be hard to impossible with the older GDI architecture and no desktop compositor process.
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.
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.
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.
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.
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.
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.
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.
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.
The world doesn't run on personal aesthetics, when nobody is willing to pay for them.
https://en.gamegpu.com/news/zhelezo/defitsit-pamyati-zastavi...
Bwahahah!
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
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. :-)
For an extreme example:
Inside of a conky widget would do the trick, I think.https://github.com/brndnmtthws/conky/wiki/Lua:-Shell-Integra...
[1] https://news.ycombinator.com/item?id=49205592
Edit: I see the "250MB" line later in the article. This article is itself bloated for repeating nearly the same thing again.
It is using 122.7 MB at present.
Not only is this unwanted spyware, it is extremely inefficient spyware.
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.
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
Back in my day 100MB was all you had for all your compute, and somehow programs still ran.
Things weren’t actually worse.
They "could" make it easy but why bother? I assume next update will make calculator 1 gb download, 2gb ram resident and ADS
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.
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.
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.
Or render everything using css, 100mb is someone not trying. 1gb is absurd abuse that only domestic violence victims put up with.
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.
https://web.archive.org/web/20010210023051/http://www.softse...
https://web.archive.org/web/20070210195451/http://www.locutu...
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?
- 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.
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.
If you're at a BBQ would you take 5 plates just because?
Personally I just use my government's website when I need to check the forecast.
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
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?
Now I am glad to get a Java or dotnet app.
Last decade has been the worst, not even worth it for the eye candy like before.
1: i.e.: not "debloated" or running a bunch of random customizer scripts.
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.
Some kind of weather app challenge would be fun. Vote for the best balance of features vs efficiency.
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/
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.
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.
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)
but complexity merchants make them weight as much as the sun.
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.
And this isn't really new either, they've been pushing for everything web tech since the 90s no less. Remember Active Desktop?
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.
open source, no ads, seems like the perfect replacement
https://github.com/Gabboxl/FluentWeather
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.
Also, I don't think Apple should be commended for using "only" 250 Mb of ram for that.
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.
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.
To be fair, that was the peak of Windows UI. Also, KDE Plasma is way ahead of Windows (any of them).
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.
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 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.
On Windows you have to add the step "figure out the secret incantation this week to not need to set up a Microsoft account"
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.
... 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.
1196 points by ajdude on March 3, 2025 | 1213 comments
https://news.ycombinator.com/item?id=43243075
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/
As always, Captain Obvious is quick to respond.
100 tools < 100mb.
Get your shit together and be the change you want to see. Or stop whining.
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!
https://www.tomshardware.com/pc-components/ram/scientist-say...
...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).
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.
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.
Today 8GB is bare minimum.
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.
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"
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.
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?
> 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.
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.
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?
Anyone can recommend one of those?
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.
The company's "optimise our productivity" trumps.