Rendered at 04:32:40 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
d3Xt3r 21 hours ago [-]
> In our Linux test it opens in under a second and uses about 200 MB of idle RAM
Is it just me or does anyone else feel that 200 MB is a lot for a native chat app written in Rust, that's essentially a remote interface for the WhatsApp on your phone?
I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM, even when you had multiple plugins talking several protocols at the same time, whilst having a ton of advanced features not found in WhatsApp. Yes I get that times have changed and software has become bloated etc, but 200 MB still feels a bit too much.
SkiFire13 18 hours ago [-]
Almost all of those 200MB will be system libraries for rendering and GPU buffers.
rtpg 21 hours ago [-]
> Is it just me or does anyone else feel that 200 MB is a lot for a native chat app written in Rust, that's essentially a remote interface for the WhatsApp on your phone?
> I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM, even when you had multiple plugins talking several protocols at the same time
I think what's happening in the second one is that because you're using the native OS toolkits a bunch of stuff is shared, whereas with these "self-contained" "native"-y apps you end up having to load up the whole world and aren't sharing things with everything else
I'd love to be proven wrong but I feel like if you use e.g. Qt you're gonna have to hold onto a bunch of stuff that you wouldn't if you were "just" using OS-native stuff (though maybe that gets shared if you're using the exact same version? Is there something that can be done in this space?)
saghm 14 hours ago [-]
As an additional data point, I recently vibed an egui wrapper around a library I wrote for mod management for a game, and testing it out now, it idles at 92 MB. This implies to me that at least half of the overhead is probably not from the gui framework, but I also don't know how much effort they spent trying to optimize it; I didn't try to optimize my vibed GUI app at all, but I did hand-write the library that it uses for file management, state tracking, etc., and I tend to go out of my way to try to avoid unnecessary allocation in my Rust code. I don't know how much of the memory usage is essentially required overhead or from other dependencies for non-GUI parts of the app, but my instinct is that there's probably a bit of optimization that can be done. I don't think it's crazy for them not to have spent the effort on trying to do that yet though (or potentially even at all, if it's efficient enough for their own personal use).
elendilm 21 hours ago [-]
With Qt, on my KDE Linux, a simple app usually stays well below 60 to 100 MB.
rixed 12 hours ago [-]
Just tested, mine is 400MiB RSS. I was expecting less :-/
elendilm 9 hours ago [-]
I just tested a simple Qt app on my Linux KDE Neon and it consumes just ~32.3 MB RSS. Simple Qml app memory consumption is ~120.4 MB RSS.
Sure. Sorry it wasn't clear; I meant I just tested the Telegram desktop app for Linux.
elendilm 21 hours ago [-]
> Is it just me or does anyone else feel that 200 MB is a lot for a native chat app written in Rust ...
That was my first thought. But considering it as a significant improvement from > 1 GB, I guess it is what it is.
> I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM ...
Sadly this was true for many apps.
andai 18 hours ago [-]
Looking forward to the 2030s when we get a wave of lightweight actually native software as an alternative to the bloated Rust rewrites ;)
throwaway27448 15 hours ago [-]
How would you you do that—chucking libc out the window? A monokernel?
saghm 14 hours ago [-]
"Claude, write me a client for WhatsApp in raw assembly"
v1ne 16 hours ago [-]
I just checked with the native WhatsApp client on Windows 11:
650 MB of RAM as it is running, across all its processes. Thus, taking ≈⅓ of RAM is nothing to brag about for a reimplementation that focuses on being lean and fast.
Also, "opens in under a second" – back in the days when SSDs where new, programs opened instantaneously (<60 ms)!
Lastly, I still have to be convinced that Rust is a good choice for GUI programs, considering their messy mutable state and ownership.
andai 18 hours ago [-]
Hello world in Rust is huge, and every actual program I've looked at installed dozens of packages for basic functionality.
Turns out all those zero cost abstractions add up to a lot!
tcfhgj 17 hours ago [-]
The number of packages doesn't have anything to do with this
andai 17 hours ago [-]
It does with the compile times lol
Is there actually a way to see a breakdown of memory usage for a program? If you want to see where all the memory is going?
saghm 14 hours ago [-]
> Is there actually a way to see a breakdown of memory usage for a program? If you want to see where all the memory is going?
Flame graphs are a pretty common tool for this (maybe slightly less common than using them for seeing the breakdown of the time spent when running).
tcfhgj 16 hours ago [-]
The topic was ram usage during runtime.
andai 14 hours ago [-]
What causes that?
throwaway27448 15 hours ago [-]
You're welcome to demonstrate otherwise
wooque 17 hours ago [-]
yeah 200MB is nothing to boast about
clot27 27 minutes ago [-]
Not supporting calls is a dealbreaker for me
Also doesnt whatsapp ban you for using 3rd party clients?
Muromec 16 hours ago [-]
Matrix bridges for sup, signal and the rest are good enough to never use the web client anyway. You can also skip the part where you need to have it installed on the phone by running waydroid (if you can figure out how to scan qr codes with it).
loremdifr 24 hours ago [-]
dont get me wrong, I like the extra performance, but every single alternative whatsapp client has the same issue where it's missing enough core features that you end up needing to go to the browser version often enough to be a nuisance and I end up just using the browser instead (which I hate, I really really would prefer a performant client instead!)
cassianoleal 16 hours ago [-]
Having also been through a similar journey, which features are missing from this one?
mikojan 16 hours ago [-]
I use this:
$ cat $(which whatsapp)
#!/bin/dash
# A kiosk is full-screen by design. You need to go to about:config and toggle
# full-screen-api.ignore-widgets to true to prevent our window manager from
# creating an actual full-screen window.
# Additionally, you need to set the name to "kiosk" which will set the app id
# under sway to "kiosk" so that in sway you can disable full-screen on
# startup.
firefox --name kiosk -P whatsapp --kiosk https://web.whatsapp.com/
andunie 18 hours ago [-]
Feels like you're just a serial complainer.
codedokode 24 hours ago [-]
Egui is pretty bad idea. It uses "immediate mode" rendering which means whole window is redrawn on every mouse move. I ran PhotoCraft (built in Rust + egui) in a VM wihout a GPU and the UI felt like it was running on 3 fps. If you use egui, try running it without a GPU before releasing.
Egui is definitely not what you want to use on a 4K screen. It is only good for tiny screens of embedded devices.
Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn? (not React, it also re-calculates (but not redraws) everything on every change).
Also why does it visually look like bad version of Telegram? And Telegram can run without a phone present.
d3Xt3r 22 hours ago [-]
> Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn?
There's plenty of them. Slint, Floem, iced, Vizia, fltk etc. Slint and fltk in particular also exhibit excellent performance and very little resource usage even without a GPU.
hridyaagrawal 19 hours ago [-]
eframe is reactive by default, so it only repaints on input/animation, mouse moves count as input technically though so you get a pass on hover
dingaling911 11 hours ago [-]
I vibed some code using ImGui and it had this problem. I made it so that it only redraws when data changes with a fixed refresh rate and it went away. So it's not a permanent state of affairs.
ozgrakkurt 22 hours ago [-]
What is the argument here?
Basically every device has a GPU.
Why is it bad on 4K?
Did you measure anything in a real setup?
codedokode 7 hours ago [-]
I disagree. First, not every GPU supports Vulkan and other modern standards, and not every GPU even supports executing code. Drivers are often buggy/unsupported. Even if there is a GPU, compiling shaders takes time and CPU must be used in the meantime.
Finally, for app to have access to GPU, it must run on a host unrestricted. Why would you take somebody's code from Internet and run it unrestricted, violating the principle of minimal pivileges? That does not sound smart, especially if you have a crypto wallet on the same computer. Those who do not use VM or sandboxes will sooner or later learn this.
> Did you measure anything in a real setup?
VM is a real setup. Why would I run third-party apps without a sandbox?
Also, today we have an advanced AI that is capable of solving science problems. Should not be difficult to build a GUI that works fast without graphic acceleration, right?
Finally: the modern DDR4 DRAM has approximately 40-50 Gb/s bandwidth. Updating 4K screen at 120 Hz requires 3840 × 2160 × 4 (actually should be 3) × 120 ≈ 4 Gb/s. No problem at all.
viraptor 22 hours ago [-]
> Basically every device has a GPU.
Many VMs and remote desktops don't. (Or can't really make use of)
saghm 14 hours ago [-]
This is an app that connects to your phone and sends messages via the app. I don't think it's that crazy to decide that running on a VM or remote desktop is out of scope.
viraptor 8 hours ago [-]
It doesn't connect to your phone, it just authenticates via the app. I deal with a company where people use thin clients that run WhatsApp on the remote desktop. It's not an unusual case.
saghm 8 hours ago [-]
Interesting, I apparently skimmed the "Link to your phone" section too quickly (and I guess have a different sense of what that phrase implies than the author of that README, since a "link" that no longer requires the other end to exist anymore doesn't really seem like a link at all).
codedokode 7 hours ago [-]
It is a potentially unsafe app from some random person that can backdoor your computer so it doesn't make sense to run it without a VM.
Barrin92 22 hours ago [-]
>What is the argument here?
it's an incredible waste of resources, especially at high resolutions, to redraw a Gui application like you would a videogame at 60 FPS. These immediate mode UI frameworks were made in particular for that case, to be embedded in real time software, not for a UI where the state is idle or changes only occasionally.
piker 19 hours ago [-]
You only redraw when there’s interaction. In exchange you use basically no memory for state retention which frees up the real resource constraint.
codedokode 7 hours ago [-]
Moving the mouse is an interaction because there are hover effects.
v1ne 16 hours ago [-]
Redrawing the whole thing consumes resources. That's power and resources not available to other tasks. There is value in being clever with what you draw.
piker 9 hours ago [-]
Yes but it comes at the trade off persistent memory usage. It isn’t just free, and depending on the application in question that may be a lot better trade to make if, say, the app runs in the background or is rarely interacted with.
rixed 21 hours ago [-]
The argument is that it's wasteful?
Even if I had a GPU, I'd rather use it to do inference for insurance rather than drawing a simple UI?
Why do I have to state the obvious like that?
sexy_seedbox 23 hours ago [-]
PDFCraft works fine for me on a 4k screen connected to an older laptop with an integrated Intel graphics card, blazing fast and smooth.
txdv 21 hours ago [-]
I am using it on a 2017 intel macbook and its faster than anything else on that device
fastball 24 hours ago [-]
React doesn't re-calc on every change either if you use memoization and such properly.
codedokode 23 hours ago [-]
To use memoization you must use immutable structures (otherwise React is unable to detect changes) which are a pain to use and are slow if not designed properly. Do not believe me, try designing for example an algorithm that accepts a huge immutable sorted list with keys, a large sorted list of bulk deletes/inserts and produces a new sorted list with minimum operations. I made 2 or 3 prototypes and they still are not good and not even working properly.
In my book, a good UI framework simply attaches to a mutable model made of arbitrary objects, detect changes and displays it with minimum number of operations. Doesn't require to use any proxies or immutable data or store data in components. Shouldn't be difficult. Why nobody made it, I do not understand.
asdf88990 23 hours ago [-]
This is incorrect. You don’t need to use immutable structures to have stable references which is what matters.
Use context liberally instead of plumbing things through prop’s needlessly and you’re halfway there.
rtpg 21 hours ago [-]
React isn't immediate mode by my understanding.
In my head it's retained mode + the diffing layer, which sounds the same but if you try to write an "immediate-mode" API (say, using hooks) in React you'll find yourself churning a lot.
At least unless you use the magic React compiler that memo-izes everything correctly.
7 hours ago [-]
dejw 20 hours ago [-]
nothing stops you to render gui at 5 fps. most people won't notice
LoganDark 23 hours ago [-]
> Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn?
Nowadays the focus seems to be on video game-style interfaces that redraw every frame. The justification for this is typically that computers are so fast they can now come up with the entire interface every frame, so why not take advantage of that and forget all this retained-mode complexity?
They don't realize that this is a classic case of the developer's machine fallacy, where the developer has a machine so vastly more powerful than any of their users' that they produce a terrible experience for said users. This is also why games these days typically require upscaling even on 5090, because developers usually have that or something even more powerful and they think the bleeding edge is pushing even THAT machine to its knees.
Developers should be testing their software on the most entry-level, bottom of the barrel Chromebooks from 2015, running the heaviest and most bloated operating system they can think of. If people still optimized their software for that, then maybe computers would still feel almost as fast as the Apple II from 1977.
And obviously all computers have infinite capacity batteries to maintain game-level power consumption.
SkiFire13 18 hours ago [-]
Depending on what you're doing GPU accelerated rendering is more battery friendly than CPU rendering though.
codedokode 7 hours ago [-]
How long can a phone run on a battery when playing games? A day? Or an hour? Clearly shows how "efficient" GPU is.
LoganDark 4 hours ago [-]
I mean, if the game used CPU for rendering, it would last even less long.
LoganDark 18 hours ago [-]
Drawing the entire interface is more expensive than drawing only what changed, though. You don't have to give up the GPU for that.
LoganDark 21 hours ago [-]
That's actually a very good point, I haven't seen any care for power consumption from software developers in many many years. The only people who seem to still care about it are hardware developers like Valve and Apple. I admit I never thought about it myself either.
I would figure that doing less work generally requires less power, but some developers are crazy and act like they own the whole CPU, generate tons of heat, stress out the cooling system etc. with multithreaded bullshit that did NOT need to be multithreaded.
proneb1rd 20 hours ago [-]
Not sure why multi threading is a victim. It really depends.
LoganDark 19 hours ago [-]
It does indeed depend.
Some multithreaded workloads will use the full logical processor count to pin every core and that can really suck on low-end systems. I think aside from balancing multithreading overhead, this is one of the reasons why some more advanced software (such as 7-Zip) lets you select the number of threads to use for a workload, even if you already know and accept that it'll be expensive until it's completed.
Lots of multithreading things I come across as a developer have a default of something like 4 threads, or only use a certain fraction of logical cores up to a certain maximum, etc. because it's generally more polite not to always pin every core.
rixed 21 hours ago [-]
Or are plugged into a world with infinite quantity of renewable energy.
21 hours ago [-]
todo-laterx 23 hours ago [-]
[flagged]
zerr 16 hours ago [-]
For any vibe-coded open-source project, shouldn't the prompt history and token costs be published as well?
arjie 16 hours ago [-]
What purpose would that serve? You have the source code. In the old days we’d just share tarballs. No provenance. It’s fine. You have the unit of legible modifiability.
There have definitely been times when I've cloned repos that were vibed, pointed my own agent at it, and then hacked up whatever changes I've wanted. I don't think there's been a single time that a lack of prompts has caused any issues, but there have been at least a few times where stuff like AGENTS.md checked into the repo has caused hiccups from them encoding stuff that conflicts with how I want things done.
dangoodmanUT 23 hours ago [-]
it seems like we're entering the next phase of "written in rust": UIs
aeontech 24 hours ago [-]
Looks great, but... how can one trust it with credentials/communication? (nothing against the developer, more the principle of the thing)
thehamkercat 23 hours ago [-]
ummm, you can read the code...
but you shouldn't trust these unofficial clients, easy way to get your whatsapp account banned
iantpe 22 hours ago [-]
Yes, it would be great if we could set up our own test WhatsApp server.
pmlnr 21 hours ago [-]
It's called an XMPP server.
stavros 17 hours ago [-]
Good thing all my friends are already on XMPP server!
16 hours ago [-]
codedokode 23 hours ago [-]
Also, I looked at how dates are written in a screenshot and thought that "2 days ago" would be so much better than "Tuesday". Because you do not have to compute in your head how many days ago Tuesday was.
sudahtigabulan 21 hours ago [-]
Sounds reasonable, but IME apps that use relative timestamps switch to absolute time past certain threshold, and then I end up with two adjacent entries "14:38” and "15 minutes ago" and scratching my head.
Signal does that and I hate it when it happens.
aljgz 21 hours ago [-]
There are other minor problems as well:
- Screenshots don't age well: you need to know the screenshot time and do math
- They need to be maintained, which means the screen keeps updating even if nothing else is happening
Mawr 18 hours ago [-]
Claude Code: "Heads up. At this pace you’ll run out Sunday night, before the Oct 14 reset."
It is silly to mix the two. I usually display the relative time and offer a timestamp on hover or if there's space, show both.
louis_ 10 hours ago [-]
For an easy-to-read chat list, I chose in a recent tui application to adapt to the age of the message and write only the hour for today's messages, "Yesterday" for yesterday's messages, the week day for 2 to 6 days messages (so this couldn't be ambiguous), month+day for previous messages, year+month+day for last year+ ones. Works pretty well!
pezezin 20 hours ago [-]
I hate relative timestamps, I find it much easier to remember specific week days, so I very much prefer this style so I don't have to compute in my head which day of the week I got the text.
Anyway, I tried this application and it seems to mix different styles depending on how long ago you got the text: "yesterday", "Friday", "18 Oct 2026".
cowlevel 22 hours ago [-]
I presume if I use this my phone number will be blacklisted from WhatsApp.
viraptor 21 hours ago [-]
That's the annoying thing with WhatsApp, Slack, Discord, etc. Let's say I've got a personal client (that I'm definitely not using...) which works so much better than the official one. I cannot distribute it or use it according to their rules. It's forced enshitification, even though we have better options.
On the good side though - if you're replicating the official behaviour close enough... maybe nobody will know. But then you have to make sure everything, including key sort order, and JA4 of requests matches. And that's tough...
tombh 1 days ago [-]
In their own README:
> Using an unofficial client may be against WhatsApp's terms of service and could get an account suspended.
Same for all of these unofficial clients.
jedbrooke 1 days ago [-]
It’s really a shame that all of these unofficial clients are like this. APIs are APIs, if they’re on the public internet why can’t anybody call them? If there’s potential for abuse then that should be secured server side anyway, since needing a unofficial client isn’t going to stop hackers
darccio 21 hours ago [-]
I think this doesn't apply to European users, as WhatsApp announced around one year ago that under Digital Markets Act they were required to allow interoperability with third party providers [0].
It's irresponsible that the warning is hidden down in "Acknowledgements" and if you go via the homepage to download there's no warning at all.
cowlevel 22 hours ago [-]
I actually wish they'd delete the warning so then anyone who gets banned from WhatsApp for using an unofficial client would have a more legit cause of action against WhatsApp. Meta wouldn't be able to defend themselves with "well you were warned" if you weren't warned.
vanviegen 22 hours ago [-]
Oh, but it's in Meta's ToS of course! Didn't you study those before agreeing to them? /s
atonse 1 days ago [-]
Dammit. I installed it, it worked beautifully, and now I don't want to risk it.
dvdyzag 22 hours ago [-]
Eventually the unofficial client gets "fingerprinted" and its over. Its easy to remove the suspension, though. I vaguely remember it was through email.
qingcharles 21 hours ago [-]
Eh, there's no humans any longer IIRC. It's all down to whether their support AI blesses you or not.
I got banned for trying to move my chats from Android to iOS using the app rather than the special tool I didn't know you were supposed to use. I was lucky I eventually got unlocked.
I want a decent WhatsApp client that doesn't crash constantly and where you can search properly, but it's not worth the risk of getting banned again.
oofbey 22 hours ago [-]
Too bad. WhatsApp might be a reasonable service if you could trust the client not to spy on you.
nianzhibai 24 hours ago [-]
It's a bit basic. I installed it and then uninstalled it.
Is it just me or does anyone else feel that 200 MB is a lot for a native chat app written in Rust, that's essentially a remote interface for the WhatsApp on your phone?
I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM, even when you had multiple plugins talking several protocols at the same time, whilst having a ton of advanced features not found in WhatsApp. Yes I get that times have changed and software has become bloated etc, but 200 MB still feels a bit too much.
> I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM, even when you had multiple plugins talking several protocols at the same time
I think what's happening in the second one is that because you're using the native OS toolkits a bunch of stuff is shared, whereas with these "self-contained" "native"-y apps you end up having to load up the whole world and aren't sharing things with everything else
I'd love to be proven wrong but I feel like if you use e.g. Qt you're gonna have to hold onto a bunch of stuff that you wouldn't if you were "just" using OS-native stuff (though maybe that gets shared if you're using the exact same version? Is there something that can be done in this space?)
$ ps -o pid,rss,command -p $(pgrep -f SimpleQtApp)
PID RSS COMMAND
1471929 33052 ./SimpleQtApp
$ ps -o pid,rss,command -p $(pgrep -f SimpleQmlApp)
PID RSS COMMAND
1478335 123260 ./SimpleQmlApp
// Following is the simple Qt app code.
#include <QApplication>
#include <QWidget>
#include <QLabel>
#include <QPushButton>
#include <QVBoxLayout>
int main(int argc, char argv[]) {
}// Following is the QML app code
#include <QGuiApplication>
#include <QQmlApplicationEngine>
int main(int argc, char *argv[]) {
}// Main.qml
import QtQuick
import QtQuick.Controls
Window {
That was my first thought. But considering it as a significant improvement from > 1 GB, I guess it is what it is.
> I remember back in the day, apps like Miranda IM (and early versions of Trillian) used only digits of RAM ...
Sadly this was true for many apps.
Lastly, I still have to be convinced that Rust is a good choice for GUI programs, considering their messy mutable state and ownership.
Turns out all those zero cost abstractions add up to a lot!
Is there actually a way to see a breakdown of memory usage for a program? If you want to see where all the memory is going?
Flame graphs are a pretty common tool for this (maybe slightly less common than using them for seeing the breakdown of the time spent when running).
Egui is definitely not what you want to use on a 4K screen. It is only good for tiny screens of embedded devices.
Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn? (not React, it also re-calculates (but not redraws) everything on every change).
Also why does it visually look like bad version of Telegram? And Telegram can run without a phone present.
There's plenty of them. Slint, Floem, iced, Vizia, fltk etc. Slint and fltk in particular also exhibit excellent performance and very little resource usage even without a GPU.
Basically every device has a GPU.
Why is it bad on 4K?
Did you measure anything in a real setup?
Finally, for app to have access to GPU, it must run on a host unrestricted. Why would you take somebody's code from Internet and run it unrestricted, violating the principle of minimal pivileges? That does not sound smart, especially if you have a crypto wallet on the same computer. Those who do not use VM or sandboxes will sooner or later learn this.
> Did you measure anything in a real setup?
VM is a real setup. Why would I run third-party apps without a sandbox?
Also, today we have an advanced AI that is capable of solving science problems. Should not be difficult to build a GUI that works fast without graphic acceleration, right?
Finally: the modern DDR4 DRAM has approximately 40-50 Gb/s bandwidth. Updating 4K screen at 120 Hz requires 3840 × 2160 × 4 (actually should be 3) × 120 ≈ 4 Gb/s. No problem at all.
Many VMs and remote desktops don't. (Or can't really make use of)
it's an incredible waste of resources, especially at high resolutions, to redraw a Gui application like you would a videogame at 60 FPS. These immediate mode UI frameworks were made in particular for that case, to be embedded in real time software, not for a UI where the state is idle or changes only occasionally.
Why do I have to state the obvious like that?
In my book, a good UI framework simply attaches to a mutable model made of arbitrary objects, detect changes and displays it with minimum number of operations. Doesn't require to use any proxies or immutable data or store data in components. Shouldn't be difficult. Why nobody made it, I do not understand.
Use context liberally instead of plumbing things through prop’s needlessly and you’re halfway there.
In my head it's retained mode + the diffing layer, which sounds the same but if you try to write an "immediate-mode" API (say, using hooks) in React you'll find yourself churning a lot.
At least unless you use the magic React compiler that memo-izes everything correctly.
Nowadays the focus seems to be on video game-style interfaces that redraw every frame. The justification for this is typically that computers are so fast they can now come up with the entire interface every frame, so why not take advantage of that and forget all this retained-mode complexity?
They don't realize that this is a classic case of the developer's machine fallacy, where the developer has a machine so vastly more powerful than any of their users' that they produce a terrible experience for said users. This is also why games these days typically require upscaling even on 5090, because developers usually have that or something even more powerful and they think the bleeding edge is pushing even THAT machine to its knees.
Developers should be testing their software on the most entry-level, bottom of the barrel Chromebooks from 2015, running the heaviest and most bloated operating system they can think of. If people still optimized their software for that, then maybe computers would still feel almost as fast as the Apple II from 1977.
https://danluu.com/input-lag/
I would figure that doing less work generally requires less power, but some developers are crazy and act like they own the whole CPU, generate tons of heat, stress out the cooling system etc. with multithreaded bullshit that did NOT need to be multithreaded.
Some multithreaded workloads will use the full logical processor count to pin every core and that can really suck on low-end systems. I think aside from balancing multithreading overhead, this is one of the reasons why some more advanced software (such as 7-Zip) lets you select the number of threads to use for a workload, even if you already know and accept that it'll be expensive until it's completed.
Lots of multithreading things I come across as a developer have a default of something like 4 threads, or only use a certain fraction of logical cores up to a certain maximum, etc. because it's generally more polite not to always pin every core.
In the early days of AI coding someone did publish the prompts and it was utterly useless to me https://github.com/i365dev/LetterDrop
The source code itself is a sufficient prompt.
but you shouldn't trust these unofficial clients, easy way to get your whatsapp account banned
Signal does that and I hate it when it happens.
- Screenshots don't age well: you need to know the screenshot time and do math
- They need to be maintained, which means the screen keeps updating even if nothing else is happening
It is silly to mix the two. I usually display the relative time and offer a timestamp on hover or if there's space, show both.
Anyway, I tried this application and it seems to mix different styles depending on how long ago you got the text: "yesterday", "Friday", "18 Oct 2026".
On the good side though - if you're replicating the official behaviour close enough... maybe nobody will know. But then you have to make sure everything, including key sort order, and JA4 of requests matches. And that's tough...
> Using an unofficial client may be against WhatsApp's terms of service and could get an account suspended.
Same for all of these unofficial clients.
0: https://www.whatsapp.com/legal/dma-notice-non-users
I got banned for trying to move my chats from Android to iOS using the app rather than the special tool I didn't know you were supposed to use. I was lucky I eventually got unlocked.
I want a decent WhatsApp client that doesn't crash constantly and where you can search properly, but it's not worth the risk of getting banned again.