Vlákno názorů k článku
Vývojář, který přidal birthDate do systemd, čelí šikaně od Josef Pavlik - Registrovat vek globalne v systemu, navic v tom...

Registrovat vek globalne v systemu, navic v tom silenem paskvilu jako systemd, je totalni blbost. Jestli si ti idioti v Kalifornii nevsimli, Linux je multi user operating system. Nemuzes zaregistrovat vek globalne. Pro ktereho usera pak plati? To je blbost. Pokud chcou nekde registrovat vek, melo by to byt v databazi uzivatele, stejne jako jmeno, cislo dveri a telefon - polozky, ktere uz tam nekde jsou, v zivote jsem nevidel, ze by je nekdo pouzil. Proste kazdy uzivatel, pokud si toho senatori nevsimli, ma jiny vek.
V kazdem pripade je tento zaznam veku totalne nesmyslna zalezitost, protoze kdo chce, si to muze nastavit jak chce a hotovo. Ja, kdyz po me nejaky formular chce datum narozeni, davam zasadne 1/1/1970. To se aspon dobre pamatuje :-). A i kdyby bylo nekde v systemd API na zjisteni veku, tak tohle datum nastavim uplne presne stejne. Proc by kazdy robot a kazda blba webova stranka mela mit pristup na moje datum narozeni.

Co takhle si to přečíst, než budete reagovat? Není to globálně, je to pro každého uživatele...

Nepochopili ste to spravne. Ano pri kazdom konte sa to bude vyplnat tak ako si dnes mozete napriklad pri kazdom konte vyplnit telefonne cislo, adresu, ... (nemusite ale mozete). Robi to administrator systemu a uzivatel si to nevie zmenit.
Browser potom moze pridat API ktore bude sluzit na dotazanie sa aku vekovu hranicu ma. V kalifornii je to myslim nieco ako do 12, do 15, do 18, do 21 a nad 21. Browser posle tuto informaciu o limite, nie datum narodenia, prislusnej stranke a vypocita ho interne z datumu narodenia.
Ak to bude implementovane pomocou SYSTEMD ma to jednu velku vyhodu. Je tam mozne pri pristupe na toto API pridat dialog ze 'Tato aplikacia zada o pristup na datum narodenia' a vy mozete kliknut povolit alebo zakazat. Pri pristupe kedy je tato informacia ulozena v subore iba pre 'niektore' aplikacie by to bolo ovela komplikovanejsi.

Konečně relevantní příspěvek. Vidím výhody i nevýhody, je to tak 50 na 50

Tohle v principu není špatná funkčnost. (Jen doplním, že kromě možnosti vracet příslušné pásmo je/byla ve hře ještě varianta, že se API browseru zeptá na konkrétní pásmo a dostane odpověď true/false.)
Vadí mi na tom dvě věci:
a) povinná implementace i v OS, kde nikdy žádné API, které by se ptalo, nebude (routery, infotainmenty, ústředny, meteostanice, servery,...),
b) duplicitní stahování do systemd, když původní (ty správné/platné) údaje jsou uložené v uživatelském profilu = jinde.

> povinná implementace i v OS
Ziadna povinna implementacia v OS tam nie je. SystemD nie je vobec sucast OS a toto API tam vobec nemusite mat. SystemD je modularny sam o sebe.

> duplicitní stahování do systemd
tam ide prave pouzit to ako 'portal' kedy vy ako uzivatel si riadite kam aplikacie mozu pristupovat aj ked su spustene pod vasim uctom na vasom screene. Takze to zobrazenie 'XY aplikacia sa pokusa pristupovat k vasmu datumu narodenia' aplikacia nedokaze obist a vy mozete povolit alebo zakazat pristup k tejto informacii.

Povinné má být - v Kalifornii - to API. Implementace je na výrobci OS.
Se SystemD to má společného jen to, že se udělal přípravný krok v podobě té databáze.
Tedy naopak: nemusí to být v SystemD, nemusí tam být ani SystemD, ale to API je (do budoucna) povinné, to tam být musí (budoucí čas).

Pokud to má být portál, nepotřebuje si tu informaci stahovat k sobě. Ono by se také mohlo stát, že nějakým hackem a zneužitím zranitelnosti by se třeba podala informace za jiného uživatele, než jaký se ptá. Pokud by tohle celé bylo zavřené v procesu uživatele, tohle riziko by bylo menší.

Navíc, v homed je pokud vím tyhle záznamy možné šifrovat per account, takže se ostatní uživatelé k těm datům ani nemají jak dostat. Jedno z hlavních lákadel Homed je možnost vyrobit šifrovaný přenosný uživatelský účet nezávislý na systému, míň globální v rámci systému to asi být nemůže.