Planeta OpenAlt

Sledujte Mozilla.cz na sociálních sítích!

Pokud vás zajímají novinky ze světa Firefoxu, Thunderbirdu a dalších produktů Mozilly, můžete nás sledovat nejen zde na webu, ale i na sociálních sítích. Právě tam jsme nejaktivnější – sdílíme často aktualizace, zajímavosti a důležité informace o vývoji okolo projektu Mozilla.

Na sociálních sítích můžete nejen sledovat naše příspěvky, ale také se zapojit do diskuzí, komentovat novinky nebo se nás zeptat na cokoliv, co vás zajímá. Rádi si s vámi vyměníme názory a odpovíme na vaše dotazy.

Najdete nás na následujících sítích:

Přidejte se k nám a buďte součástí komunity Mozilla!

Predaj nenávisti

14.
února
Fero Volár
Predaj nenávisti

Na siedmej priečke najpredávanejších kníh cez cenový porovnávač Heureka.sk je Mein Kampf od Adolfa Hitlera.

Predaj nenávisti

Má hodnotenie 78% a niekoľko komentárov, ktoré nepriamo a v inotajoch oceňujú túto knihu.

V dobe, keď sa globálne spoločnosti veľmi nedarí bojovať proti nenávisti, dezinformáciám a extrémizmu, je to nepríjemný fakt, ktorý opäť raz vyvoláva závažné etické otázky nielen o zodpovednosti konkrétnej platformy, v tomto prípade Heureka.sk, ale aj o širších dôsledkoch slobodného šírenia nebezpečnej ideológie.

Akékoľvek e-shopy alebo platformy by si mali byť vedomé svojej etickej úlohy v spoločnosti. Nie sú iba pasívnymi sprostredkovateľmi obchodu – zohrávajú aktívnu úlohu pri formovaní verejného diskurzu tým, čo umožňujú propagovať a predávať. V prípade knihy ako Mein Kampf, ktorá je základným textom nacistickej ideológie, je ich nečinnosť de facto schvaľovaním šírenia toxických myšlienok.

Platformy by preto mali zaviesť prísnejšie pravidlá pre obsah, ktorý propagujú, a minimalizovať jeho dostupnosť, ak nie úplne vylúčiť jeho predaj. Toto nie je cenzúra, kniha by mala byť dostupná ale v tomto prípade aj s kontextom. Ten ako komentár nie je dostačujúci, ako komentáre na Heureke ukazujú.

Prítomnosť tejto knihy medzi najpredávanejšími titulmi je nielen šokujúca, ale aj alarmujúca. Znamená to, že existuje dopyt po jej obsahu, čo by malo byť vážnym varovným signálom. Ak spoločnosť začne považovať takéto diela za bežný tovar, dochádza k normalizácii nebezpečných ideológií. Naša história nás už naučila, aké tragické dôsledky môže mať slepá akceptácia nenávistných myšlienok.

Ešte znepokojivejšie je, že kniha získava pozitívne hodnotenia. Zároveň výborne zrkadlí množstvo nenávisti, ktoré v spoločnosti je. A bohužiaľ to podčiarkuje absenciu historickej pamäte, ale aj stále viac rastúci vplyv extrémistických myšlienok v spoločnosti. Máme morálnu zodpovednosť uvedomiť si, že nie každá kniha je len “názorom”, ale že niektoré myšlienky sú priamo spojené s genocídou, utrpením a nesmiernym zlom.

Tento týždeň som písal, že v Európe Ľudia nechcú jazdiť v swasticars od hajlujúceho Muska. Než som však dopísal tento článok, tak kniha Mein Kampf sa posunul o priečku vyššie na TOP 6.

Predaj nenávisti

Popiš památku je v polovině. Přes 250 nových článků a jedeme dál!

13.
února
Wikimedia ČR

Osmý ročník soutěže Popiš památku běží již od poloviny měsíce ledna. Cílem je psát nové články o kulturních památkách v České republice ale i v zahraničí.

Letos píšeme také Portugalsko

Letošní ročník soutěže Popiš památku má nicméně svoji novinku. Tou je speciální portugalská kategorie, která byla spuštěna za podpory Oddělení portugalistiky Filozofické fakulty Univerzity Karlovy Ústavu románských studií. Píšeme proto hesla o památkách v Portugalsku – mnohdy jde o dědictví zámořských objevů. Nových článků vzniklo již přes 250: můžeme si tak již přečíst o katedrále Nejsvětějšího srdce Ježíšova v Coimbře, kostelu svatého Rocha v Lisabonu, hradu Marvão a o mnohých dalších. 

Zajímají vás portugalské památky? Chcete si o nich zkusit něco napsat? Jejich seznamy můžete na portugalské Wikipedii nalézt zde: https://pt.wikipedia.org/wiki/Categoria:Listas_de_patrim%C3%B3nio_de_Portugal_por_distrito

A jak se daří u nás?

Pokud se vrátíme do českých luhů a hájů, zjistíme, že byly sepsány například články o chybějících městských opevněních (tj. hradbách, ale i navazujících fortifikačních systémech) v řadě měst. Nově tak potkáte na Wikipedii článek o městském opevnění v Jevíčku nebo v Náchodě. Vznikají ale hesla i o lázeňských budovách, divadlech nebo významných vilách. Zkrátka je toho hodně.

Nám jako organizátorům chodí k soutěži zpětná vazba od řady členů. Letos jsme použili nástroj Hashtag pro portugalskou kategorii. Také evidujeme postřehy od správců, ale i dalších editorů Wikipedie. Ti by mnohdy uvítali, abychom se podívali na „zoubek“ i řadě stávajících článků. Stává se totiž, že získá krásný článek na Wikipedii dosud chybějící památka, ale známá stavba, kolem které chodíme denně, má pouze krátký a nedostatečný článek. Příkladem budiž most Legií u Národního divadla v Praze, který do soutěže nespadá (článek máme skoro dvacet let), ale pořád je to vlastně pahýl. Co myslíte, stálo by za to zařadit i památky, které už na Wikipedii jsou? A pokud ano, které? Napište mi na email: jan.louzek@wikimedia.cz

Co třeba psát o hvězdách, kopretinách nebo drůbeži? Zkuste naše minigranty!

Soutěž je na české Wikipedii již stálicí. Její podpora probíhá prostřednictvím tzv. Komunitních minigrantů. To je nástroj, jehož prostřednictvím může každý wikipedista nebo wikipedistka zorganizovat svoji soutěž, editaton, workshop nebo jinou akci rozvíjející největší českou encyklopedii. A soutěž Popiš památku? Pokud jste byli pozorní, mohli jste o ní uslyšet i v Českém rozhlase! Naše poselství zaznělo 22. ledna na Dvojce mezi 14:30 až 15:00! 

