Forwarded from 👌🏼Ciekawostki & pomysły & fantazje🚀 (Tomasz Starszy od Arpanetu)
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