Uživatel Goldenfish se tentokrát neohlédl za uplynulým rokem (diskuse)

[smazáno]

miriam 2.0

... u osob ženského pohlaví (nezávisle na počtu titulů a směru vzdělání) jsem skoro vždycky mohl pozorovat tu snahu zlepšit výkon zařízení otevíráním oken, aby 'ty vlny mohly lépe dovnitř...

Ženské otvírají okna, protože chtějí mít všechno obráceně než chlapi (viz také např. prkýnko na záchodě apod.). O žádné vlny jim nejde.

[Jiří Lisický]

Z důvodu snížení tepelných ztrát jsou některá skla pokovená. A tam to opravdu může mít vliv

[Heron]

Přesto se před lety objevily databáze, jejichž největší výhodou by mělo být, že jsou právě nerelační. To by mohlo znít nějak nekonsistentně a také to nekonzistentní je.

Ono to není nekonzistentní.

Databáze nevznikly rovnou jako relační s dotazovacím jazykem SQL. K tomu byla dlouhá cesta. Potřeba ukládat data je stará jako počítače samotné. Takže od počátku vznikaly datové struktury do kterých se to zapisovalo. Jednou z takovou struktur je hashovací tabulka. Potom přišla relační algebra a z toho vnikly relační databáze, které jednak umožňovaly komplexní vyhledávání, ale hlavně uměly redukovat objem dat (což bylo v jisté době nezbytné, protože kapacita všeho byla dost omezená) pomocí návrhových pravidel (normální formy). Až potom vznikl jazyk SQL. Každopádně, ty relační databáze používaly a používají pro ukládání dat stejně nějakou již existující datovou strukturu (haldu, hash table, jejich modifikace apod.).

Takže nerelační databáze tady byly dřív než relační a stále žijí vedle sebe. Bohužel, dneska se ke všemu musí udělat hype a založit na to 200 startupů. Takže někteří sice po 50 letech "objevili" věci jak key-value hash table a udělali z toho obrovský hype s cílem (asi) na té bublině nejvíc vydělat, ale co se týče technologie, tak to tady bylo už před desítkami let a není to vůbec žádná novinka.

Minulý rok bych tedy charakterizoval zejména jako rok zbytečně práce.

Co se týče webu, tak takový pocit mám už několikátý rok po sobě. Každý rok přijde deset nových technologií (zejména v oblasti JS) a všechno se přepíše. Potom se objeví článek typu tato technologie je zastaralá (tohle jsem slyšel od jednoho programátora propagátora jisté JS technologie asi tak po půl roce od chvíle, kdy tvrdil, že je to žhavá novinka) používejte tohleto. A zase se to předělává. Netýká se to jen webu, i spousta programů má "potřebu" přejít na nový framework, cestou se ztratí polovina funkcí, ale hlavně že to vypadá cool.

No vypadá... Vzpomněl jsem si na diskusi pod Frantovým blogem ohledně grafického prostředí pro práci. A pro mě je jedním z největších zklamáním za poslední roky fenomén HiDPI.

Už kdysi dávno při každé výuce html se zakazovalo používat absolutní délkové jednotky jako px. Všechno se dělalo pomocí relativních em, ex, nebo rovnou procentama. Důvod byl jasný, každý monitor má jiné dpi, takže 5px je pokaždé jinak velké. Dokonce si tehdy dělali linuxáci srandu s windowsáků o tom, že přece stačí nastavit správně DPI a je to.

Přišel rok 2016, přišel hype HiDPI a začaly se objevovat HiDPI témata, HiDPI ready programy apod. Jako proč? Nemělo by stačit jen nastavit příslušné DPI a je to? Kde se stala chyba, když už před 20 lety se vědělo, jak to dělat dobře?

A tohle se netýká jen DPI, tohle by se dalo napsat o kde čem. Pro mě byl minulý rok rokem zklamání z IT.

Zřizují se ministerstva pravdy

Na rozdíl od některých jiných mě toto nechává chladným. Tenhle úřad je jen dalším teplým místem pro kamarádíčky. Dnes má 15 zaměstnanců, za pár let jich tam bude 200 a neštěkne po tom ani pes.

Jestli je na tom něco ke komentáři tak to jsou slova paní Romancovové, že každé falešné tvrzení prozkoumají s úřady státní správy a zjistí, kde je pravda. Ok, dobře, tak proč ty úřady samotné ty informace nezveřejní? Proč musí nejdřív vzniknout hoax, potom musí přijít nějaký úřad a odhalit pravdu (kterou dle slov Romancovové státní správa zná), proč prostě ty úřady řádně neinformují veřejnost průběžně?

věcné byť marné diskuze s panem Jirsákem na všech možných portálech

S Filipem se dobře diskutuje. S ním by se skvěle chodilo na pivko. Dokonce jsem s ním už na jedné akci před mnoha lety byl, ale tehdy jsem nevěděl, že je to FJ.

[kralyk z abclinuxu]

Co se týče webu, tak takový pocit mám už několikátý rok po sobě. Každý rok přijde deset nových technologií (zejména v oblasti JS) a všechno se přepíše. Potom se objeví článek typu tato technologie je zastaralá

Takový je přesně aktuálně svět JS. Viz How it feels to learn JavaScript in 2016. Osobně jsem přesně tohle zakusil, když jsem si chtěl vyzkoušet kombinaci TypeScriptu, Reactu, Reduxu a pár dalších věcí za použití "moderních technologií" typu Webpack a podobně. Závěr: Zvěsti nelhaly, ekosystém JS je přesně tak špatný, jak se píše, ne-li horší.

Nejhorší je na tom asi to, že tam kde v ostatních jazycích typicky stačí 1-3 nástroje na sestavování projektu a přidružené úkoly, je v JS potřeba nástrojů tak 5-15, kde každý z nich 1) ve skutečnosti toho až tak moc neumí, 2) složitě se konfiguruje a 3) potřebuje X pluginů na to, si mohl povídat s těmi ostatními nástroji nebo udělal něco užitečného.

Hello World projekt napsaný v moderní verzi ES s použitím těhle moderních nástrojů pak ve výsledku má klidně stovky závislostí.

Po několika dnech dohadování se s těmahle nástroje jsem je všechny poslal do horoucích pekel, nasadil Elm + yarn na JS závislosti + Makefile na sestavování a jsem v zásadě spokojen.

S Filipem se dobře diskutuje.

Mně to vždycky přišlo jako nekonečné cvičení v rozmotávání nesmyslných analogií, tautologií a logických klamů. (Na druhou stranu je ale pravda, že v řadě věcí jsem s ním souhlasil...)

