• 62 Posts
  • 284 Comments
Joined 3 years ago
cake
Cake day: May 2nd, 2022

help-circle



  • Nawet rozwijają w tym kierunku swoje narzędzia wyszukiwania i analizy.

    Właśnie po to analizuję IR gcc :-)

    Jak duże są większe fragmenty? To coś co wymaga już jakiejś ogólnej struktury?

    To zależy od złożoności zadania. Ogólnie nie ma problemu ze składnią kodu z LLMa. Kompilacja C++ prawie zawsze się udaje.
    W przypadku łatwiejszych zadań zdarza się, że kilkaset linijek boilerplate’u nie zawiera istotnych problemów.
    Ale czasem nawet 5 linijek z bardziej złożoną manipulacją na IR (generowanie wywołaia funkcji, obsługa wyjątków) potrafi spowodować Internal Compiler Error.
    W takich przypadkach przetworzony IR narusza zazwyczaj wewnętrzne założenia w GCC. Np. zaburza postać static single-assignment.

    Człowiek może takie problemy można dość prosto rozwiązać.
    Na przykład mój plugin ma automatycznie dodawać w określonych miejscach wywołania hooków.
    Najpierw piszę sobie wzorcowy kod C/C++ z wstawionymi hookami i dumpuję jego prawidłowy IR do pliku.
    Potem porównuję go z tym co wygenerował mój plugin dla kodu bez hooków.
    LLM (bez trybu agenta) takiego porównania nie zrobi, bo nie ma możliwości uruchomienia tych narzędzi.

    Wiele osób też nie umie kodować bez ciągłego uruchamiania kompilacji lub jakiegoś serwera wskazującego błędy podczas pisania.

    Carmack nie pisze testów, ale uruchamia każdą nową funkcję pod debuggerem i sprawdza jej działanie linijka po linujce.

    Ktoś jednak powiedział, że to psuje umysł.

    Nie wątpię, ale nadal zdobywam wiedzę o dużym projekcie komercyjnym i nie dałbym rady robić równolegle podobnej analizy dla gcc bez wspomagania.


  • Integrację kilku komponentów (rozwijanych w innych zespołach) w gotowy produkt.
    Ten etap produkcji software’u to jest takie piekiełko, gdzie wychodzą wszystkie niedociągnięcia i braki testów we wcześniejszych etapach. W żadnym innym projekcie nie spędziłem tyle czasu nad debuggerem.

    Nauczyłem się też, że nie każðy jest skłonny bez “walki” zaakceptować istnienie błędu w swoim komponencie. Czasem trzeba było spędzić kilka godzin na dokumentowaniu scenariusza reprodukcji buga, bo wskazanie złej logiki w kodzie nie wystarczało.
    Krótko mówiąc “keep calm and blame frontend” (chociaż nie robiliśmy nawet UI).

    Podobnie każde przekroczenie deadline’u przez którykolwiek “upstreamowy” zespól stawało się na końcu twoim własnym problemem. Pytania od kierowników odpowiedzialnych za release pojawiały się zanim uzyskaliśmy wszystkie zależności.

    Po tym projekcie doszedłem do wniosku, że absolutnie nie sprawdza się “potokowy” model produkcji software’u, jak przy taśmie w fabryce.
    Każdy zespół musi wertykalnie odpowiadać za swój produkt, albo cykle wydawnicze każdego komponentu muszą być niezależne (tak żeby downstreamowy projekt mógł odrzucić niedziałające wersje zależności).


  • Mogę się założyć o czekoladę z okienkiem, że wynik prezentacji nie był wygenerowany w czasie rzeczywistym, tylko został przygotowany wcześniej. :-)

    Przy okazji, ostatnio dłubię trochę w GCC i próbuję poznać ten kompilator od środka. Ogólnie projekt jest znacznie gorzej udokumentowany od LLVM. Ciężko jest znaleźć od ręki sensowne opisy do wewnętrznych API, czy reprezentacji kodu (GIMPLE).
    Wyniki z Google często zawierają tylko szczątkowe informacje. Nawet na Stack Overflow są wątki z pytaniami bez żadnych odpowiedzi. Finalnie doszedłem do wniosku że pozostanie mi czytanie jakichś prac naukowych i prezentacji developerów. Ewentualnie analiza kodu źródłowego.

    Spróbowałem jeszcze z ciekawości zadać parę pytań LLMowi i okazało się, że Claude potrafi udzielić całkiem sensownych odpowiedzi. Można go poprosić o opis dowolnej funkcji w kodzie, podsumowanie różnych etapów kompilacji, albo o fragment kodu wykonujący konkretną manipulację na IR.
    Jestem prawie pewien, że nie są to informacje “przeklejone” z jakiejś strony. Spędziłem parę godzin na przeszukiwaniu sieci i nie udało mi znaleźć takich opisów.
    Moim zdaniem skraca to czas potrzebny na analizę projektu i “onboarding” o minimum jeden, może dwa rzędy wielkości. To jest faktycznie pierwszy przypadek, gdzie zauważyłem, że AI zwiększyło moją wydajność.

    Z drugiej strony, samo generowanie większych fragmentów kodu nie idzie mu już tak dobrze.
    Nie używam trybu agenta i model ewidentnie nie radzi sobie z poprawieniem błędów. Bez użycia narzędzi do debugowania nie ma chyba wystarczającej informacji zwrotnej o przyczynie problemu.







  • Tylko że ja właśnie nie mam jakiegoś standardowego worfklowu. :-)

    Może jestem staromodny, ale jeśli mam do skompilowania 3 pliki, to używam shella albo prostego Makefile.
    Nie będę pisał CMakeLists.txt z zarządzaniem zależnościami ani stawiał pipeline’u CI/CD dla projektu, który zrobię na swoim komputerze przez dwa tygodnie.

    Często widzę w repo malutkich projektów gotowe integracje z różnymi narzędziami, nix flakes, dockerem, trzema systemami budowania kodu, GitHub pipelines.
    Zastanawiam się wtedy, czy te narzędzia zostały wprowadzone by rozwiązać rzeczywisty problem, czy po prostu ktoś chciał przetestowac nową zabawkę.

    W ostatnich latach miałem taka ekspozycję na tego typu rozwiązania w różnych projektach firmowych, że dorobiłem się chyba jakiejś alergii na takie “devopsowe” tematy.



  • Nix ma swoje wady: jest trudny w utrzymaniu, analiza błędów jest bardziej skomplikowana od debugtowania szablonów C++, żeby zmienić konfigurację systemu musisz mieć połączenie z siecią, integracja z LSB jest słaba, ciężko jest rozwijać software na inne dystrybucje używając Nixosa (chyba że wspiera się tylko nixa).

    Tmux to w sumie nic nowego, ale używam go tylko do utrzymania sesji terminala na zdalnych hostach.
    Nie robię tym narzędziem multiplexowania sesji, bo wygodniejszą obsługę wielu okien mam w i3wm.
    Bardziej przydatny w pewnych warunkach jest mosh. bo eliminuje problem opóźnienia w terminalu na słabych/mobilnych łączach.





  • Wydaje mi się, że piszemy o dwóch różnych przypadkach.
    Ja nie twierdzę, że obecne zabezpieczenia chronią przed zaawansowanym atakiem na konkretne urządzenie/użytkownika sieci.
    Jakiś wektor zawsze się znajdzie, chociażby na poziomie systemu operacyjnego. Państwo może też współpracować z dostawcą sieci w określonych przypadkach.

    Chodzi mi o wprowadzanie zmian, które umożliwią automatyczne monitorowanie komunikacji na masową skalę.
    Zamiast szyfrowania E2E będziesz mieć ruch przetwarzany w centrach danych, z wyszukiwaniem określonych wzorców w każdej wypowiedzi.
    Politycy którzy forsują ten projekt nie mają chyba pojęcia, jak szybko może się on obrócić przeciwko nim samym. Nawet jeśli przyjmiemy założenie, że pomysłodawcy ustawy mają dobre intencje. Jaką mają gwarancję, że ich następcy nie użyją tego narzędzia do eliminacji przeciwników politycznych?




  • Będzie miał mniej spamu, fałszywych newsów, komentarzy z farmy botów?

    Nic z tych rzeczy nie jest prawdą. Te działania prowadzone są przy użyciu zainfekowanych komputerów, albo z krajów gdzie nie ma odpowiednich regulacji.

    Przecież ludzie używają jednej strony, w porywach trzech, na które to nie wpłynie w jakiś wyraźny sposób. Reszta to usługi dla których internet jest tylko medium.

    Monitorowanie ruchu nie będzie dotyczyć tylko stron. Ja osobiście nie życzę sobie, żeby moja komunikacja z członkami rodziny była nadzorowana przez funkcjonariuszy.
    To jest bardzo prosta analogia. Czy chciałbyś, żeby przy każdej Twojej rozmowie był obecny policjant? Bo bez skutecznego szyfrowania będzie mógł się z tymi treściami zapoznać.
    Jeśli ktoś twierdzi, że temat go nie interesuje, bo nie ma nic do ukrycia, zawsze możesz spytać, czy udostępni Ci w takim razie swoją komórkę na 10 minut.