qarmin

Mają płacone za robotę czy pro publico bono?

@qarmin polecam najlepszy laptop jaki dostaniesz w tej cenie, atakuj poleasingowki

@qarmin

Poleasingowy thinkpad - szukaj serii L albo T z najlepszym procesorem jaki znajdziesz. Unikaj ultrabookow, mogą się grzać i mieć gwiżdżący wentylator. Grube = lepsze ;)

Kiedyś miałem L440 z i7-4XXX, może zmieści się w budżecie? Aczkolwiek intel 5gen byłby tu idealnym rozwiązaniem, mniej się grzeją.

Przed zakupem potwierdź, czy ma 1Gbit ethernet i oryginalna ładowarkę.

Po zakupie wyczyść mu porzadnie kiszki i wymień pastę termo. Dobrze powtarzać to co roku.

Ponieważ będzie to sprzęt ok 10 letni, na 100% jego HDD/SSD będzie w drugiej połowie swojego żywota. Może pociągnie rok, może 10 lat. Proponowałbym przemyśleć budżet i wymienić dysk dla świętego spokoju.

Have fun!

@qarmin Kiedyś gdy pobierałem dużo filmów z cda i innych stron to zrobiłem coś podobnego tylko zamiast rozszerzenia do przeglądarki to napisałem skrypt do Tampermonkey który dodaje przycisk pobierz pod playerem więc w sumie jeszcze prościej i szybciej.

Btw yt-dlp potrafi pobierać też filmy z cda jak coś.

@qarmin Skoro ogarniasz Rusta to może na front zobacz to, ostatnio mi się obiło o oczy: https://dioxuslabs.com/

A co do backendu to jeżeli to ma być coś małego i z niewielkim ruchem to imo Node.js + jakiś fajny framework (typu Fastify, Nestjs albo Hono) będzie idealny i nie sądze żeby napisanie tego w Rustcie cokolwiek ułatwiło.

> aplikacja łatwa do outsourceowania

> rust

wybierz jedno

Tauri??

Chopie, kto ci to utrzyma?.

Node.js na serverze, react/next.js na apce webowej ktora bedzie zoptymalizowana na telefony.

Wszedzie JS, technologie ktore zna wiele osob + dosyc latwy stack. Rust jest spoko, ale wez znajdz ogarnietych specjalistow od reki, a w razie jak aktualni programisci zrobia "pa, pa" to szybko ich podmien.

Chociaz przy reactie sie nie upieram bo ostanie zmiany ida w zlym kierunku. Powoli mysle czym zastapic react.

@qarmin Nie pisałem dawno w rust, zwłaszcza na tym poziomie, ale zdecydowanie druga opcja. Wydaje mi się, że w pierwszej opcji będziesz miał proces w kolejce do ubicia/ubity, a to co zostanie to będą tzw. detached threads. Ale nie jestem (już) ekspertem, podpytaj może kogoś innego

@qarmin a to nie jest kwestia tego, że operacje na plikach robi kernel? Ubicie procesu nie przerywa fs::copy.

Po drugie, obsługa sygnałów nie jest synchroniczna. Jak zrobisz kill PID && rm costam, to na pewno to nie zadziała. Musisz poczekać, aż proces obsłuży sygnał i się zamknie.

Jak robisz timeout na wątkach wewnątrz programu, to z pewnością da się to bardziej elegancko obsłużyć.

@qarmin Analizując obie koncepcje, które przedstawiłeś, można zauważyć kilka istotnych różnic w sposobie zarządzania zakończeniem wątków i zatrzymaniem programu.

Pierwsza koncepcja

• Zalety:
  

• Każdy wątek sprawdza warunek time_left < 0 przed rozpoczęciem kopiowania.
  

• Jeśli warunek jest spełniony, natychmiast wywołuje process::exit(127), co natychmiastowo kończy cały program.
  

• Wady:
  

• process::exit(127) powoduje natychmiastowe zakończenie programu bez czekania na zakończenie pozostałych wątków. To może skutkować niekompletnym zakończeniem operacji IO, co może być przyczyną problemów z plikami.
  