[Agent]

Což o to Filípek, ale Ivánek (často se vyskytuje na Rootu, ale i jinde), to je teprve klasa.

[melkors]

Jo, ten je dokonaly

[podlesh]

V podstatě klasický stereotypní kavárenský intelektuál, akorát se z nějakého důvodu rozhodl že bude kovaným pravičákem.

Hilarity ensues.

[Petříček]

Tak, tak. Je neskutečné co dokáže způsobit chybějící #include

[Kvakor]

Takový je přesně aktuálně svět JS. Viz How it feels to learn JavaScript in 2016. Osobně jsem přesně tohle zakusil, když jsem si chtěl vyzkoušet kombinaci TypeScriptu, Reactu, Reduxu a pár dalších věcí za použití "moderních technologií" typu Webpack a podobně. Závěr: Zvěsti nelhaly, ekosystém JS je přesně tak špatný, jak se píše, ne-li horší.

Ten článek je úžasný a měl by si ho přečíst každý programátor, který brblá nad tím, jak to má složité. Osobně mi to připadá, že stav, kdy se technologie mění stejně šílenou rychlostí jako oděvní/obuvní móda, je velmi nezdravý (minimálně z hlediska spolehlivosti a bezpečnosti), nicméně se obávám toho, že mlamojům ze "síťové generace" takto překotný rozvoj může připadat normální a na konzervativnější IT obory (jako třeba průmyslové a embedded systémy) se dívají jako kdyby ustrnuly v době kamenné a zatím jen velmi opatrně koketují s bronzem ...

[Fluttershy, yay!]

Z toho bych si zase tak nedělal hlavu. Taková entropie není na celkem novém trhu (v novém oboru) nic neobvyklého. Ono se zatím zkouší, co vlastně funguje a co ne. Časem se to ustálí.

I ta zavedená odvětví IT jsou při pohledu zvenčí z hlediska metodiky, odpovědnosti nebo organizace práce zatím často směšná a na vodě.

Jenom je otázka, jak dlouho to bude trvat.

[podlesh]

Ono to ale na druhou stranu dává trochu smysl, protože weby v podstatě jsou módní záležitost jako dámské oděvy či obuv. Po třech, čtyřech letech se prostě musí obměnit! A i když se náhodou zrovna nezmění móda, tak je potřeba web předělat, aby byla změna.

Samozřejmě to neplatí obecně. Koneckonců - sako s kravatou, svetr s norským vzorem nebo gumáky se můžou nosit desítky let.

[Tomáš]

Tak pokud člověk není debil, může módní trendy ignorovat - a nemusí při tom ze sebe dělat ještě většího debila tím, že by si ke krku vázal kravatu. Blbé je, když se vymódění metrosexuálové nebo bezmozci s kravatou a MBA dostanou k nějaké technologii, a začnou ji prznit.

[podlesh]

Skutečně to má být reakce na to co jsem napsal? No, asi je to moje chyba, použil jsem klíčové slovo...

[pavlix]

Potřeba ukládat data je stará jako počítače samotné.

Daleko daleko daleko starší. A tím pádem i databáze dalece předcházejí počítače. A naše generace by to ještě měly vědět, sice jsme se narodili do počítačové doby, ale kartotéky jsme ještě v provozu viděli.

[Heron]

Ano, předpokládám, že toto je všem jasné. Zápisek hovoří o počítačových databázích.

[pavlix]

Nikdy není na škodu si připomenout, že jsme před rozšířením počítaču nelezli po stromech.

U některých lidí bych si tím nebyl jistý.

[JS1]

Takže nerelační databáze tady byly dřív než relační a stále žijí vedle sebe.

Jenom technicka, tohle v tom zapisku napsane je, ze driv se pouzivaly nerelacni. Ale prave to je to, co autorovi nejde do hlavy, proc driv prestaly byt popularni a najednou byt popularni zacaly, aniz by si lide uvedomili, jake nevyhody to prinasi.

Fakt je, ze treba IMS se porad pouziva. Ale ma to krome vyhod (rychlost) i nevyhody (mensi flexibilita).

Jinak kolega nedavno sarkasticky zminil, ze dnes se NoSQL casto vydava za "Not only SQL".

[Heron]

Jinak kolega nedavno sarkasticky zminil, ze dnes se NoSQL casto vydava za "Not only SQL".

Tak dneska asi ani neexistuje databáze, která by byla čistě SQL. Už s podporou XML se to zvrhlo (xml je hierarchický dokument), samotný postgres má dlouhá léta hstore (key value) a časem přišel i s báječnou podporu jsonu. Nevím, jak je to dnes, ale v určité době byl postgresql výkonnější než mongodb. Což je pikantní, protože mongo je nosql databáze pro ukládání json dokumentů a nějaký starý moloch ji převálcuje. (Ono to až takové překvapení není. Doporučuju nahlédnout do historie pg a jeho úložného systému. To je (podle mě) učebnice toho, jak to dělat správně - a nemyslím tím jen ten storage, ale celý projekt.)

[JS1]

"Což je pikantní, protože mongo je nosql databáze pro ukládání json dokumentů a nějaký starý moloch ji převálcuje."

Tak to me vubec neprekvapuje - IMS je taky stary moloch, ktery leccos prevalcuje. Ono vubec stare programy jsou casto efektivnejsi, coz je z casti asi survivorship bias, z casti je na nich proste vic prace, a z casti je to za cenu jinych nevyhod (treba mensi pohodli pri administraci).

[Josef Kufner]

Hlavně tehdá bylo potřeba brutálně optimalizovat, aby to vůbec nějak chodilo. Dnes se nahází pár knihoven na hromadu a když je to pomalé, tak se přihodí další knihovna na optimalizace.

[melkors]

Ono uz ladeni zelezem zase neni v mode?

[podlesh]

Tenkrát samozřejmě také bylo spousta neoptimalizovaného SW, ale ten lépe optimalizovaný vyhrál. To je ten zmíněný survivorship bias.

[Josef Kufner]

Už kdysi dávno při každé výuce html se zakazovalo používat absolutní délkové jednotky jako px. Všechno se dělalo pomocí relativních em, ex, nebo rovnou procentama. Důvod byl jasný, každý monitor má jiné dpi, takže 5px je pokaždé jinak velké.

Ne tak docela. S CSS3 (nebo možná už CSS2) se změnila definice 'px'. Ve zkratce: Je to jednotka, která se zaokrouhluje na násobek fyzických pixelů zobrazovadla tak, aby velikost zhruba odpovídala 1px na běžném 96ppi monitoru. Tedy prohlížeč by 1px tlustou čáru na 200ppi displeji měl vykreslit 2 pixely tlustou.

