shatsky

SDL3 can handle both Wayland and X11: https://news.ycombinator.com/item?id=47790895

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.

Does this mean Google just forked it to develop proprietary XR runtime and doesn't contribute back?

https://github.com/shatsky/lightning-image-viewer

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).

It does support dynamic libs, but virtually all important Rust software seems to be written without any consideration for it.

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?

PS. Actually I'll risk to share my (I'm new to Rust) thoughts about it: https://shatsky.github.io/notes/2025-12-22_runtime-code-shar...

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.

See also https://github.com/hakavlad/prelockd

Fun fact: EXIF is simultaneously JPEG format (EXIF spec describes compressed image file format which is based on JIF, the base JPEG file format described in JPEG spec, also EXIF is for "EXchangeable Image File format", suggesting that authors saw it as new file format) and TIFF format (EXIF metadata is actually embedded TIFF which can be parsed with tiffdump, also EXIF spec describes uncompressed image file formats which are TIFF with embedded EXIF metadata which is also TIFF...)

Yoshkar-Ola itself is a forgery, just google for its photos and name of that embankment street (no offence, just kidding, I even kinda like it, hope they didn't destroy some valuable authentic architecture to build it).

Repairing it is as easy as rebooting and selecting last generation which worked.

hopefully converges onto the same working state Saying it’s just about integrity is like saying docker images are just about integrity atomic units of deployment, the ability to run the same thing in prod as you do in dev

In my understanding, integrity is exactly about software being in certain known correct state, including absence of anything which is not part of that state. Of course integrity of parts of software system like individual packages contents does not make it really reliable when the whole system does not have it. NixOS has it and also allows to "run the same thing"

make drift from the original config impossible

NixOS makes that too, its whole "system output path closure" is as immutable as every single store unit within it. But NixOS "reuses" units which are unaffected by NixOS config changes when applying new config, making its "system rebuild" super fast and light on resources when something like a single config file is changed in NixOS config. And possible to be done "in place", unlike with "conventional immutable distro"

Another opinion: immutability is required to guarantee software integrity, but there is no need to make whole system or "apps" immutable units. NixOS also consists of "immutable units", but its "granularity" is similar to packages of traditional Linux distros, each unit (Nix store item) representing single program, library or config file. This provides a better tradeoff, allowing to change system relatively easily (much easier than in immutable distros described here, and in many cases as easy as in traditional Linux distros) while having advantages of immutability.

Maybe it was just a poorly prepared humorous performance referencing Monty Hall problem?

Cardboard is still here, YouTube app can play VR videos via it, Chrome for Android provides WebXR support via it, it's 3DoF only, but main usecase for phone VR is VR stereoscopic video which is 3DoF anyway. Daydream was attempt to create another proprietary ecosystem and is obsolete. Since then OpenXR has won as cross platform, cross vendor, open standard XR API, if Android gets standard OpenXR runtime with good 6DoF tracking and shell support everyone will be happy.

Looks like a chance to finally have modern standalone HMD with unlocked bootloader. Meta and ByteDance ones are locked down and full of spyware

This seems to be about possibility to enable Vulkan in any guest OS for which virtio-gpu guest driver will be developed. For Windows https://github.com/virtio-win/kvm-guest-drivers-windows/pull... is being developed, hopefully it will take off

Is suspend-to-ram something that often doesn't work on laptops with Linux, really? I used it on dozens and saw problems maybe once or twice. Though I usually pick ones which are 3+ years old.

"As easy as in desktop" not going to happen anytime soon. Phone "bootloader firmwares" lack full description of phone hardware in stardartized form like PC ACPI does, expecting customized OS kernel to know the phone it's running on. Phone devices lack capability to emulate something ancient-but-standard, expecting customized OS to include drivers for all of them. That's enough to make unified OS images impossible.

Not a VR expert, but it seems to be about same thing for OpenXR+Vulkan as A-frame is for WebXR+WebGL. Minimalist 3D engine with simple API wrapping much more complex lower level APIs, "reducing number of things which can be done in exchange for making some things easy to do with it". Native, not web app.

OpenXR is "Vulkan for VR" by the way, every major HMD vendors runtime supports it. Though only SteamVR supports Linux, and there's mess with support of advanced tech like asynchronous reprojection, I hope Monado which is "Mesa for VR" will succeed. And Firefox gets WebXR.

It's sad that there's no support for lossy compressed images. People copypaste images a lot without intention to change them, and each time it's JPEG source the compression is lost but artifacts are preserved, and more artifacts are added upon repeated JPEG compression, which happens immediately with most target web apps. https://xkcd.com/1683/