@nprofile1q... @nprofile1q...

No to jest ewidentnie za stara (ma 3+ lata). yt-dlp cały czas goni zmiany w YT (i innych serwisach z których ściąga), więc zwykle wersje sprzed paru miesięcy nie działają.

Możesz chcieć zaktualizować Debiana z Bookworm na coś nowszego (p. https://wiki.debian.org/DebianBookworm).

@nprofile1q... (I wasn't necessarily thinking about acute issues, but rather about things that can develop over regular instances of that. I do expect a good trainer to deal with those too.)

@nprofile1q... It feels like something that, if applied with no leeway, would be likely to create injuries. Am I misestimating, or is some amount of judgement/leeway (e.g. deciding how early to stop) essential to making it work well?

On a different tack, do you know of anything similar for endurance training?

@nprofile1q... Mhm. So, you have the passenger express judgement on whether you can go, right?

@nprofile1q... I don't like that it creates implicit expectations (that the passenger is looking at the area the driver thinks they're looking at). Do you have a way to avoid that?

Also, what do you communicate when distance/rate of closure is actually important?

@nprofile1q... How can you tell if it's a thermoplastic? By trying?

@nprofile1q... @nprofile1q... Not sure if related, https://black-magic.org (mentioned on codeberg as homepage) gives a TLS error to me (not a cert problem, but along the lines of tls handshake aborted because server declared an error).

In case it's helpful, curl output: https://paste.sr.ht/~robryk/2253076060f0e7fe3b4ebfb8920be7aa3e375cc3

@nprofile1q... @nprofile1q...

Wyobraź sobie, że masz edytor tekstu. Nie jest dziwnym, jeśli ten edytor tworzy plik na nowo za każdym razem jak go zapisujesz (w ten sposób może łatwo uniknąć uszkodzenia pliku gdyby się wywalił podczas zapisywania). Nie jest też szczególnie dziwnym, jeśli ten edytor tego nie robi. Strzelam, że chcesz, żeby "data stworzenia pliku" była taka sama w obu przypadkach; wobec tego w jej ustalaniu potrzebna jest współpraca programu, który ten plik zapisuje.

Jest wiele plików, gdzie nie za bardzo wiadomo jaka ta data miałaby być: wyobraź sobie bazę danych, która jest zapisana w katalogu, w którym czasami tworzy pliki. Z jednej strony te pliki powinny mieć datę utworzenia taką samą jak data utworzenia bazy danych. Ale jeśli niektóre można przypisać jednoznacznie do jakiejś tabeli, może te powinny mieć datę utworzenia taką samą jak data stworzenia tabeli? Albo jeśli któreś zawierają dane zapisane nie wcześniej niż moment ich stworzenia, to może powinny mieć datę stworzenia równą momentowi kiedy faktycznie zostały stworzone? Wydaje mi się, że niezbyt dobrze da się zdefiniować to czego szukasz dobrze dla wszystkich rodzajów plików.

Możnaby mieć intefejs, w którym podczas tworzenia pliku możesz podać "faktyczną" datę jego stworzenia i zapisywać te dane w systemie plików. Ciężko byłoby spowodować, żeby był w miare uniwersalnie używany, oraz nie misużywany.

Niektóre typy plików (np. docx, cokolwiek co obsługuje tagi id3) zawierają taką datę stworzenia gdzieś w środku i być może lepiej definiują co owa znaczy. Może to czego byś chciał to jakiś w miarę uniwersalny sposób czytania owych tam gdzie istnieją? (Byłoby miło gdyby `file` to umiał, ale pewnie się nie da, bo ta data pewnie jest często poza fragmentem który jest przezeń czytany.)

(BTW. szybko przywoływalne metadane backupów mogą też być pomocne, aczkolwiek raczej[1] nie powiedzą Ci, że jakiś plik był skopiowany z np. innego systemu)

[1] backupy deduplikujące możnaby pytać o pliki o podobnej zawartości, ale nie jestem świadom żadnego softwareu do nich który to obsługuje.

@nprofile1q... @nprofile1q... Jeśli plik ściągniesz z Internetu, to chcesz tam widzieć datę ściągnięcia, czy datę jego oryginalnego powstania?

(To czego chcesz wygląda dość podobnie do mtime dla plików, których nigdy nie zmieniasz.)

@nprofile1q... @nprofile1q... Co to znaczy utworzenia? Czy `mv` tworzy plik? A co z `cp` lub `scp`?

@nprofile1q... @nprofile1q...

If there's a maybe-low-bandwidth way to pass on information alongside the ciphertext that's public (attacker can read) but trustworthy (attacker can't modify) I'd transmit hashes and filenames with it.

If there isn't one, I'd sign something (e.g. with minisign): either the encrypted file itself or the kind of manifest I described above. If you want to prevent the attacker from swapping files around you need to either go a manifest-like route or use sth like the "trusted comment" in minisign to specify which file it is, and verify that at decryption-and-verification time.

@nprofile1q... @nprofile1q...

I'm not UnePorte, but wanted to say something similar in response to your original question (that the threat model matters a lot here).

Consider attackers who can modify the encrypted file. Do you want to ensure that the file is not some weird mixture of the contents you wanted and contents the attacker put there (this particular property is ensured by `age`)? Do you want to be able to ensure that the file is not wholesale replaced by the attacker in a way that allows the attacker to control its contents? If you have two such encrypted files, do you want to ensure the attacker didn't swap them?