[Heron]

Uff. Takže když někdo bude skutečně potřebovat něco vykreslovat v absolutních jednotkách, tak má smůlu? Nebo tam přidali něco jako reálnýpx?

[Fluttershy, yay!]

Ano, má smůlu. Na webu je to jedna z mála věcí, které jsou dobře.

[Heron]

Na webu je to jedna z mála věcí, které jsou dobře.

Podle tebe je dobře to, že px není px a že jeho velikost se odhaduje z bůh ví čeho? Zatímco od počátku tady existují jednotky, které přesně tohle řeší?

[Fluttershy, yay!]

Jedno slovo: responzivita.

Web před CSS byl plně responzivní (až na bitmapy).

[Heron]

To neodpovídá na otázku, zda je podle tebe správné měnit definici pixelu.

Pokud byl problém ve velikosti obrázku, tak stačilo přidat atributy umožňující zadat velikost obrázku v relativních jednotkách. (Resp předat skutečné rozlišení bitmapy tak jak dosud a potom velikosti plátna, kam se má vykreslit.)

Taky by docela pomohlo, kdybys místo vykřikování slov odpovídal v celých větách, protože ti fakt nerozumím.

[Fluttershy, yay!]

Možnost manipulovat s pixely na webu (tj. přesný opak responzivity) považuji za historický omyl.¹ To, že se jednotce říká pixel, je jeho důsledek.

Protože webaři, kteří dělají frontend, zneužijí cokoliv, co se k nim dostane. Spoléhání na fixní rozlišení je jeden příklad, jiný je třeba reimplementace ovládacích prvků v různých frameworcích (pak se třeba tlačítko nechová jako standardní tlačítko, takže je pak rozbitá navigace klávesnicí nebo si s tím neporadí různé čtečky mj. pro postižené).

¹ Pravda, taky to nakonec dopadlo tím lepším způsobem. Adobe Flash jsme tu mohli mít pro celé weby dodnes.

[pavlix]

Protože webaři, kteří dělají frontend, zneužijí cokoliv, co se k nim dostane.

Jo, to mi taky vadí. Myslím si, že by web za žádných okolností neměl dostat informaci o velikosti obrazovky. Do toho mu prostě nic není, má se přizpůsobovat zobrazovací ploše, kterou mu přidělím. To může rovnou přizpůsobovat zobrazení velikosti péra.

[JS1]

Myslím si, že by web za žádných okolností neměl dostat informaci o velikosti obrazovky.

To je nesmysl..

Aplikace musi mit aspon radovou predstavu. Treba graficky editor na 22' obrazovce desktopu by se stejnym layoutem GUI vypadal na obrazovce mobilu dost spatne.

Samozrejme, bylo by idealni, kdybychom mohli jednoho dne napsat univerzalni GUI a fungovalo by to pekne (pouzitelne) na vsech rozlisenich, ale takova doba jeste nenastala, jestli je to vubec realne.

[Fluttershy, yay!]

To je problém, že se řeší absolutní počet pixelů namísto poměru stran a jemnosti obrazovky.

Takže některé moderní weby mi cpou mobilní verzi, protože mám méně než 1280 pixelů na šířku, ale už je nezajímá, že jde o monitor se 100 dpi (to by si ještě zjistit mohli) otočený na výšku.

[pavlix]

To je nesmysl..

A důvod? Ve tvém komentáři jsem žádný nenašel.

[Josef Kufner]

Máš ho hned pod tím. Zrovna před pár dny jsem to řešil. Stránka, kde je schema a popisky. Na menším displeji se to vedle sebe nevleze, ale na širším to zas škoda místo nevyužít. Takže je v CSS podmínka, že od určité šířky se layout přeskládá do širší verze.

[pavlix]

Vážně jste už dva, co mě přesvědčujete naprosto lichými argumenty, že se webová aplikace nemá řídit velikostí vykreslovací plochy a že nutně potřebuje znát velikost fyzického displeje, který jako celek nemá vůbec přidělený?

[Josef Kufner]

Hm, koukám, že JS1 neměl citovat jen půlku toho komentáře.

[pavlix]

+1

[Michal Kubeček]

Takže je v CSS podmínka, že od určité šířky se layout přeskládá do širší verze.

Pokud je řeč o šířce viewportu, pak nemám námitek. Pokud by se aplikace chtěla přeskládávat podle šířky obrazovky, je zásadní chyba návrhu.

Na menším displeji se to vedle sebe nevleze, ale na širším to zas škoda místo nevyužít.

Webová aplikace nemá uživateli co diktovat, jak velkou část obrazovky jí přidělí, to je volba uživatele. Třeba chce mít vedle sebe dvě (tři) okna prohlížeče, třeba chce mít vedle okno s jinou aplikací, třeba jen prostě při čtení nechce vypadat jak na tenise. To je čistě jeho věc, aplikaci do velikosti monitoru(-ů) nic není.

[pavlix]

+1

[JS1]

Pokud je řeč o šířce viewportu, pak nemám námitek.

Je rec o sirce viewpointu. Pointa je, ze aplikace musi vedet (nebo aspon tusit) fyzickou velikost, nestaci jen preskalovat podle DPI. Tudiz nestaci jen jedno cislo, je potreba znat jak fyzicky rozmer tak rozliseni.

[Josef Kufner]

To se zas dá snadno řešit pomocí rozumných jednotek, jako je například em (nebo rem), což je velikost písmena 'M', které má pokaždé rozumnou velikost bez ohledu na displej.

[pavlix]

Je rec o sirce viewpointu.

Tak určitě. :D

[Heron]

To, že se jednotce říká pixel, je jeho důsledek.

Takže ještě jednou. html poskytuje mnoho délkových jednotek. Relativní (procenta z velikosti bloku), definované velikostí písma (em, ex), definované rozměrem (cm, in, pt) a absolutní (px).

Mě přijde mimořádně hloupé předělávat absolutní px na nějaké jiné relativní px.

To, co píšeš ve druhém odstavci je pravda, ale nejsem přesvědčený o tom, že se to vyřeší změnou definice px. To už by bylo mnohem rozumnější ten px prostě vyhodit úplně.

Aneb, můžu jen zopakovat: Kde se stala chyba, když už před 20 lety se vědělo, jak to dělat dobře?

Nevím proč, ale vzpomněl jsem si na to, jak někdo chtěl definovat zákonem pi jako 3.2.

[Fluttershy, yay!]

CSS, nikoliv HTML AFAIK.

