Planeta OpenAlt

Ú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

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

Filip Goszler– RAYNET
11. 2. 2025 – úterý
17:30 - 19:00 – 18:00 espresso note
Máma mele kafe – Hrnčířská 3, Opava

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ů.

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…)

Vydán nový MX-Linux (23.5)

Byla vydána nová aktualizace MX Linuxu, tentokráte ve verzi 23.5. Verze jsou k dispozici dle prostředí následovně: –Xfce -KDE –Fluxbox Verzi lze získat z přímého repozitáře, zrcadla, torrentu nebo zakoupením předinstalovaného hardwaru. Download / Stažení Použijte přímý repozitář nebo jedno ze zrcadel pro následující produkty. Official release with no subsequent changes… Číst dále

Linux Mint 22.1 je vydán

Tým vývojářů vydal  Linux Mint 22.1 “Xia” Cinnamon, Mate a Xfce ve finální verzi. Stahovat můžete například ZDE. 64-bitový obraz ISO je doporučeno použít pro všechny moderní počítače (x64) – (téměř všechny počítače prodávané od roku 2007 jsou vybaveny 64-bitovými procesory). Verze je Long term support release (LTS), podporovaná do… Číst dále

10 najčítanejších článkov za rok 2024 na blogu alian.info

20.
ledna
Fero Volár

10. - Reštartujeme AWS meetupy v Bratislave

10 najčítanejších článkov za rok 2024 na blogu alian.info

S veľkou pokorou preberáme v Labyrinth Labs pomyselnú štafetu od Stell-ERP v organizovaní AWS User Group meetupov v Bratislave.

9. - „Zlá EÚ nám nechce dovoliť AI aplikácie“

OpenAI vylepšila hlasového asistenta (či asistentku), ktorá ešte nie je dostupná v krajinách Európskej únie. A zatiaľ v každom videu, článku alebo statuse som sa dočítal o zlej EÚ, ktorá nás ochudobňuje o výdobytky AI. No a že vďaka tomu Európa nemôže napredovať pred Čínou alebo Spojenými štatmi.

8. - V jej garáži začínal Google, YouTube spravila úspešným – zomrela Susan Wojcicki

Dennis Troper, manžel Susan Wojcicki informoval, že zomrela na rakovinu pľúc. Mala 56 rokov.

7. - Redis už nie je open-source

Od verzie 7.4 prechádza Redis na duálne licencovanie a to Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1), namiesto pôvodnej BSD licencie. Nie je teda už open-source, čo sa týka OSI definície.

6. - Nikdy sa nepoddať

Naša demokracia je relatívne mladá. Aj preto si vyžaduje toľko starostlivosti. S rôznymi priateľmi hovoríme, že sa častejšie stretávame na protestoch, než príjemnom rozhovore. Ale to je to najmenej, čo pre ňu môžeme robiť. Nemusíme pre ňu zomierať, ako naši susedia a bratia.

5. - Vlaky a ja

Sedím vo vlaku do Štrby, je slnečný letný deň. Začiatok júla. Posledné 2-3 roky pri voľných chvíľkach reflektujem svoje životné postoje, čo mám rád, ale aj zlozvyky. A toto je perfektné miesto, kde sa môžem pozrieť na vlaky.

4. - Zákaznícky portál ZSE – phishing, alebo enterprise Microsoft služba?

Posledný pár rokov ide celkom dobre phishing. Určite vaša banka, pošta, kuriér, alebo obchodný reťazec vás upozorňovali na prebiehajúce útoky. Email takmer na nerozoznanie od pravého, webový portál s celkom precízne ukradnutou grafikou.

3. - Meta si zaslúži potlesk

Tak čo, stihli ste vyplniť dotazníček, že si neprajete trénovanie AI od spoločnosti Meta na vašich dátach? Mal som ho otvorený, ale keď som si uvedomil na akých dátach Slovákov a Sloveniek by sa trénovalo, tak som si to rozmyslel.

2. - 25 rokov budovaný ecommerce biznis zničený za mesiac

Na českej ecommerce scéne sa toto leto odohráva zaujímavý príbeh. Informácií je zatiaľ minimum, ale v skratke takto.

1. - Elon Musk kupuje slovenský startup na výrobu elektrickej energie za 1 miliardu dolárov

Tomu poviem šok na slovenskej start-up scéne. Že sa objavý unicorn (firma s hodnotou nad 1 miliardu amerických dolárov) asi nečakal nikto.

Jak povolit AI Google Gemini pro žáky mladší 18 let v Google Workspace

