#Google wiedziało, co kupujesz. #AI wie, dlaczego płaczesz w nocy.
⬇️ https://t.me/ProgramowanieLinux/2032

Przez ostatnią dekadę baliśmy się, że #Facebook czy #Google wiedzą o nas za dużo. Ale z perspektywy roku 2026, tamta inwigilacja wydaje się zabawnie prymitywna.

Co wiedział o Tobie Google? Że szukałeś "taniego hotelu w Paryżu" i "leków na ból pleców". To były okruchy - metadane. Co wie o Tobie Twój asystent #AI, z którym rozmawiasz codziennie?

Wie wszystko, co jest pomiędzy!

W oknach czatów z #ChatGPT, #Gemini czy #Claude oddajemy korporacjom coś, czego nigdy nie wpisalibyśmy w wyszukiwarkę:
- Nasz proces myślowy.
- Nasze lęki ("Jak powiedzieć żonie, że straciłem pracę?").
- Nasze finanse ("Przeanalizuj ten PIT, nie wiem, czemu wiszę tyle urzędowi").
- Nasze surowe pomysły na biznes, zanim jeszcze powstaną!!!

Stworzyliśmy najdoskonalszy system inwigilacji w historii, i to dobrowolnie. Dlaczego?
Bo jest pomocny.

To transakcja faustowska: my dostajemy "inteligentnego przyjaciela", który pomaga nam ogarnąć życie, a Big Tech dostaje kompletny profil psychologiczny każdego użytkownika.

Do czego mogą to wykorzystać? To już nie chodzi o "targetowanie reklam butów".

Precyzyjna manipulacja:
Jeśli #AI wie, jakie masz kompleksy i lęki, może podsunąć Ci produkt w sposób, któremu nie będziesz w stanie się oprzeć. Scoring życiowy:
Wyobraź sobie, że bank lub ubezpieczyciel kupuje dostęp do "profilu ryzyka" opartego na Twoich rozmowach z AI.
Kradzież innowacji:
Twój genialny pomysł na startup, który "skonsultowałeś" z modelem, staje się częścią zbioru treningowego.

Traktujemy okno czatu jak konfesjonał. Ale w tym konfesjonale po drugiej stronie nie siedzi dyskretny ksiądz, tylko #algorytm, który wszystko notuje, indeksuje i sprzedaje (lub wykorzystuje do trenowania jeszcze sprytniejszych modeli).

Prywatność w 2026 roku jest cenniejsza od złota. A my ją tracimy za darmo w zamian za streszczenie maila.

🔙 https://t.me/ProgramowanieLinux/2031

Przestań strzelać z armaty do muchy. #AI to nie jest rozwiązanie każdego problemu.
⬇️ https://t.me/ProgramowanieLinux/2034

Obserwuję ostatnio niebezpieczny trend, zwłaszcza wśród vibe coderów. Mamy w rękach najpotężniejszą technologię w historii, a używamy jej do... wyciągania nagłówka ze strony internetowej.

Widzę projekty, gdzie ludzie budują skomplikowane łańcuchy w n8n albo make, podpinają GPT-4o i płacą za tysiące tokenów tylko po to, żeby sprawdzić, czy w tekście znajduje się adres email. To jak kupowanie Ferrari, żeby pojechać po bułki do sklepu za rogiem. Wygląda fajnie, ale jest drogo, niepraktycznie i trudno zaparkować.

Dlaczego "stara szkoła" programowania wciąż bije AI na głowę w 80% przypadków?

1. Koszt
Gdy robisz demo na Twittera, koszt API rzędu $0.05 nikogo nie boli. Ale gdy Twój SaaS zaczyna mieć ruch, te centy zamieniają się w tysiące dolarów. Pythonowy skrypt z biblioteką BeautifulSoup (bs4) przemieli tysiąc podstron za darmo. LLM przepali na to budżet, który mógłbyś wydać na marketing.