Mě přijde mimořádně hloupé předělávat absolutní px na nějaké jiné relativní px.

Pokud vím, tak „absolutní px“ dávno nejsou absolutní i mimo web.

Navíc, tahle změna i docela rozumně zachovává zpětnou kompatibilitu, kdežto některé weby dělané s absolutním polohováním (a hlavně písmy) v Adobe Flashi se nedají číst.

[pavlix]

CSS, nikoliv HTML AFAIK.

To jednak. A jednak osobně nevěřím na kvalitu návrhu CSS a třeba ten zmatek s Microsoftem, který bývalo zvykem připisovat povaze té firmy, já osobně připisuju nedostatečné kvalitě toho standardu v různých fázích vývoje. Ještě si pamatuju, jak se všude psalo o ideálech jako je oddělení obsahu a prezentace, přičemž k tomu CSS ani v nejmenším neposkytovalo nástroje a XSL byl jen takový zoufalý pokus, co to ještě více zkomplikoval, což se dá říct prakticky o všem, co vzniklo okolo XML.

[Heron]

Pokud vím, tak „absolutní px“ dávno nejsou absolutní i mimo web.

Kde? V jakémkoliv programu, co má co dělat s grafikou se pixelem stále ještě myslí jedna rgb(a) buňka obrazu.

Navíc, tahle změna i docela rozumně zachovává zpětnou kompatibilitu

Ano, takže místo aby se nastavilo správně DPI a vše dál fungovalo (kromě blbě napsaných programů, které používají absolutní px na nevhodných místech a účelu a je potřeba je přepsat správně), tak se pro jistotu rozbije všechno, ale je potřeba se tvářit, že to vlastně funguje.

Každopádně díky za odpověď, už je mi konečně jasné, kde se stala chyba. (Ne že bych to nevěděl už od počátku...)

[pavlix]

Ano, takže místo aby se nastavilo správně DPI a vše dál fungovalo

U rozměrů grafických prvků to nikdy nefungovalo, tudíž to nemůže fungovat dál. Skoro všechna grafika na webu je bitmapová usazená na pixely. To je samo o sobě dost dobrý důvod pro specifikaci velikosti textu v pixelech, aby se trefoval do zbytku grafiky. Holt se používá Web a CSS jinak než se předpokládalo a W3C nikdy nemělo tendenci starat se o přizpůšobení standardů realitě a namísto toho se dlouhodobě snažili standardy diktovat změny v realitě a moc se nedařilo.

[Heron]

Skoro všechna grafika na webu je bitmapová usazená na pixely.

Tak tomu od počátku nebylo, obrázky se umísťovali do textu. Složitější kreace přišly až potom a mohlo se zavést i pro obrázky zadávání rozměrů jinak než v px.

To je samo o sobě dost dobrý důvod pro specifikaci velikosti textu v pixelech

No vidím to opačně, podle mě je to dobrý důvod zadávat rozměry obrázků pomocí em, cm apod.

Ostatně v sazbě (když už jsme se tady nedávno bavili o *texu) se to tak dělá běžně (právě proto, že nikdo dopředu neví, na jakém zařízení se to bude tisknout nebo zobrazovat, takže nelze rozměry obrázku definovat px). Takže stačilo to udělat stejně správně jako v sazbě.

[Fluttershy, yay!]

Tiskárny, některé dnešní "retina" displeje.

HiDPI ostatně demonstruje, že pouhá změna nastavení DPI nemusí nutně nepomáhat. Ona se totiž i "geometrie" liší mezi různými grafickými stacky/toolkity (stačí si porovnat klidně i historické manuály od Apple a Microsoftu).

[Michal Kubeček]

Hlavní chyba byla IMHO v tom, že webaři nepochopili, že smyslem té jednotky je umožnit definovat délku v pixelech tam, kde je potřeba, aby to byly opravdu pixely (typicky třeba pro přizpůsobení něčemu, co má pevnou velikost v těch pixelech, např. bitmapovému obrázku). Místo toho tu jednotku používali všude možně a jednu dobu jsem se (marně) snažil bojovat proti tehdy hojně rozšířenému názoru, že px je ta jediná správná jednotka (na všechno) a pt (a další podobné) je třeba zavrhnout ("protože pt je absolutní, zatímco px relativní").

To pevné svázání s absolutními jednotkami je pak už vlastně jen logický důsledek kombinace skutečnosti, že se px používá na věci, pro které nebyl určen, a většího rozšíření displejů s rozlišením výrazně odlišným od 96dpi.

[pavlix]

Hlavní chyba byla IMHO v tom, že webaři nepochopili, že smyslem té jednotky je umožnit definovat délku v pixelech tam, kde je potřeba, aby to byly opravdu pixely (typicky třeba pro přizpůsobení něčemu, co má pevnou velikost v těch pixelech, např. bitmapovému obrázku).

Tedy na graficky zpracovaných webech skoro všude.

Místo toho tu jednotku používali všude možně a jednu dobu jsem se (marně) snažil bojovat proti tehdy hojně rozšířenému názoru, že px je ta jediná správná jednotka (na všechno) a pt (a další podobné) je třeba zavrhnout ("protože pt je absolutní, zatímco px relativní").

Já jsem se tehdy postavil na druhou stranu barikády. Používání pt vedlo k nespokojenosti zákazníků, protože se písmo jednak ukazovalo všude jinak a jedna se ne všude hezky vykreslilo na skutečné pixely. Ona vůbec ta doba byla taková hodně rozpolcená, na jedné straně ideály, na druhé straně flash. Docela dlouho mi trvalo pochopit, že tuhle oblast daleko víc požkozuje svaté W3C než zlý Microsoft.

Jako jo, taky jsem měl spoustu představ, jak by se věci mohly nebo měly dělat. Nevím jak dneska, třeba si na to ještě sáhnu, jestli teď půjdu zpátky na živnost, ale tehdy byl frontend hlavně o tom zahodit ideály a natvrdo se naučit, jak se chovají cílové browsery, kdy měl každý úplně jiné chyby, odchylky od standardů a tweaky na změnu chování. Nebylo to nic hezkého, což byl jeden z hlavních důvodů, proč jsem se znažil se z webové oblasti vyvázat.

[Sten]

To se mi právě líbí na Androidu: dp a sp. Jsou to násobky pixelů (tedy žádné rozmazaniny) podle DPI a sleposti uživatele (zvětšení písma).

[kralyk z abclinuxu]

Kde? V jakémkoliv programu, co má co dělat s grafikou se pixelem stále ještě myslí jedna rgb(a) buňka obrazu.