• Możliwe nieprzewidywalne zachowanie, jeśli process::exit(127) jest wywoływane z wielu wątków jednocześnie.
  

Druga koncepcja

• Zalety:
  

• Sprawdza warunek time_left < 0 przed rozpoczęciem kopiowania w każdym wątku, ale zamiast natychmiastowego zakończenia, wątki, które spełniają warunek, po prostu kończą swoją pracę.
  

• Pozwala wszystkim aktywnym wątkom dokończyć swoje operacje kopiowania, zanim program sprawdzi, czy powinien zakończyć się process::exit(127).
  

• Bezpieczniejsze podejście, ponieważ nie powoduje natychmiastowego zakończenia programu, co pozwala na bardziej przewidywalne zarządzanie zasobami.
  

• Wady:
  

• Może powodować krótkie opóźnienie w zakończeniu programu, jeśli trzeba czekać na zakończenie wszystkich wątków.
  

Wnioski

Druga koncepcja jest bardziej bezpieczna i elegancka, ponieważ pozwala na kontrolowane zakończenie programu i uniknięcie problemów związanych z nieskończonym tworzeniem plików po wywołaniu timeout.

Natychmiastowe zakończenie programu przy użyciu process::exit w pierwszej koncepcji może prowadzić do nieprzewidywalnych problemów związanych z niedokończonymi operacjami IO. W drugiej koncepcji wątki mogą bezpiecznie zakończyć swoje zadania, co zmniejsza ryzyko wystąpienia problemów z plikami i zasobami.

Zatem rekomenduję skorzystanie z drugiej koncepcji. Jeśli jednak decydujesz się na pierwszą koncepcję, warto wprowadzić mechanizm, który upewni się, że wszystkie wątki zakończyły swoją pracę przed zamknięciem programu, aby uniknąć problemów z niekompletnym przetwarzaniem plików.

W Linux adres 127.0.0.1 i localhost nie są tym samym. Ten pierwszy korzysta z całego stacka sieciowego, więc pakiety są kierowane na kartę sieciową i wracają z powrotem. Z kolei localhost jest w pełni ogarniany przez kernel. Jeżeli jest jakiś problem z kartą to możliwe że uda się go wyeliminować przez zastosowanie localhost.

@qarmin sprawdź limity otwartych plików. Socket to też plik

Możliwe że mimo komunikacji wewnętrznej używany jest interfejs ethernetowy. Spróbowałbym wymusić ruch lokalny przez interfejs "lo" (LOOPBACK) np. taką komenda:\

ip router add 127.0.0.0/24 dev lo

@qarmin afere krecisz pomijajac to ze

po 1, przeciez juz to robia tylko sie nie chwala

po 2, mozna to wylaczyc

po 3, nie musisz kupowac ich surface

Windows 11 to jest w sumie raczysko. Korzystałem z tego systemu od początku i przy każdej większej aktualizacji sobie odpalałem, aby zobaczyć, jak jest ale ten system poza designem nie ma nic ciekawego do zaoferowania. Szkoda, że nie ma fluent design na 10tce, gdzie aplikacje systemowe mają czarny motyw i ogólnie mają poprawiony wygląd. Skalowanie jest zepsute w 11 a sam system wydaje się dziwacznie powolny względem 10, nawet na SSD. Obecnie siedzę na Ubuntu 24.04 LTS i w sumie jestem zadowolony, bo wreszcie Windows i jego nadbudowywanie systemu na systemie potrafi przyprawić o ból głowy.

Jak korporacje przetwarzające dane niejawne wykryją że Windows sam wysyła coś na zawnetrzne serwery pozwy będą w miliardy. Dlatego zapewne jak będzie to wyłączone to naprawdę nie będzie nic wysyłać.

Wygląda trochę jak nieślubne dziecko Windy i Maczka, obrzydliwe 😛

Pozostanę przy KDE.