16.
ledna
Pavel Hodál
Jak povolit AI Google Gemini pro žáky mladší 18 let v Google Workspace
Jak povolit AI Google Gemini pro žáky mladší 18 let v Google Workspace
Pavel Hodál 16. 1. 2025
Služba umělé inteligence Gemini, vytvořená společností Google, je nyní dostupná i žákům starším 13 let. Tato služba byla navržena, aby odpovídala specifickým potřebám mladších uživatelů a zároveň zajistila jejich bezpečné používání.

Pokud chcete aplikaci Gemini zpřístupnit ve vaší škole, postupujte podle následujících kroků:

Popiš památku je tu! Napište článek a vyhrajte ceny!

15.
ledna
Wikimedia ČR

Již poosmé vypukla na české Wikipedii soutěž s názvem Popiš památku. V ní píšeme nové encyklopedické články o kulturních památkách v Česku i v Evropě.

Zámek Bartošovice

Proč vlastně památky?

Kulturních památek je v České republice přes čtyřicet tisíc. Každý rok jich řada nových přibyde. Přibližně čtvrtina z nich jsou stavby, které už splňují parametry na to, aby na Wikipedii byly popsány, tedy parametry tzv. encyklopedické významnosti.

Jedná se o téma, které je oblíbené, které na Wikipedii patří a které má přesah i mimo encyklopedii – dobře zdokumentované regiony na Wikipedii mají ohlas i co se týče turistického ruchu v reálném světě.

Žhavá novinka od moře

Soutěž Popiš památku se koná na přelomu ledna a února v podstatě již každý rok. Postupně jsme ji rozšiřovali o řadu témat. Nejprve o památky slovenské, posléze o všechny evropské. Letos se podařilo ve spolupráci s Filozofickou fakultou Univerzity Karlovy, resp. tamním oddělením portugalistiky při Ústavu románských studií uskutečnit jednu překvapivou novinku, a to portugalskou kategorii.

Je to tak. Pokud napíšete články o portugalských památkách, tak můžete vyhrát knižní ceny, které nám poskytl právě uvedený ústav.

Portugalsko je v tomto směru tak trochu netradiční volbou. Jedná se o zemi, která má ohromnou tradici – koneckonců se jednalo o světovou mocnost, která se podílela na zámořských objevech. Na české Wikipedii je však poměrně málo zdokumentovaná. Loni navíc země oslavila 50. výročí své cesty k demokracii, když tamní Karafiátová revoluce svrhla režim António Salazara.

Šanci vyhrát mají všichni!

Na vítěze čekají knižní ceny o památkách, vybrané historičkou architektury. Oceněni budou nejen aktivní přispěvatelé, ale i autor nejhodnotnějšího příspěvku (kterého změříme nástrojem Wikirank), ohodnotíme také nováčky a některé ceny budeme losovat. Šanci tak mají v podstatě všichni účastníci a účastnice.

Soutěž probíhá ve spolupráci s partnery. Již dlouhodobě s námi spolupracuje například časopis Propamátky.

Jak se do soutěže zapojit? Stačí si vybrat ze seznamu vhodnou památku, třeba v blízkosti vašeho bydliště. Na výběr jsou různé fary, kostely, tvrze, hrady, zámečky, mosty a podobně. Vybírat lze i z novějších staveb, např. různých vil, domů nebo radnic. Stačí kliknout na červený odkaz vybrané památky, napsat článek a potom jej vložit do soutěžního rozhraní. Tam patří památky české i evropské.

A nebo se můžete „vydat“ po Evropě až na konec světa – do Portugalska. Tyto soutěžní příspěvky do našeho rozhraní neukládejte ale do shrnutí editace dejte hashtag #portugalsko

Články můžete překládat z jinojazyčných verzí Wikipedie, anglické, portugalské nebo jakékoliv jiné. Jen si dávejte pozor na kvalitu textu, neboť strojové překlady jsou sice super, zvlášť v dnešní době umělé inteligence, ale ve výsledku bez důkladné kontroly mohou nadělat více škody než užitku. Proto se podívejte na časté chyby překladačů. A pokud hledáte zdroje na psaní článků tak se u nás něco také najde.

Máte oblíbené místo v Česku, Evropě nebo Portugalsku, které vás zaujalo svou historií, architekturou nebo příběhem? Napište jeho popis, zdůrazněte, čím je jedinečné, a přihlaste svůj příspěvek do naší soutěže. Přidejte se a pomozte oživit kulturní dědictví na Wikipedii prostřednictvím vašich článků!“

Podpora onkologických pacientů, vzdělávání dětí i komunitní zahrada. Rozdělíme dva a půl milionu korun v Moravskoslezském kraji

14.
ledna
Nadace OSF