Měli jsme donedávna doma TV, která neměla čtvercové pixely.

[Heron]

Ano, to za nás, co jsme začínali na 14" kulatých CRT bylo docela běžné.

[Michal Kubeček]

Na 14" a 15" bych to moc nečekal, tam bylo obvyklé 1024x768, občas u fajnšmekrů 1152x864. Problém nastal spíš později, kdy se objevily 17" CRT obrazovky s poměrem stran 4:3 a spousta uživatelů nich vesele používala 1280x1024, protože v tom omezeném seznamu nabízeném Windows mezi 1152x864 (často dokonce 1024x768) a 1600x1200 (výjimečně 1400x1050) nic nebylo. Zkreslení ignorovali, koneckonců dost lidí nemá problém ani se zkreslením vzniklým roztažením 4:3 obrazu na 16:9 televizi.

[hefo]

"koneckonců dost lidí nemá problém ani se zkreslením vzniklým roztažením 4:3 obrazu na 16:9 televizi"

A toto ma neprestáva fascinovať. Ak u svokrovcov zapnem deťom nejakú rozprávku, tak je pomer strán chybne oproti tomu, čo to zobrazuje z DVB-T settopboxu. A manželka vždy krúti hlavou, načo to vždy v menu televízora pracne manuálne mením - "však to nevadí"...

[Michal Kubeček]

Reakce "však to nevadí" ještě není to nejhorší, já znám i "nepřepínej to, nekoupili jsme si velkou televizi, abysme jí používali jen kus" (případně "my my už jsme starší, tak to potřebujeme mít větší").

[PepaSFI]

Ještě horší je když zjistíš že to nejde. V televizním signálu je dané jaký má mít formát a televizní přístroj by se na to měl nastavit. Nejsem si jistý jak to je v současnosti ale každý kanál to měl jinak. Někde se to přepínalo, někde byl formát stále stejný a už ve vysílání byly přidané okraje, někde se to přepínalo ale skutečný formát tomu neodpovídal. Do toho mají televize možnost ručně zvolit formát a tím je v tom ještě větší chaos. Moje matka má v kuchyni starší LCD značky Huňády, tedy Hyundai která mi pije krev mnoha způsoby a formát obrazu je jedním z nich. Nakonec jsem to dlouhodobým zkoušením vyřešil ručním nastavením na nějaký kompromisní stav kdy to někdy něco ořezává ale nikdy nedeformuje.

[pavlix]

Co si pamatuju, tak jsem zapojil nějaký box s Linuxem do TV monitoru od samsungu a 1920x1080 přes HDMI mi to automaticky ořízlo všechny strany a tím i všechny ovládací prvky, vybarvilo do růžova, rozsypalo hrany umělým doostřením a přeškálovalo na 1920x1080. Tehdy jsem pochopil, že je přeškálování a změna poměru stran opravdu jen prkotina a „však to nevadí“ je celkem validní argument a většina lidí si problému ani nevšimne.

[Michal Kubeček]

To ořezání a roztažení je AFAIK nějaký podivný relikt z dob CRT obrazovek. Obvykle by to mělo řešit, že se místo "16:9" zvolí režim "disable overscan" (z nějakého záhadného důvodu výrobci do češtiny jednotně překládaný jako "pouze skenování").

[Josef Kufner]

To není relikt CRT, ale analogového vysílání, které bylo napevno 4:3 a neumělo přepnout na nic jiného. To pak se širokoúhlé filmy nedají řešit jinak než přidáním černého okraje. Pokud takto konvertovaný film přehraješ na 16:9 televizi, dostaneš jedny černé okraje kvůli doplnění 4:3 obrazu na 16:9 televizi a pak ještě jsou okraje v obrazu vzniklé předchozím rozšířením pro starou televizi.

[sigma]

Nejde o poměry stran, ale o tzv. "overscan", což je věc definovaná dávno před nějakým 16:9. Důvod jsou právě CRT obrazovky, které u TV přijímačů (narozdíl od pozdějších CRT PC monitorů a posledních typů CRT TV) nemají přesně obdélníkovou aktivní oblast. Běžné TV měly hrany poněkud zakřivené, a zároveň byl u analogové techniky principielní problém se zarovnáním obrazu přesně na aktivní oblast obrazovky.

Proto je v např. v PAL normě definována oblast obrazu, která by měla být na TV vždy viditlená. Mimo tuto oblast by se neměla umisťovat např. loga nebo nápisy, protože na některých TV nemusí být viditelná.

Je to podobná věc jako spadávka u tiskových podkladů, kde existuje také určitá tolerande ořezu.

Aby to na LCD TV zobrazujících analogové vysílání nevypadalo pro běžného diváka "divně", je obraz ořezán také.

Proč některé TV ve standardním nastavení dělají overscan i z HDMI vstupu je mi trochu záhadou. Ale v TV technice dožívá divností a obskurností spousta. Třeba prokládané řádkování, to moc nechápu proč do DVB norem vůbec dávali.

[PepaSFI]

jo to je fakt, televize je už v principu relikt minulosti, tedy myslím to technicky. Ono to ten obraz dělá stejně jako v začátcích, jen dnes se přenáší digitálně a místo paprsku ho maluje blikání pixelů. Ale principy videosignálu jsou pozoruhodně staré a kompatibilní s dnešní technikou. Viděl jsem v muzeu několik generací televizorů a normálně na nich běžel dnešní program. Samozřejmě ze settopboxu s modulátorem, analogově se v prvním tv pásmu už nevysílá. Dokonce i replika amatérského přijímače z doby úplných začátků, postavená z dobových součástek, se zelenou osciloskopovou obrazovkou to umí.

[Heron]

Viděl jsem v muzeu několik generací televizorů a normálně na nich běžel dnešní program.

Tady?

Dokonce i replika amatérského přijímače z doby úplných začátků, postavená z dobových součástek, se zelenou osciloskopovou obrazovkou to umí.

Totéž video čas kolem 16:15.

Vratislav Rýpar umí skvěle vyprávět, to je radost poslouchat. Nebo pozorovat, jak vyrábí vlastní snímací hlavy.

[PepaSFI]