Ciekawe jak długo pożyje, większość takich projektów tak samo się kończy. Wow wow, jak pięknie, 2 lata i martwy albo się kończy tylko na gadaniu.

Po co? Że tak spytam?

Nie wydaje mi się, żeby problem Linuxa była zbyt mała ilość środowisk i dystrybucji.

@qarmin koledzy zdaję się wyczerpali temat, ja tez stoje po stronie pisania testów, od siebie jeszcze dodam, że testy naturalnie tworzą dokumentację projektu. Najłatwiej jest sprawdzić jak się zachowuje komponent za pomocą testów i najlepiej naprawić buga najpierw pisząc test do przypadku.

@qarmin ja bym przede wszystkim chciał podkreślić, że testy jednostkowe to głównie narzędzie służące do projektowania, wymuszające stosowanie dobrych praktyk. W sumie czyste unit testy mają sens przede wszystkim w TDD, jeśli piszemy je później niż kod, to sens ich pisania jest dyskusyjny. Dobrze się natomiast sprawdzają w roli żywej dokumentacji. To testy integracyjne powinny służyć do wykrywania regresji, tych można stworzyć zdecydowanie mniej, za to każdy powinien mieć wielokrotnie większe pokrycie kodu. W praktyce, jeśli zespół nie stosuje TDD, to właśnie na takim rodzaju testów warto się skupić.

Pracuję przy takim projekcie w node, gdzie ktoś sprytny testuje timery bez użycia mocków, test po prostu czeka aż te timery odczekają swoje, nic mnie tak nie wkurwia jak odpalanie testów w tym projekcie xD.

po pracy w januszexie-startupie, gdzie nigdy nie bylo czasu na testy, nauczyłem się, jaką mają wartość. Zawsze na koniec projektu przy małej zmianie koncepcji ze strony klienta, caly kod sie zaczynał się jebać, bo choćby nie wiem co, nie jesteś w stanie zawsze mieć w głowie całego projektu.

Odkąd odszedłem z tej firmy, zacząłem robić wszystko uzywając TDD. Bez TDD twój kod = gówno. Choćby nie wiadomo jak czytelny i sprytny, bez dobrych testów nie jest niczego warty.

Żeby język mógł zaistnieć musi mieć przede wszystkich ogromną bibliotekę. Rust jest jeszcze w fazie gdzie się mnóstwo tworzy, a same staty wiosny nie czynia. Choć już czytałem że hype na ten język się trochę wypalil.

Piszę w rust pare miesięcy i uważam że to jest naprawdę dobry język w porównaniu do Java, typescript czy c lub c++

RUST is not a dust. Bardzo lubię ten język, już wiem, że warto.

Obydwa nadają się do trywialnych i prostych zadań. Niech dla przykładu zaproponuje Ci rozwiązanie problemu, gdy mając jakąś starą aplikację w Javie (choćby 7 i starsze) musisz zacząć obsługiwać TLSv1.2. Skończysz na przepisywaniu aplikacji lub tysiącu propozycji, z których żadna nie zadziała.

Dopiero się z tym ogarniam, wiele prostych podpowiedzi jest spoko, niestety jak już trzeba coś na poważnie skonfigurować to sugestie AI są - delikatnie mówiąc - z pupy.

U mnie niestety przydatne tylko do wskazania ogólnego kierunku - w narzędziu z którym pracuję najczęściej kod napisany przez chatGPT po prostu nie działa. Za dużo halucynacji, wymyśla biblioteki które nie istnieją, wrzuca nieaktualne biblioteki albo takie które nie są wspierane w wykorzystywanej przeze mnie wersji tylko następnej, albo podaje kod który zwyczajnie nie zadziała bo korzysta ze słów kluczowych czy funkcji które nie istnieją. Często też podaje użycie funkcji w sposób w który nie da się z nich skorzystać (np totalnie złe argumenty). A czasami zapytany o stworzenie jakiejś logiki zwraca deklarację funkcji z jej nazwą i komentarzem - dopisz sobie resztę xD

