aary

u/aary@xn--e1aghfa.xn--e1aqbccjfc.xn--p1acf
6 posts · 21 comments

Recent posts

Recent comments

on Announcing Rust 1.97.1 · c/rust · 1 pts · 68d
localhost(2026-07-19|14:57:51) ~/rust$ rustup update stable
info: syncing channel updates for stable-x86_64-unknown-linux-gnu
info: latest update on 2026-07-16 for version 1.97.1 (8bab26f4f 2026-07-14)
info: removing previous version of component cargo
info: removing previous version of component clippy
info: removing previous version of component rust-docs
info: removing previous version of component rust-std
info: removing previous version of component rustc
info: removing previous version of component rustfmt
info: downloading 6 components
        cargo installed                       10.63 MiB
       clippy installed                        4.71 MiB
    rust-docs installed                       22.73 MiB
     rust-std installed                       28.71 MiB
        rustc installed                       77.30 MiB
      rustfmt installed                        2.06 MiB                                                                                                      
  stable-x86_64-unknown-linux-gnu updated - rustc 1.97.1 (8bab26f4f 2026-07-14) (from rustc 1.96.0 (ac68faa20 2026-05-25))

info: checking for self-update (current version: 1.29.0)
localhost(2026-07-19|15:01:20) ~/rust$

I think that it should do backups first and remove only in the end. Or do parallel installs.

is not recommended for production systems

I think that this is because the protocol doesn't contain means of routing (similar to "SEEN-BY" fields). But that is solvable with some coding. And current implementation will work in restricted (controlled) tree-like topologies. I think this is negotiable, and there are no too much nodes, so agreements are possible.

The main repository of this project is https://github.com/igniterealtime/Openfire License: Apache-2
Current version is v5.1.0 (2026-06-03)
The feature was implemented since v4.6.0 (2020-10-16)
«[OF-2030] - Add support for XEP-0289: Federated MUC for Constrained Environments»

::: spoiler uninteresting notes about OF-2030 (i don't see that link under OF-2030 - https://issues.igniterealtime.org/browse/OF-2030, and

web.archive org don't saved it
https://download.igniterealtime.org/openfire/docs/4.6.0/changelog.html

«

Loading...

https://issues.igniterealtime.org/browse/OF-2030 |
	    17:30:40 September 20, 2022

Got an HTTP 301 response at crawl time

Redirecting to...

https://igniterealtime.atlassian.net/browse/OF-2030

»

The link https://igniterealtime.atlassian.net/browse/OF-2030
is unavailable at web archive org https://web.archive.org/web/20220922044149/https://igniterealtime.atlassian.net/browse/OF-2030 says:

426 Upgrade Required

« Похоже, на этом сайте есть проблема

https://web.archive.org/web/20220922044149if_/https://igniterealtime.atlassian.net/browse/OF-2030 вернул ошибку.

Код ошибки: 426 Upgrade Required

Проверьте, правильно ли вы ввели адрес веб-сайта.
»

, but available in the internet.

Contain almost no information, except that Guus der Kinderen is the author of implementation

:::

Have you considered the time-verified Redis for key/value storage?

I prefer to keep the setup as it is now. But if I will need k/v storage next time, I will use something else. And then, when it will be time to upgrade, i will migrate from minio to next choice. Or, just drop this setup and create a new one.

I don't know is it related or not. I have only one container instead of two, and I use Firefox instead of Chromium. Theoretically it's possible that there is no enough access rights for images data volume, but I didn't checked that yet (and in this case the error message is not clear and helpfull).

An additional problem - the site https://lemmyverse.link/ is available only partially (requires VPN to work).

So my new idea is to deploy
https://github.com/RikudouSage/lemmyverse.link
into my website locally, and give 2 links - the relative (via local redirector) and the direct one (as a fallback).

the relative link on forein server will became broken, until they also install such redirector into the same path.

After that the link will always lead to local server and redirect to preferred server of user.

You should be more constructive. We have opensource software, so probably there will be opensource life length boosters. What do YOU done to make the second scenario happened?

You can also paste that into the search of any lemmy instance to find it, if they mirrored it

Yes, this works. But I don't understand how. The question is - will it work, if remote instance went down?

«Your original url is right there in the path if it were to go down» But how it's supposed to help one, to see the original URL? It will help only if the content is archived in some way. If remote lemmy server will go down. Then content will became unavailable, even If I install a local copy of that redirecting engine.