Akce, kterou spolek Wikimedia Česká republika pořádá v partnerství s časopisem PROPAMÁTKY, trvá až do 28. února. Zapojit se může každý. Oceníme totiž nejen wikipedisty a wikipedistky s nejvíce články, ale některé ceny budeme i losovat. Největší odměnou přitom zůstává fakt, že budou vaše články přínosem pro čtenáře Wikipedie!

Ľudia nechcú jazdiť v swasticars

12.
února
Fero Volár
Ľudia nechcú jazdiť v swasticars

Viete, že to T v loge automobilky Tesla znamená Trump? A že Musk neznáša, že sa jeho autám vraví swasticars? Schválne hľadajte. Majitelia sa od nich začínajú dištancovať a hákové kríže ako nálepky či odkaz sprejom sa na nich nachádzajú čoraz častejšie.

A nie je sa čomu čudovať. Elon Musk neukazoval ako veľkú chce opäť spraviť Ameriku ale si zahajloval. To muselo mať nejakú odozvu, lebo na tomto svete sú stále aj príčetní ľudia.

Tesla zaznamenala prudký pokles predaja svojich elektromobilov na kľúčových európskych trhoch, pričom jedným z možných dôvodov je práve odpor spotrebiteľov voči politickým aktivitám Elona Muska.

V januári 2024 Tesla zaregistrovala v Nemecku len 1 277 nových vozidiel, čo predstavuje medziročný pokles o 59,5 %. Tento pokles je obzvlášť výrazný vzhľadom na fakt, že Nemecko je domovom jedinej európskej továrne Tesly. Kým trh s elektromobilmi v Nemecku vzrástol v januári o 50 %, podiel Tesly sa prepadol zo 14 % na 4 %. Podobný trend bol zaznamenaný aj vo Francúzsku (-63 %), Nórsku (-38 %) a Spojenom kráľovstve (-8 %).

Politická angažovanosť Muska v Európe pre podporou neonacistickej strany Alternatíva pre Nemecko (AfD) pred nadchádzajúcimi voľbami vyvolala kontroverzie a ostrú kritiku zo strany politických lídrov.

Môže za tým byť samozrejme aj niečo iné ako čakanie zákazníkov na modernizovaný Tesla Model Y (2025).

U.S. Immigration and Customs Enforcement&aposs (ICE) vraj dostáva denne desiatky telefonátov s informáciou, že je potrebné jeho vyhostenie späť do Juhoafrickej Republiky ako imigranta.

Silné stránky osobnosti a spolupráce v týmech

Filip Goszler– RAYNET
11. 2. 2025 – úterý

V IT týmech se často setkávají výrazné osobnosti, což může spolupráci komplikovat. Gallupův test silných stránek pomáhá odhalit jedinečné talenty jednotlivců. Jeho výsledky lze využít ke zvýšení osobní produktivity, efektivnější spolupráci v týmu i k posílení mezilidských vztahů.

GNOME nemá české překladatele

Posledních minimálně 15 let byly překlady GNOME do češtiny ve výborném stavu. U každého vydání jsem jen hlásil, že je vše přeložené, poslední roky to platilo i pro drtivou většinu dokumentace. Poslední rok se to ale začalo zadrhávat. Přispěvatelé, kteří to dlouhé roky táhli, odešli a není nikdo, kdo by to po nich převzal. Proto jsme se rozhodli jít s pravdou ven: GNOME momentálně nemá české překladatele a pokud se toho neujme někdo nový, překlady začnou postupně upadat.

Ako to skončilo s Biooo.cz?

11.
února
Fero Volár
Ako to skončilo s Biooo.cz?

Počas predvianočnej návštevy Prahy, keď sme išli okolo Václavského náměstí sme sa zastavili v prevádzke Biooo.cz o ktorej problémoch som písal počas augusta. Čakali nás prázdne regály z ktorých bolo cítiť, že táto značka má to najlepšie naozaj za sebou. Otvorenosť prevádzky totiž bola absolútne zbytočná.

Aktuálne informácie priniesli novinky.cz z ktorých vyplýva, že firma Biooo.cz podala v polovici januára návrh na insolvenciu a konkurz. Výška dlhov dosahuje približne 1,5 milióna českých korún. Krátko pred týmto krokom došlo k zmene názvu spoločnosti na Nature Home Plus s.r.o. a k výmene konateľa. Novou konateľkou sa stala 62-ročná Monika Vacíková, ktorá má podľa verejne dostupných informácií dve dlhodobé exekúcie. Právnici preto predpokladajú, že ide o tzv. “bieleho koňa”, teda osobu formálne zastupujúcu spoločnosť bez reálneho vplyvu na jej riadenie.

E-shop Biooo.cz je síce stále funkčný, avšak nákup v žiadnom prípade neodporúčam. Podobne sú na tom aj dodávatelia, ktorí čakajú na svoje vyplatenie, nový tovar nedodávajú a web napriek tomu informuje o počte dní za ktoré vie tovar dodať.

Som veľmi zvedavý, či niekedy zistíme, čo a ako sa v spoločnosti udialo a ako z lovebrandu dá padnúť na dno.

Freelens ako slobodná alternatíva k Mirantis Lens pre Kubernetes

10.
února
Fero Volár
Freelens ako slobodná alternatíva k Mirantis Lens pre Kubernetes

Lens patrí medzi najlepšie a najobľúbenšie IDE pre Kubernetes. Pôvodným tvorcom bol fínsky startup Kontena, ale väčšinu kódu vlastnil a vytvoril Lakend Labs.

V roku 2010 odkupuje Lens od Kontena Mirantis. Zbytok stratupu nakoniec skončí u Suptask, čo je ticketovací systém pre Slack.

Ale späť k Lens o ktorom som prvý raz tu písal už veľa rokov späť. Mirantis ponechal kód pod MIT licenciou a je voľne dostupný. Binárne zostavenia od Mirantis sú dostupné na webe k8slens.dev, avšak už sú to isté obmedzenia. Pre ich používanie musíte mat aktívny účet od Mirantis, ten je bezplatný avšak bez prihlásenia vám aplikácia nebude fungovať.

Freelens ako slobodná alternatíva k Mirantis Lens pre Kubernetes

Naviac spoločnosti s obratom viac ako $10 miliónov ročne musia prejsť na Pro alebo Enterprise verziu, čo je 25 resp 50 dolárov mesačne za užívateľa.

Riešením tak môže byť nový projekt, ktorý s objavil minulý rok s názvom Freelens. Ten zostavuje balíčky a inštalátory pre macOS (aj Homebrew), Windows a Linuxové distribúcie.

