Window transparency is available on all major platforms, and there are cross platform libs which support it, such as SDL3: https://wiki.libsdl.org/SDL3/SDL_WINDOW_TRANSPARENT (for rendering, making underlying windows visible where window surface pixels are transparent), https://wiki.libsdl.org/SDL3/SDL_SetWindowShape (for input, making pointer events pass to underlying windows where surface pixels are fully transparent)
I (ab)use it in my image (pre)viewer to have image presentation area always fitting image during pan&zoom without window borders limiting it, while having underlying windows visible outside of it (transparent fullscreen overlay): https://github.com/shatsky/lightning-image-viewer
Strange that article does not mention that Euro-Office fork has been created because OnlyOffice has Russian origins. I feel bad for Russian devs who tried to build great free software while staying in Russia, hope they will be given options to relocate.
UPD seems that company claims they reside outside Russia and is silent about their previous residence and relocation, fork readme claims that devs still reside in Russia and company is trying to hide it. Ambiguous situation.
Tiny desktop (pre)viewer which displays image in transparent overlay without any UI, allowing to look into specific image detail with single hand move (zoom with scroll and pan with drag simultaneously like in map apps, with nothing but display borders limiting visible image surface) and toggle between file manager and image view almost instantly (close with left click anywhere/keyboard Enter).
Also finished initial rewrite in Rust just hours ago:) (originally did it in C and intentionally tried to make it initially close to preceding C codebase before going further, so many things are still managed manually)
Vibes of sunset of beautiful architecture. "It shouldn't be beautiful it's just a tool it should be practical, if it steals your attention [from some tiktok brainrot] to admire it it's not good thing". Can't say I like most detailed icons most, but not least detailed either.
I don't know much about node but cargo has lock file with hashes which prevents dep substitution unless dev decide to update lock file. Updating lock file has same risks as initial decision to depend on deps.
I believe NixOS-like "build time binding" is the answer. Especially with Rust "if it compiles, it works". Software shares code in form of libraries, but any set of installed software built against some concrete version of lib which it depends on will use this concrete version forever (until update replaces it with new builds which are built against different concrete version of lib).
And yet Rust ecosystem practically killed runtime library sharing, didn't it? With this mentality that every program is not a building block of larger system to be used by maintainers but a final product, and is statically linked with concrete dependency versions specified at development time. And then even multiple worker processes of same app can't share common code in memory like this lib, or ui toolkit, multimedia decoders, etc., right?
No, transcription has nothing to do with written text, it guessed few words here and there but not even general topic. That's doctors note about patient visit, beginning with "Прием: состояние удовл., t*, но кашель / patient visit: condition is OK, t(temperature normal?) but coughing". But unreadable doctors handwriting is a meme...
Will look into that again. If you're right about unevictability of these pages, what is the mechanism which causes sudden extreme degradation of performance when system is almost out of memory due to some app gradually consuming it, from quite responsive system to totally unresponsive system which can stay stuck with trashing disk for ages until oom will fire?
Author pushes abstract idea about "page reclamation" in front of ideas of performance, reliability and controllable service degradation which people actually want; because author believes that it is the one and only solution to them; and then defends swap because it is good for it.
No, this is just plain wrong. There are very specific problems which happen when there is not enough memory.
1. File-backed page reads causing more disk reads, eventually ending with "programs being executed from disk" (shared libraries are also mmaped) which feels like system lockup. This does not need any "egalitarian reclamation" abstraction and swap, and swap does not solve it. But it can be solved simply by reserving some minimal amount of memory for buf/cache, with which system is still responsive.
2. Eventually failure to allocate more memory for some process. Any solutions like "page reclamation" with pushing unused pages to some swap can only increase maximum amount of memory which can be used before it happens, from one finite value to bigger finite value. When there is no memory to free without losing data, some process must be killed. Swap does not solve this. The least bad solution would be to warn user in advance and let them choose processes to kill.