2. Latency
Zapytanie do API OpenAI czy Anthropic to często sekundy oczekiwania. Klasyczny kod w JavaScript czy Pythonie wykonuje się w milisekundach. Jeśli każesz użytkownikowi czekać 5 sekund na wynik prostego filtrowania danych tylko dlatego, że "AI musi pomyśleć", to zabijasz swój UX. Nikt nie ma na to czasu.

3. Halucynacje
Regex jest nudny. Jest trudny. Ale jest przewidywalny. Zawsze zadziała tak samo. AI? Bywa różnie. Raz zwróci Ci idealnego JSON-a. Za drugim razem doda komentarz "Here is your JSON", który wywali Twój parser. Za trzecim razem zmyśli dane, bo zgubi kontekst. Często "może zadziała" to za mało.

Kiedy więc używać AI? Tam, gdzie kończy się logika, a zaczyna "rozumienie". ✅ Analiza sentymentu (czy klient jest wkurzony?). ✅ Wyciąganie danych z totalnego bałaganu (nieustrukturyzowany tekst). ✅ Kreatywność i generowanie treści.

Ale do całej reszty? Błagam, przeproście się z "klasykami". Python (Requests, BeautifulSoup, Pandas). Zwykły SQL. Stary, dobry JavaScript.

Bycie dobrym programistą (lub vibe coderem :) ) w 2026 roku nie polega na wciskaniu AI wszędzie. Polega na wiedzy, kiedy go NIE używać. Budujcie systemy, które są szybkie, tanie i działają.

🔙 https://t.me/ProgramowanieLinux/2033

Nigdy nie mówcie nigdy...
I nie piszcie takiego kodu 😁

#Bielik czyli Polski #LLM
https://youtu.be/gDJclWCw1qY?si=X1FJLbwrsS6M_mom
PS: a w rozmowie w ogóle sporo technicznych detali na temat technologi LLM i w ogóle "wielkich sieci neuronowych".

Czy wiesz, że nawet “nieistniejąca” firma może mieć dane publicznie udostępnione w sieci i to bez Twojej wiedzy?

Z naszym darmowym poradnikiem OSINT otrzymujesz:
✅ 5 narzędzi do pasywnego rozpoznania,
✅ przykłady z realnych wycieków danych,
✅ 12 linków do sprawdzonych baz i frameworków,
✅ praktyczne instrukcje krok po kroku.

Już dziś sprawdź, co Internet “wie” o Twojej domenie, serwerach, e-mailach lub firmie.
To wiedza, dzięki której zyskujesz przewagę nad potencjalnymi atakami — i zwiększasz bezpieczeństwo danych.

🛡️ Kliknij, poniżej i odbierz poradnik.
https://www.facebook.com/share/p/1HZCcyFSFN/

Dyski #SSD są już 16 razy droższe od #HDD i osiągają wartość złota w skrajnych przypadkach - GRYOnline.pl https://share.google/wFFDpoXmgSOXrbbHW
PS: To już jakaś masakra!😁

Pokolenie Z nie chce już studiować programowania, a 76% osób wybiera radykalnie inne ścieżki kariery. Stanowi to problem dla Amazona, Apple i Google - GRYOnline.pl https://share.google/Q8XPuwhIJuaeyLNde
PS: skoro wszyscy, łącznie z szefami tych big-techów, mówią że "wkrótce programistów zastąpi AI", to skąd to zaskoczenie? 🤔

#LLM w rękach "ciemnej strony mocy". Proroczy wykład z 2023 roku.
https://www.youtube.com/watch?v=2HcBCOt7P1w&list=PL2SAIqXrTWagFqCFcAtHZs95yYYM2YzU1
#ProfJerzySurma

⚡💁Agent sztucznej inteligencji wydał 3000 dolarów na kursy związane z budowaniem marki osobistej

Użytkownik udostępnił sieci neuronowej dostęp do swojego komputera i kont bankowych, licząc na zysk. Jednakże sztuczna inteligencja wydała 2997 dolarów na kurs u „internetowego oszusta”, obiecując, że po 90 dniach i trzech lekcjach uda się zwiększyć inwestycję właściciela dziesięciokrotnie.