Nadační fond Hyundai i v roce 2024 vyhlásil grantovou výzvu zaměřenou na rozvoj občanské společnosti a ochranu životního prostředí v Moravskoslezském kraji. Porota vybírala z rekordních 105 přihlášených projektů. Částkou 2 490 880 Kč podpoříme 14 místních organizací a jejich environmentální a komunitní aktivity.

(více…)

Známe nejhezčí šumperák v ČR: Výsledky mikrosoutěže Šumperáky

14.
ledna
Wikimedia ČR

Již tradičně se od konce října do půlky prosince koná výzva Československo. Tento projekt se zaměřuje zejména na doplňování chybějících článků o osobnostech, událostech a reáliích spojených s Československem.

Foto: Sumperak – kresba, Autor: Filo, CC BY-SA 3.0, via Wikimedia Commons.

Wikiprojekt Československo

V rámci letošního ročníku probíhala nově také fotografická soutěž zaměřená na focení dobových staveb, tzv. šumperáků. Jak uvádí Wikipedie, je šumperák označení pro typ rodinného domu, jehož projekt vznikl na konci šedesátých let 20. století.

Někteří tyto stavby obdivují, jiní se jim vysmívají. Jednoznačně jde však o součást naší kulturní historie, která je svědectvím své doby. Mnoho z těchto budov už nenávratně zmizelo, jiné byly přestavěny a modernizovány. Najdou se ale i takové, které stojí v původní podobě dodnes. Cílem soutěže bylo zmapovat, co nejvíce podob tohoto fenoménu české užitné architektury 20. i 21. století. Součástí výzvy byla i úvodní online přednáška Tomáše Pospěcha, autora publikace Šumperák

Vítězná fotka soutěže 

Do mikrosoutěže Šumperáky se zapojilo celkem 13 fotografů, kteří si dali tu práci a nahráli na Wikimedia Commons 32 unikátních fotografií těchto staveb. V porotě soutěže usedl mnohaletý aktivní wikipedista, fotograf, organizátor soutěží a člen rady spolku Wikimedia Česká republika Aktron; dále již zmiňovaný Tomáš Pospěch, historik, odborník na Šumperáky a autor knihy Šumperák a koordinátor fotografických programů Richard Sekerák. 

Vítězem Mikrosoutěže Šumperáky se, s rozdílem jednoho bodu, stal Bazi s fotografií Šumperáku ve Slavkově u Brna. “Je to pěkně a původně dochovaný šumperák”, shrnul Tomáš Pospěch. 

Foto: Slavkov u Brna, ČSA 1189, šumperák, Autor: Martin Strachoň, CC BY-SA 4.0, via Wikimedia Commons.

Vítěz získává roční licenci k programu ZPS X, od partnera soutěže společnosti Zoner, která dlouhodobě podporuje fotografy nahrávající na Wikimedia Commons. Všichni fotografové, kteří splnili pravidla, obdrží ponožky od Klubu Pánů z Ponožkovic, partnera projektu WikiProjekt Československo a Wikipedistické vyznamenání.


Ukázky nahraných fotografií

Call blocking on Ubuntu touch

10.
ledna
Jozef Mlich
🚫📞 I've created exPhone, a call-blocking app for Ubuntu Touch! It blocks unwanted calls (including "ex-" calls 😄). Built with libwatchfish, SQLite, and AI tools for the logo. Despite UX feedback, I’m proud of the journey! 🚀 Try it out & contribute if you can! #UbuntuTouch #AppDev #OpenSource #CallBlocking

Nemusíte sa báť, že vás okopíruju ak ...

09.
ledna
Fero Volár
Nemusíte sa báť, že vás okopíruju ak ...

Ak v biznise máte obavu, že vám konkurencia ukradne vaše know-how, ľudí, technológie, biznis model, zákazníkov - môže to byť veľký problém. Poznám veľa founderov, podnikateľov čo uvažujú, čo ak sa to stane.

A potom sú tu firmy, ktoré to majú vyriešené. Lebo ...

Inovujú, myslia a pracujú pre budúcnosť, modernizujú, vylepšujú seba, kolegov a aj spoločnosť. Majú stratégiu, taktiku a napredujú. Splniteľné plány. Čiastkový, ale kontinuálný progres. Releasujú nové verzie, features, zlepšujú zákaznícky zážitok a rozpoznateľnosť značky.

Ak ich niekto okopíruje, tak kopíruje ich minulosť. Ich históriu.

Lebo oni sú už niekde ide. V budúcnosti.

Ak aj vy takto uvažujete a fungujete, tak sa nemusíte báť, že vás okopírujú.