Projekt a zostavenia nájdete aj na GitHube.

Tyto fotky ovládly Czech Wiki Photo 2024 – podívejte se na vítěze!

07.
února
Wikimedia ČR
Foto: Tomáš Krulich z kapely Kabát.jpg, autor: Littleomig, CC BY-SA 4.0, prostřednictvím Wikimedia Commons.

V pátek 31 ledna 2025 byly v rámci Večera svobodné kultury v Didaktikonu Kampusu Hybernská vyhlášeny výsledky hlavní fotografické soutěže Czech Wiki Photo 2024.

Czech Wiki Photo: Kdo a jak soutěží?

Czech Wiki Photo je hlavní fotografická soutěž na české Wikipedii. Jejím cílem je ocenit autory nejlepších snímků, které byly pořízeny na území Česka a nahrány pod svobodnou licencí na Wikimedia Commons za uplynulých 365 dní, a rozšířit tak databázi fotografií, která slouží nejčastěji k ilustraci článků na Wikipedii.

Tradičně se soutěží ve třech kategoriích: Příroda, Vytvořeno člověkem a Společnost, kultura a události. V každé ze soutěžních kategorií porota, složená z fotografky Edity Bízové, fotografa a novináře Jana Rybáře a aktivního wikipedisty Pavla Hrdličky, vybrala nejlepší fotografii. Porota ocenila i nejlepšího nováčka, tedy fotografa, který se do soutěže zapojil poprvé.

Absolutní vítěz – kategorie příroda

Po dvouleté přestávce byla jako nejlepší fotografie soutěže vybrána fotografie z kategorie Příroda. V této kategorii letos dominovaly fotografie s ornitologickou tematikou. Fotografii dudka chocholatého (upupa epops) přilétajícího do hnízda v kmenu stromu od Luckyho86 vybrala porota jako absolutního vítěze.

Foto: Upupa epops (057A2126).jpg, autor: Luckhy86, CC BY-SA 4.0, prostřednictvím Wikimedia Commons.

Vytvořeno člověkem

Má křídla jako pták, ale pták to není (jasný pane). Je to přeci Airshow Břeclav, vítězná fotografie v kategorii Vytvořeno člověkem. Jejím autorem je Pavel Kříž, který se, mimo jiné, zaměřuje na focení historických rekonstrukcí.

Foto: Airshow Břeclav, autor: Pavel21kriz, CC BY-SA 4.0, prostřednictvím Wikimedia Commons.

Společnost, kultura a události

I v této kategorii zůstala porota hlavou v oblacích. Tedy nejenom porota, ale také Airshow Pilot, který byl vybrán jako nejlepší fotografie v kategorií Společnost, kultura a události. Jejím autorem je Pavel Kříž.

Foto: Airshow Pilot, autor: Pavel21kriz, CC BY-SA 4.0, prostřednictvím Wikimedia Commons.

Pozvánka na výstavu

Na vernisáži byly vedle vítězných fotografií také představeny nejlepší fotografie loňského ročníku napříč fotografickými soutěžemi. Nemohli jste se dostavit na vyhlášení 31. ledna? Nezoufejte, fotografie jsou k vidění v prostorách Kampusu Hybernská až do 28.února 2025.

Všem výhercům gratulujeme! Ostatním děkujeme za účast a rozšíření svobodné databáze fotografií. Těšíme se zase za rok.

Ukázka vystavovaných fotografií

Únorové RoboDoupě bude 22.2.

06.
února
RoboDoupě

Únorové RoboDoupě bude 22.2. proto sledujte web a fórum, kde se dozvíte podrobnosti.

Místo konání: MFF UK, kampus Troja, pavilon N („Impakt“), 2. patro, Laboratoř robotiky.Adresa: V Holešovičkách 2, Praha 8 (zastávka MHD Kuchyňka; auto lze zaparkovat podle mapy tady)1.

Program:

10:00 – 10:15   Slovo úvodem… 10:15 – 11:00   Úvod do REST [...]

🚨 Falešné SMS z linky 158: Jak útočníci podvádějí uživatele pomocí spoofingu a phishingu 🚨

Kyberzločinci opět udeřili! Tentokrát využívají SMS spoofing, tedy podvržení telefonního čísla, aby se vydávali za policii (linka 158). Cílem je přimět oběť ke kliknutí na podvodný odkaz a získat její bankovní údaje. 🔍 Jak útok probíhá? 🕵️‍♂️ Technická analýza podvodného …

Příspěvek 🚨 Falešné SMS z linky 158: Jak útočníci podvádějí uživatele pomocí spoofingu a phishingu 🚨 pochází z Spajk

Jak získat a nastavit Canva for Education přes Google licencování aplikací

31.
ledna
Pavel Hodál
Jak získat a nastavit Canva for Education přes Google licencování aplikací
Jak získat a nastavit Canva for Education přes Google licencování aplikací
Pavel Hodál 31. 1. 2025
Chcete, aby vaši učitelé a studenti měli přístup k Canva for Education? Díky propojení s Google Workspace to zvládnete za 5 minut. Včetně získání nové licence, pokud ji ještě nemáte.

Tento návod vám pomůže rychle projít celým procesem – od registrace až po nastavení přístupu pro učitele a žáky.

New PostgreSQL instance configuration

You’ve spent weeks, maybe a few months, developing a prototype locally with a local PostgreSQL in docker, not worrying about a thing. But now the moment has come, and you must push to prod. You start an RDS instance, execute the migrations to set up the schema, and launch the app. It’s all good so far!

However, the team has grown from a single lonely wolf, and now you have new colleagues and maybe a few junior devs. It turns out that if everybody uses the same username and password, it’s very hard to find out who left that 5-hour query running that caused the instance to crawl so badly that a full outage would probably be better. So you give everyone their own user, and for some time, everything works great! Except on one late Friday night during a routine deployment, the migrations have failed! What do you mean by “cannot drop X because other objects depend on it”???

Disclaimer: This article does not aim to extensively describe all the best practices, just to set you on the right path and save you from a few ruined Fridays.

Roles and ownership basics

The strategy that has worked for me in the past is to set up a few roles that will serve as the bedrock of our permissions. Instead of giving individual users specific permissions, you’ll always give them one of the roles.

Another important rule will be that a single admin role will own all of our database objects; nobody else will own anything. Technically, PostgreSQL doesn’t distinguish between users and roles (a user is just a role that can log in), so here, I mean a logical role that is not somebody’s user.

