for_xyz

That workflow seems really slow when dealing with multiple repos/subrepos actively compared to what UI frontends offer.

But it's still more efficient method for single repository project where using UI git client would be the overkill.

I always wonder how using cli to commit changes is faster than using dedicated git frontends such as Fork to do such tasks.

I used to use it like that but it was too much work to manage multiple repositories in such way especially if i didn't remember all changes I made.

Using Fork greatly reduced time spent making useful commit messages by having all changes visible at glance. It even allows to stage specific lines of source code and has insanely good interactive rebase UX.

Things like that are impossible to achieve with only using cli productively.

Also I like the ability to see commits from all branches at glance.

Last time I checked (almost 2 years ago) OpenLayers did not support webgl backend for vector graphics. That's why it was slower.

"It went from nicely working Qt program that worked well on OSX, Linux, and Windows to Electron beast that maybe works on Windows"

Skype was originally written in Delphi on Windows. Linux and OSX ports used QT.

Nowadays the Skype app is just single codebase written in React Native and it targets multiple platforms: UWP, Electron, Android and iOS.

Since ribbon UI you can always add ribbon items to the quick access toolbar (right click -> add to quick access) which can be accessed by the alt + (item slot number)

I always used to add powershell and powershell (admin) from the File menu to the quick access toolbar which allows me to quickly open the powershell in the current folder via keybind (Normal ps: alt + 3, Admin ps: alt + 4)

I wish they would add new windows terminal and all user defined profiles to the file menu.

Defender does the scanning on CloseHandle() calls in untrusted code which can block the thread for even up to ~10ms (including other NTFS filter drivers) which is significant if you do open() close() pairs a lot.

More info about the similar issue and solution is apparently to sign the application [1]

[1] https://github.com/rust-lang/rustup/issues/1540#issuecomment...

Some people use tmux when connecting to their virtual machines on the server and forget to quit the htop instances. This adds to the total CPU utilization really quick.

On my system there are 240 tasks running with ~1700 threads. Htop is using 6% of single core with cgroup column disabled and 9% with it enabled. It spends most of the time in kernel space so it's not htops fault.

> While I agree that it is _less_ efficient than some other ways, in what way is that _significant_?

This gets noticeable when every connected user/session runs the htop.

The problem with htop on Linux is that once there are 200+ processes running on the system htop takes significant portion of CPU time and utilization. This is because htop has to go through each process entry in procfs (open, read, close) every second and parse the text context instead of just calling appropriate syscall like on the OpenBSD and friends to retrieve such information.

It would help if kernel provided process information in binary form instead of serializing it into text. Or even better to provide specific syscalls for it like on macOS, Windows, OpenBSD, Solaris and others.

Linus called Geekbench as useless few years ago since it uses hardware implementations of crypto algorithms on some architectures and not on others.

[1] https://www.realworldtech.com/forum/?threadid=136526&curpost...

Or disable caching for specified file when calling CreateFile API

https://docs.microsoft.com/en-us/windows/win32/api/fileapi/n...

Yes

https://www.youtube.com/watch?v=SsoOG6ZeyUI