[assninja]

Szybkie porównanie kilku systemów synchronizacji plików/backupu, założenia to synchronizacja między #macbook a serwerem #linux
Nie potrzebuję kalendarzy, offica, wideokonferencji itd

Testowane:

#nextcloud
minusy:
- php
- jeden wielki p--------k
- 2137 aktualizacji na miesiąc które nic nie zmieniają
- skomplikowany deploy, chyba że używasz AIO
- AIO ssie, system backupów wymaga wyłaczenia całości, która potem lubi nie wstać
- dosyć wolny
plusy:
- dobra apka na wiele platform w tym ios

#owncloud infinite scale (ocis) oraz jego fork #opencloud
minusy:
- brak 2fa bez LDAP
- skomplikowany deploy jeśli chcesz LDAP
- apka na desktop nie potrafi synchronizować katalogów poza głównym katalogiem który synchronizuje. Próbowało mi usunąć wszystkie pliki z $HOME gdy go ustawiłem jako główny katalog
- dziwne założenia, nie synchronizuje się katalogów tylko "spaces"
plusy:
- łatwy deploy bez LDAP
- szybki, bezpieczny, prosty

#syncthing - po prostu synchronizacja plików, bez niczego innego
minusy:
- interfejs www służy tylko do ustawień. Nie przeglądniesz w tym plików
plusy:
- stabilny, bezpieczny, szybki, świetna apka - prawie ideał

#seafile
minusy:
- wersja pro płatna powyżej 3 użytkowników
- pliki są przechowywane podobnie jak w repozytorium git, nie można sobie po prostu skopiować z serwera w inne miejsce albo podpiąć tam np. immich
plusy:
- świetna apka
- szybka synchronizacja
- łatwy, dobrze udokumentowany deploy

Deploy wszystkich oczywiście w dockerze, ale gdy mówię skomplikowany to znaczy że często musiałem nanosić dużo poprawek by działało prawidłowo. Tym bardziej że we wszystkich przypadkach używałem tailscale w osobnym kontenerze, nie na hoście

[fervi]

@assninja: W sumie to nie wiem co złego w PHP, bardzo dobry język do pisania stron.

[assninja]

@fervi: ale nie do pisania systemu który ma bezpiecznie przechowywać i synchronizować pliki

a i nie jest bardzo dobry w niczym :P

[fervi]

@assninja: PHP jest dość szybki i odporny na awarie. A to obie ważne rzeczy dla devów

[assninja]

@fervi: ważniejsza jest dobra dokumentacja, trzymanie się jednej konwencji, przewidywalność. W php używa się takich_funkcji() czy może takichFunkcji()? Czy w parametrze używa się (element, stack) czy (stack, element)?

Odpowiedź brzmi "tak" XD

Aczkolwiek i tak wolałbym robić w php niż w jakimś react w js lol. Gdzie samo npx create-next-app@latest foo tworzy prawie 10k plików i 360 MB.

create-react-app tworzy 41k plików i nawet nie wiem czemu, ale

[RobinSchudl]

@assninja: ja używam nextclouda od lat i jest spoko.

[fervi]

@assninja: Oczywiście język Ci wielu rzeczy nie definiuje. Pytanie czy powinien ( ͡° ͜ʖ ͡°) Ale w sumie dlatego Python jest dla noobów (chociaż moim zdaniem jest znacznie trudniejszy od PHP), bo właśnie dużo uwagi skupiasz się nie na funkcjach, a na indentacji, ładnym układaniu itd.

[rtp_diov]

założenia to synchronizacja między #macbook a serwerem #linux

Nie potrzebuję kalendarzy, offica, wideokonferencji itd

@assninja: każdy z tych projektów bałbym się użyć. Według mnie lepiej skorzystać po prostu z SFTP a do asynchronicznej wydajnej synchronizacji rsync. To działa cuda. Używam tego rozwiązania do synchronizacji i backupów wszystkich swoich urządzeń, również dla telefonów i dostępu z całego świata do swoich danych.

[meczace_loginy]

@assninja: Przy nextcloudzie należy nadmienić, że api nie istnieje. Nie można sobie po prostu curlem wrzucić plik i udostępnić go wygenerowanym linkiem.

[assninja]

@meczace_loginy: plik curlem zawsze można wrzucić, masz webdav, ale żeby wygenerować automatycznie link to uuuuuu

[assninja]

@rtp_diov: to nie to samo co stały, natychmiastowy sync z wersjonowaniem plików po stronie serwera. Owszem, można zrobić magię z rsync i hardlinkami co będzie to trochę udawało wersjonowanie ale no właśnie

[rtp_diov]

@assninja: nie rozumiem? SFTP daje ci możliwośc natychmiastowego sync , rsync także wraz z prsotym wersjonowaniem tego typu, że np. istniejącą wersję starą na serwerze może zachować w folderze np o nazwie "old_backup". Oczywiście masz rację, że nie jest to wersjonowanie pełne - no to racja jak czegoś takiego wymagasz to moje rozwiązanie nei jest najlepsze

[assninja]

@rtp_diov: w rsync masz --link-dest dzięki któremu możesz mieć np. jeden pełen backup z wszystkimi plikami a potem każdy kolejny backup będzie miał tylko zmienione/dodane/usunięte pliki, natomiast te które się nie zmieniają będą hardlinkami z poprzedniego backupu. Szybkie i nie zabiera więcej miejsca niż jeden pełen, można wrócić do konkretnej wersji itd

Ale oduczyłem się robić własnego softu do backupów, a tak bym to traktował, i wolę polegać na czymś

[rtp_diov]

Ale oduczyłem się robić własnego softu do backupów, a tak bym to traktował, i wolę polegać na czymś dobrze przetestowanym i sprawdzonym 乁(♥ ʖ̯♥)ㄏ

@assninja: no to wiesz rsync jest normalnym rozwiązaniem tyle, że konsolowym po prostu bez UI. Ale też jest rozwiązaniem przetestowanym i sprawdzonym na świecie bazuje na nim wiele innych narzędzi, ale rozumiem każdy ma inne podejście.

[assninja]

@rtp_diov: jeśli chodzi o normalne rsync -avP /foo/bar/ server:/baz/ to jasne ale robienie coś w stylu applowego time machine na podstawie hardlinków no to lubi wybuchnąć w twarz :P

[meczace_loginy]

@assninja: Otóż właśnie. Jak plik od biedy się jeszcze da wrzucić, tak linka zrobić, to już nie. Jak i wielu innych akcji. Ktoś nie do końca przemyślał interfejs.