To start, let’s say we’ll have the following roles, where the fp_ is the initials of your company to be able to tell where the role came from:

  • fp_role_ro - a read-only role - useful for tools like Metabase or a tech-savvy Product Manager
  • fp_role_app - a role for the common needs of the application, such as modifying data, calling functions, etc. All of that except changing schema. By applying the Principle of least privilege, you’ll realize that usually, most apps don’t need to be able to change their schema under normal operations, so by removing that privilege, you’re making a potential attack on your system a bit harder.
  • fp_role_admin - an admin role that can do anything with our database and is the sole owner of all database objects

In PostgreSQL, unless you specify otherwise (and it’s annoying to think of it every time), the user creating the object will be its owner. Sometimes, it’s perfectly reasonable (even though it shouldn’t be the rule) to execute some schema changes manually, but when you do that, you fragment the ownership, making further changes harder.

This can be solved by having your users always execute SET ROLE fp_role_admin; when they open a new session, which is annoying and easy to forget. Luckily, PostgreSQL enables you to configure this to happen automatically when a user opens a new session.

ALTER ROLE fp_prochazka_filip SET role TO fp_role_admin;

Now, every time I connect to the database, I’ll be switched to the fp_role_admin role, and any objects I create will be owned by it. I can still switch to any other role I have access to, but I would have to do that knowingly, and if you’re the admin, there is little reason to do so.

This switch only affects permissions and ownership. Your users will still be nicely visible in the open sessions and running queries list.

Before we jump into defining our roles, there are a few more topics we need to look into.

The PUBLIC role

Let’s see what the PostgreSQL documentation has to say about it:

The keyword PUBLIC indicates that the privileges are to be granted to all roles, including those that might be created later. PUBLIC can be thought of as an implicitly defined group that always includes all roles. Any particular role will have the sum of privileges granted directly to it, privileges granted to any role it is presently a member of, and privileges granted to PUBLIC.

This role has, by default, some permissions that might allow the read-only users to do things we don’t want them to do, so we will also have to do a reset of the PUBLIC role’s permissions.

Settings inheritance basics

In PostgreSQL, most settings can be overridden in your current session. This means that most settings serve only as defaults. There are multiple levels of settings defaults:

  • System
  • Database
  • Role
  • Role+Database (see notes here, highest precedence)

When a new session starts (something connects to a database), these settings are applied as if you’ve executed SET parameter TO value. This is very useful because you can enforce sane defaults for people and systems that make sense for your application without having to rely on the same people and systems to always apply those defaults at the start of the session.

CREATEROLE vs SUPERUSER

With version 16, the CREATEROLE permission got nerfed. Before, a role with this permission could grant itself to another user, but not anymore. To grant a role, you must either have the ADMIN OPTION for the role or you must be a SUPERUSER.

You will likely use the AWS RDS or some other managed service. Some of the managed services give you full power, and some of them limit you. AWS RDS is in the group that restricts you a bit - there are things it will not allow you to do. So, to get the most permissions possible, our admin role has to inherit from the rds_superuser role. If you inspect a newly created RDS instance, you might also notice that the rds_superuser role does not actually have the SUPERUSER permission - it only inherits a bunch of the system roles.

Let’s look at a few different behaviors on localhost:

CREATE ROLE fp_role_admin WITH CREATEROLE INHERIT;
SET ROLE fp_role_admin;
CREATE ROLE second_user INHERIT IN ROLE fp_role_admin ENCRYPTED PASSWORD 'secret';
-- [42501] ERROR: permission denied to grant role "fp_role_admin"
-- Detail: Only roles with the ADMIN option on role "fp_role_admin" may grant this role.

This is consistent with what we would expect after the change in PostgreSQL 16, let’s try adding SUPERUSER into the mix:

CREATE ROLE rds_superuser WITH CREATEROLE SUPERUSER INHERIT;
CREATE ROLE fp_role_admin INHERIT IN ROLE rds_superuser;
SET ROLE fp_role_admin;
CREATE ROLE second_user INHERIT IN ROLE fp_role_admin ENCRYPTED PASSWORD 'secret';
-- [42501] ERROR: permission denied to create role
-- Detail: Only roles with the CREATEROLE attribute may create roles.

I don’t know about you, but this one surprised me - neither the CREATEROLE nor the SUPERUSER is inherited. The only way a role can grant itself to another role is if the role itself is directly SUPERUSER:

CREATE ROLE fp_role_admin WITH SUPERUSER INHERIT;
SET ROLE fp_role_admin;
CREATE ROLE second_user INHERIT IN ROLE fp_role_admin ENCRYPTED PASSWORD 'secret';
-- works

Now let’s look at the RDS example:

CREATE ROLE fp_role_admin WITH CREATEROLE INHERIT;
SET ROLE fp_role_admin;
CREATE ROLE second_user INHERIT IN ROLE fp_role_admin ENCRYPTED PASSWORD 'secret';
-- [42501] ERROR: permission denied to grant role "fp_role_admin"
-- Detail: Only roles with the ADMIN option on role "fp_role_admin_2" may grant this role.

This fails consistently with localhost. Let’s try a SUPERUSER role:

CREATE ROLE fp_role_admin WITH SUPERUSER INHERIT;
-- [42501] ERROR: permission denied to create role
-- Detail: Only roles with the SUPERUSER attribute may create roles with the SUPERUSER attribute.

As expected based on the RDS documentation. And what happens if we create a user that inherits rds_superuser?

CREATE ROLE fp_role_admin INHERIT IN ROLE rds_superuser;
SET ROLE fp_role_admin;
CREATE ROLE second_user INHERIT IN ROLE fp_role_admin ENCRYPTED PASSWORD 'secret';
-- works

What? So SUPERUSER is not inherited, but if you inherit rds_superuser, suddenly it counts as if you’re SUPERUSER yourself? This smells like some RDS customization, but whatever. Let’s apply the knowledge.

The init script for a new database instance

Now that we have the basics covered, we can put together the following block of SQL, which can be used as a template for when you want nicely and consistently defined permissions on your local database and production AWS RDS:

-- After a new PgSQL RDS instance is created,
-- there is only a single initial user with the LOGIN privilege,
-- and it belongs to the role 'rds_superuser'.

-- First, we ensure the rds_superuser role exists, to be consistent on localhost
DO $body$
BEGIN
    CREATE ROLE rds_superuser WITH INHERIT;
    GRANT pg_monitor,
          pg_read_all_data,
          pg_write_all_data,
          pg_signal_backend,
          pg_checkpoint,
          pg_maintain,
          pg_use_reserved_connections,
          pg_create_subscription TO rds_superuser WITH ADMIN OPTION, INHERIT TRUE;
EXCEPTION
    -- On RDS, the CREATE ROLE will fail with one of the following reasons:
    WHEN SQLSTATE '42501' THEN
        RAISE NOTICE '%, skipping', SQLERRM USING ERRCODE = SQLSTATE;
    WHEN duplicate_object THEN
        RAISE NOTICE '%, skipping', SQLERRM USING ERRCODE = SQLSTATE;