ten přístroj je tentýž ale bylo to v Muzeu historické elektrotechniky Tesla v Třešti u Jihlavy. mají tam spousty nádherných věcí jednak z té spotřební elektroniky ale taky z "těžké", tedy studiové techniky a vysílací. Dokonce tam je i vysílač OMA, dlouhovlnný vysílač časového signálu, tedy to co dnes známe z Německa jako DCF a řídí se tím kdejaký budík. Což mě jako hodináře velmi potěšilo a průvodce překvapilo že to znám. Bohužel vysílač přišel ve špatnou dobu, příliš brzy, paradoxně, být vpředu se vždycky nevyplácí. Prostě v té době ještě elektronika nebyla tak daleko aby se daly levně dělat komerční hodiny s přijímačem a pro nekomerční užití se vysílač nevyplatilo financovat. Muzeum provozuje banda podobných nadšenců jako je ten pán ve videu, původně sběratelé a nadšenci kterým jejich sbírky začaly přerůstat přes hlavu. A tak koupili staré nádražní skladiště, nádhernou stavbu z obrovských dřevěných trámů a v něm udělali muzeum.

[Heron]

To není relikt CRT, ale analogového vysílání, které bylo napevno 4:3

To není pravda. Televizní norma poměr stran neurčuje. Určuje jen počet řádků. Počet bodů na řádek není definován, protože snímací elektronka scanovala řádky spojitě (a televize je vykreslovala spojitě). Takže horizontální rozlišení je dáno pouze šířkou pásma (4.4MHz).

[Josef Kufner]

Norma ne, ale ty skleněné trubky byly nějak vyrobené a informace o poměru stran v "protokolu" nebyla. To vyjde na stejno.

[Heron]

ty skleněné trubky byly nějak vyrobené

To ano, ale mohl se použít stejný trik jako u filmu (CinemaScope) a na snímač poslat obraz příslušně horizontálně komprimovaný přes anaformickou čočku. (Nemám info o tom, že by to někdo někdy dělal a asi ani ne, protože u CRT byl obrovský problém je vůbec udělat nekulaté. O nějakém širokoúhlém poměru stran si mohli nechat jen zdát.)

[Fluttershy, yay!]

protože u CRT byl obrovský problém je vůbec udělat nekulaté. O nějakém širokoúhlém poměru stran si mohli nechat jen zdát

Nějaké ty širokoúhlé (~16:10) CRT obrazovky existovaly.

[Michal Kubeček]

Pár jsem jich viděl, ale spíš až jako takovou labutí píseň v době, kdy už - aspoň v oblasti televizních obrazovek - CRT technologie vyklízela pozice.

[Michal Kubeček]

Nejhorší, na co jsem narazil, byla televize, kde to sice šlo přepnout, ale jen jednorázově, ne trvale. Že by to nešlo vůbec, to jsem IIRC viděl jen u nějaké podivné kombinace pochybného set-top boxu a podobně pochybné televize.

Ta automatika přímo v TV vysílání mi naštěstí u Samsungu vždy fungovala. Jednu dobu bylo běžné i to, že se v rámci reklamního bloku střídaly reklamy natočené v 16:9 a 4:3, dneska už naštěstí 4:3 vysílání celkově dost ubylo.

[Michal Kubeček]

Ještě jsem zapomněl na opravdovou lahůdku, trafikové DVD filmu Rebelové, kde je film 16:9 (možná ještě širší) zapouzdřený do 4:3. Sice i s tím si některé televize poradí (režim "zvětšení"), ale stejně si člověk říká, že ty středověké tresty pro nepoctivé řemeslníky měly něco do sebe.

[Dalibor Smolík]

Tak tohle mě vytáčí. Příjdu domů a film ve formátu 4:3 jede na 16:9. Okamžitě upravuji formát

[Michal Kubeček]

V CSS2 to tak ještě nebylo. Tam to byl prostě pixel s tím, že tam byla alternativní definice pro zařízení s "pixel density … very different from that of a typical computer display", která vycházela z úhlové velikosti při typické pozorovací vzdálenosti. To hodně lidí mátlo, ale bylo to tam hlavně kvůli velmi specifickým zařízením jako třeba projektory.

Pozdější CSS 2.1 (kterou považuji z mnoha důvodů za velmi nešťastnou) prostě definuje 1px jako 0.75pt. CSS3 pak jako 1/96 in (což je totéž - a je to ekvivalentní i tomu, co uvádíte vy).

[pavlix]

Už kdysi dávno při každé výuce html se zakazovalo používat absolutní délkové jednotky jako px.

A už tehdy to byl nesmysl.

[Sten]

HiDPI témata a HiDPI-ready programy jsou potřeba proto, že veškerá grafika ve Windows je stále bitmapová. Až se konečně Windows naučí vektorové ikony jako Linux a Android (i když ten to umí teprve od Marshmallow), HiDPI-ready budou všechny programy.

A ne, MacOSovský přístup všechno zvětšit není řešení. Nepotřebuji 4K monitor, abych na něm prohlížel všechny bitmapy se 200% zoomem a viditelným rastrem.

[pavlix]

Ani na Linuxu není tak úplně grafika obecně vektorová a na webu už vůbec ne.

[kralyk z abclinuxu]

Např. předminule hovořil o přetěžování operátorů a to se mi vždy vybaví Vodafone.

LOL. Jestli je Vodafone něčím přetížený, tak jedině nesmyslně vysokým přítokem financí.

A současně možná vysokým odtokem někam do zahraničí.

[kralyk z abclinuxu]

Ale v technické oblasti to není problém, tam nikoho nezajímá, co se tvrdilo včera a proto klidně v minulém roce implementovaly relační databáze další nerelační prvky - ano přesně to, co není potřeba.

Mimochodem - tohle bych rozhodně netvrdil. To, že okolo NoSQL je nesmyslný hype je sice pravda, ale to ještě neznamená, že celý ten koncept je úplně k ničemu. Nemuset řešit schéma pro všechna data je užitečná věc. Ve volných chvílích se občas pracuju na aplikaci, která pracuje s document-like datama, který mají jednak dost volnou strukturu a jednak nejsou moc provázaný. NoSQL document-oriented databáze je na tohle ideální. Případně bych mohl využít třeba PostgreSQL a mít část věcí relačně provázanou (tam, kde to je užitečné) a část free-form.

Nějaký hype mi může být úplně někde.

[Sten]

Jen bych dodal, že taková typická polorelační databáze jsou moderní souborové systémy: metadata (jméno souboru, datum a GPS poloha vytvoření, velikost, délka u videa, rozlišení u fotek ap.) jsou relační (takže se dá nad nimi rychle vyhledávat), zatímco obsah souboru je free-form.

[Bystroushaak]

Souborové systémy narazí vždy tam, kde je třeba řešit atomicitu a konkurentní přístup. Nebylo by asi od věci, kdyby unix-like distribuce obsahovaly nějakou lepší podporu pro databázi, aby lidi neměli nutkání stavět jednoduchou DB kolem souborů, což zatím vždy co jsem tak měl možnost vidět skončilo dřív, nebo později pracným přepisem na skutečnou databázi.

