You usually keep old mails around that malware can then silently forward, this is a problem for unencrypted data. To authenticate through email, even if possible, there are hoops the attacker would need to go through and you'd likely be notified of e.g. a password reset mail
While more informative on its own, it's still kind of useless with the wide variance of power usage across models.
Laptops use Wh but you still need to do the same research as you would have if it was in mAh (ignoring the 100Wh max for planes that you'd have to calculate yourself)
The problem is that mAh tells you absolutely nothing about battery capacity. An mAh rating is useful if you're comparing two single-cell batteries using the same chemistry - but that's not what we are doing in practice.
For example, a 100Wh battery could be built using a single li-ion cell, which means it would be 27,000mAh. Same battery using an LFP cell? 31.250mAh. But wait, it's a laptop - it's far more efficient to put multiple cells in series. Four li-ion cells in series would mean a capacity of 675mAh, or 540mAh if you use five cells.
The five-cell one is probably more efficient, but if you blindly look at the mAh rating it looks like it has a significantly smaller capacity. Nobody is going to buy that, so the marketing team will convert it back to "single-cell equivalent" and put 27,000mAh on the box while still keeping an 18.5V rating, and people who passed a highschool physics class are going to think it's a 500Wh battery.
It gets even worse with LFP, because now the marketing team is asking you to convert it to "single-sell li-ion equivalent" and the figure is now completely unrelated to what's actually happening! That 520mAh 6-cell LFP battery? Just put a 27,000mAh label on it: who cares, bigger is better.
You can't directly map it to the win key, but you can use the keyboard manager to remap one (or both) of the win keys to a shortcut you then assign to command palette https://u.numerlor.me/zRq6PA
Alcohol would dry up faster, demineralised water will have more time to dissolve and redeposit particles. Though you have to be careful with alcohol as it can destroy some plastics
I've been running zfs on root on my Debian home server, only the install was a tiny bit more involved but it was done in maybe half an hour going off of the guide and trying to understand everything it was doing with 0 experience (... And then did it again after I broke networking after an hour lol)
On windows you shouldn't be able to do (most of) these directly with apps running under admin, though that's a small consolation when the browser is a normal process.
I'm not sure if we'll get away from these anytime soon as any out of the box solution will inherently limit the user's freedom that has persistently been there for decades on PCs
I have absolutely done all of these things on Windows, even for commercial applications. Programs that keylog (i.e. calls SetWindowsHookEx) sometimes get tagged by antivirus though.
If all you need is the terminal than windows is definitely getting in your way, WSL is a worse experience. Plus you still have to put up with candy crush in your start menu, Cortana annoying the hell out of you, and the taskbar giving you unwanted updates on the latest news from the Kardashians.
I don't have any of that in Windows. I'm not using the home version but the preinstalled apps can be removed in a minute, I think cortana has been deprecated for a while now, and the only unwanted thing I've seen on the taskbar has been the weather that I've hidden with two clicks.
For wsl, it's just a normal VM that's integrated with Windows. Maybe it'd get in the way of I did development that needed to work closer with the hardware, but I don't at the time
You can remove them in a minute, but they'll come back. ChatGPT will pop in there when Microsoft adds it. You will get a full-screen blue "get windows ready" wizard every few days to "remind" you to log in. OneDrive will reappear on your desktop.
You can still choose most things, but they will keep asking and twist your arm as much as possible.
OK, I'm coming from Linux, but I have to say my experience has been the opposite.
I have a semi-complex app I've decided to port to Windows (it's so far on Linux and MacOS and configures/debugs/tests servo motors on serial and CAN busses), and after a couple of days I've been unable to make any sane workflow work without installing three seperate half-assed copies of Linux userspace (Git for Windows w/ its bash install, cygwin and wsl2) and choco on top to install more Linux/Unix-originated stuff. It's a lot like MacOS and needing to fiddle with homebrew, except worse and you need four of them.
Let me give you an example: I have a serial device connected to an SBC mini computer that I want to interface with from my dev PC, so I want to proxy that serial port over tcp to Windows and make it available as a COM port. On Linux this is trivial to do using socat, or ser2net+socat.
On Windows, plenty of similar tools exist. Usually you need two of them, one to make a virtual pair of COM ports, and another one to pipe a TCP socket connection into one end of the pair. So far, so good.
Except all of the utilities, drivers, etc. I've tried have just plain not worked, and I've tried a good half dozen. Often their last version is from somewhere in the 2007-2012 time frame, and something no longer works on Windows 11. I think a lot of devs of tools like this just nope'd out when Microsoft started enforcing signing and pushed the Store model harder, and moved to Linux or Mac.
In the end I had to write my own thing for the COM pair and run socat in cygwin.
And I've jumped through a few hoops like this.
I'm sure if all you do is need a place to run npm from and the rest of your stuff is all in the browser, the OS barely matters. But for native dev, Windows feels dead and barren, and fully reliant on the Linux ecosystem to be productive at this point. It's where all the reliable and well-maintained stuff comes from, whereas Windows-native tools are a ghost town of abandoned, frequently closed-source binaries.
The many years Windows couldn't make their minds up between the managed code .NET stack and native C/C++ APIs, and one was incomplete while the other bitrotted away, have really taken their toll, I think.
From what I remember only the c/++ toolchains were a problem on windows but the couple of times I needed them they were either managed by some other build process and ran fine or I could just compile and run in wsl
reply