END
$body$;

-- Create an admin role.
-- The admin users will inherit the necessary privileges from this role.
-- This role is meant to own all database objects used in production!
CREATE ROLE fp_role_admin CREATEDB CREATEROLE INHERIT IN ROLE rds_superuser;

-- Make the role a superuser on localhost for consistent behavior with AWS RDS
DO $body$
BEGIN
    ALTER ROLE fp_role_admin WITH SUPERUSER;
EXCEPTION
    -- On RDS, this ALTER will fail with 'Only roles with the SUPERUSER attribute may change the SUPERUSER attribute'
    WHEN SQLSTATE '42501' THEN
        RAISE NOTICE '%, skipping', SQLERRM USING ERRCODE = SQLSTATE;
END
$body$;

-- Allow the initial user to switch to the new role:
GRANT fp_role_admin TO SESSION_USER WITH ADMIN OPTION, INHERIT TRUE;

-- Defaults that are applied when the initial user logins,
-- to ensure nobody will accidentally create objects owned by a different user.
ALTER ROLE SESSION_USER SET role TO fp_role_admin;

-- We will recreate the public schema later, using the correct role
DROP SCHEMA public CASCADE;

-- Database-specific reset
DO $body$
DECLARE
    fp_db_name TEXT := current_database();
BEGIN
    -- The public privileges (all users) are too permissive, we must reset it
    EXECUTE 'REVOKE ALL PRIVILEGES ON DATABASE ' || quote_ident(fp_db_name) || ' FROM PUBLIC';
    EXECUTE 'GRANT CONNECT, TEMPORARY ON DATABASE ' || quote_ident(fp_db_name) || ' TO PUBLIC';

    -- Transfer the ownership of all objects (which should be only the database itself) to the new role:
    EXECUTE 'ALTER DATABASE ' || quote_ident(fp_db_name) || ' OWNER TO fp_role_admin';
END
$body$;

-- This role is going to create tables, so it must also own the default privileges.
SET ROLE fp_role_admin;

-- Recreate the public schema, now under the correct owner
CREATE SCHEMA public;

-- Define role for read-only access
CREATE ROLE fp_role_ro;
GRANT USAGE ON SCHEMA public TO fp_role_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT SELECT ON TABLES TO fp_role_ro;

-- Define role for application's access
CREATE ROLE fp_role_app INHERIT IN ROLE fp_role_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT INSERT, UPDATE, DELETE, TRUNCATE ON TABLES TO fp_role_app;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT USAGE, SELECT ON SEQUENCES TO fp_role_app;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
    GRANT EXECUTE ON FUNCTIONS TO fp_role_app;

On RDS, any user we grant our admin role to will not have the SUPERUSER permission, but they’ll be as close as possible - they’ll be able to manage databases, roles, and permissions freely. And they’ll be able to read as much system info as RDS allows.

On localhost, the users granted our admin role will have the SUPERUSER permission, resulting in slightly more permissions, but counterintuitively also a better consistency with RDS.

If you want to see what user is connected and what role it’s currently “impersonating”, you can run the following select:

SELECT SESSION_USER, CURRENT_USER;

Managing users

Once you execute that big SQL, your next step should be to define the users:

  • One user for yourself, so in my case, it would be e.g. fp_prochazka_filip
  • One admin user for database migrations so that your deployment process is able to change the schema
  • One app user for the normal application runtime

Creating users is trivial now:

-- Create app user
CREATE USER name_of_app_user INHERIT IN ROLE fp_role_app ENCRYPTED PASSWORD 'please-use-password-manager-and-generate-something-random';

-- Create read-only user
CREATE USER name_of_ro_user INHERIT IN ROLE fp_role_ro ENCRYPTED PASSWORD 'please-use-password-manager-and-generate-something-random';

-- Create admin user
CREATE USER name_of_admin_user INHERIT IN ROLE fp_role_admin ENCRYPTED PASSWORD 'please-use-password-manager-and-generate-something-random';
ALTER ROLE name_of_admin_user SET role TO fp_role_admin;

If you ever need to remove a user, it’s also simple:

DROP ROLE some_user;

So with the requirements that we know so far, we would probably create the following users:

CREATE USER fp_a_developer INHERIT IN ROLE fp_role_admin ENCRYPTED PASSWORD 'secret';
ALTER ROLE fp_a_developer SET role TO fp_role_admin;

CREATE USER fp_metabase INHERIT IN ROLE fp_role_ro ENCRYPTED PASSWORD 'secret';

CREATE USER fp_app_runtime INHERIT IN ROLE fp_role_app ENCRYPTED PASSWORD 'secret';

CREATE USER fp_app_migrations INHERIT IN ROLE fp_role_admin ENCRYPTED PASSWORD 'secret';
ALTER ROLE fp_app_migrations SET role TO fp_role_admin;

Timeouts basics

Before we dive into configuring the timeouts, let’s first take a look at what the official documentation, has to say about timeouts:

  • statement_timeout - Abort any statement that takes more than the specified amount of time. … A value of zero (the default) disables the timeout.
  • transaction_timeout (since 17.0) - Terminate any session that spans longer than the specified amount of time in a transaction. … A value of zero (the default) disables the timeout.

So by default, you can shoot off a query and let it run for eternity. Usually, you won’t notice this during development or early phases of the project because you don’t have a lot of data. Only after your database grows can it lead to nasty problems if you don’t have your queries finishing quickly.

To test things, we can quickly spin up an instance of the latest PostgreSQL using docker compose up -d experiments with the following config:

services:
  experiments:
    image: postgres:17.2-alpine
    environment:
      - POSTGRES_DB=experiments
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=secret
    ports:
      - "127.0.0.1:5432:5432"

And then you can play around with the various settings levels, for example:

-- database level timeout
ALTER DATABASE "experiments" SET statement_timeout='10min';
-- user-level timeout
ALTER ROLE "fp_a_developer" SET statement_timeout='5min';

Then, you can log in as one of the users we’ve defined before and see how it affects the timeout you get in a new session. You could try running a slow query and watching it get killed after the timeout, but it’s probably faster to run SHOW statement_timeout; to get the final value.

And, of course, there are valid use cases for long-running statements and transactions. So, if you run into them, you can adjust the timeouts on the session level. Once the session ends, the next session will have the configured default.

-- session level timeout
SET statement_timeout='1h';

I’ll give you some spoilers that you can find out by experimenting:

  • The precedence is intuitive: system < database < role < role+database < session
  • The settings you configure for roles (that other users inherit) are ignored; only settings for the session_user (the user you use for the login) affect the session. I know, bummer.