[Heron]

Nebylo by asi od věci, kdyby unix-like distribuce obsahovaly nějakou lepší podporu pro databázi

Ono je jich v repositářích málo? Nebo jak jsi to myslel?

[pavlix]

1) On ten přepis není nutně vůbec pracný.

2) Ono na ten přepis často nikdy nedojde, protože to prostě není potřeba.

3) Berkeley DB a SQLite pokrývá tak strašně moc potřeba v distribucích jsou.

[Bystroushaak]

3) Berkeley DB a SQLite pokrývá tak strašně moc potřeba v distribucích jsou.

Yep. Jenže lidi mají stejně tendence začít dělat „jednoduché“ věci nad filesystémem a ono to chvíli funguje, dokud najednou ne.

[Heron]

Jsem rád, že se situace posouvá. Když jsem si tady před lety (cca 6) dovolil říct, že data patří do databáze, málem mě ukamenovali, protože od toho je přece FS.

Akorát by mě stále zajímalo, jak jsi myslel tu lepší podporu pro databáze v distrech. Jako nějak víc zapracovat do shellu? Nebo třeba přístup přes soubory (něco jako /proc)?

Jinak těch produktů je strašně moc. Můj první web jsem dělal nad tdb (trivial database), což je v podstatě jen key value a mělo to knihovnu do Cka. Tuším, že to používá i Samba. Potom zmiňovaný BDB (to je prostě klasika), sqlite se taky prosadilo, "velké sql databáze" se zase nechají snadnou používat z příkazové řádky a na nové věci jako mongo z počátku bohatě stačí jakýkoliv http klient. Komu by se to zdálo moc pomalé tak jsou tady věci jako redis (i když třeba sqlite se taky nechá strčit do paměti, v pythonu to takto používám pro dočasné db).

[Bystroushaak]

Akorát by mě stále zajímalo, jak jsi myslel tu lepší podporu pro databáze v distrech. Jako nějak víc zapracovat do shellu? Nebo třeba přístup přes soubory (něco jako /proc)?

Osobně by se mi víc líbil ten druhý jmenovaný přístup pro key:val storage s podporou konkurentního přístupu a transakcí. Něco jednoduchého, co by ale zároveň eliminovalo nutnost si neustále reimplementovat vlastní pokusy.

Jinak těch produktů je strašně moc. Můj první web jsem dělal nad tdb (trivial database), což je v podstatě jen key value a mělo to knihovnu do Cka. Tuším, že to používá i Samba. Potom zmiňovaný BDB (to je prostě klasika), sqlite se taky prosadilo, "velké sql databáze" se zase nechají snadnou používat z příkazové řádky a na nové věci jako mongo z počátku bohatě stačí jakýkoliv http klient. Komu by se to zdálo moc pomalé tak jsou tady věci jako redis (i když třeba sqlite se taky nechá strčit do paměti, v pythonu to takto používám pro dočasné db).

Já jsem pythoňák, takže jsem dřív používal shelve, jenže potom co jsem několikrát za sebou dostal bsddb.db.DBPageNotFoundError: (-30986, 'BDB0075 DB_PAGE_NOTFOUND: Requested page not found') jsem přešel na sqlite. Nejdřív ručně, pak přes ponyorm a poslední dobou v podstatě jen přes sqlitedict. Nějakou dobu jsem taky používal ZODB, ale poté co se to po několika updatech celé posralo a vytuhávalo na vyžrání všech dostupných file descriptorů jsem to radši zavrhl. Jinak v práci jedeme přes peewee nad postgre.

[Heron]

Osobně by se mi víc líbil ten druhý jmenovaný přístup pro key:val storage s podporou konkurentního přístupu a transakcí.

To moc nevím, jak by mělo fungovat. Dokážu si představit někam naházet soubory (key) s obsahem (value), nebo vytvořit další adresář (aka další "tabulka" nebo kolekce dokumentů) a někde dát echo "commit" > action, ale to už mě rovnou přijde lepší použít nějaký stávající software, který se ochotně nechá ládovat před nativního cli klienta. (Ne že bych preferoval skládání dotazů v bashi a ládování do psql -c, to zavání problémem sql injection.)

Jinak v práci jedeme přes peewee nad postgre.

Koukám, že to má být nějaké další ORM. Já v pythonu používám psycopg2 konektor a vše si řeším sám dotazy přes prepared statement (psycopg snad ani nic jiného neumí).

[Bystroushaak]

Peewee taky používá psycopg2. Občas z toho mám problémy při instalaci balíčků, protože to je Cčková knihovna, která se musí při instalaci přes pip kompilovat.

[Heron]

Jaké je to distro? Já to mám přímo z repa

python-psycopg2/testing,now 2.6.2-1 amd64 [installed]
  Python module for PostgreSQL

python3-psycopg2/testing,now 2.6.2-1 amd64 [installed]
  Python 3 module for PostgreSQL

[Bystroushaak]

Obecně různé, od suse po ubuntu. Většinou proto spoléhám na pip, ale pravda, není to nejjistější, protože to pak stejně chce závislost na python-dev / python-devel balíku z repa distribuce.

[pavlix]

Jenže lidi mají stejně tendence začít dělat „jednoduché“ věci nad filesystémem

Vím o tom, taky to dělám, vyhovuje mi to.

[Josef Kufner]

Souborové systémy narazí vždy tam, kde je třeba řešit atomicitu a konkurentní přístup.

Snad všechny rozumné souborové systémy umí zamykat soubory. Samozřejmě to funguje jen pro celé soubory, což je dáno tím, že souborový systém neřeší obsah souborů. Nevidím nijak velký rozdíl mezi zámkem na řádku/tabulce v databázi a zámkem na souboru.

[kralyk z abclinuxu]

Snad všechny rozumné souborové systémy umí zamykat soubory.

Ano, ale typicky umí pouze advisory locking, resp. mandatory locking není moc prakticky použitelný (v Linuxu vyžaduje specielní mount option + nějaká práva). Krom toho, člověk by kolikrát potřeboval zámek na celé adresáře. No a konečně, zámky nejsou transakce...

[sigma]

Samozřejmě to funguje jen pro celé soubory

Samozřejmě je možné zamykat i jen části souborů definované jako byte-range, pomocí standardního fcntl. Nakonec to uměly snad už Windows 95 včetně fungování přes síť. Třeba FoxPro by se bez toho asi neobešel.

[Josef Kufner]

No vidíš. To o fcntl byla vždy kapitola dokumentace, která se mi nechtěla číst