Szkoda bo narzędzie jako takie bardzo przydatne, ale najwyraźniej moje środowisko pracy zbyt mało popularne żeby umiał sobie z nim poradzić.

@qarmin jest standardowy moduł w Pythonie, nazywa się multiprocessing. W nim znajdziesz Pool i metody typu starmap i map. Najczęściej z tego korzystam gdy trzeba zrównoległość obliczenia.

https://superfastpython.com/multiprocessing-pool-map/

# SuperFastPython.com

# example of parallel map() with the process pool

from random import random

from time import sleep

from multiprocessing.pool import Pool

# task executed in a worker process

def task(identifier):

    # generate a value

    value = random()

    # report a message

    print(f'Task {identifier} executing with {value}', flush=True)

    # block for a moment

    sleep(value)

    # return the generated value

    return value

# protect the entry point

if __name__ == '__main__':

    # create and configure the process pool

    with Pool() as pool:

        # execute tasks in order

        for result in pool.map(task, range(10)):

            print(f'Got result: {result}', flush=True)

    # process pool is closed automatically

Na zamieszczonym zdjęciu znajdziesz wszystkie metody z klasy Pool które możesz wykorzystać.

Niesamowite że ktoś pomyślał że może z tym nie być problemu - zawsze powinno się budować, uruchamiać testy na docelowym sprzęcie (przecież tam będzie to wszystko działać na nie na kompie programisty lol). Dobrym pomysłem jest nawet redundancja, macie joba który uruchomi testy na x86_64 i joba na ARM, oba muszą przejść. Gdybyście kompilowali, to również im więcej kompilatorów tym lepiej. W embedded trzeba spodziewać się niespodziewanego.

A już totalną ignorancją okazali się prowadzący ten projekt jeśli uruchamiacie testy na 64 bitowej platformie, a docelową platformą jest 32 bitowy ARM

Najgorzej jak znajdziesz buga w Firefoxie i okazuje się że podobny błąd został zgłoszony w 2006 roku i od 18 lat toczy się pod nim dyskusja. Co jakiś czas ktoś pyta kiedy to będzie naprawione, następnie ktoś z mozilli odpowiada że nad tym pracuje by za dwa lata znowu dostać pytanie o postępy xD

Zauważyłem np że firefox na androidzie bardzo często odświeża strony po powrocie do niego, tak jakby od razu po przeskoczeniu do innej apki czyścił dane strony z pamięci. Oczywiście zgłoszony bug wisi od paru lat w backlogu bo niby ważny błąd ale jakoś tak nie umieją go odtworzyć

(sorki za offtop xD)

Używacie biblioteki scipy i się dziwicie… zaciągnijcie normalnie z github a nie z jakiejś cipy…

@qarmin bez tagów ID3v1/2 ?

lata stagnacji?

z linuksem to mi się już tylko kojarzy kilkaset dystrybucji i kilkanaście menedżerów okien.

Wszystko w permanentnych wersjach rozwojowych, w których najwięcej rozwijających się rzeczy to błędy.

Żadnej stabilizacji, nic pewnego poza płatnymi dystrybucjami typu rhel.

Rok temu rozważałem odejście z windowsa, ale odpuściłem bo już wybranie właściwej dystrybucji dla mnie było twardym orzechem do zgryzienia. A w trakcie tego pojawiła się kolejna zagwozdka: jakie X?

I tak minął kolejny huczny rok linuksa (☞ ﾟ ∀ ﾟ)☞

Aby jednak było jasne, nie mam nic przeciwko nowym inicjatywom w oprogramowaniu.

Za to mam wszystko do kolejnych odłamów oprogramowania ( ͡° ͟ʖ ͡°)

DE? a po co to komu

Jestem dinozaurem. Dobre środowiska graficzne skończyly się na KDE 3.X

@qarmin - ale do przesyłania plików weź ty użyj czegoś normalnego jak scp, rsync, robocopy, gołe SSH, sftp a nawet ftp(s).