Configuring timeouts

Given the information we now know, how should we configure the timeouts? I’d start by collecting more requirements, and I’ll give you an example:

  • The app is a web-based application with some background processing
  • Most “transactions” come from the HTTP request, and the load balancer or proxy in front of the application is configured to timeout requests after 5min.
  • Our application web server has 1min timeout configured for HTTP requests, but the ideal response time is 1ms.
  • Our background processes may run longer queries.
  • We don’t want our developers to accidentally run a query that eats too many resources. Quick queries are fine. Running slow queries is not ideal, but we won’t try to prevent it if it’s intentional.
  • We want to be able to connect to the database from Metabase to allow the creation of dashboards on the live database. This is risky, but it saves a lot of time by not having to create fully-featured dashboards in our admin interface.

Given the 1min requirement for HTTP requests, we should be strict with the database defaults.

ALTER DATABASE "experiments" SET statement_timeout='15s';

Next is the migration user. As you probably know, migrations can take very long - not ideal, but they warrant a big safety buffer:

ALTER ROLE fp_app_migrations SET statement_timeout='1d';

We don’t want Metabase draining our resources, but we can tolerate reasonably slow queries.

ALTER ROLE fp_metabase SET statement_timeout='5min';

Next, we should consider creating more “app runtime” users to separate the HTTP traffic from the cron jobs and message consumers that might run longer. Not only can you then centrally configure more granular timeouts, but you’ll also get better visibility in the running queries overview.

If you’re using stuff like Spring Boot and its @Scheduled jobs within the web server, you’ll share one database connection pool between the HTTP requests and background jobs. This is a perfectly reasonable way to start because it simplifies the rest of the infrastructure but makes separating users hard. If your background jobs are fast, then you’re good with just one user, and the occasional slow job can increase the statement timeout for its transaction with the SET command we’ve seen previously.

But let’s say for the sake of the example, we want them also separated, so instead of having just one fp_app_runtime, we’ll split it into three users:

-- the role fp_app_runtime_http takes the 15sec default from database level, so we won't be setting the defaults
ALTER ROLE fp_app_runtime_cron SET statement_timeout='5min';
ALTER ROLE fp_app_runtime_consumers SET statement_timeout='5min';

With all this done, let’s look at what SHOW statement_timeout for each user returns:

  • fp_a_developer - has the database default of 15s
  • fp_metabase - has its own default of 5min
  • fp_app_migrations - has its own default of 1d
  • fp_app_runtime_http - has the database default of 15s
  • fp_app_runtime_cron - has its own default of 5min
  • fp_app_runtime_consumers - has its own default of 5min

Looks good! But remember, your app might have different requirements, so if you arrive at different timeouts, it’s probably not wrong either.

Conclusion

We’ve defined the roles we’ll need, cleaned up the default permissions, and configured some sane timeouts to prevent disasters. By defining granular users, we’ve also gained relatively good visibility into who’s running what.

What next? If the project warrants it, you might want to think about more granular admin permissions - separating user management from schema changes. Later down the line, you might realize you need even better user management and auditing of who is doing what - at that point, looking into Teleport or a similar tool makes sense. But that’s all out of the scope of this already lengthy article :)

Have you also run into object ownership shenanigans or issues related to infinite default timeouts yourself? How did you solve it?

Chytré hodinky pohledem linuxáka

30.
ledna
Jozef Mlich
Na srazu OpenAltu jsem měl přenášku na téma: Chytré hodinky pohledem linuxáka. Proč chtít chytré hodinky, co se s nimi dá dělat bez ztráty soukromí. Různé střípky z vývoje doprovodné aplikace a komu darovat starší zařízení (třeba s vybitou baterkou). Na vhsky.cz je záznam: https://vhsky.cz/w/24Gnj89Pn8smTN7AikeFgD?start=1h7s

#36 – Kdy se z Česka stane tahoun na poli videoher?

„Neměli bychom si vybírat hry, které budeme vyvíjet, na základě nostalgie hráče, protože to je z principu neaktuální. Taky je to hodně subjektivní a může na tom člověk ztroskotat, protože k tomu má vztah a hůř se mu přijímá kritika od hráčů, hůř se mu zapracovávají změny a nepřistupuje k tomu jako designér ale jako nostalgický vývojář. A to může být jeden z kamenů úrazu, proč hra není úspěšná. Pokud se do toho pustí, tak to nejde vzít zpátky, jsou to roky.“
 
 Pro plno lidí jsou videohry kratochvílí pro děti, ve skutečnosti je ale herní průmysl výdělečnější než filmový a hudební dohromady. Denně vychází stovky nových titulů a hry od velkých studií atakují cenovku 2000 korun. I v Česku máme celosvětově úspěšné hry, přesto by se daly spočítat na prstech obou rukou. Jak se u nás daří herním vývojářům? Je náročné vytvořit hru od A do Z? A kde se to můžeme naučit? Do studia o tom přišla povyprávět Natálie Sodomková, která má za sebou studium v Ateliéru herních médií na FaVU VUT a zároveň vede brněnský herní inkubátor Gamebaze, který podporuje začínají malé a střední vývojářské týmy. Mluví třeba o tom, proč je vývoj her řemeslo, jak se jim podařilo dostat středoškolskou hru k youtuberovi s 37 miliony sledujících, ale také o tom, jaké má česká videoherní scéna problémy a kdy je lepší hru zahodit a začít znovu.

Hledání šéfa

Hledání šéfá není náborový příspěvek, ale táborová hra, mně rovněž známá pod názvem Hledání pokladu. Bratr Zet, Miloš Zapletal, celoživotní sběratel her, kterému vděčíme za mnohé, nedávno oslavil 95. narozeniny. Což mi připomnělo, že si má člověk budovat vlastní sbírku. Tam kde on skončil, kniha Retrohraní začíná. Jim nehodlám konkurovat, ale o své poznámky bych se s vámi rád podělil. Ani nevím, kde se hra vzala, abych mohl někomu připsat zásluhy. Já se s ní seznámil na táboře Pikomat.

Úvod

Hra není běhací, i když pro zrychlení běhat můžete, každopádně se u ní dost nachodí. Vyzkoušená doba trvání je odpoledne (od poledního klidu až po večeři). V případně potřeby lze zkrátit vzdálenosti, ubrat stanoviště či úkoly, nebo naopak vzdálenosti prodloužit a přidat na obtížnosti úloh. Lze hrát na louce, v lese či polních cestách a vlastně klidně i ve městě.

Jak název napovídá, cílem je najít šéfa/poklad. Legendu si vymyslete vlastní.