Výše jsem měl na mysli flock(), který je jen na celý soubor. Pokud bych někde potřeboval používat byte-range zamykání, tak je to docela výrazná indicie, že se na to mám vybodnout a použít už hotovou databázi.

[R]

Cez siet to sice funguje, ale len pokial to pouzivaju tak dvaja-traja ludia. Ak zacne k tym suborom pristupovat viac klientov, je to peklo. Vid Pohoda...

[JS1]

Tak me napada - proc vlastne souborove systemy nepodporuji primo transakce?

Nebo mozna lepe, proc vsechno v operacnim systemu nepodporuje transakce?

[kralyk z abclinuxu]

Na spoustu věcí to je zbytečný overhead...

[JS1]

Me jde hlavne o to, ze by to asi dost usnadnilo zpracovani chyb v aplikacich.. Bylo by garantovano, ze aplikace bude v konzistentnim stavu.

Uz ted mame STM a ano, je to pomale, ale spousta veci to zjednodusuje.

Vlastne by mi ani nevadilo, kdyby se to dalo obejit. Mozna by mely existovat tri urovne (OS, jakysi middleware a aplikace) misto dvou, a ta treti vrstva by byly aplikace, ktere by mely vsechen stav garantovany skrze transakce.

No nic, jen takovy napad kdyby nekdo chtel psat novy OS..

[Heron]

a ta treti vrstva by byly aplikace, ktere by mely vsechen stav garantovany skrze transakce.

Otázkou je: "co by měli garantované?" a s tím související otázka: "co si představujeme pod pojmem transakce?".

Transakce se obvykle definuje jako atomické provedení několika kroků, které se vně dané transakce tváří jako jeden. Buď se provedl kompletně, nebo vůbec.

To je sice hezké jenže to s sebou nese hromadu věcí k řešení. Co se stane v případě, kdy nad stejnými daty má pracovat více procesů? Z naivního pohledu na transakce by měly oba dva začít pracovat nad stejnými daty (každý vidí svou neměnnou "kopii" dat a má právo si připadat, že je v celém vesmíru sám - transakční izolace) a potom... co? Prostě je zapsat na disk a ten proces, který bude pomalejší, nakonec vyhraje? Jeho data budou vidět a toho předchozího procesu ne? To asi není žádoucí stav, protože ten proces co běžel rychleji vlastně nemusel běžet vůbec. Jenže, který z těch dvou (a více) to je?

Toto se běžně řeší pomocí zamykání. Prostě určitá data může mít k zápisu pouze jeden proces. Jenže tohle zase docela úspěšně brání paralelizaci. Takže od doby vzniku zámků se řeší to, jak se jich efektivně zbavit. Ve světě databází jsou to různé MGA, MVCC apod. přístupy (de facto verzování dat). Jenže ani tak všechny zámky nezmizely a tam, kde být musejí, se řeší jejich rozdělení na zamykání menších celků, pokud to jde. Opět, ve světě databází by se mělo počítat s tím, že transakce prostě nedopadne a její změny jsou zahozeny (rollback) - aplikace s tím prostě musí počítat (v praxi s tím reálně počítá málokterá, ale to je na jinou diskusi. Jako mnoho dalších věcí.).

Nevím, jak by toto mělo fungovat napříč celým OS. Asi by to bylo neskonale náročné na prostředky, asi by to moc neškálovalo co do počtu procesorů a disků. Ale možná mám jen slabou fantazii.

Myslím si, že současný stav je dobrý. OS poskytuje určité funkce jak zajistit konzistentnost jednotlivých souborů a vynucení zapsání dat na disk. A kdo potřebuje víc, tak zde má hotové transakční databáze a to v mnoha různých podobách.

[pavlix]

+1

[pepa z depa]

Plan9 neco takoveho dela. Protoze je to distribuovany system, tak to jinak nez transakcemi nejde. To je ale take jeden z tech duvodu, proc se ten system nerozsiril, protoze by se vsechny aplikace musely vlastne prepsat.

[pavlix]

Protože to vyžaduje zamykání nebo rollback? Já mám spíš problém s tím, že se v poslední době tvoří relativně významné aplikace zcela bez ohledu na skutečné vlastnosti systému. Třeba takový TaskWarrior, který klidně zahodí úplně celou databázi úkolů a pak doufá, že se nová verze databáze uloží a uchytí. Nebo takový Docker, který mountuje /etc/resolv.conf, přestože je běžným postupem /etc/resolv.conf nahrazovat, což přímé mountování zablokuje. A to jsou jenom náhodné příklady, na které jsem v poslední době narazil a nepočítám takovéty poplašné zprávy, že filesystém XYZ ztrácí data, když je ve skutečnosti zahodila sama (zpravidla desktopová) aplikace a ještě navíc nechala nová data dlouhodobě nezapsaná.

[deda.jabko]

Tak me napada - proc vlastne souborove systemy nepodporuji primo transakce?

NTFS/Windows to ma. A treba u ZFS nebo BtrFS by to nemuselo mit ani velkou rezii.

Skoda, ze Microsoft zarizil WinFS, to podle me melo docela zajimavy potencial.

[kralyk z abclinuxu]

Tak já asi budu ten hroznej člověk, co napíše, že se nediví, že to zařízli, páč mi to nepřipadá až tak skvělý. Zní to jako úžasná fíčura, ale kolik aplikací by to reálně používalo a kolik by k tomu dál přistupovalo (nebo se o to snažilo) jako ke klasickému FS?

[deda.jabko]

S timhle typem argumentace muzes zavrhnout cokoliv, např.

Počítač?

Zní to jako úžasná fíčura, ale kolik lidí by to reálně používalo a kolik by k tomu dál přistupovalo (nebo se o to snažilo) jako ke klasickému psacímu stroji?

Pricemz realna poptavka i aplikace, ktere by dokazaly vyuzit chytrejsi FS, tu je, hezky priklad je treba Spotlight v macOS.

[pavlix]

Nemyslím si, že by ten argument seděl.

[Heron]

Jestli myslíš xattr, tak to je první věc, která se ztratí při manipulaci se soubory, protože kdejaký nástroj nepodporuje. Navíc to není indexované, takže dotaz typu "najdi mi všechny soubory s atributem X a hodnotou Y", může taky trvat celé odpoledne. To není dobrá databáze.

[Alois]

za socialismu, když někdo vystudoval , tak dostal odpovídající práci

ja bych jen upresnil, ze to nastalo obvykle jen pokud mel spravny tridni puvod, ze mohl vubec vystudovat a pote vstoupil do strany...