#AMD i #Qualcomm rzucają wyzwanie #NVIDIA. Wykorzystają rewolucyjne pamięci #RAM w formacie #SOCAMM
https://www.ppe.pl/news/397595/amd-i-qualcomm-rzucaja-wyzwanie-nvidia-wykorzystaja-rewolucyjne-pamieci-w-formacie-socamm.html
#AI czy #GRY

New Linux license terms
https://redd.it/1p4y4o7
@r_linuxmemes

Czy potrafisz dostrzec cały las za drzewami?

Jak często widziałeś programistów, którzy utknęli w recenzji kodu, omawiając optymalizację metod lub „doskonałość kodu”? Spędzają godziny lub nawet dni, próbując uczynić kod doskonałym? Czy to naprawdę pomogło w stworzeniu dobrze zaprojektowanego rozwiązania?

Programiści często utkną w drobnych szczegółach i całkowicie tracą z oczu ogólny obraz. To bardzo częsty błąd, który widzę w zespołach inżynieryjnych. W rezultacie mamy doskonałe klasy lub funkcje i kompletny bałagan w ogólnej strukturze.

Właściwa recenzja powinna zawsze zaczynać się od ogólnego spojrzenia:
🔸 Struktura komponentów: Czy zmiany są wdrożone w komponentach/usługach, które są faktycznie odpowiedzialne za tę logikę?
🔸 Struktura modułów: Czy zmiany w modułach są takie, jakich się spodziewałeś (publiczne vs prywatne, pkg vs wewnętrzne itd.)?
🔸 Kontrakty publiczne: Sprawdź, jak Twoje API będą wykorzystywane przez inne aplikacje. Czy są one jasne, wygodne, łatwe w użyciu i łatwe do rozszerzenia?
🔸 Nazewnictwo: Czy nazwy modułów, klas i funkcji są jasne i łatwe do zrozumienia? Czy nie dublują istniejących podmiotów?
🔸 Model danych: Czy model jest prawidłowo modelowany? Czy model postępuje zgodnie z zasadą pojedynczej odpowiedzialności?
🔸 Testy: Czy główne przypadki są uwzględnione? A co z negatywnymi scenariuszami? Czy mamy właściwe podejście do obsługi błędów?

W większości przypadków nie ma sensu sprawdzać szczegółów kodu, dopóki powyższe elementy nie zostaną sfinalizowane. Kod prawdopodobnie zostanie przepisany, być może nawet więcej niż raz.
Dlatego konkretne linie kodu powinny być ostatnią rzeczą do sprawdzenia.

Szczegóły są łatwe do naprawienia.
Struktura i kontrakty nie są.

#engineering #codereview

Can you see the forest for the trees?

How often have you seen developers stuck in code review discussing some method optimization or "code excellence"? Spending hours or even days trying to make code perfect? Did that really help build a well-architected solution?

Developers often get stuck in small details and completely lose sight of the bigger picture. That's a very common mistake that I see in engineering teams. As a result, there are perfect classes or functions and complete mess in overall structure.

A proper review should always start with a bird’s-eye view:
🔸 Component structure: Are changes implemented in the components\services that are actually responsible for this logic?
🔸 Module structure: Are changes in the modules you expect them to be (public vs private, pkg vs internal, etc.)?
🔸 Public contracts: Review how your APIs will be used by other parties. Are they clear, convenient, easy to use, and easy to extend?
🔸 Naming: Are module, class and function names clear and easy to understand? Don't they duplicate existing entities?
🔸 Data model: Is the domain modeled correctly? Does the model follow single responsibility principle?
🔸 Testing: Are main cases covered? What about negative scenarios? Do we have proper failure handling approach?

In most cases, there’s no point in reviewing code details until the items above are finalized. The code will likely be rewritten, maybe even more than once.
That’s why specific lines of code should be the last thing to check.

Details are cheap to fix.
Structure and contracts are not.

#engineering #codereview

Linux GUI Programming Experience
https://redd.it/1qsbgu1
@r_linuxmemes