Cesta k cíli není snadná, na každém kroku je potřeba splnit nějaký úkol. Příprava vyžaduje vymyslet úkoly, nakreslit slepou mapu pro každé družstvo a zajistit stanoviště, kde každý vedoucí musí mít vlastní kartu. Ohledně úkolů se představivosti meze nekladou. Hledáte-li přesto nějaká nápady, tak můžou zpívat píseň, vázat uzel, zahrát scénku, poznávat přírodniny…

Poklad může být umístěn na speciálním místě, třeba na lodičce uprostřed rybníka.

Průběh hry

  1. Družstvo přijde na stanoviště
  2. Vybere si cestu (A, B, C, D) a splní patřičný úkol.
  3. Vedoucí na stanovišti jim do mapy zakreslí cestu. Může popsat, kde se stanoviště nachází.
  4. Pokud chcete za zamezit podvodům, na druhou stranu může zapsat kam jdou.
  5. Družstvo se časem dovtípí, kam se musí dostat, aby získali poklad.

Karta stanoviště

Takhle může například vypadat karta stanoviště číslo 1.

Možnost Úkol Cíl
A Každý uvažte lodní uzel. 2
B Najděte na louce 5 rostlin, které poznáte jménem. 5
C Přenoste vodu v kelímku z potoka do kýble. 2
D Zazpívejte mi všichni dohromady píseň. 3


Další karty stanoviště si vytvořte s vlastními úkoly. Cesty, kam mají jít, naleznete v přehledové mapě níže.

Slepá mapa pro děti

Děti dostanou průvodku, slepou mapu.

Přehledová mapa pro tvůrce hry

Na přehledové mapě vidíte, že stanoviště 1 a 5 jsou startovní, to aby všechna družstva nestartovala z jednoho místa. Poklad je číslo 7. To je sice neveřejná ale zřejmá informace. U každého stanoviště jsou šipkou označené možné postupy, které jsou pro přehlednost vyjmenované i v tabulce níže. Cesty samozřejmě nemusí projít všechny, podstatné je najít poklad.

Stanoviště číslo 6 je speciální, od něj vede jediná cesta k pokladu. Vedoucí má obrovskou pravomoc změnit cíl na kartě, může tak hru prodloužit nebo zkrátit. Pakliže hrajete příliš krátkou dobu, tak i kdyby si družstvo vybrala cestu k pokladu, můžete je poslat jinam. Případně blíží-li se večeře a družstvo si vybralo cestu, která je vrací na start, můžete je popohnat. Vedoucí si ale musí si zaznamenat co na co změnil, aby se nestalo, že jiné družstva jdou jinou cestou, respektive hlavně, aby fungovaly ty cesty, které už prošli a zanesli do svých poznámek.

Pro přehlednost uvádím možnosti postupu.

Start Cíle
1 5, 2, 2, 3
2 5, 3, 1, 5
3 5, 1, 4, 2
4 5, 3, 6, 1
5 2, 3, 1, 2
6 1, 4, 7, 2


Závěr

Hra je léty ověřená. Vyžaduje určitou nenulovou přípravu. Na druhou stranu neklade nároky na prostředí. Obtížnější je odhadnout časovou náročnost, ale zkušení vedoucí mají možnosti, jak hru v průběhu ovlivnit. Děti dokáže unavit, i když nutně nemusí běhat.

BitBeam Model Cup 2025

28.
ledna
RoboDoupě

Zúčastněte se prvního ročníku BitBeam Model Cup 2025! Vytvořte digitální model v LeoCADu z max. 500 dílků a soutěžte v kategoriích studentské týmy a jednotlivci. Odevzdání do 31. března 2025. Více informací a pravidla najdete na BitBeam.cc.

[...]

Komunitní wikikonference představila možnosti rozvoje české wiki-komunity i zapojení AI

28.
ledna
Wikimedia ČR

Již po třinácté proběhla letos na podzim wikikonference, největší setkání wikipedistů a wikimediánů v České republice. Letošní program byl zaměřen na rozvoj komunity, představení nových nástrojů, přípravu nových projektů, ale také na úvahy o zapojení umělé inteligence, která by podle některých hlasů mohla ohrozit celý globální projekt Wikipedie, podle jiných být jeho užitečnou součástí.

By Richard Sekerak (WMCZ) – Own work, CC BY-SA 4.0, via Wikimedia Commons

V sobotu 9. listopadu 2024 se téměř 50 členů české wiki-komunity setkalo v prostorách Didaktikonu v kampusu Hybernská, v místě kde probíhají vybrané akce spolku Wikimedia ČR ve spolupráci s partnerskou Univerzitou Karlovou v Praze. I tentokrát se setkali zkušení wikipedisté a wikipedistky s nováčky. Součástí programu byly také workshopy pro začínající wikipedisty a wikipedistky, učitele a učitelky.

Ohlédnutí do minulosti

Wikikonference s přívlastkem “komunitní” proběhla podruhé, navázala však na dvanáctiletou tradici předchozích wikikonferencí (podívejte se na záznamy přednášek), kterou přerušila pandemie Covidu-19 v roce 2020. V programu konferencí se v průběhu času představovali lidé s nejrůznějšími příspěvky a tématy. Někteří z nich – např. Jan Spousta nebo Okino – se po mnoha letech objevili i na té letošní.

Autor: Richard Sekerak (WMCZ) – Vlastní dílo, CC BY-SA 4.0, via Wikimedia Commons

Pomyslný vrchol sezóny české komunity Wikipedie proběhl za velkého zájmu všech přítomných. Nabitý program, který vznikal více než půl roku, probíhal paralelně ve třech sálech. Plodné diskuze bylo bohužel mnohdy potřeba dokonce omezovat, aby se dostalo na všechny řečníky. Dle ohlasů publika, představili nejzajímavější prezentace opět zkušení wikipedisté jako Marek Blahuš – Blahma (který vystoupil rovnou čtyřikrát), Aktron, Okino nebo Jan Spousta.

Wikipedie a její budoucnost (s AI)?

Příspěvek Jana Spousty Jak mohou velké jazykové modely přispět Wikipedii byl jedním z plánované série příspěvků, které měly reflektovat využití generativní umělé inteligence a vliv na Wikipedii. Obzvláště důležité bylo představení pozitivního přínosu, které jazykové modely mohou mít. Patří tam například vítání nováčků, návrhy popisů fotek nebo návrhy nových položek ve wikidatech.

