Bezgraniczne zaufanie do obcych technologii...
Dobrze że nie chińskich jak #premier.
Dobrze że nie chińskich jak #premier.
Zimny prysznic dla entuzjastów #AI. Nauka ostrzega: #LLM-y nigdy nie będą „myśleć”, bo język to nie inteligencja | iMagazine
https://imagazine.pl/2025/12/01/zimny-prysznic-dla-entuzjastow-ai-nauka-ostrzega-llm-y-nigdy-nie-beda-myslec-bo-jezyk-to-nie-inteligencja/
PS: Ale prędzej czy później powstanie algorytm który będzie naprawdę myśleć. To tylko kwestia czasu i mocy obliczeniowej. Oraz genialnego w swej prostocie pomysłu 😁
https://imagazine.pl/2025/12/01/zimny-prysznic-dla-entuzjastow-ai-nauka-ostrzega-llm-y-nigdy-nie-beda-myslec-bo-jezyk-to-nie-inteligencja/
LLM-y doskonale radzą sobie z naśladowaniem przeciętnej ludzkiej kreatywności (np. pisaniem korporacyjnych maili), ale nie są w stanie wejść na poziom ekspercki czy nowatorski. Dlaczego? Bo to, co nowatorskie, jest z definicji mało prawdopodobne statystycznie. Jeśli model spróbuje być zbyt „kreatywny”, zaczyna halucynować i generować bełkot. Jeśli trzyma się statystyki – generuje przeciętność.
PS: Ale prędzej czy później powstanie algorytm który będzie naprawdę myśleć. To tylko kwestia czasu i mocy obliczeniowej. Oraz genialnego w swej prostocie pomysłu 😁
imagazine.pl
Zimny prysznic dla entuzjastów AI. Nauka ostrzega: LLM-y nigdy nie będą „myśleć”, bo język to nie inteligencja | iMagazine
Dyrektorzy tacy jak Sam Altman czy Mark Zuckerberg wydają miliardy dolarów na farmy serwerów, obiecując nam, że lada moment stworzą AGI.
Forwarded from 👌🏼Ciekawostki & pomysły & fantazje🚀 (Tomasz Starszy od Arpanetu)
"Nie szukajmy tajemnicy tam, gdzie jej nie ma. To, że niektórzy dziennikarze mainstreamowi czy ludzie związani z tą technologią w różny sposób chcą nią zaintrygować, odwołują się do tego pojęcia tajemniczości, czy niezrozumiałości działania tych systemów - no to bądźmy poważni."
Wyjaśnienie działania tzw. "sztucznej inteligencji" na przykładzie modelu językowego, prezentowane przez kompetentnego eksperta, a nie celebrytę/influencera czy popularyzatora. Z eksponowanym w mediach mitem bezkompromisowo rozprawia się dr hab. Jerzy Andrzej Surma, profesor Szkoły Głównej Handlowej w Instytucie Informatyki i Gospodarki Cyfrowej, specjalizujący się w inteligentnych systemach wspomagania decyzji oraz zastosowaniach i bezpieczeństwie sztucznej inteligencji.
link do materiału: https://t.me/PomyslyCiekawostkiFantazje/9029
#AI #llm
♨️https://www.facebook.com/share/p/1BtG3s2kuf/
Wyjaśnienie działania tzw. "sztucznej inteligencji" na przykładzie modelu językowego, prezentowane przez kompetentnego eksperta, a nie celebrytę/influencera czy popularyzatora. Z eksponowanym w mediach mitem bezkompromisowo rozprawia się dr hab. Jerzy Andrzej Surma, profesor Szkoły Głównej Handlowej w Instytucie Informatyki i Gospodarki Cyfrowej, specjalizujący się w inteligentnych systemach wspomagania decyzji oraz zastosowaniach i bezpieczeństwie sztucznej inteligencji.
link do materiału: https://t.me/PomyslyCiekawostkiFantazje/9029
#AI #llm
♨️https://www.facebook.com/share/p/1BtG3s2kuf/
Każda praca na celowniku AI. Prezes Google uważa, że rola CEO „jedną z łatwiejszych rzeczy” do zastąpienia przez sztuczną inteligencję 😅*
♨️
https://share.google/MgRZxcVl4Eb1BZdBo
* W przypadku większości prezesów dobrym zastępnikiem była by zwykła funkcja losowa 😁
♨️
https://share.google/MgRZxcVl4Eb1BZdBo
Sztuczna inteligencja już teraz wpływa na niektóre zawody. Branża artystyczna przekształca się powoli w sektor zajmujący się korektą prac #AI, ale to nie koniec zmian. Według szefa Google powinniśmy szykować się na rewolucję, ponieważ narzędzia sztucznej inteligencji wpłyną na każdy zawód i ludzie powinni dostosowywać się do nowych realiów i zmian społecznych.
* W przypadku większości prezesów dobrym zastępnikiem była by zwykła funkcja losowa 😁
GRY-Online.pl
Każda praca na celowniku AI. Prezes Google uważa, że rola CEO „jedną z łatwiejszych rzeczy” do zastąpienia przez sztuczną inteligencję…
Szef Google uważa, że sztuczna inteligencja wpłynie na wszystkie zawody i każdy będzie musiał się dostosować. Jego zdaniem nie można unikać tematu nadchodzących zmian.
Forwarded from Wolna Fantastyka (Tomasz Starszy od Arpanetu)
Uważaj o co prosisz 🫤
Forwarded from Naukowy Telegram
Naukowy Telegram
Photo
👨🔬 Edgar F. Codd: Architekt Relacyjnych Baz Danych
Edgar Frank Codd (1923–2003) był brytyjskim informatykiem, który pracował w firmie IBM. Jest on powszechnie uznawany za "ojca" relacyjnego modelu danych, który zrewolucjonizował sposób przechowywania i zarządzania informacjami, stanowiąc fundament dla niemal wszystkich nowoczesnych systemów baz danych, w tym najpopularniejszych obecnie systemów RDBMS (Relational Database Management System).
Jego przełomowa praca „A Relational Model of Data for Large Shared Data Banks” została opublikowana w 1970 roku. Do tego czasu dominowały mniej elastyczne i trudniejsze w zarządzaniu modele hierarchiczne i sieciowe.
📜 12 Postulatów Codda: Definicja Relacyjności
Kluczowym wkładem Codda, który stanowił punkt odniesienia dla wszystkich twórców baz danych, jest zestaw zasad, pierwotnie sformułowany w 1985 roku jako 12 Postulatów (Zasad) Codda. Miały one za zadanie precyzyjnie zdefiniować, co sprawia, że system zarządzania bazą danych jest naprawdę relacyjny, a nie tylko udaje taki.
W praktyce Codd sformułował 13 reguł, numerowanych od 0 do 12, aby podkreślić fundamentalną wagę reguły zerowej. Choć żaden komercyjny RDBMS nie spełnia ich wszystkich w pełni, stanowią one teoretyczny wzór dla projektowania baz danych.
Oto najważniejsze zasady:
1. Reguła 0: Reguła Fundamentu (Foundation Rule)
System musi zarządzać bazami danych wyłącznie za pomocą swoich relacyjnych zdolności. Oznacza to, że nie można polegać na niskopoziomowych, nierealacyjnych funkcjach do obejścia systemu.
2. Reguła 1: Reguła Informacji (The Information Rule)
Cała informacja w bazie danych musi być reprezentowana w jednym i tylko jednym sposobie: jako wartości atrybutów w tabelach (relacjach).
3. Reguła 2: Reguła Zagwarantowanego Dostępu (The Guaranteed Access Rule)
Każda wartość w bazie danych musi być teoretycznie dostępna przez podanie nazwy tabeli, wartości klucza głównego (identyfikującego wiersz/krotkę) i nazwy kolumny (atrybutu). Eliminuje to potrzebę polegania na fizycznej lokalizacji danych.
4. Reguła 3: Systematyczne Traktowanie Wartości NULL (Systematic Treatment of Null Values)
System musi obsługiwać specjalną wartość NULL w sposób spójny i systematyczny, aby reprezentować brakujące, nieznane lub nieadekwatne informacje, w sposób odmienny od wszystkich innych wartości.
5. Reguła 5: Reguła Kompleksowego Języka Danych (The Comprehensive Data Sublanguage Rule)
System musi dostarczać przynajmniej jeden język, który:
* Ma wyraźną składnię i może być używany zarówno interaktywnie, jak i w programach aplikacyjnych.
* Obsługuje definiowanie danych, manipulowanie nimi, bezpieczeństwo, integralność i zarządzanie transakcjami.
Tym językiem stał się powszechnie używany SQL (Structured Query Language), który powstał w IBM w oparciu o idee Codda i służy jako standardowy interfejs do RDBMS.
🌐 Wpływ i Dziedzictwo
Praca Codda była ogromnym krokiem naprzód, odsuwając bazy danych od skomplikowanych, powiązanych struktur na rzecz prostszej, matematycznie spójnej teorii zbiorów. Relacyjny model danych umożliwił:
* Niezależność Danych: Zmiany w fizycznej organizacji danych nie wpływają na programy aplikacyjne (Reguła 8).
* Integralność Danych: Utrzymywanie spójności dzięki kluczom głównym (Primary Key) i kluczom obcym (Foreign Key).
* Łatwiejsze Kwerendy: Stosowanie języka deklaratywnego (SQL), w którym użytkownik mówi co chce, a nie jak to uzyskać.
W 1981 roku Edgar F. Codd otrzymał Nagrodę Turinga, najwyższe wyróżnienie w informatyce, za fundamentalny wkład w teorię i praktykę systemów zarządzania bazami danych.
Edgar Frank Codd (1923–2003) był brytyjskim informatykiem, który pracował w firmie IBM. Jest on powszechnie uznawany za "ojca" relacyjnego modelu danych, który zrewolucjonizował sposób przechowywania i zarządzania informacjami, stanowiąc fundament dla niemal wszystkich nowoczesnych systemów baz danych, w tym najpopularniejszych obecnie systemów RDBMS (Relational Database Management System).
Jego przełomowa praca „A Relational Model of Data for Large Shared Data Banks” została opublikowana w 1970 roku. Do tego czasu dominowały mniej elastyczne i trudniejsze w zarządzaniu modele hierarchiczne i sieciowe.
📜 12 Postulatów Codda: Definicja Relacyjności
Kluczowym wkładem Codda, który stanowił punkt odniesienia dla wszystkich twórców baz danych, jest zestaw zasad, pierwotnie sformułowany w 1985 roku jako 12 Postulatów (Zasad) Codda. Miały one za zadanie precyzyjnie zdefiniować, co sprawia, że system zarządzania bazą danych jest naprawdę relacyjny, a nie tylko udaje taki.
W praktyce Codd sformułował 13 reguł, numerowanych od 0 do 12, aby podkreślić fundamentalną wagę reguły zerowej. Choć żaden komercyjny RDBMS nie spełnia ich wszystkich w pełni, stanowią one teoretyczny wzór dla projektowania baz danych.
Oto najważniejsze zasady:
1. Reguła 0: Reguła Fundamentu (Foundation Rule)
System musi zarządzać bazami danych wyłącznie za pomocą swoich relacyjnych zdolności. Oznacza to, że nie można polegać na niskopoziomowych, nierealacyjnych funkcjach do obejścia systemu.
2. Reguła 1: Reguła Informacji (The Information Rule)
Cała informacja w bazie danych musi być reprezentowana w jednym i tylko jednym sposobie: jako wartości atrybutów w tabelach (relacjach).
3. Reguła 2: Reguła Zagwarantowanego Dostępu (The Guaranteed Access Rule)
Każda wartość w bazie danych musi być teoretycznie dostępna przez podanie nazwy tabeli, wartości klucza głównego (identyfikującego wiersz/krotkę) i nazwy kolumny (atrybutu). Eliminuje to potrzebę polegania na fizycznej lokalizacji danych.
4. Reguła 3: Systematyczne Traktowanie Wartości NULL (Systematic Treatment of Null Values)
System musi obsługiwać specjalną wartość NULL w sposób spójny i systematyczny, aby reprezentować brakujące, nieznane lub nieadekwatne informacje, w sposób odmienny od wszystkich innych wartości.
5. Reguła 5: Reguła Kompleksowego Języka Danych (The Comprehensive Data Sublanguage Rule)
System musi dostarczać przynajmniej jeden język, który:
* Ma wyraźną składnię i może być używany zarówno interaktywnie, jak i w programach aplikacyjnych.
* Obsługuje definiowanie danych, manipulowanie nimi, bezpieczeństwo, integralność i zarządzanie transakcjami.
Tym językiem stał się powszechnie używany SQL (Structured Query Language), który powstał w IBM w oparciu o idee Codda i służy jako standardowy interfejs do RDBMS.
🌐 Wpływ i Dziedzictwo
Praca Codda była ogromnym krokiem naprzód, odsuwając bazy danych od skomplikowanych, powiązanych struktur na rzecz prostszej, matematycznie spójnej teorii zbiorów. Relacyjny model danych umożliwił:
* Niezależność Danych: Zmiany w fizycznej organizacji danych nie wpływają na programy aplikacyjne (Reguła 8).
* Integralność Danych: Utrzymywanie spójności dzięki kluczom głównym (Primary Key) i kluczom obcym (Foreign Key).
* Łatwiejsze Kwerendy: Stosowanie języka deklaratywnego (SQL), w którym użytkownik mówi co chce, a nie jak to uzyskać.
W 1981 roku Edgar F. Codd otrzymał Nagrodę Turinga, najwyższe wyróżnienie w informatyce, za fundamentalny wkład w teorię i praktykę systemów zarządzania bazami danych.
Forwarded from Naukowy Telegram
Naukowy Telegram
👨🔬 Edgar F. Codd: Architekt Relacyjnych Baz Danych Edgar Frank Codd (1923–2003) był brytyjskim informatykiem, który pracował w firmie IBM. Jest on powszechnie uznawany za "ojca" relacyjnego modelu danych, który zrewolucjonizował sposób przechowywania i zarządzania…
# 🔗 Jak działa JOIN w SQL? Proste wyjaśnienie dla każdego!
Jeśli kiedykolwiek pracowałeś z bazami danych, prawdopodobnie trafiłeś na tajemnicze słówko JOIN. Dla początkujących brzmi ono trochę jak zaklęcie, a dla ekspertów — jest jednym z najważniejszych narzędzi do pracy z danymi. JOIN-y pozwalają łączyć informacje z wielu tabel, tak jakbyś składał puzzle w jeden obrazek. 🧩
W tym artykule wytłumaczę Ci, co to jest JOIN i jakie są jego rodzaje — prosto, jasno i bez matematycznego bólu głowy. 😉
---
## 🏗 Dlaczego potrzebujemy JOIN?
Wyobraź sobie, że masz dwie listy:
* listę pracowników
* listę działów w firmie
Dane te są rozdzielone nie bez powodu — to poprawia porządek i oszczędza miejsce. Tylko że… czasem potrzebujesz informacji z obu naraz. Na przykład:
„W jakim dziale pracuje Anna?”
To właśnie moment, w którym SQL mówi:
➡️ *Spoko, zrobię JOIN i połączę za Ciebie te dane.*
---
# 🔍 Rodzaje JOIN i ich działanie
## ⭐️ 1. INNER JOIN — znajdź to, co pasuje 🎯
INNER JOIN pobiera tylko te rekordy, które mają dopasowanie w obu tabelach.
To trochę jak notes z kontaktami: jeśli masz numer telefonu i nazwisko — super. Jeśli brakuje jednego lub drugiego, tracisz dopasowanie.
### Przykład:
Łączymy pracowników z ich działami:
Wynik?
Tylko pracownicy, którzy faktycznie są przypisani do jakiegoś działu.
---
## ⭐️ 2. LEFT JOIN — pokaż wszystko z lewej tabeli 🟩➡️
LEFT JOIN zwraca wszystkie rekordy z tabeli po lewej stronie, nawet jeśli nie znajdzie dopasowania w prawej.
To tak, jakbyś powiedział:
➡️ „Pokaż mi wszystkich pracowników, a przy okazji — jeśli wiadomo — ich dział.”
Jeśli działu brak, pojawi się NULL.
Super przydatne, gdy chcesz znaleźć „brakujące dane”.
---
## ⭐️ 3. RIGHT JOIN — przeciwieństwo LEFT JOIN 🟥⬅️
RIGHT JOIN działa jak LEFT JOIN, tylko w drugą stronę.
Czyli:
➡️ „Pokaż mi wszystkie działy, nawet jeśli nie mają pracowników.”
Wiele popularnych baz danych (np. SQLite) go nie obsługuje, ale warto wiedzieć, że istnieje.
---
## ⭐️ 4. FULL OUTER JOIN — pokaż wszystko ze wszystkimi 🌐
Najbardziej „otwarty” JOIN.
FULL JOIN łączy wszystko z obu tabel, niezależnie od tego, czy pasuje, czy nie.
Efekt?
* pasujące dane są połączone
* brak dopasowania → pojawia się NULL po którejś stronie
To taka pełna panorama danych. 📸
(Uwaga: SQLite go nie obsługuje.)
---
## ⭐️ 5. CROSS JOIN — każdy z każdym 🔥
To JOIN dla odważnych.
CROSS JOIN tworzy kombinację wszystkich rekordów z obu tabel.
Jeśli masz 5 pracowników i 5 działów, CROSS JOIN zrobi z tego… 25 wyników. 😅
Przykład:
Świetne do generowania kombinacji, ale używaj ostrożnie!
---
## ⭐️ 6. SELF JOIN — tabela łączona sama ze sobą 🪞
Brzmi dziwnie? A jednak.
SELF JOIN to sposób na porównanie rekordów między sobą, np.:
* pracownik → jego manager
* produkt → jego podobny produkt
* wierzchołki grafu → połączenia między nimi
Przykład:
Jak lustro odbijające dane. 🪞
---
# 📌 Podsumowanie — który JOIN wybrać?
| JOIN | Co zwraca? |
| -------------- | ---------------------------------------- |
| INNER JOIN | tylko dopasowane rekordy |
| LEFT JOIN | wszystkie z lewej + dopasowania z prawej |
| RIGHT JOIN | wszystkie z prawej + dopasowania z lewej |
| FULL JOIN | wszystko ze wszystkimi |
| CROSS JOIN | kombinacje każdy z każdym |
| SELF JOIN | tabela łączona sama ze sobą |
JOIN to jedno z najpotężniejszych narzędzi SQL — i fundament pracy z danymi.
Gdy go zrozumiesz, świat relacyjnych baz danych staje się znacznie prostszy i bardziej logiczny. 🧠💡
Jeśli kiedykolwiek pracowałeś z bazami danych, prawdopodobnie trafiłeś na tajemnicze słówko JOIN. Dla początkujących brzmi ono trochę jak zaklęcie, a dla ekspertów — jest jednym z najważniejszych narzędzi do pracy z danymi. JOIN-y pozwalają łączyć informacje z wielu tabel, tak jakbyś składał puzzle w jeden obrazek. 🧩
W tym artykule wytłumaczę Ci, co to jest JOIN i jakie są jego rodzaje — prosto, jasno i bez matematycznego bólu głowy. 😉
---
## 🏗 Dlaczego potrzebujemy JOIN?
Wyobraź sobie, że masz dwie listy:
* listę pracowników
* listę działów w firmie
Dane te są rozdzielone nie bez powodu — to poprawia porządek i oszczędza miejsce. Tylko że… czasem potrzebujesz informacji z obu naraz. Na przykład:
„W jakim dziale pracuje Anna?”
To właśnie moment, w którym SQL mówi:
➡️ *Spoko, zrobię JOIN i połączę za Ciebie te dane.*
---
# 🔍 Rodzaje JOIN i ich działanie
## ⭐️ 1. INNER JOIN — znajdź to, co pasuje 🎯
INNER JOIN pobiera tylko te rekordy, które mają dopasowanie w obu tabelach.
To trochę jak notes z kontaktami: jeśli masz numer telefonu i nazwisko — super. Jeśli brakuje jednego lub drugiego, tracisz dopasowanie.
### Przykład:
Łączymy pracowników z ich działami:
SELECT e.name, d.dept_name
FROM employees e
INNER JOIN departments d
ON e.department_id = d.id;
Wynik?
Tylko pracownicy, którzy faktycznie są przypisani do jakiegoś działu.
---
## ⭐️ 2. LEFT JOIN — pokaż wszystko z lewej tabeli 🟩➡️
LEFT JOIN zwraca wszystkie rekordy z tabeli po lewej stronie, nawet jeśli nie znajdzie dopasowania w prawej.
To tak, jakbyś powiedział:
➡️ „Pokaż mi wszystkich pracowników, a przy okazji — jeśli wiadomo — ich dział.”
Jeśli działu brak, pojawi się NULL.
SELECT e.name, d.dept_name
FROM employees e
LEFT JOIN departments d
ON e.department_id = d.id;
Super przydatne, gdy chcesz znaleźć „brakujące dane”.
---
## ⭐️ 3. RIGHT JOIN — przeciwieństwo LEFT JOIN 🟥⬅️
RIGHT JOIN działa jak LEFT JOIN, tylko w drugą stronę.
Czyli:
➡️ „Pokaż mi wszystkie działy, nawet jeśli nie mają pracowników.”
Wiele popularnych baz danych (np. SQLite) go nie obsługuje, ale warto wiedzieć, że istnieje.
---
## ⭐️ 4. FULL OUTER JOIN — pokaż wszystko ze wszystkimi 🌐
Najbardziej „otwarty” JOIN.
FULL JOIN łączy wszystko z obu tabel, niezależnie od tego, czy pasuje, czy nie.
Efekt?
* pasujące dane są połączone
* brak dopasowania → pojawia się NULL po którejś stronie
To taka pełna panorama danych. 📸
(Uwaga: SQLite go nie obsługuje.)
---
## ⭐️ 5. CROSS JOIN — każdy z każdym 🔥
To JOIN dla odważnych.
CROSS JOIN tworzy kombinację wszystkich rekordów z obu tabel.
Jeśli masz 5 pracowników i 5 działów, CROSS JOIN zrobi z tego… 25 wyników. 😅
Przykład:
SELECT e.name, d.dept_name
FROM employees e
CROSS JOIN departments d;
Świetne do generowania kombinacji, ale używaj ostrożnie!
---
## ⭐️ 6. SELF JOIN — tabela łączona sama ze sobą 🪞
Brzmi dziwnie? A jednak.
SELF JOIN to sposób na porównanie rekordów między sobą, np.:
* pracownik → jego manager
* produkt → jego podobny produkt
* wierzchołki grafu → połączenia między nimi
Przykład:
SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m
ON e.manager_id = m.id;
Jak lustro odbijające dane. 🪞
---
# 📌 Podsumowanie — który JOIN wybrać?
| JOIN | Co zwraca? |
| -------------- | ---------------------------------------- |
| INNER JOIN | tylko dopasowane rekordy |
| LEFT JOIN | wszystkie z lewej + dopasowania z prawej |
| RIGHT JOIN | wszystkie z prawej + dopasowania z lewej |
| FULL JOIN | wszystko ze wszystkimi |
| CROSS JOIN | kombinacje każdy z każdym |
| SELF JOIN | tabela łączona sama ze sobą |
JOIN to jedno z najpotężniejszych narzędzi SQL — i fundament pracy z danymi.
Gdy go zrozumiesz, świat relacyjnych baz danych staje się znacznie prostszy i bardziej logiczny. 🧠💡
Forwarded from Programmer Humor
Forwarded from Programmer Humor
#Dania zajmuje historyczne stanowisko w erze cyfrowej, proponując #prawo wzorowane na prawach autorskich, które przyznaje każdemu obywatelowi pełną #własność jego twarzy, głosu i ciała. Proponowane przepisy uczyniłyby nielegalnym wykorzystywanie wizerunku danej osoby przez systemy #AI, firmy lub osoby prywatne — poprzez #deepfake’i, klonowane głosy lub cyfrowe awatary — bez wyraźnej zgody. Działanie to bezpośrednio wymierzone jest w rosnące nadużycia treści generowanych przez sztuczną inteligencję w kampaniach dezinformacyjnych, oszustwach i kradzieży tożsamości.
Definiując #tożsamość osobistą jako własność intelektualną, Dania dąży do zapewnienia ludziom takich samych praw do ich obecności cyfrowej, jakie przysługują dziełom twórczym, takim jak #muzyka czy #sztuka. Eksperci podkreślają, że może to ustanowić globalny #precedens dla praw człowieka w erze sztucznej inteligencji, inspirując podobne rozwiązania w całej Europie i poza nią.
⬇️ https://t.me/ProgramowanieLinux/2008
#AIRegulation
Definiując #tożsamość osobistą jako własność intelektualną, Dania dąży do zapewnienia ludziom takich samych praw do ich obecności cyfrowej, jakie przysługują dziełom twórczym, takim jak #muzyka czy #sztuka. Eksperci podkreślają, że może to ustanowić globalny #precedens dla praw człowieka w erze sztucznej inteligencji, inspirując podobne rozwiązania w całej Europie i poza nią.
⬇️ https://t.me/ProgramowanieLinux/2008
#AIRegulation
LINUX &&|| PROGRAMMING
#Dania zajmuje historyczne stanowisko w erze cyfrowej, proponując #prawo wzorowane na prawach autorskich, które przyznaje każdemu obywatelowi pełną #własność jego twarzy, głosu i ciała. Proponowane przepisy uczyniłyby nielegalnym wykorzystywanie wizerunku…
Przekaz jest jasny: wraz z postępem technologii #godność ludzka i autentyczność muszą pozostać chronione.
🔙 https://t.me/ProgramowanieLinux/2007
#Denmark #AIEthics #DigitalRights #Deepfake #AIRegulation
🔙 https://t.me/ProgramowanieLinux/2007
#Denmark #AIEthics #DigitalRights #Deepfake #AIRegulation
Forwarded from Programmer Humor
[Meme] microsoftDemandsOneMillionLinesOfCodeMonthlyFromEachEngineer
https://redd.it/1ptiq2i
by @programmer_humor
https://redd.it/1ptiq2i
by @programmer_humor
Forwarded from Programmer Humor
LINUX &&|| PROGRAMMING
Każda praca na celowniku AI. Prezes Google uważa, że rola CEO „jedną z łatwiejszych rzeczy” do zastąpienia przez sztuczną inteligencję 😅* ♨️ https://share.google/MgRZxcVl4Eb1BZdBo Sztuczna inteligencja już teraz wpływa na niektóre zawody. Branża artystyczna…
🚨 Nowy Jork wymaga umieszczania ostrzeżeń na mediach społecznościowych skierowanych do nastolatków, traktując wciągającą konstrukcję platform jako produkt podobny do tytoniu i dopuszczając sankcje za brak zgodności z tym wymogiem.
🔗 https://link.ie.social/wRcsaf
#cenzura #równowagaCyfrowa
🔗 https://link.ie.social/wRcsaf
#cenzura #równowagaCyfrowa
Interesting Engineering
New York mandates warning labels for addictive social media feeds
New York joins a growing global push to regulate social media design features blamed for excessive use among children and teens.
👏1
#GitHub zablokował chińskiego giganta chipów. Ukradli kod projektu #FFmpeg
https://ithardware.pl/aktualnosci/github_rockchip_electronics-47623.html
https://ithardware.pl/aktualnosci/github_rockchip_electronics-47623.html
Według autorów FFmpeg Rockchip wykorzystywał fragmenty ich kodu źródłowego z naruszeniem warunków licencyjnych, mimo wcześniejszego przyznania się do błędu.
ITHardware
GitHub zablokował chińskiego giganta chipów. Ukradli kod projektu FFmpeg
GitHub zablokował publiczne repozytorium chińskiego producenta układów scalonych Rockchip Electronics po skardze złożonej przez twórców projektu FFmpeg.