Omluvili se bohužel dva klíčoví řečníci, Josef Šlerka a Jaroslav Mašek, kteří měli rovněž promluvit v souvislosti s AI a chatboty. Oba se měli věnovat velkým jazykovým modelům ve vztahu k Wikipedii, resp. využití umělé inteligence při tvorbě obsahu Wikipedie a ve vzdělávání obecně. Jejich příspěvky a téma Wikipedie a AI shrnul ve svém souhrnném příspěvku hlavní lektor Wikipedie ČR Pavel Bednařík. Přednáška byla také doplněna konkrétními příklady využití chatbotů při editování z pohledu Jana Spousty jako aktivního uživatele. Velký zájem o toto téma inicioval mimo jiné uspořádání webináře, na kterém by promptování chatbotů bylo ukázáno na konkrétní příkladech, což nebylo vzhledem k časovým možnostem na konferenci možné.

Co nového v české wikikomunitě?

Autor: Richard Sekerak (WMCZ) – Vlastní dílo, CC BY-SA 4.0, via Wikimedia Commons

Kromě programu zaměřeného na konkrétní projekty a nástroje byl s velkým zájmem představen také nový projekt české Wikipedie, konkrétně české Wikicesty. Ty se dostaly v loňském roce z prostředí inkubátoru do hlavního prostoru projektů Wikimedia a jsou tedy řádným projektem české wikimediánské komunity. Hlavní zásluhu na tom mají brněnští wikipedisté Blahma a LiMr, ale také všichni ostatní, kteří se do přispívání na tomto výjimečném nekomerčním cestovatelském průvodci podílejí.

V rámci programu byly představeny jednotlivé wikikluby a wikisrazy, které probíhají v řadě českých a moravských měst a obcí (aktuální přehled je na stránce Pod reálnou lípou). Představili je jejich organizátoři na panelové diskuzi, která měla za cíl výměnu zkušeností mezi jednotlivými aktéry a také inspiraci pro další pokračování těchto komunitních akcí. Výjimečným okamžikem bylo blahopřání zástupců spolku Markovi Blahušovi aka uživateli Blahma, který na konci minulého roku oslavil 20 narozeniny na Wikipedii. Jak sám při své děkovné řeči poznamenal, aktuálně je již větší část svého života wikipedistou, než ne-wikipedistou.

Jak tedy aktuálně wikikluby a wikisrazy vypadají a fungují? Jak mohou pomoci ostatní členové komunity k jejich rozvoji a fungování? Co zásadně chybí jejich pořadatelům? V jakých městech mají tradici a pokračují, a kde je naopak jejich fungování je ohroženo? To vše jsme se dozvěděli od zástupců české komunity (Frettie, Jan Myšák, Blahma, Podroužek, Pavel Bednařík, V0lkanic, Anaj7, Czeva, nebo Roman Vyšanský). Pro pořadatele akcí bude během ledna 2025 na stránce pro organizátory zpřístupněn manuál, aby jejich pořádání bylo snadnější a efektivnější. Ten bude sloužit také těm, kteří by rádi založili nový wikiklub ve svém městě.

Závěrem

Co wikikonference přinesla jejím účastníkům? Především velké množství inspirace do další práce a informace o tom, co chystá spolek Wikimedia Česká republika v roce 2025 (tomu byly věnovány dva samostatné bloky). Vyplynulo z ní také to, čemu se wikipedisté věnují a chtějí věnovat v současnosti, co je zajímá, trápí a inspiruje. Důležitou roli hrála také podpora mezi jednotlivými členy komunity. Vzájemné povzbuzení k tomu, aby všichnieditovali s chutí a zájmem a aby byli schopni poprat se s úskalími a obtížemi, se kterými se zákonitě potýkají v průběhu editování, je jedním z největších smyslů podobných setkání.

Jaká bude budoucnost komunitní wikikonference? Odpověď není jednoznačná. Samotný přípravný programový výbor se scházel pravidelně a často, diskutoval podobu programu a oslovoval také další prezentující, kteří by se sami nepřihlásili. Jak ale zajistit, aby všechny příspěvky byly dostatečně kvalitní a aby je slyšelo co nejvíce lidí? Jak motivovat i ty méně aktivní wikipedisty a wikipedistky a wikimediany a wikimediánky k tomu, aby se konference aktivně zúčastnili? Jak dát vědět široké veřejnosti, která o Wikipedii příliš informací nemá, že může na takovou akci dorazit?

Jednou z odpovědí může být zapojení studentů Univerzity Karlovy, se kterou spolek podepsal v roce 2023 memorandum o spolupráci. Studenti a studentky FF UK se poprvé mohli zapojit do rozvoje Wikipedie formou odborné praxe. Studentka Lenka Holá dorazila na konferenci a zúčastnila se většiny programů včetně workshopu v základu editování Wikipedie. 

Na základě této pozitivní zkušenosti začala pracovat na překladech hesel o translatolozích a překladatelích a následně je úspěšně publikovala. Její zájem o editování Wikipedie může být inspirací pro další studenty, ale také pro lidi z řad široké veřejnosti, kteří by měli zájem obsah Wikipedie zkvalitňovat, a to nejen formou psaní hesel článků. Věříme a doufáme, že bude vytrvalý zájem jak o pronesení příspěvku na komunitní wikikonferenci v roce 2025, tak o organizační pomoc a podporu při přípravě této unikátní akce.

Odkazy

Záznamy a prezentace přednášek z předchozích ročníků

Jak zvýšit bezpečnost vašeho iPhonu

Pomocí automatického restartu 📴 Jedním z jednoduchých a efektivních způsobů, jak zvýšit bezpečnost vašeho iPhonu, je jeho pravidelný restart. Tento článek je inspirován Jakubem Onderkou, bezpečnostním analytikem z Národního úřadu pro kybernetickou a informační bezpečnost, pravidelný restart zařízení může zamezit útočníkům udržet …

Příspěvek Jak zvýšit bezpečnost vašeho iPhonu pochází z Spajk

Shrnutí roku 2024

26.
ledna
Josef Jebavý
Přestože jsem v roce 2024 cestoval méně než v předešlých letech, i tak rok 2024 pro mě byl velmi nabitý, místy až hektický. Ostatně stanovil jsem si vysoké cíle! A nyní nastal čase rok 2024 si shrnout, abych mohl zhodnotit jak jsem plnil plán a následně si mohl optimálně stanovit nové plány a cíle. Pojďme tedy rok 2024 shrnout.

Dárcovství v Česku raketově roste, ukazují data. Češi darují ročně miliardy

22.
ledna
Nadace OSF

Dárcovství v Česku dramaticky roste, jak dokládá nový výzkum realizovaný STEM pro Úřad vlády ČR s finanční podporou Technologické agentury ČR. Analýza dat z daňových přiznání platforem Darujme.cz a Donio.cz ukazuje, že za posledních deset let se objem darovaných prostředků téměř ztrojnásobil. Výzkum iniciovala pracovní skupina Rady vlády pro nestátní neziskové organizace, které je Nadace OSF součástí.

(více…)