abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 14:44 | Komunita

Dalších sedm produktů od společnosti ThinkPenguin získalo certifikaci RYF (Respects Your Freedom, Respektuje vaši svobodu) udělovanou Nadací pro svobodný software (FSF). Poprvé získal certifikaci USB mikrofon, konkrétně TPE-USBMIC. Certifikace RYF byla představena v říjnu 2012.

Ladislav Hagara | Komentářů: 0
dnes 13:33 | Komunita

Na Humble Bundle lze získat počítačovou hru Tacoma (YouTube, Wikipedie) běžící také v Linuxu zdarma. Speciální akce končí v neděli v 18:00.

Ladislav Hagara | Komentářů: 0
dnes 11:11 | Zajímavý projekt

Na Kickstarteru byla spuštěna kampaň na podporu zařízení NexDock 2. Jedná se o přenosnou dokovací stanici aneb notebook bez procesoru a paměti. Stačí připojit podporovaný telefon s Androidem nebo Raspberry Pi.

Ladislav Hagara | Komentářů: 0
dnes 09:55 | Zajímavý článek

Před týdnem byly vydány nové verze 4.2.11.1, 5.0.7.2, 5.1.6.2, 5.2.2.1 a 6.0.0.beta3 frameworku pro vývoj webových aplikací Ruby on Rails (Wikipedie). Opraveny byly 3 bezpečnostní chyby: CVE-2019-5418, CVE-2019-5419 a CVE-2019-5420. Analýza CVE-2019-5418 (zobrazit si lze libovolný soubor na serveru, například /etc/passwd) na blogu Chybeta.

Ladislav Hagara | Komentářů: 1
včera 23:33 | Zajímavý projekt

Na Humble Bundle byla spuštěna akce Humble Book Bundle: Web Programming by O'Reilly. Za 1 dolar a více lze koupit 5 elektronických knih, za 8 dolarů a více lze koupit 11 elektronických knih a za 15 dolarů a více lze koupit 17 elektronických knih věnovaných webovému programování od nakladatelství O'Reilly Media. Část ceny lze určit charitě.

Ladislav Hagara | Komentářů: 0
včera 23:00 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 162. brněnský sraz, který proběhne v pátek 22. března od 18:00 v restauraci Slatinský šenk na adrese Zlínská 12.

Ladislav Hagara | Komentářů: 0
včera 16:22 | Nová verze

Jonathan Thomas oznámil vydání nové verze 2.4.4 video editoru OpenShot (Wikipedie). Přehled novinek na YouTube. Zdrojové kódy OpenShotu jsou k dispozici na GitHubu. Ke stažení je také balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo na spouštění a spustit.

Ladislav Hagara | Komentářů: 0
včera 15:22 | Zajímavý článek

Mozilla.cz informuje, že Firefox bude mít nového správce hesel Lockbox. Lockbox bude integrován s Firefox Monitorem – službou pro varování při únicích dat.

Ladislav Hagara | Komentářů: 0
včera 11:33 | Nová verze

Webový prohlížeč Falkon založený na QtWebEngine (Blink) byl vydán ve verzi 3.1. Podle seznamu změn zlepšuje integraci v rámci KDE, opravuje několik chyb a stabilizuje podporu rozšíření v Python a přidává podporu QML.

Fluttershy, yay! | Komentářů: 2
včera 11:22 | Komunita

Česká Wikipedie je dnes vypnuta. Na protest proti evropské reformě autorského práva.

Ladislav Hagara | Komentářů: 15
Kolik balíčků (v tisících) máte nainstalovaných na svém systému?
 (4%)
 (13%)
 (33%)
 (30%)
 (19%)
 (3%)
 (2%)
 (1%)
 (3%)
Celkem 228 hlasů
 Komentářů: 22, poslední dnes 12:39
Rozcestník
Alternativně viz také můj osobní blog v notionu.

Od určité doby jsou všechny texty které zde publikuji verzované na Githubu.

Jestliže najdete chybu, nepište mi do diskuze a rovnou jí opravte. Github má online editor, není to skoro žádná práce a podstatně mi tím usnadníte život. Taky vás čeká věčná sláva v commit logu :)


Pokud se vám líbilo něco z mé produkce, můžete svou přízeň vyjádřit v kryptoměnách:

  • BTC: 13CS7yKTcqPQUH2hrcuFsqf1AKr4gThZTD

Ne že bych je nějak potřeboval, ale patří to k věcem, které autory obecně potěší a jasně ukazují, že jsou lidi, kteří ty hodiny času stráveného psaním umí ocenit.


Víte že můžete odebírat mé blogy pomocí RSS? (Co je to RSS?)


A kdo neumí použít RSS, tak je tu twitter: @Bystroushaak.
Aktuální zápisy

Programátorova kritika chybějící struktury OS

10.12.2018 01:40 | Přečteno: 5143× | Obecné IT | Výběrový blog | poslední úprava: 11.12.2018 15:24

Před nějakou dobou se mi dostalo do rukou zamyšlení, zdali je vlastně zapotřebí operační systém, či ne. Sám na toto téma provádím jakýsi „průzkum“ už přibližně dva roky. Rozhodl jsem se tedy, že bych mohl sepsat nosné myšlenky spolu s odkazy na některé relevantní zdroje informací.

Buďte varováni

Pozor, tento zápisek obsahuje množství textu. Pokud vás text uráží, zvažte, zda se vůbec chcete pustit do diskuze.

<možné přeskočit>

Předně bych rád deklaroval, že tu mluvím sám o sobě. Když budu psát, že „je něco zapotřebí“, „možné“, nebo „schůdné“, myslím tím „zapotřebí pro mě“, „možné pro mě“, nebo „schůdné pro mě“.

Zažil jsem až příliš diskuzí na internetu, které byly způsobeny čtením mezi řádky a vztahováním čtenářovo názorů a předsudků na osobu autora. Vím, že tohle upozornění pravděpodobně nepomůže, ale zkuste se nad prezentovanými myšlenkami zamyslet s otevřenou myslí.

Pokud vám některé moje nápady přijdou kontroverzní, nesmyslné, či pokud budete mít dokonce pocit, že Vás pobuřují svou donebevolající blbostí - uklidněte se. Vzpomeňte si na výše uvedenou deklaraci. Uvědomte si, že vůbec nemluvím o vás, nemám potřebu a chuť vám něco vnucovat, měnit vám workflow, nebo pomlouvat Váš systém. Berte to jako mojí podivnost, jako možný směr, který to chce vyzkoušet a nevztahujte to o čem tu mluvím na sebe.

Jestliže v článku i poté uvidíte nedostatky a napadne Vás něco konstruktivního k věci, napište to do diskuze. Zkusme to tu pro jednou udržet v konstruktivní rovině.

Poznámka k časovému rozpětí diskuze

Neušlo mé pozornosti, že diskuze pod většinou článků na abclinuxu trvá maximálně několik týdnů, v řídkých případech jednotky měsíců.

Jsem si vědom, že abclinuxu zobrazuje u starších článků upozornění na dlouhou dobu od vydání článku a nepovažuji to za správný nápad. Pokud máte co konstruktivního říct a přečtete si tenhle článek třeba desetiletí po jeho vydání, já jako autor stále stojím o váš názor.

Pokud ho nechcete, či nemůžete vložit do diskuze, pošlete mi ho emailem na bystrousak[]kitakitsune.org, s nějakým smysluplným předmětem. Možná Vás to překvapí, ale napsal jsem docela hodně článků s podobným upozorněním a dodneška diskutuji s lidmi co je četli, i když je to třeba 7 let od vydání. O váš názor stojím.

Osobně ovšem preferuji diskuzi zde pod článkem, neboť z ní mohou těžit i ostatní. Taky to trochu zabraňuje neustálému opakování otázek.

</možné přeskočit>

Proč?

V posledních letech jsem pracoval pro několik firem vytvářejících software. V některých případech jsem se zapojil do již existujících týmů, v ostatních jsem začínal spolu s několika dalšími programátory „na zelené louce“. Často jsem se přímo podílel na návrhu architektury, pokud jsem jí rovnou nevymýšlel sám.

Pracuji jako „backendový programátor“. Mým popisem práce je typicky vytvářet systémy, které načítají, zpracovávají a ukládají různá data, parsují všemožné formáty, volají různé programy, či interagují s ostatními systémy a zařízeními.

V Národní knihovně jsem v tříčlenném týmu dělal na systému pro zpracování elektronických publikací. Vytvořil jsem tam prakticky veškerý backendový kód, od ukládání dat, po komunikaci s ostatními systémy, mezi které patří například Aleph, Kramerius, nebo LTP (dlouhodobý archiv digitálních dat). Pro ukládání byl použit linuxový filesystém ext4 na CentOSu a objektová databáze ZODB vynucená Plonem, ve kterém byla frontendová část. Pro komunikaci pak všechno možné, od volání API přes REST, nahrávání XML souborů na FTP, balení věcí do ZIPu az po kopírování na sambu. Interní komponenty mezi sebou používaly RabbitMQ.

V jisté nejmenované společnosti jsem pracoval na systému k ochraně proti DDoS útokům. Kvůli NDA nemůžu rozebírat podrobnosti nad rámec popisu tehdejších pracovních inzerátů. Ty ukazují, že byl také použit linux, python, SQL i NoSQL databáze, spousta různých existujících opensource programů a na komunikaci RabbitMQ. Na velké části z toho komunikačního kódu jsem dělal přímo já.

Pro Nubium development, vytvářející asi nejznámější český filehostingový web ulož.to, jsem dělal na backendu. Zrefaktoroval jsem a částečně navrhl kusy software, které se starají o ukládání a redistribuci souborů napříč různými servery, ale i o zpracování uživatelských dat. Například ikonky, které se zobrazují u náhledů archivů a videí, jsou moje práce, kromě spousty dalších věcí, které nikde neuvidíte.

Pro pár dalších firem jsem dělal různé weby a RESTové služby. Sáhl jsem si ovšem i na exotičtější věcí, například na systém pro rozpoznání a automatické vyhodnocování záběrů z kamer v různých tunelech a k tomu přidružený machine learning.

Všude kde jsem dělal se používal linux, databáze, a většinou i nějaká forma message queue předávající strukturovaná data. Někdy šlo o SQL tabulky, jindy o JSON poslaný přes RabbitMQ.

V každé z jmenovaných firem jsem viděl ten samý vzor - nezávisle na sobě vytvořený, přibližně podobný kus software, který přirozeně vyplynul z několika požadavků:

Pokud programujete, pravděpodobně víte, kam tím mířím. Jestliže spousta programátorů vytváří nad danou knihovnou stále stejný vzor, nejedná se o chybu programátorů, ale o špatně navrženou knihovnu.

Postupně, jak jsem nad tím tak přemýšlel, jsem dospěl k názoru, že je špatně samotná architektura operačního systému. To co nám nabízí a co umožňuje nepovídá tomu co po něm chceme a co od něj očekáváme. Především z hlediska „programátorského uživatelského interface“, tedy toho, s čím jako programátor pracuji.

Operační systém

Když jsem byl mladší, měl jsem poměrně jasnou představu o tom, co je to operační systém: Windows přece. To je ta věc, co mají všichni na počítači, vlevo dole to má tlačítko start, a když nenaběhne a zobrazí se jen černá obrazovka, je zapotřebí napsat win.

Na střední škole mě naučili definici, podle které je operační systém „programové vybavení počítače zpřístupňující vstupně-výstupní zařízení“.

Později jsem zjistil, že operačních systémů existuje hodně a v podstatě všechny dělají to samé; vytvářejí ± jednotnou abstrakci nad hardwarem počítače, umožňují pouštět různé programy, nabízí více, či méně propracovaný filesystém, spravují paměť, řeší multitasking a uživatelská práva.

V dnešní době je operační systém pro většinu lidí to, čím pouští své prohlížeče, ve kterých koukají na youtuby a na facebooky a taky skrz to posílají emaily. Občas to umí pouštět hry a pracovat se vším možným, od CD-ROMky po klávesnici.

Pro pokročilé uživatele je to pak určitá forma databáze a API, která umožňuje spouštět jejich programy a také nabízí standardizovaný přístup ke konkrétním činnostem. Například výpis znaku, uložení souboru, navázání spojení po internetu a tak podobně.

Většinou máme tendenci vnímat operační systém jako něco neměnného, co si vybereme z relativně malé nabídky diktováné svatou trojicí (Windows, Mac, Linux), okolo které se zmateně krčí několik prakticky nepoužívaných (0.03% celkem) alternativ (*BSD, Plan9, BeOS, ..).

Z nějakého důvodu jsou všechny skutečně používané systémy až na výjimky hodně podobné. Rád bych se zamyslel, jestli je to skutečně žádaná vlastnost, nebo náhodný historický vývoj.

Krátká historie operačních systémů

První počítače neměly operační systém a byly uživatelsky velmi nepříjemné. Daly se programovat pouze přímou změnou hardwarového propojení.

Pak přišly děrnoštítkové a děrnopáskové stroje. Na nich operátor nacvakal sérií přepínačů přímo do paměti binárně „zavaděč“, jenž mu umožnil načíst děrné štítky, či děrný pásek. Ten obsahoval sekvence instrukcí a data.

Systém pracoval v takzvaných dávkách. Programátor dodal médium s dávkou dat, operátor je načetl do počítače a spustil. Po dokončení běhu vrátil programátorovi výsledky, či chybovou hlášku, pokud došlo k chybě.

Jelikož se jednalo o hodně manuální činnosti, časem vznikly knihovny pomocných funkcí a různé užitečné nástroje. Například zavaděč, který se zavede automaticky po startu počítače a umožní načtení programátorova programu pouhým stisknutím patřičného tlačítka. Nebo subrutina, která při pádu programu vypíše obsah paměti. Těmto programům se říkalo monitory.

Protože tehdejší počítače byly velmi, velmi drahé, vznikl tlak na jejich použití vícero uživateli zároveň. S tím přišly první operační systémy, které sloučily funkcionalitu monitoru, přidaly podporu běhu vícero programů zároveň a také nabídly správu a paralelní přístup vícero uživatelů.

Stále komplikovanější hardware a komplexita jeho přímého ovládání způsobila narůstající tlak na univerzálnost kódu mezi různými stroji a jejich verzemi. Operační systémy začaly nabízet podporu typicky používaných zařízení. Nadále již nebylo třeba zadávat adresu paměti na disku, stačilo uložit data do pojmenovaného umístění, a později i do složek. Vznikly první souborové systémy. S podporou vícero uživatelů zároveň vyvstala také snaha oddělit jejich programy, aby si navzájem nemohly přepisovat a číst data. Také vznikly plánovače a virtuální paměť a multitasking.

Operační systémy se staly vrstvou, která stojí mezi uživatelem, jenž nadále nemusí být programátorem, a poskytuje mu standardní způsoby uložení dat, výpisu znaku na obrazovku, práci s klávesnicí, tisku na tiskárnu a spuštění jeho dávky / programu.

Později k tomu přibylo ještě grafické rozhraní a síťování. Osobní počítače nabídly plejádu zařízení, z nichž všechny musel operační systém umět používat a podporovat. Až na pár výjimek, kterým se budu věnovat dále, šlo o iterativní vývoj, který nepřinesl nic zásadně revolučního. Všechno se zlepšovalo, zefektivňovalo, samotné paradigma se však moc nezměnilo.

Kritika operačního systému

Nemám nejmenší problém s konceptem operačního systému jako hardwarové abstrakce. Naopak! Mám problém s konceptem OS jako uživatelského rozhraní. Tím nemyslím grafiku, ale zbytek všeho s čím interagujete, a co má nějaký tvar;

Koncept souborového systému

Schválně se zkuste zamyslet, co to vlastně je. Vyjde vám, že je to omezená hierarchická key-value databáze.

Omezená, protože omezuje nejen velikost a subset klíče, který je v lepším případě v UTF, ale i samotnou uloženou hodnotu na proud bajtů. To se zdá rozumné jen do chvíle, kdy si uvědomíte, že je to stromová databáze, která vám nedovoluje přímo ukládat strukturovaná data. Počet inodů (větví struktury) je navíc omezen na číslo, jenž se v horších případech pohybuje v řádu desítek až stovek tisíc, maximálně však pár milionů prvků v jednom adresáři.

Ve dvou z mých předchozích zaměstnáních jsme museli obcházet omezený počet inodů na složku retardací jako BalancedDiscStorage, či ukládáním souborů do tří podsložek složených z prvních tří písmen MD5 hashe souboru.

K tomu pro většinu operací chybí atomicita, a transakce nejsou podporovány vůbec. Paralelní zápisy a čtení fungují v různých operačních systémech různě, a ve skutečnosti není garantováno naprosto nic. Schválně si to srovnejte se světem databází, kde se ACID považuje za samozřejmost.

Filesystém je specificky omezená databáze. Každý koho znám, kdo se kdy pokusil filesystém použít pro cokoliv netriviálního, dřív nebo později tvrdě narazil. Ať už je to programátor, který si řekne, že si ty data prostě a jednoduše bude ukládat do souborů, nebo uživatel, který se v bordelu na filesystému nemůže vyznat a musí používat různé divné vyhledávání a indexování. Výkřikem techniky je, když dokáže poznat, že má poškozená data a dopočítat je zpětně ze samo-opravných kódů, pokud máte disky v RAIDu.

Samozřejmě chápu, že pointou je něco jiného. Řeší se tu sektory na disku a žurnálování, plotny a oddíly a RAIDy a celé je to super pokrok oproti původním primitivním systémům ukládání dat. Ale — není to náhodou pokrok špatným směrem?

Původní filesystémy byly metafora. Metafora pro ukládání souborů do složek, tak jako se strkají papíry do šanonů a šuplíků. Kromě mnoha technických omezení, daných stavem tehdejší výpočetní techniky, trpěly a trpí i omezením z podstaty této metafory. Přemýšlím, jestli by jsme si místo otázky „jak trochu vylepšit padesát let starou metaforu“ (třeba pomocí tagů) neměli klást spíš otázku „je to vážně ta správná metafora pro ukládání dat?“

Programy

Čistě fyzicky, programy jako takové nejsou nic jiného, než jen sekvence uložených bajtů. V podstatě ani pro operační systém nemůžou být nic jiného, neboť souborová databáze operačního systému s ničím jiným pracovat ani neumí.

Programy se prvně napíšou ve zdrojovém kódu příslušného jazyka, který se potom zkompiluje a slinkuje do jednoho bloku. Ten je následně vyděrován na děrné štítky (binární data) a zastrčen do patřičné krabice (souboru) ve správné sekci kartotéky (filesystému).

Když chce uživatel program pustit, napíše jeho jméno na příkazovém řádku, nebo někde klepne na ikonu. Poskládané děrné štítky jsou následně vyndány z kartotéky a nacpány do paměti, která se pro program tváří, jako kdyby byl v celém operačním systému sám. Kód je poté prováděn od počátečních děrných štítků k těm koncovým, s tím že program může podmíněně přeskočit na konkrétní děrný štítek v krabici, která ho tvoří.

Programy taky můžou číst parametry příkazového řádku, používat sdílené knihovny, volat API operačního systému, pracovat s filesystémem, posílat (číselné) signály různým jiným programům, reagovat na ně, vracet návratové hodnoty, nebo otevírat sockety.

Co je na tom špatně?

Nechci říct, že je koncept špatný jako takový. ALE. Opět je to stejná stará metafora, iterativním vývojem posunutá o pár kroků dál. Všechno mi přijde hrozně nízkoúrovňové. Celý ten systém se za posledních 40 let změnil jen minimálně a nemůžu se zbavit myšlenky, že než že by jsme dorazili k naprosté dokonalosti, spíš jsme někde uvázli v zákrutě lokálního maxima.

Lispovské stroje, Smalltalkovské a Selfové prostředí mě naučily, že se to dá dělat i jinak. Že programy nutně nemusí být kolekce bajtů, ale můžou to být malé samostatné objekty, které jsou (metaforou posílání zpráv) zavolatelné z ostatních částí systému, a které se dynamicky kompilují podle potřeby.

Znáte takovou tu unixovou filosofii, že je dobré používat malé programy, které dělají jednu věc, na tu se zaměřují a dělají jí dobře? Proč tu myšlenku nedotáhnout do konce a neudělat malé programy z každé funkce a metody vašeho programu? Ta by naoplátku mohla komunikovat s metodami a funkcemi ostatních programů.

Ve Smalltalku to tak funguje, dokonce není problém to verzovat, specifikovat závislosti, mít nad tím package manager, ošetření chyb, nápovědu a kdo ví co dalšího. Vážně by to nešlo dělat s programy obecně?

Data bez struktury, nazývaná soubory

The whole UNIX ethos has been a huge drag on industry progress. UNIX's pitch is essentially: how about a system of small functions each doing discrete individual things... but functions must all have the signature char function(const char )? Structured data is for fools, we'll just reductively do everything as text. What we had in 1972 is fine. Let's stick with that.

(Zdroj: http://www.righto.com/2017/10/the-xerox-alto-smalltalk-and-rewriting.html?showComment=1508781022450#c7613952874348706529)

A jsme zase u těch binárních dat. Na první pohled geniální myšlenka, protože nic nemůže být víc univerzální. Na další pohled už tak ne.

V čem je problém?

Prakticky všechna data mají svou strukturu. Kdykoliv, kdy programátoři v programovacím jazyku pracují s daty, a nejedná se jen o jejich přesunutí, tak se jim snaží dát strukturu. Namapují je na různé struct konstrukty. Vytvoří z nich strom objektů. I u streamovaných věcí, jako je třeba záznam zvuku ve formátu WAV, se iteruje skrz jednotlivé chunky.


(Struktura WAV souboru. Zdroj: https://github.com/corkami/pics/.)

Proč tedy proboha každý program vezme data, dá jim strukturu, něco nad ní udělá a tu strukturu zahodí a zkolabuje zpět na nestrukturovaná, surová binární data?

Současná počítačová kultura je posedlá parsery a externími popisy dat, jenž by však mohly nést strukturu samy o sobě. Každý den jsou nesmírná kvanta výpočetních cyklů zcela nesmyslně plýtvána na konverzi surových bajtů na struktury a zase zpět. A každý program to dělá jinak, dokonce i v různých verzích. Nemalá část mé práce jako programátora je jen o parsování a převodech dat, jenž kdyby měla strukturu, tak by byla upravitelná jednoduchou transformací. Tady vem kus stromu a přesuň ho sem. K téhle části grafu přidej tohle, jinde něco uber.

Současná situace je analogická k situaci, kde kdybych posílal poštou hrad z lega, tak bych ho rozložil na jednotlivé kostky a k balíku přibalil referenci na návod, jak si hrad složit. Příjemce by si pak návod musel někde sehnat a hrad pracně skládat. Absurdita je zřejmější, když si uvědomíme, že se to netýká jen kostek lega, ale úplně všeho. I kdybych chtěl někomu podat sklenici, tak bych jí podal jako hrst písku a příjemce by si musel sklenici vyrobit sám. Je mi jasné, že na konci se vždy musí posílat bajty, stejně jako se musí posílat kostky lega. Ale proč je neposlat už složené?

Nejde jen o nesmyslnost toho všeho. Jde o to, že zároveň s tím je to i horší. Horší pro uživatele, a horší pro programátory. Data se kterými pracujete by mohla být sebe-popisná, ale nejsou. Jednotlivé položky by mohly obsahovat datové typy, ale i dokumentaci. A nemají. Proč? Protože je v módě mít zvlášť hromadu binárních dat, a zvlášť jejich externí popis. Vážně to tak chceme, vážně to má nějaké výhody?

V minulém desetiletí bylo možné vidět masivní nárůst používání formátů jako XML, JSON a YAML. Určitě lepší než drátem do oka, ale to stále není to o čem tu mluvím. Nejde mi o konkrétní formát, jde mi o strukturu samotnou. Proč nemít strukturovaně všechna data?

Nemluvím tady o parsování XML parserem, mluvím tu o přímém načtení do paměti, ve stylu message packu, SBE, nebo FlatBuffers, či Cap’n Proto. Bez toho aniž by bylo třeba vyhodnocovat text a řešit escape sekvence a formát unicode. O tom že na strukturovaná data o Frantovi Putšálkovi v kolekci lidí přistoupím pomocí people[0].name, místo toho abych v jednom formátu dělal doc.getElementByTagName("person")[0].name.value a v druhém doc["people"][0]["name"]. O tom že si můžu k atributu přečíst nápovědu pouhým help(people), místo abych hledal dokumentaci.

Mluvím tu o tom že se neparsuji s WAVem, ale prostě iteruji přes jednotlivé chunky, které tam jsou. O tom že data popisují sebe sama přímo svou strukturou, ne externím popisem. Mluvím o přímé serializaci objektů, o jednotném systému podporovaném všemi jazyky, i když nemají objekty.

Váž ně by to bylo tak nemožné? Proč?

Strukturovaná komunikace

Všímáte si toho vzoru v mé kritice, hněvu a vášni? Je jím téma neuvědomělé struktury.

Souborové systémy nevnímáme jako databáze. Nedochází nám, že jejich struktura jsou hierarchická key-value data. Programy bereme jako binární bloby, místo klubka propojených funkcí a struktur a objektů majících potřebu komunikovat se sebou, ale i s okolním světem. Data chápeme jako mrtvé série surových bajtů, místo stromových a grafových struktur.

Co dalšího má strukturu, o čem jsem zatím nepsal? Samozřejmě komunikace. S operačním systémem. S programy. Mezi programy.

/sys

Plan9 byl úžasným krokem tímhle směrem. Poté co jsem ho prozkoumal jsem však dospěl k názoru, že tvůrci sice měli obecné povědomí o tom co dělají, ale nedošlo jim to v celé úplnosti. Možná částečně proto, že byli stále hodně ovlivněni unixem a komunikací v proudech bajtů.

Na Plan9 je úžasné, jak můžete interagovat se systémem pomocí zápisu a čtení z různých speciálních souborů. Fantastické! Revoluční! Tak úžasné, že to linux převzal například v podobě /sys subsystému a FUSE.

Víte co tomu chybí? Reflexe a struktura. Pokud si nepřečtete manuál, tak naprosto netušíte co kam zapsat.

Zde je kód pro blikání diodou na raspberry pi:

echo 27 > /sys/class/gpio/export
echo out > /sys/class/gpio/export/gpio27/direction
echo 1 > /sys/class/gpio/export/gpio27/value

Jak jsou řešeny chyby? Co když do /sys/class/gpio/export/gpio27/value zapíšu string „vánočka“? Dostanu zpět error kód z echa? Nebo se v nějakém jiném souboru něco objeví? Jak jsou zvládány paralelní zápisy? A co čtení, kde je popsáno co můžu dostat za hodnoty, když do /sys/class/gpio/export/gpio27/direction zapíšu „in“ místo „out“?

Prostě jak si to který modul udělá, tak to bude. Datové typy se neřeší. Pojďme postavit komunikaci se systémem na databázi, která si neuvědomuje že je databáze!

Tohle je asi největší neuvědomělá snaha o zavedení čehosi jako objektů, jakou jsem kdy viděl. Ta struktura jsou objekty. Jen ten rozdíl mezi sys.class.gpio.diode a složkou na podobném umístění je že složka je nepopsaná key-value položka, podobně jako JSON, která nemá jasně dané properties, formát dat, nápovědu, nebo třeba formát a způsob vyvolávání výjimek.

Sockety

Já chápu, proč vznikly. Vážně. Ve své době to bylo naprosto racionální a nebylo nic lepšího. Ale proč proboha používat nestrukturovaný formát přenosu binárních dat i dneska, když veškerá komunikace je strukturovaná, což platí i pro zdánlivé proudy bajtů, jako streamované audio.

Vemte si, jak to vypadá, když píšete IRC bota. Navážete spojení. Super. Samozřejmě použijete select, aby jste nevytěžovali procesor. Data čtete v blocích, například 4096 bajtů. V paměti je převádíte na stringy a hledáte v nich nové „\r\n“. Musíte bufferovat a zpracovávat řádky vždy až když dorazí celé. Pak parsujete textovou strukturu a skládáte z ní zprávy o jednom řádku. A různé zprávy mají různé formáty a je třeba je parsovat různě. Hrozná zábava s reimplementací specifikace po milionté jinak. Přitom zprávy by mohly mít strukturu samy o sobě, stejnou jako zbytek všeho ostatního.

Nebo třeba HTTP. To přece přenáší strukturovaná HTML data, ne? Máte jasně daný jazyk a jeho popis a způsob parsování. Super! Co víc si přát. Myslíte ale, že HTTP používá na úrovni přenosového protokolu jako datový formát (HT/X)ML? Ani náhodou, samozřejmě, že si specifikuje vlastní protokol, který vypadá úplně jinak (key-value data hlaviček a pak způsob posílání chunků dat).

Email? Ani mě nenechte začít na téma zkaženosti emailu, jeho protokolu a formátu, kde se nejasně definovaná struktura v asi pěti standardech mísí mezi sebou a každý výrobce si to implementuje po svém. Pokud jste někdy zkoušeli zpracovávat emailové hlavičky z nějaké konference, tak určitě víte. Pokud ne, zkuste si to. Garantuji, že vám to změní pohled na svět.

A tak je to se vším. Skoro nikdy nepotřebujete proud bajtů, ale posílat zprávy, které jsou prakticky vždy hierarchie key-val dat, nebo pole. Proč tedy skoro 50 let po vynálezu socketu stále přenášíme data ve streamech a neustále si vymýšlíme vlastní textové protokoly? Není čas na něco lepšího?

Vytvoříme strukturu tady, pak jí serializujeme na surové bajty, nacpeme do socketu a pošleme systému, který musí provést deserializaci a rekonstrukci na základě externího popisu dat, který je s trochou štěstí podobný tomu našemu. Proč? Proč neposílat rovnou struktury?

ZeroMQ byla podle mého názoru krok správným směrem, ale zatím mi přijde, že se nedočkala moc vřelého přijetí.

Parametry příkazové řádky

Máte program na disku, který něco dělá. Když vynechám kliknutí a následné „ruční“ zadání dat, tak argumenty příkazové řádky jsou jeden z nejčastějších způsobů, jak programu říct, co po něm chcete. A každý druhý program si je parsuje vlastním způsobem.

Reálně neexistuje žádný standard formátu argumentů na příkazové řádce. Některé programy používají --param. Jiné -param. Další jen param. Někdy se seznamy oddělují mezerami, jindy čárkami. Už jsem dokonce zažil i JSON parametry mixované s těmi normálními.

Pokud program voláte z nějakého příkazového řádku, tak se vám do toho navíc mixuje jeho scriptovací jazyk a jeho způsob definice stringů, proměnných a bůh ví čeho dalšího (z hlavy mě napadají escape sekvence, jména funkcí, eval sekvence, wildcards znaky, -- pro ukončení wildcardů a tak podobně). Celé je to jeden velký, gigantický bordel, který si každý patlá a parsuje, jak se mu zrovna chce.

A co volání ostatních programů z jiných programů? Ani nechci vzpomínat, kolikrát jsem viděl, či psal kód ve stylu:

import subprocess

sp = subprocess.Popen(
  ['7z', 'a', 'Test.7z', 'Test', '-mx9'],
  stderr=subprocess.STDOUT,
  stdout=subprocess.PIPE
)
stdout, stderr = sp.communicate()

Naposledy nedávno, i s celou plejádou parsování free-form výstupu. A už mě to vážně nebaví.

Pokud jsou argumenty složitější, stane se z toho rychle onanie skládání stringů, kde si navíc nemůžete být jisti bezpečností, nemáte garanci podporované znakové sady, musíte sanitizovat uživatelský vstup a volané podprogramy navíc stále můžou vykazovat chování, které je všechno, jen ne triviální. Například vám zatuhne buffer při větším výstupu. Nebo program reaguje jinak v neinteraktivním režimu, než v interaktivním a není žádný způsob, jak ho přesvědčit o opaku. Případně vám cpe escape sekvence a tty formátování, kam by jste nechtěli. A jak asi přenesete strukturovaná data tam a zpět?

Přitom parametry příkazové řádky jsou většinou nějakým seznamem, nebo slovníkem s vnořenými strukturami. Chce to jednotný a na zápis jednoduchý jazyk. Něco lehčího na zápis, než JSON, ale zároveň víc expresivního.

Úplně pak vynechávám, že nutnost parametrů příkazové řádky se úplně vytratí, když můžete posílat programu strukturované zprávy podobně jako volat funkci v programovacím jazyku. Vždyť nejde o nic jiného, než o zavolání patřičné funkce / metody s konkrétními parametry, tak proč to dělat takhle divně a nepřímo?

Env proměnné

Env proměnné jsou slovník. Doslova se tak mapují a chovají. Jenže díky chybějící struktuře jsou jen jednorozměrným slovníkem s klíči a hodnotami v podobě stringů. V D by se zapsaly jako string[string] env;. To často nestačí, protože potřebujete přenést vnořené struktury.

Má duše křičí, terorizována hláškami jako „potřebuješ předat složitější data do env proměnné? tak tam zapiš JSON, nebo odkaz na soubor!“ Proč proboha jako civilizace nezvládneme jednotný způsob předávání a ukládání dat, že musíme míchat syntaxi env proměnných v bashi s JSONem?

Konfigurační soubory

Ať už si to uvědomujete, nebo ne, prakticky každý netriviální program ve vašem počítači potřebuje nějakou konfiguraci. Tu si zpravidla bere z konfiguračního souboru. Víte, kde je ten soubor umístěný? V Linuxu bývá standardem je umisťovat do /etc, ale klidně můžou být taky ve vašem $HOME, nebo v $HOME/.config, nebo v libovolné podsložce (třeba $HOME/.thunderbird/).

A co formát? Hádáte správně. Může být libovolný; (pseudo)INI, XML, JSON, YAML. Nebo Lua. Nebo taky hybrid vlastního programovacího jazyka (viz postfix). Co koho zrovna napadne, to se používá.

Existuje vtip, že komplexita každého konfiguračního souborů s časem roste, dokud v něm někdo vytvoří špatně implementovanou půlku lispu. Mým oblíbeným příkladem je Ansible a jeho nedotažená, nekompletní parodie na programovací jazyk postavený nad YAMLem.

Chápu, kde se to bere. Taky jsem touhle cestou šel. Proč to ale nemůže být standardizované a stejné napříč celým systémem? Ideálně ten samý datový formát, který je zároveň jazykem, napříč vším. Proč nemůžou být konfigurací samotné objekty uložené v patřičném umístění?

Logy

U logování je typicky nutno řešit následující problémy:

  1. Strukturované logování. Ukládání ve formátu, jenž je možné následně zpracovávat, provádět nad ním dotazy a tak podobně.
  2. Paralelní přístup, aby mohlo logovat vícero aplikací do jednoho logu a jednotlivé záznamy se „nekřížily“.
  3. Rotování logů. Staré logy se postupně přejmenovávávají, jsou komprimovány a po čase úplně smazány.
  4. Způsob logování. Aplikace musí logy nějak dopravit do cílového úložiště.

Současná řešení jsou opět typicky zcela různá, tak jak koho zrovna co napadlo:

  1. Struktura logů je nahodilá. Prakticky všichni používají nějaký více/méně parsovatelný formát, ale jeho tvar je často různý. Málokdy je definováno například jak jsou uloženy a „escapovány“ víceřádkové logy. Parsování probíhá ve velké části přes regexpy a prakticky vždy je křehké a rozbitelné. S určitou pýchou vždy ukazuji kolegům že jejich logy dokážu rozbít obejitím jejich regexpu a snažím se je přesvědčit o použití něčeho nerozbitného.
  2. Paralelní logování je řešeno separátní logovací aplikací. Filesystém, na rozdíl od většiny ostatních databází, neumí atomický přístup, ani nic jako triggery, takže pokud tahle aplikace spadne, je po lozích.
  3. Rotování je také řešeno externí aplikací, a prakticky vždycky se jedná o záležitost periodicky pouštěnou cronem. Ještě jsem neviděl chytré logování, které by zvládlo odrotovat log, když hrozí, že na disku kvůli němu nezbude místo, zato jsem viděl pár služeb v produkci, jenž to položilo. Další problém je, že aplikace typicky mají otevřený soubor s logem a pokud je jim „odrotován“ pod rukama, tak se to celé rozbije. Řeší se to naprosto ne-elegantně posíláním signálů, na které musí umět asynchronně reagovat. Nedávno jsem se hrozně vysmál, když kolega chtěl logovat jen na stdout a tak změnil cestu k souborovému logu na /dev/null. Celé to krásně fungovalo jen do té doby, než se pythonní RotatingFileHandler rozhodl soubor odrotovat a celá aplikace spadla.
  4. Co se způsobu týče, tak některé aplikace prostě otevřou soubor a logují do něj. Jiné posílají data na UDP (syslog). Další zas posílají zprávy v JSONu do Sentry. Co koho napadne a co je zrovna populární, tak to bude.

Logování mi přijde jako krásná ukázka programátorské struktury, kterou je nucen řešit prakticky každý a kterou operační systém v celé komplexitě podporuje skoro vůbec, nebo jen málo. Je to také krásná ukázka konceptu, který by si zasloužil převést na posílání strukturovaných zpráv;

Zprávy jsou objeky. Mají své datum odeslání, mají krátký text a většinou i dlouhý text a také „úroveň“ (v pythonu typicky DEBUG, INFO, WARNING, ERROR). Pokud s logy pracujete, skoro nikdy nechcete pracovat na úrovni textu. Chcete například omezit datum - jak to uděláte, když se jedná o text? Nebo úroveň - pokud chcete všechny zprávy úrovně ERROR, nechcete to grepovat textově, protože slovo „ERROR“ může být použito i v tělě zprávy v různých kontextech. Například „NO_ERROR“.

Aplikace, do které se loguje by měla přijímat zprávy, které bude uchovávat v datové struktuře fronta. Tím by nikdy nemohlo dojít místo na disku. Starší struktury by bylo možné automaticky komprimovat, ale pro uživatele by to mělo být transparentní - pokud chce vyhledávat nad komprimovanými zprávami, ani by o tom neměl vědět.

Nemělo by existovat padesát způsobů logování - pro uživatele by to měla být záležitost instancování systémového loggeru a jeho následné používání, po krátké konfiguraci, kde si zvolí politiku rotace. Pak už jen loguje standardním posláním zprávy, ať už lokálně, nebo vzdáleně z internetu.

Ukázková studie: Docker

Docker je virtualizační nástroj umožňující vám sestavovat, spravovat a spouštět kontejnery virtuálních počítačů, ve kterých je specifické programové vybavení.

Osobně mám Docker docela rád a občas ho používám k sestavování balíčků pro cílové distribuce (například .deb pro Debian a .rpm pro RHEL).

Parametrů Dockeru je nepřeberně: https://docs.docker.com/engine/reference/run/. Mojí oblíbenou částí jsou volumes, tedy složky, jenž jsou mountovány dovnitř kontejneru z vnějšího hosta.

Syntaxe je přibližně -v local_path:/docs:rw. Jako dobrá ukázka mi to přijde, protože se do jednoho parametru cpou tři různé hodnoty: cesta v počítači na kterém příkaz pouštíte (která navíc musí být absolutní!), cesta uvnitř kontejneru a práva k zápisu.

K naprosté dokonalosti to bylo dovedeno novým parametrem --mount, který dělá to samé, ale zavádí pro to úplně novou syntaxi, jenž přináší úplně jiná pravidla parsování:

--mount source=local_path,target=/docs

Komplexnější ukázka může vypadat například takto:

--mount 'type=volume,src=<VOLUME-NAME>,dst=<CONTAINER-PATH>,volume-driver=local,volume-opt=type=nfs,volume-opt=device=<nfs-server>:<nfs-path>,"volume-opt=o=addr=<nfs-address>,vers=4,soft,timeo=180,bg,tcp,rw"'

a zahrnuje ukázky escapování CSV parseru (!).

Z hodnot oddělených dvojtečkami se stává úplně nový formát hodnot oddělených čárkami, definující key-value hodnoty pomocí rovnítka (=), ale zároveň hodnoty jako list, protože místy tam žádné rovnítko není, a je možné používat uvozovky a celkově .. co to sakra je?

To ani nemluvím o tom jak se různě chování mění, podle toho co zrovna použijete, protože to není předmětem diskuze.

Pointou je, že místo aby se jednalo o nějak jasně definovaný objekt, kterému můžete poslat zprávu, tak je to systém hned několika konvencí skládání stringů na příkazové řádce, který je peklo snažit se nějak obalit do vašeho programu, protože se chová nekonzistentně a nepředvídatelně.

A to není všechno, pořád je tady ještě Dockerfile, protože to je samozřejmě další se vším ostatním nekompatibilní formát bez debuggeru a jasné vize a logiky.

Dockerfile

Původní myšlenka Dockerfile byla hádám podobná, jako u makefile. Pustíme na to docker a on provede jednotlivé direktivy krok za krokem a sestaví nám „projekt“.

Původní idea byla jednoduchá - prostě soubor KEY value definic, které se budou postupně vykonávat. Může to vypadat například takto:

FROM microsoft/nanoserver
COPY testfile.txt c:\\
RUN dir c:\

FROM určuje co se má použít za původní kontejner, ze kterého se bude vycházet, COPY zkopíruje soubor z počítače, na kterém je kontejner sestavován a RUN provede nějaký příkaz.

Každý kdo zná Greenspunovo desáté pravidlo asi tuší, jak se to vyvíjelo dál. Přišla definice ENV proměnných a jejich nahrazování pomocí šablonování. Definice escape znaků, .dockerignore soubor. Příkazy jako třeba CMD získaly alternativní syntaxi, takže to nemusí být jen CMD program parametr, ale i CMD ["program", "parametr"].

Věci jako LABEL umožnily definovat další key=value struktury. Samozřejmě, SAMOZŘEJMĚ, že někdo potřeboval podmíněný build, tak vznikly hacky jak ho obejít přes templatování a nastavování key value hodnot z vnějšku: https://stackoverflow.com/questions/37057468/conditional-env-in-dockerfile

Je jen otázkou času, než tam někdo přidá plnohodnotné podmínky a funkce a udělá z toho svůj vlastní zprasený programovací jazyk. Bez debuggeru, bez profileru, bez pěkných tracebacků.

Proč? Protože neexistuje žádný standard a operační systém neposkytuje nic po čem by se dalo sáhnout. Fragmentace tak pokračuje.

Ukázková studie: OpenShift

Nedávno jsem v práci byl nucený pracovat s OpenShiftem. Musím říct, že se mi docela líbil a myslím si, že má zářnou budoucnost. Umožňuje vytvářet pěknou hardwarovou abstrakci nad clustery počítačů, provádět relativně bezbolestný deployment aplikací na vlastním firemním cloudu.

Přesto jsem během procesu portování několika balíčků ze starého RHEL 6 formátu, který běžel na fyzických serverech do nového RHEL 7 spec formátu, který má běžet uvnitř OpenShiftu neustále kroutil hlavou ohledně specifik nastavování a konfiguraci.

Abyste tomu rozuměli, tvůrci OpenShiftu ho umožňují konfigurovat přes webové rozhraní prostě jen klikáním. K tomu navíc nabízejí REST API a také utilitu příkazové řádky oc, kterou je možné provádět to samé co z ostatních dvou rozhraní.

Kroutil jsem hlavou, protože jak v případě Webu, REST API či oc se jedná o konfiguraci nahráváním a upravováním objektů popsaných pomocí YAMLu či JSONu (formáty je možné zaměňovat).

Tyto objekty je možné definovat v takzvané template, která funguje jako svého druhu Makefile, postupně vykonává jednotlivé bloky a na konci by měl být výsledkem běžící systém. V rámci template je možné používat šablonovací systém, který umožňuje definovat a expandovat proměnné.

Tohle všechno je postavené nad YAMLem, což je poněkud méně ukecaný bratr JSONu. Ukázka template může vypadat například takto:

apiVersion: v1
kind: Template
metadata:
  name: redis-template
  annotations:
    description: "Description"
    iconClass: "icon-redis"
    tags: "database,nosql"
objects:
- apiVersion: v1
  kind: Pod
  metadata:
    name: redis-master
  spec:
    containers:
    - env:
      - name: REDIS_PASSWORD
        value: ${REDIS_PASSWORD}
      image: dockerfile/redis
      name: master
      ports:
      - containerPort: 6379
        protocol: TCP
parameters:
- description: Password used for Redis authentication
  from: '[A-Z0-9]{8}'
  generate: expression
  name: REDIS_PASSWORD
labels:
  redis: master

Expanze proměnných probíhají zvenčí přes parametry příkazové řádky.

Dosud dobré. Jenže jak by se dalo tušit, mám k tomu spoustu výhrad:

Naprosto zde chybějí podmínky. Aby člověk mohl například podmíněně vykonat nějakou část kódu, musí použít šablonovací systém (Jinja2 třeba) nad tímhle šablonovacím systémem.

Chybí tam taky samozřejmě definice funkcí (často opakovaných bloků) a cyklů. Kdyby se jednalo o cokoliv jiného, tak bych to asi odpustil, ale představte si úplně ukázkové použití. U nás ve firmě používáme pro každou jazykovou mutaci našeho produktu čtyři prostředí: dev, test, stage a prod. Prvně si vývojáři testují nasazení na devu, potom testeři na testu, businnesáci poté na stage a zákazníci nakonec používají prostředí na produ.

Když nasadím novou verzi programu, musí postupně projít přes všechny tyto prostředí. Tudíž by bylo dobré mít nějakou možnost například provést spuštění virtuálního stroje v rámci OpenShiftu tak, že prostě řeknu „pusť toto čtyřikrát“. Jenže OpenShift samozřejmě nic takového neumí a je třeba to dělat manuálně. To začne být velmi rychle velmi velký opruz, protože prostředí se od sebe moc nelíší, kromě trochy konfigurace, která je to jediné co by bylo třeba dynamicky upravit.

Vzpomínáte si, že jsem původně psal o různých jazykových mutacích? Protože to jsou čtyři instance per jazyk a jazykové mutace máme momentálně taky čtyři, což dává dohromady šesnáct instancí. A to máme projekty, kde je to deset instancí per vývojové prostředí, per jazyk. Tedy dohromady musí běžet 160 instancí.

Je asi jasné, že tohle nejde a tak jsme byli nuceni si nad tím postavit vlastní správu v podobě python scriptů a shellscriptů a ansible. Nemám z toho radost. A to jsem se nakonec rozhodl nepitvat, že OpenShift používá docker a je v něm nutné zároveň s jeho YAML formátem řešit i Dockerfile formát a argumenty příkazové řádky.

To vše proto, že neexistuje jednotný široce přijímaný formát konfiguračního jazyka, který by byl zároveň jazykem scriptovacím. Něco jako lisp.

Ukázková studie: Ansible

Ansiblééé je krásnou ukázkou jak to dopadne, když se někdo jen tak ad-hoc pokusí podobný jazyk uvařit, aniž by nad tím nějak moc přemýšlel, nebo měl za sebou teorii programovacích jazyků.

Původně začal jako deklarační konfigurační jazyk, který popisoval co se má jak dělat, založený na JSONu.

Zde je například ukázka deklarace instalace nginxu:

- name: Install nginx
  hosts: host.name.ip
  become: true
  tasks:
  - name: Add epel-release repo
    yum:
      name: epel-release
      state: present
  - name: Install nginx
    yum:
      name: nginx
      state: present
  - name: Insert Index Page
    template:
      src: index.html
      dest: /usr/share/nginx/html/index.html
  - name: Start NGiNX
    service:
      name: nginx
      state: started

Celé je to poměrně jednoduše čitelná YAML key-value struktura. Samozřejmě, SAMOZŘEJMĚ že nemohlo zůstat jen u tohohle a tak někoho napadlo přidat podmínky a cykly. Samozřejmě jako YAML:

Samozřejmě, že tím vznikl programovací jazyk bez jakékoliv konzistence, vnitřní logiky a smyslu. Jazyk který byl nucený jít dál a dál a nadefinovat si bloky a výjimky a ošetřování chyb a funkce a to celé postavené nad YAMLem. To celé bez debuggeru, IDE, toolingu, smysluplnných stacktrace a s naprostou ignorací šedesáti let vývoje uživatelského rozhraní programovacích jazyků.

tasks:
    - command: echo {{ item }}
      loop: [ 0, 2, 4, 6, 8, 10 ]
      when: item > 5

Ten tenký vysoký zvuk znějící jako pištění na vysoké frekvenci, jenž můžete slyšet v dokonalém tichu třeba chvíli před spaním jsou andělé řvoucí frustrací. Je to řev mojí duše nad vší lidskou demencí, která se vrší a vrší nad sebe.

Nemůžeme se prostě domluvit nad něčím co by pro jednou dávalo smysl?

Obecný princip

Co takhle vzít všude tam, kde se dneska používá nějaký podivný stringový formát, ať už je to předávání parametrů programům, nebo komunikace mezi nimi, a nahradit to nějakým úsporným, jednoduše zapisovatelným jazykem pro definici struktur? Jazykem, který by byl zároveň popisným formátem, jenž by chápal datové typy jako dict, list, int a string a delegaci (dědičnost). Tak aby pro člověka i program odpadla většina parsování a dohad nad strukturou, a druhý jmenovaný je dostal už rovnou ve svém nativním formátu.

Tolik tedy ke kritice. Pojďme se podívat na nápady, jak se posunout někam dál.

Ohledně objektů

Když mluvím o objektech, nemám na mysli co znáte z programovacích jazyků jako třeba C++, nebo Java. Spousta lidí na to má poslední dobou alergii.

Myslím tím obecný koncept grupování funkcí s daty, nad kterými operují. K tomu není třeba class based přístup (= nemusíte psát třídy). Není k tomu třeba ani dědičnost, i když nějaká forma delegace se hodí.

GPIO podsložka filesystému /sys obsahující kontrolní soubor, jenž udává směr zápisu dat na LED diodu, a datový soubor, kterým data můžete zapsat či číst, je objekt. Má metodu (ovládací soubor) i data, nad kterými se operuje. Samozřejmě, že ideálně by bylo možné podobný objekt i kopírovat a instancovat standardním způsobem, předávat ho dalším objektům a metodám a provádět jeho introspekci. Ale i tak je to primitivní objektový systém, kde objektem je složka, daty jsou soubory, a metodami kontrolní soubory a operace nad nimi.

Samotné objekty jsou na nejnižší úrovni key-value data. Klíč způsobí provedení kódu v případě že jde o jméno metody, nebo vrácení dat, v případě že jsou v něm uloženy data. Rozdíl mezi objekty a key-value záznamem v databázi je poměrně minimální, a spočívá především v možnosti uložit kód, a také v delegaci, kde když se nenajde daný klíč v potomkovi, tak se přesune hledání do konkrétního rodiče.

Pokud tedy mluvím o objektech, mám na mysli obecné key-value struktury umožňující delegaci, referencování dalších (objektových) key-value struktur, reflexi a ideálně i nějakou formu homoikonicity.

Záměrně nemám na mysli konkrétní jazyk, ale zcela a vůbec nemám na mysli imperativní, objektově orientované a na strukturách založené jazyky, jako jsou C++, C#, Java a další podobné.

Ohledně zpráv

Je pro mě fascinující, že na nejnižších úrovních internetových protokolů není problém se domluvit na strukturovaném formátu zpráv. Každý TCP/IP packet má jasně danou hlavičku, jasně dané adresování a celé to funguje v naprosto masivním, celosvětovém měřítku. Proč by to tedy nemohlo fungovat na počítači, či mezi nimi i na vyšší úrovni?

Opravdu by nešlo adresovat jednotlivé metody objektů, či objekty samotné, jak v rámci jednoho počítače, tak po internetu?

Idea

Nebudu popisovat nějaký konkrétní systém. Sice jsem na tohle téma provedl pár experimentů, ale v zásadě nemám konkrétní data a zkušenosti. Shrnu pouze to co jsem napsal předtím. Tím by postupným zhušťováním a krystalizací již jednou rozebraných myšlenek mohlo vzniknout cosi jako dostatečně komprimovaný popis požadavků, aby to bylo možno brát jako nekonkrétní definici konkrétního produktu.

Databáze místo filesystému

Přemýšlel jsem nad tím, a nevyhnutelným krokem je podle mého názoru zahodit filesystém a nahradit ho databází. Když mluvím o databázi, nemám tím na mysli konkrétní SQL databázi, ani key-value „no-SQL“ databáze. Mluvím tu o obecném strukturovaném systému uchovávání dat na záznamových médiích, který podporuje datové typy, atomicitu, indexování, transakce, žurnály a ukládání libovolně strukturovaných dat, včetně velkých bloků čistě binárních dat.

Něco kam můžete prostě hodit nějakou strukturu a ono se to postará o její uložení bez zbytečné serializace a deserializace. Já vím, že na konci jsou to vždycky jen bajty, ale právě proto nevidím moc důvodů, proč dělat signifikantní rozdíl mezi tím co je v paměti a co je na disku.

Nechci aby to vypadalo, jako že mám něco proti tradičním souborovým systémům. Jsem jejich uživatelem stejně jako všichni ostatní, ale myslím, si, že bez tohohle se není možné posunout někam signifikantně jinam. Když nejste schopni vynutit strukturu na úrovni uložených dat, bez neustálého převádění sem a tam, z formátu do formátu a reprezentací v paměti, je to jako stavět barák v bažině, na základech, které se neustále hýbou.

Programy jako kolekce adresovatelných bloků kódu v databázi

Jakmile máte filesystém, který vám umožňuje nativně uchovávat strukturované informace, nedává smysl mít programy jako jednu velkou sérii bajtů, která se uzavírá před světem. Naopak dává smysl z toho postavit něco podobného architektuře microservices.

Pokud se nad tím zamyslíte dostatečně abstraktně, program je objekt. Je to kolekce dat, nad kterými operují v něm obsažené funkce. Celé je to zapouzdřené a komunikuje to jen pomocí nějakých standardních způsobů (stdin/out/err, socket, signály, env, error kódy, zápisy do souborů..). Když máte filesystém umožňující tyhle objekty uchovávat nativně, nevidím důvod, proč potom nezpřístupnit jednotlivé metody tohoto objektu i z venčí.

Jakmile je zveřejníte, nepotřebujete komunikovat starými streamovými způsoby (socket, soubor, ..), stačí vám prostě vracet strukturovaná data.

Kód se může stále kompilovat, stále je možné používat různé programovací jazyky. Liší se to však výsledkem, jenž z toho vypadne. Místo binárního blobu, posílaného přímo do procesoru, jenž je izolován od ostatních procesů a zbytku systému, máte v podstatě definici API a reakcí na ně. Něco jako sdílenou knihovnu, až na to že tohle je nativní prvek systému a jeho finální podoba.

Smrt konfiguračních formátů a parsování textu

Konfigurační soubory a různé jejich formáty existují, protože filesystém neumí uložit strukturu. Kdyby to uměl, můžete prostě uložit daný slovník s danými klíči a hodnotami, a příště po nich sáhnout. Nemusíte zapisovat RUN=1 do sekce [configuration] a pak to parsovat a serializovat a deserializovat. Můžete prostě uložit samotný fakt "RUN": True na umístění configuration přímo na disku.

Nepotřebujete řešit, jestli je to JSON, nebo CSV, protože v tom pro vás není rozdíl z hlediska formátu, ale jen struktury dat (JSON typicky dict, CSV pole polí).

Parametry příkazové řádky, env proměnné, ale i všechno ostatní píšete jako datové typy zachovávající si strukturu. Programem nejsou parsovány jako text, o to se stará už systém ve chvíli kdy to uživatel dopíše. Datový formát je jednoduchý na textový zápis. Když posílá data program programu, nikde mezi nimi se neserializuje do textu, zprávy se neposílají jako stream bajtů, ale jako zprávy (ve stylu zeromq).

Komplexní redukce

Předchozí popis je pořád moc dlouhý, pojďme ho proto ještě trochu víc zredukovat, tak jak se redukují třeba matematické výrazy do jednoho vzorce:

Místo filesystému strukturovaná hierarchická databáze zachovávající datové typy. V ní jak programy, uložené jako kolekce navzájem se volajících, ale i z venku zavolatelných funkcí, tak konfigurační soubory a uživatelská data. To vše formou přístupných a adresovatelných struktur. Na zápis a čtení jednoduchý, lehký textový formát, používaný všude kde je strukturovaný uživatelský vstup. Programy které ke komunikaci nepoužívají textové protokoly, ale předávají si přímo struktury.

Dost bylo iterativního vylepšování padesát let starých myšlenek. Myslím, že je čas na něco nového.

Inspirace a kontext

Pokud si myslíte, že jsou to všechno naivní blbosti, zkuste si přečíst něco na téma Genery:

Zjistíte, že před desítkami let existoval grafický systém splňující velkou část všeho, o čem jsem psal. Systém tak dobrý, že dodnes kolem sebe spojuje skupiny nadšenců.

Dále pak na podobná témata:

       

Hodnocení: 72 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

10.12.2018 05:33 BFU
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Re: /sys/class/gpio , cele to je deprecated [1]. Navic to slouzilo pouze k debugovani, pokud chces blikat LED, pouziva se na to kernelovy LED subsystem [2].

[1] https://www.kernel.org/doc/Documentation/gpio/sysfs.txt

[2] https://www.kernel.org/doc/Documentation/leds/leds-class.txt
Bystroushaak avatar 10.12.2018 10:52 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Uznávám námitku*, ale na pointě to nic nemění (ta byla celkově o virtuálním fs ve stylu Plan9).

*Nepíší tam jen o ABI?
31.12.2018 12:27 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ale kritiku syntetického filesystému ve stylu Plan 9 nelze postavit pouze na kritice /sys v Linuxu. Ten jejich 9P byl v mnohém vymyšen docela pěkně a jak sám píšeš. Zkoušel sis někdy s tím Plan 9 hrát ve virtuálu nebo psát nad tím aplikace? Ptám se, protože jsem si s tím sám nikdy seriózně nehrál, ale z popisu co jsem četl to nevypadalo úplně posixově.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
Bystroushaak avatar 31.12.2018 14:51 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ale kritiku syntetického filesystému ve stylu Plan 9 nelze postavit pouze na kritice /sys v Linuxu. Ten jejich 9P byl v mnohém vymyšen docela pěkně a jak sám píšeš. Zkoušel sis někdy s tím Plan 9 hrát ve virtuálu nebo psát nad tím aplikace? Ptám se, protože jsem si s tím sám nikdy seriózně nehrál, ale z popisu co jsem četl to nevypadalo úplně posixově.
Právě že jsem si s tím hrál (i jsem o tom něco načetl) a sice uznávám, že je to krok správným směrem, ale potom co jsem si hrál nějakou dobu se smalltalkama a Selfem prostě jasně vidím, že to chce udělat těch kroků víc. Samo o sobě to pořád nechává spoustu problémů nevyřešených, proto si myslím, že se z toho nestalo dominantní paradigma.
10.12.2018 05:41 BFU
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
OS by mel byt ta nejjednodussi a nejtenci abstrakce nad HW, aby si nad tim BFU mohlo postavit presne to, co potrebuje a nemelo tam rezii a bloat ktery nepotrebuje. Pokud BFU potrebuje neco navic, naloaduje si knihovnu, ktera to implementuje nad zakladnima primitivama, ktere OS poskytuje.
Bystroushaak avatar 10.12.2018 10:53 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Pokud bys skutečně důsledně následoval tuhle strategii, tak bys používal něco jako forth, nebo interpret basicu.
10.12.2018 19:28 BFU
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Shodou okolnosti pouzivam interpret BASICu kazdy den.
11.12.2018 00:12 BFU
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Muzes to zduvodnit ?
Bystroushaak avatar 11.12.2018 09:57 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Hláška že OS by měl být co nejjednodušší je totálně mimo ve chvíli, kdy používá OS co vůbec není jednoduchý ani omylem (žádný z běžné trojice). Nejjednodušší OS jsou skutečně jen loadery na tvoje programy, které navíc třeba poskytují ještě nějakou hardwarovou abstrakci, jako třeba ten interpretr forthu.
11.12.2018 15:30 BFU
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
> ... ve chvíli, kdy používá OS co vůbec není jednoduchý ani omylem (žádný z běžné trojice).

Tomu uplne nerozumim, co pouziva OS ? Mas na mysli, pokud ma BFU na OS nejaky specificky pozadavek ? V ten moment si muze BFU#1 natahnout knihovnu, ktera mu da jednodussi API implementujici jeho pozadavek. BFU#2 ten pozadavek mit nemusi a proto si knihovnu nenatahne. Obe BFU nicmene spokojene pouzivaji ten stejny OS.

> Nejjednodušší OS jsou skutečně jen loadery na tvoje programy

Tady bych byl opatrny. Loader je skutecne jen loader a neposkytuje zadne rezidentni sluzby (napr. prikaz bootelf v U-Boot), proste rozparsuje ELF hlavicku, nataha sekce do pameti a skoci na entrypoint. OS poskytuje zakladni sluzby (multitasking, abstrakce pristupu k HW, popr. nejake zakladni knihovny atd.), loader muze byt jedna z nich, ale nemusi (viz ruzne RTOS, ktere jsou orezane az na kost).

> poskytují ještě nějakou hardwarovou abstrakci, jako třeba ten interpretr forthu.

Viz napr. OLPC, jejich implementace OF je presne toto, interpret forthu. Pokud to BFU staci, muze pouzivat pouze to. Pokud to BFU nestaci, nabootuje si GNU/Linux a muze vyuzivat jeho API.

>

Tato citace od Exuperyho se mi opravdu libi a myslim si, ze tim by se vyvoj software ridit mel, obzvlast dnes, kdy vic kodu znamena vetsi bezpecnostni riziko:

It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.
13.12.2018 08:39 melkors | skóre: 13 | blog: kdo_chce_kam
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
"Tato citace od Exuperyho se mi opravdu libi a myslim si, ze tim by se vyvoj software ridit mel, obzvlast dnes, kdy vic kodu znamena vetsi bezpecnostni riziko:

It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove. "

Pokud se nemylim, Antoine de Saint-Exupéry psal francouzsky. Zajimal by mne duvod, proc davas citaci v anglickem prekladu, kdyz je k dispozici (IMHO velmi dobry) cesky preklad.
13.12.2018 19:31 BFU
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Protoze je znam v anglictine a francouzsky zde rozumi mene lidi nez anglicky. HTH
Bystroushaak avatar 13.12.2018 10:25 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tato citace od Exuperyho se mi opravdu libi a myslim si, ze tim by se vyvoj software ridit mel, obzvlast dnes, kdy vic kodu znamena vetsi bezpecnostni riziko:

It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.
Asi bych mohl polemizovat, jestli je dokonalost to na co fakt cílíš, a jak jí budeš definovat, ale obecně s tím souhlasím.

Nicméně to záleží čistě na definici toho, co vlastně chceš dělat. Pokud si jako definici dáš současný styl OS, tedy Unixový systém, tak tvoje idea dokonalosti může vypadat úplně jinak, než když si dáš za cíl třeba co nejlepší systém pro práci s informacemi, nebo co nejlepší systém pro programátora.

Já si navíc hlavně nemyslím, že současný stav byl zvolen nějak racionálně, podle v současnosti smysluplných cílů. Myslím si, že je to jen historický artefakt a lokální maximum, do kterého jsme spadli.

Což je mimochodem taky dobré poznamenat, že pokud chceš všechno co nejvíc univerzální a co nejvíc použitelné, tak to z principu musí optimalizovat ve více dimenzích (například právě v univerzálnosti, použitelnosti, jednoduchosti na implementaci, naučení se a tak dál). Tím to zprůměruješ níž, než systém, který by optimalizoval v méně dimenzích. Asi jako židle zprůměrovaná na průměrný zadek, versus židle udělaná přímo tobě na míru.
13.12.2018 11:35 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Co vlastně počítáš do OS? Co třeba libc? Já bych ji jako část OS neoznačil, ale bez ní by ten OS by byl jen těžko použitelný. Podobně na tom je třeba init (v obecném smyslu).

Já bych řekl, že co nejlepší systém pro práci s informacemi nebo co nejlepší systém pro programátora může úplně krásně být postaven na něčem, co je současný styl OS.

Ten systém pro programétor, nebo práci s informacemi totiž bude stejně řešit úlohy, které řeší systém v současném stylu. Objekt uložený na disku stejně pořád bude sekvence bytů, nějak zdokumentovaná (co a kde to je, apod.) na nějakém FS. Pro jeho načtení bude potřeba ovladač disku, FS, nějaké syscally, atd. Nad tím bude parser, který z bytů udělá objekt.

Možná se současný styl OS úplně nehodí jako základ toho, co bys chtěl, ale to nic nemění na tom, že ten parser bude userspace záležitost.
Bystroushaak avatar 13.12.2018 12:04 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Co vlastně počítáš do OS? Co třeba libc? Já bych ji jako část OS neoznačil, ale bez ní by ten OS by byl jen těžko použitelný. Podobně na tom je třeba init (v obecném smyslu).
Já jí tam počítám. Chápu, že to rozdělení jde dělat různě a právě proto jsem ho udělal čistě pragmaticky tak, že OS je to co instaluju na počítač. Tedy celá distribuce. I když je mi jasné, že v čistě pedantském smyslu to tak samozřejmě není.
Já bych řekl, že co nejlepší systém pro práci s informacemi nebo co nejlepší systém pro programátora může úplně krásně být postaven na něčem, co je současný styl OS.
Do jisté míry ano. Jeden z problémů který tu vidím je spíš filosofického rázu, než čeho jiného. Je to jako když jsou programovací jazyky zpětně kompatibilní s C - lidi mají tendence to pak používat jako C, protože je to něco co znají. Jen těžko se pak posouváš někam kupředu. Můžeš si do jazyka dodělat generátory a korutiny a futures a kde co, ale pokud to uděláš zpětně kompatibilní s C, budeš jen těžko přesvědčovat ostatní, aby to používali. Proto taky vznikají nové jazyky. Ten problém je někde na úrovni vnímání světa skrz analogie. Pokud je něco skoro stejného jako něco jiného, jak budeš vysvětlovat ostatním, aby to používali úplně jinak?

Ta moje představa je něco jako Python. Je to prostě trochu víc abstraktní a nabízí to nějaké další konstrukty, které standardní OS nenabízí, samozřejmě za cenu menší univerzality. Jenže to není nevýhoda, to je největší výhoda. Pokud by měl být python zpětně kompatibilní na úrovni syntaxe a funkcionality s C, tak by neexistoval moc důvod ho používat. A plně uznávám tvrzení lidí co dělají v C, že každou aplikaci, co v Pythonu naprogramuju můžou naprogramovat i v C. Jenže každý kdo dělá v Pythonu ví, že to není pointa a že ty jeho odlišnosti jsou důležité.

Pokud uděláš to co jsem popsal jen jako vrstvu nad klasickým OS, tak i ty sám budeš pořád používat klasický OS. Nikdy se skutečně neponoříš do možností a schopností toho co jsi vytvořil, protože celý zbytek světa tě bude stahovat a držet zpět.

Nutno teda poznamenat, že já svůj vlastní OS fakt nedělám a nemám to v plánu.
Ten systém pro programétor, nebo práci s informacemi totiž bude stejně řešit úlohy, které řeší systém v současném stylu. Objekt uložený na disku stejně pořád bude sekvence bytů, nějak zdokumentovaná (co a kde to je, apod.) na nějakém FS. Pro jeho načtení bude potřeba ovladač disku, FS, nějaké syscally, atd. Nad tím bude parser, který z bytů udělá objekt.

Možná se současný styl OS úplně nehodí jako základ toho, co bys chtěl, ale to nic nemění na tom, že ten parser bude userspace záležitost.
Já s tím více/méně souhlasím, až na ten rozdíl, že podle mého názoru jde o artefakt. Tak to prostě je, nikoliv že by to tak být muselo. Pokud bys měl dost prostředků, jako třeba Google, tak bys imho mohl vytvořit něco podstatně lepšího. Samozřejmě jako jednotlivec moc nemáš šanci.
13.12.2018 13:53 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Vezmu to od konce - co považuješ za artefakt? To, že když ukládáš na disk nějaká data (ať už na ně koukáš jakkoli - hromada bytů, obrázek, objekt apod.), tak to skončí jako hromada bytů (resp. jakási magnetická stopa od ní odvozená) a potřebuješ k tomu víceméně to, co jsem popsal?

Já si myslím, že těhle věcem se jednoduše nevyhneš. Můžeš je realizovat různě, i hodně odlišně od toho, jak to je aktuálně v Linuxu, ale ty vrstvy tam pořád budou. Pořád tam bude něco, co řekne disku, co číst, co to od něj přesune někam do paměti jádra, odtamtud do userspacu, něco, co to to naparsuje (udělá z toho objekt), něco, co si bude udržovat přehled, co kde je na disku atd.

Ty chceš přidat jednu nebo víc vrstev. V principu dobrý nápad, ale nepřijde mi to jako součást OS. I když s tvým pojetím, co je to OS vlastně asi ano. Jenže pak to není v rozporu s tím, že je to knihovna/framework (v širokém smyslu).

Nevidím zásadní důvod (určitě by se našlo mnoho malých), proč by tahle vrstva(y) nemohla být nad nějakým posixem. Ten příklad s jazykem zpětně kompatibilním s C mi přijde nesprávný. C++ je zpětně kompatibilní s C (až na pár drobností) a jeho vlastnosti, co má navíc oproti C se používají hodně. Stejně tak nad posixem je dnes spousta vrstev, které lidi používají.
Bystroushaak avatar 13.12.2018 14:46 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Vezmu to od konce - co považuješ za artefakt?
Věci které jsou, protože historicky dávaly smysl, případně protože pár lidí to nějak nastřelilo a ono se to osvědčilo, ale v současnosti za tím nestojí žádné racionálně podložené rozhodnutí a série experimentů, které by jasně prokázaly, že je to lepší než jiné přístupy.

Souborový systém není z uživatelského hlediska nic jiného než artefakt. Je to jednoduše pochopitelná analogie, ale neexsituje důvod, proč bys mohl mít jen adresáře a soubory (a symlinky a pipy) a ne libovolně typované záznamy s relacema a triggerama a atomickým zápisem. Právě proto, že dole jsou to bajty a souborový systém to uloží tak jako tak.
Já si myslím, že těhle věcem se jednoduše nevyhneš. Můžeš je realizovat různě, i hodně odlišně od toho, jak to je aktuálně v Linuxu, ale ty vrstvy tam pořád budou. Pořád tam bude něco, co řekne disku, co číst, co to od něj přesune někam do paměti jádra, odtamtud do userspacu, něco, co to to naparsuje (udělá z toho objekt), něco, co si bude udržovat přehled, co kde je na disku atd.
Já bych úplně vyhodil filesystém a přidal místo něj nativně prostě databázi s podporou ukládání objektů, key-value záznamů a možná i relací. Pořád bys mohl mít /etc/your_app, ale neměl bys tam uložený soubor, ale samotná typovaná data. Místo stringu s ini souborem bys z toho dostal rovnou slovník. String by nevznikl nikde po cestě, nevznikl by ani na disku. Nebylo by ho třeba nikdy parsovat a zpracovávat.
13.12.2018 15:25 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Kde vidíš hranici mezi filesystémem a databází?
Bystroushaak avatar 13.12.2018 16:14 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ve struktuře, kterou ti to umožní uložit* a v tom jestli podporuje ACID.

*Tím myslím i adresovatelnost struktury. Nakonec jsou z toho vždy bajty, ale jde o to abys měl možnost adresovat konkrétní položku bez nutnosti dalšího postprocessingu a zpracování celého souboru.
13.12.2018 18:07 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To ale spíš vypadá, že FS je databáze, kterí chybí některé vlastnosti, ne artefakt.

Mimochodem, když vyhodíš ten FS, jak jsi navrhoval a ta db ukládat data nějak přímo na block device, tak ti vznikne spousta problémů (např fragmentace), které FS řeší.

Celkově mi přijde, že se na to koukáš tak nějak moc seshora. Myšlenka ukládat kdeco do db mi přijde celkem dobrá, ale pro realizaci mi tam tradiční FS přijde nezbytný.
Bystroushaak avatar 13.12.2018 18:16 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Mimochodem, když vyhodíš ten FS, jak jsi navrhoval a ta db ukládat data nějak přímo na block device, tak ti vznikne spousta problémů (např fragmentace), které FS řeší.
Problémy ti nevzniknou, prostě se jen FS a databáze sloučí do jednoho. Nikdy jsem netvrdil, že se obejdeš bez technik, které FS používá, jen že se obejdeš bez jeho uživatelského rozhraní (soubory, složky, možnosti zápisů do nich a tak podobně).
Celkově mi přijde, že se na to koukáš tak nějak moc seshora. Myšlenka ukládat kdeco do db mi přijde celkem dobrá, ale pro realizaci mi tam tradiční FS přijde nezbytný.
To upřímně nechápu proč. Naopak v případě databází je to v podstatě zbytečný mezikrok, který se stejně snažíš obcházet různým mapováním do paměti a sparse soubory a tak podobně.
xkucf03 avatar 13.12.2018 18:38 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Objektový OS
Problémy ti nevzniknou, prostě se jen FS a databáze sloučí do jednoho. Nikdy jsem netvrdil, že se obejdeš bez technik, které FS používá, jen že se obejdeš bez jeho uživatelského rozhraní (soubory, složky, možnosti zápisů do nich a tak podobně).

Podle mého je to jen implementační detail, je to nepodstatné a nemá cenu se o tom hádat. Představ si, že uděláš prototyp toho tvého systému -- OS, který nabootuje do nějakého objektového světa. Je úplně jedno, jestli kdesi pod tím bude Ext4, Btrfs, XFS, nebo jejich funkcionalita reimplementovaná v nějaké spodní vrstvě té DB. Uživatel to nevidí a v zásadě ho to nezajímá.

Můžeme tedy osekat všechny zbytné kroky a vykašlat se na nějakou reimplementaci a postavit to (alespoň hypoteticky, v myšlenkách) jako nadstavbu nad stávajícím systémem. Že je pod tím POSIX resp. GNU/Linux nás nemusí trápit -- může to mít nějaké výkonnostní dopady a může to představovat zbytečnou komplexitu, ale v případě prototypu je to jedno. Tak a teď máme prázdný objektový operační systém, který nastartoval a v něm na nás bliká nějaká objektová příkazová řádka... Co dál?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Bystroushaak avatar 13.12.2018 19:57 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Objektový OS
Podle mého je to jen implementační detail, je to nepodstatné a nemá cenu se o tom hádat. Představ si, že uděláš prototyp toho tvého systému -- OS, který nabootuje do nějakého objektového světa. Je úplně jedno, jestli kdesi pod tím bude Ext4, Btrfs, XFS, nebo jejich funkcionalita reimplementovaná v nějaké spodní vrstvě té DB. Uživatel to nevidí a v zásadě ho to nezajímá.
Jen pro pořádek, moje prototypy normálně pracují nad FS. To že se tu o tom hádám neznamená, že nejsem pragmatik.
Můžeme tedy osekat všechny zbytné kroky a vykašlat se na nějakou reimplementaci a postavit to (alespoň hypoteticky, v myšlenkách) jako nadstavbu nad stávajícím systémem. Že je pod tím POSIX resp. GNU/Linux nás nemusí trápit -- může to mít nějaké výkonnostní dopady a může to představovat zbytečnou komplexitu, ale v případě prototypu je to jedno. Tak a teď máme prázdný objektový operační systém, který nastartoval a v něm na nás bliká nějaká objektová příkazová řádka... Co dál?
No, tohle je jeden z důvodů, proč vůbec nemám snahu ohledně čehokoliv pro uživatele. Dál jsi jako uživatel v háji. Já jako programátor si samozřejmě začnu portovat věci co tam potřebuji.

Jinak přesně tuhle situaci jsem zažil se Selfem a chce to prostě zatnout svaly a prorážet si vlastní cestu. Což samozřejmě chápu, že nemůžu chtít po ostatních.
17.12.2018 09:59 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Objektový OS
Přesně moje myšlenka :)
Heron avatar 13.12.2018 19:18 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Naopak v případě databází je to v podstatě zbytečný mezikrok, který se stejně snažíš obcházet různým mapováním do paměti a sparse soubory a tak podobně.

To je projekt od projektu. Některé DB požadují dostatečně příčetný FS a staví až nad ním. Proč by měly ztrácet čas nad řešením něčeho co už vyřešil někdo jiný. Jiné DB v minulosti měly podporu pro block device, ale opustily ji. Některé jiné storage systémy (jmenujme CEPH) se neumějí rozhodnout a za 10 let doporučují ext4, btrfs, xfs, aby se nakonec rozhodli napsat si vlastní BlueStore (což asi nebude FS ve smyslu požadavků VFS).

Asi nelze říct, který přístup je lepší. Jsou projekty, které staví na již existujícím a očekávají funkční FS, ioscheduler, task scheduler, síťování a jsou projekty, které si chtějí řešit všechno sami. Výhoda prvního řešení je, že už to někdo napsal a je to k disposici a lze očekávat, že se to bude časem zlepšovat. Výhoda druhého řešení může být lepší optimalizace na konkrétní typ zátěže. V praxi vidíme oba přístupy.
31.12.2018 19:11 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Některé jiné storage systémy (jmenujme CEPH) se neumějí rozhodnout a za 10 let doporučují ext4, btrfs, xfs, aby se nakonec rozhodli napsat si vlastní BlueStore (což asi nebude FS ve smyslu požadavků VFS).
V případě Cephu je to doslova cesta tam a zase zpátky, ale ve výsledku to má snad i nějakou logiku, i když se to nemusí na první pohled zdát :-)

Sage už ve své disertační práci (2007) psal o EBOFS, vlastní implementaci souborového systému v user space pro potřeby Ceph OSD:
Low-level object storage on individual OSDs is managed by EBOFS, an E xtent and B- tree based Object File System. Although a variety of distributed storage arch itectures leverage existing general-purpose file systems [14, 55] such as ext3 [95], both th e performance and the standard POSIX file system interface and safety semantics are inappro priate for RADOS. Because EBOFS is implemented entirely in user-space and interacts directly with a raw block device, it is unencumbered by an unwieldy kernel file system interface, a nd avoids interaction with the (Linux) VFS inode and page caches, which were designed aroun d a different storage abstraction and workload assumptions. This allows EBOFS to optimize specifica lly for object workloads [97]
Později v roce 2009 EBOFS zahodili, protože se zdálo, že btrfs jej v budoucnu nahradí:
We dropped support for ebofs a few months back since the plan moving forward is to use btrfs and the maintenance burden wasn't deemed worthwhile. Btrfs does (almost *) everything ebofs does, and much more, and is very actively developed.
Ale do produkce vždy doporučovali XFS, případně ext4. Btrfs bylo pouze experimentální a počítalo se s ním do budoucna, viz dokumentace verze z roku 2013:
We currently recommend XFS for production deployments. We recommend btrfs for testing, development, and any non-critical deployments. We believe that btrfs has the correct feature set and roadmap to serve Ceph in the long-term, but XFS and ext4 provide the necessary stability for today’s deployments. btrfs development is proceeding rapidly: users should be comfortable installing the latest released upstream kernels and be able to track development activity for critical bug fixes.
S vývojem btrfs ale v Cephu asi nebyli úplně spokojení, protože se nakonec v roce 2017 na btrfs vykašlali a vrátili se k původní myšlence vlastního souborového systému v user space a napsali nový systém, Bluestore, který používá RocksDB key/value databazi.

Btw Ceph s Bluestore je docela dobrý příklad, jak se na dnešním OS dá postavit storage systém, který není omezený návrhem operačního systému, co beží pod ním.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
17.12.2018 10:08 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nikdy jsem netvrdil, že se obejdeš bez technik, které FS používá, jen že se obejdeš bez jeho uživatelského rozhraní (soubory, složky, možnosti zápisů do nich a tak podobně).
Tím pádem tam ale ten FS bude, jen nebude určen k přímému použití programátorem nebo uživatelem. Podobně jako teď syscally. Dají se volat přímo, ale málokterý programátor to dělá.

To upřímně nechápu proč. Naopak v případě databází je to v podstatě zbytečný mezikrok, který se stejně snažíš obcházet různým mapováním do paměti a sparse soubory a tak podobně.
Nezbytný ve smyslu vrstvy, která bude řešit ty technické problémy (např. fragmentaci) při ukládání dat na disk.
Bystroushaak avatar 17.12.2018 12:17 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tím pádem tam ale ten FS bude, jen nebude určen k přímému použití programátorem nebo uživatelem. Podobně jako teď syscally. Dají se volat přímo, ale málokterý programátor to dělá.
Je otázka do jaké míry. Například asi nedává smysl rozdělení na soubory a složky a jejich atributy a symlinky. Naopak dává smysl ta druhá část, co jsi zmiňoval, tedy řešení fragmentace a tak dál.
18.12.2018 15:27 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Takže za artefakt nepovažuješ FS jako takový, ale některé jeho prvky? Mě soubory a složky nepřijdou moc jako artefakt, ale spíš jako základní a velmi jednoduchý (z pohledu uživatele) způsob rozmístění dat na disku.
Bystroushaak avatar 18.12.2018 16:34 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
V blogu jsem to imho docela jasně popsal. Nemám nic proti částem filesystému řešícím fragmentaci a ukládání na disk a plánování čtení a zápisů a fronty cacheování a tak dál. Mám poměrně hodně (blog dokonce) proti filosofickému konceptu souborů a složek.
Mě soubory a složky nepřijdou moc jako artefakt, ale spíš jako základní a velmi jednoduchý (z pohledu uživatele) způsob rozmístění dat na disku.
No, tak samozřejmě, protože jsi s tím vyrůstal a celý ten koncept tu byl dýl než existuješ. Ale zamýšlel ses někdy proč ti to tak přijde? Jaké to má opodstatnění a jestli to vůbec dává nějaký smysl? Co jsou alternativní přístupy? Jestli by to třeba nešlo dělat líp, případně jaké by to přinášelo benefity?
18.12.2018 16:57 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ja jsem byl taky jeden cas proti slozkam, a chtel jsem filesystem, ktery by mohl ukladat stejny soubor do libovolneho mnozstvi slozek (ci spise tagu), a adresovat ho pak na zaklade obsahu. (Tedy trochu jako hardlinky ale misto inode by byl hash toho souboru.) A samozrejme, idealne, aby stejna struktura fungovala pres ruzna zarizeni nebo i ruzne lidi.

Nicmene zkusim jeden argument pro slozky. Jako lide jsme se vyvinuli zvykli orientovat se ve fyzickem prostoru, a proto je nam hierarchicke deleni (virtualniho) prostoru prirozene. U jinych deleni (treba kde prostor funguje jako orientovany graf, podobne jako treba kategorie na Wikipedii) ztracime prehled o tom, co a kolik toho kde mame.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
Bystroushaak avatar 18.12.2018 17:04 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nicmene zkusim jeden argument pro slozky. Jako lide jsme se vyvinuli zvykli orientovat se ve fyzickem prostoru, a proto je nam hierarchicke deleni (virtualniho) prostoru prirozene. U jinych deleni (treba kde prostor funguje jako orientovany graf, podobne jako treba kategorie na Wikipedii) ztracime prehled o tom, co a kolik toho kde mame.
Tohle uznávám, ale pokud ukládáš do prototypových objektů, tak pořád máš podobné hierarchie.
xkucf03 avatar 18.12.2018 17:18 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše IPFS
Ja jsem byl taky jeden cas proti slozkam, a chtel jsem filesystem, ktery by mohl ukladat stejny soubor do libovolneho mnozstvi slozek (ci spise tagu), a adresovat ho pak na zaklade obsahu. (Tedy trochu jako hardlinky ale misto inode by byl hash toho souboru.) A samozrejme, idealne, aby stejna struktura fungovala pres ruzna zarizeni nebo i ruzne lidi.

To zní jako IPFS :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
18.12.2018 20:03 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nicmene zkusim jeden argument pro slozky. Jako lide jsme se vyvinuli zvykli orientovat se ve fyzickem prostoru, a proto je nam hierarchicke deleni (virtualniho) prostoru prirozene. U jinych deleni (treba kde prostor funguje jako orientovany graf, podobne jako treba kategorie na Wikipedii) ztracime prehled o tom, co a kolik toho kde mame.
Ten argument pro adresare je docela validni. Umoznuji organizaci od obecnych kategorii dat, k tem specifickym. Cim zanorenejsi adresar, tim obvykle obsahuje spefictejsi data. Nic, co by lide nedelali po staleti pred tim.
U jinych deleni (treba kde prostor funguje jako orientovany graf, podobne jako treba kategorie na Wikipedii) ztracime prehled o tom, co a kolik toho kde mame.
Z tohoto uhlu pohledu praktictejsi "zobecneni" (resp. zuplneni) adresaru (spis nez orientovany graf) by byl svaz, kde infimum by byl prunik tagu jednotlivych dokumentu a supremum jejich sjednoceni. Svaz (strukturu adresaru) bys pak prochazel od shora dolu a jen bys pridaval tagy (zanoroval by ses do adresaru), nez bys dosel k tem konkretnim dokumentum, co hledas.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
18.12.2018 21:11 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Z tohoto uhlu pohledu praktictejsi "zobecneni" (resp. zuplneni) adresaru (spis nez orientovany graf) by byl svaz, kde infimum by byl prunik tagu jednotlivych dokumentu a supremum jejich sjednoceni. Svaz (strukturu adresaru) bys pak prochazel od shora dolu a jen bys pridaval tagy (zanoroval by ses do adresaru), nez bys dosel k tem konkretnim dokumentum, co hledas.
Wow, zajímavý nápad. Ale - jestli to teda dobře chápu - stále je tam ten problém s přehledností. V tom supremu by těch položek byly strašný mraky, ne?
18.12.2018 22:11 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ale - jestli to teda dobře chápu - stále je tam ten problém s přehledností
To mas do jiste miry pravdu. Cast veci je podle me resitelna, da se vyuzit ze tam jde zavest uzaverovy system, ktery ti nektere veci zjednodusi. Prakticky problem vidim v tom, ze ti vznikne velke mnozstvi kombinaci zanorenych "adresaru", ktere se budou lisit v jednom/dvou/atp. tagoch, resp. v jednom/dvou/atp. souborech. To na prehlednosti zrovna na prida.

Z meho pohledu klicovejsi problem je, jak primet uzivatele, aby smysluplne tagovali jednotlive soubory.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
18.12.2018 17:16 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
No, tak samozřejmě, protože jsi s tím vyrůstal a celý ten koncept tu byl dýl než existuješ. Ale zamýšlel ses někdy proč ti to tak přijde? Jaké to má opodstatnění a jestli to vůbec dává nějaký smysl?
Já jsem se nad tím (trochu) zamýšlel a IMHO to smysl dává a je to celkom přirozené, tedy teď myslím filesystém jako strom složek coby parent nodů a souborů coby obecných balíků dat. IMHO to celkem odpovídá přirozenému způsobu jakým člověk organizuje věci. Když se podíváš na nějakou organizovanou kancelář, archiv, knihovnu, dílnu nebo sklad, tak to v podstatě storm je. A ten soubor coby obecné 'něco' taky v podstatě odpovídá - jdeš do skladu, v sekci A-3-II najdeš na polici 'něco'. O co konkrétně se jedná, to záleží na konkrétní situaci, sklad to neřeší nebo to řeší minimálně.

Tím nechci říct, že hledat alternativní postupy nemá cenu nebo že fs je vrchol poznání. Klidně může někdo přijít s nějakým lepším modelem. Chtěl jsem říct to, že ten fs sice má svoje omezení a je do jisté míry neohrabaný, ale IMHO v základu smysl celkem dává a není to jenom náhodný důsledek historického vývoje.
Bedňa avatar 18.12.2018 17:38 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Už som to spomínal v inom vlákne. Linuxový prístup k dátam je o vrstvách. Mno a stále tu máme filozofiu, jeden program robí jednu vec a robí ju dobre.

Takže na spodu je nejaký súborový systém, nad tou vrstvou máme napríklad RAID, LVM, šifrovanie atď, stále sú to vrstvy a nad tie môžeme stavať ďalšie, teoreticky tam neexistujú žiadne obmedzenia.

Takže ak chceme nejak atomicky prisupovať k dátam a povedzme z toho spraviť nejaký štandart, tak musíme napísať niečo čo do toho konceptu zapadne, inak to umrie ako všetky ostatné snahy.

Čiže ďalšia vrstva, ktorá pobeží aj nad RAID, LVM, šifrovaním atď.

Ten Linuxový/Unixový koncept je OK, len ľudia ako Kay a Lennart si myslia že ten návrh nesedí a ignorujú veci ako rob jednu vec a rob ju dobre. File systém ktorý by vedel všetko a všetky tie vrstvy zahodil, by proste bol úžasný a nič by sa nad ním nedalo spraviť.

KERNEL ULTRAS video channel >>>
Bystroushaak avatar 18.12.2018 17:47 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Čiže ďalšia vrstva, ktorá pobeží aj nad RAID, LVM, šifrovaním atď.
Podle mě si pleteš systém ukládání dat a filesystém, respektive je vnímáš jako něco totožného. To první může být součástí toho druhého, není to ale nutná podmínka. Například ty vzpomínané databáze afaik můžou stále využívat RAID a LVM, přestože nepoužívají filesystém. Stejně tak ti hypoteticky nic nebrání dát smalltalkovské image jako soubor pro image prostě /dev/sda, až na to že by s ním tedy nejspíš neuměla moc efektivně pracovat (imho ukládá vždy celý image).
Bedňa avatar 18.12.2018 18:43 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Napísať niečo čo bude fungovať podľa tvojich predstáv by bolo problematické hlavne čo sa týka výkonu.

Tá pointa v Linux enviroment je podľa mňa OK, že sú tie vrstvy oddelené. Ty by si chcel aby to spracovanie dát fungovalo na úrovni súborového systému (alebo to už nazvyme hocijako inak), ja nehovorím že je to nemžné, mno všetky podobné pokusy zakapali.
KERNEL ULTRAS video channel >>>
31.12.2018 19:23 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
+1 (až na toho Lennarta, do filesystémů snad zatím nedělá ... :-)
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
Bystroushaak avatar 18.12.2018 17:52 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Příloha:
Já jsem se nad tím (trochu) zamýšlel a IMHO to smysl dává a je to celkom přirozené, tedy teď myslím filesystém jako strom složek coby parent nodů a souborů coby obecných balíků dat. IMHO to celkem odpovídá přirozenému způsobu jakým člověk organizuje věci. Když se podíváš na nějakou organizovanou kancelář, archiv, knihovnu, dílnu nebo sklad, tak to v podstatě storm je. A ten soubor coby obecné 'něco' taky v podstatě odpovídá - jdeš do skladu, v sekci A-3-II najdeš na polici 'něco'. O co konkrétně se jedná, to záleží na konkrétní situaci, sklad to neřeší nebo to řeší minimálně.
To je prostě hierarchické uložení dat. Ze svých zkušeností se Selfem* však z první ruky vím, že stejně můžeš organizovat i objekty (viz příloha).

Zintenzivnil jsem práce na článcích, takže snad vbrzku bude počtení o něm.
18.12.2018 19:50 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To je prostě hierarchické uložení dat. Ze svých zkušeností se Selfem* však z první ruky vím, že stejně můžeš organizovat i objekty (viz příloha).
Jasně. Mně tohle ani nepřijde nějak moc specifické pro Self - i v mnoha ostatních jazycích se objekty typicky používají v nějakých hierarchiích. Moderní C++, Rust a podobné jazyky mají s tímhle spjatý memory/resource management. Dokonce i v GC-ed jazycích přes určitou občasnou anarchii je typicky snaha, aby objekty "někam patřily".

Nicméně objekty se od souborů liší v tom, že to nejsou obecné, i když to tak může z názvu znít. 'Objekt' implikuje nějaký datový model a v případě že bys chtěl, aby měly metody, tak i runtime. V tom je podle mě ta obtížnost a na to jsem narážel třeba s tou otázkou na VCS: Obecný objekt nemusí mít vůbec metody porovnání a diffování a i když je bude mít, tak nemusí být vhodné pro VCS. Třeba IEEE 754 čísla sice mají operátor rovnosti, ten ale není vhodný pro VCS protože NaN != NaN, i když to je ten samý NaN. Takže by nejspíše ty objekty potřebovaly operátory pro VCS a zálohovací programy (rsync, ...), což bude IMHO těžké zajistit na opravdu obecných objektech. A to je pouze jeden konkrétní use-case, který mě napadl, kdovíkolik toho ještě je, co mě nenapadlo.

Další celkem (zjevný problém) je, jak čelit tomu, že ten datový/runtime model bude dříve či později nějakým způsobem pro někoho někde nedostatečný nebo nevhodný a bude potřeba ho přizpůsobovat nebo i změnit globálně...
Bystroushaak avatar 18.12.2018 20:04 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jasně. Mně tohle ani nepřijde nějak moc specifické pro Self - i v mnoha ostatních jazycích se objekty typicky používají v nějakých hierarchiích. Moderní C++, Rust a podobné jazyky mají s tímhle spjatý memory/resource management. Dokonce i v GC-ed jazycích přes určitou občasnou anarchii je typicky snaha, aby objekty "někam patřily".
Tohle je trochu jiné v tom že je to prototypový jazyk. Odpovídá to víc těm souborům - objekt existuje sám o sobě. Když ho někam přesuneš, tak je přesunut a tím to hasne. V C++, Rustu a tak si můžeš dělat s Objekty co chceš, ale neustále tam existuje dualita s třídami, které musíš přesunovat separátně. V Selfu je objekt v jistém smyslu svojí vlastní třídou.
Nicméně objekty se od souborů liší v tom, že to nejsou obecné, i když to tak může z názvu znít. 'Objekt' implikuje nějaký datový model a v případě že bys chtěl, aby měly metody, tak i runtime. V tom je podle mě ta obtížnost a na to jsem narážel třeba s tou otázkou na VCS: Obecný objekt nemusí mít vůbec metody porovnání a diffování a i když je bude mít, tak nemusí být vhodné pro VCS. Třeba IEEE 754 čísla sice mají operátor rovnosti, ten ale není vhodný pro VCS protože NaN != NaN, i když to je ten samý NaN. Takže by nejspíše ty objekty potřebovaly operátory pro VCS a zálohovací programy (rsync, ...), což bude IMHO těžké zajistit na opravdu obecných objektech. A to je pouze jeden konkrétní use-case, který mě napadl, kdovíkolik toho ještě je, co mě nenapadlo.
Tohle jsem úplně nepochopil. Imho se na to díváš moc z pohledu kompilovaných jazyků. V Selfu si prostě vytvoříš pro daný objekt mirror (objekt obsahující reflexi mirrorovaného objektu) a pracuješ s tím.
Další celkem (zjevný problém) je, jak čelit tomu, že ten datový/runtime model bude dříve či později nějakým způsobem pro někoho někde nedostatečný nebo nevhodný a bude potřeba ho přizpůsobovat nebo i změnit globálně...
No tak ho prostě přízpůsobíš nebo i změníš globálně? Moc té pointě nerozumím (což myslím zcela tak jak to píšu, nechápu v čem je podstata problému).
18.12.2018 21:04 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tohle je trochu jiné v tom že je to prototypový jazyk. Odpovídá to víc těm souborům - objekt existuje sám o sobě. Když ho někam přesuneš, tak je přesunut a tím to hasne. V C++, Rustu a tak si můžeš dělat s Objekty co chceš, ale neustále tam existuje dualita s třídami, které musíš přesunovat separátně. V Selfu je objekt v jistém smyslu svojí vlastní třídou.
Tohle trochu znám z JS, ačkoli to asi nebude úplně to samé. (JS je zmršený.) Nicméně popravdě pro téma diskuse mi to nepřijde podstatné...
Tohle jsem úplně nepochopil. Imho se na to díváš moc z pohledu kompilovaných jazyků. V Selfu si prostě vytvoříš pro daný objekt mirror (objekt obsahující reflexi mirrorovaného objektu) a pracuješ s tím.
Ok, dejme tomu, že píšu VCS pro takovýhle systém. V tom případě od něj potřebuju několik věcí: 1. Možnost porovnat objekty, jestli se změnily, abych věděl, který se změnil od posledního commitu, 2. Možnost vytvořit uživatelsky přívětivý diff objektu. U toho bodu 1. stojí za povšimnutí, že takovou operaci nemusí objekt poskytovat, příklad byl ten float, který sice (ne)rovnítko definuje, ale není použitelné pro VCS. Bod 2. ten float taky nenabízí, protože např. různé NaNy nebo některá čísla by se zobrazily stejně (asi by se muselo zobrazit číslo textově a zároveň hexa nebo něco takového).

Je taky otázka, jestli by tyhle operátory měl implementovat ten VCS, nebo ten object storage. Pokud ten VCS, je to nepříjemné v tom, že ten VCS musí být napsán specificky pro daný datový model. Pokud object storage, pak tenhle problém odpadá, ale zase roste komplexita object storage. Všimni si například, že třeba takový rsync taky diffuje soubory, ale zatímco VCS diffuje za účelem zobrazení uživateli, rsync diffuje za účelem efektivity přenosu, takže rsync by nejspíše potřeboval jiný diffovací operátor nad objekty.
No tak ho prostě přízpůsobíš nebo i změníš globálně? Moc té pointě nerozumím (což myslím zcela tak jak to píšu, nechápu v čem je podstata problému).
Problém je, že když tohle umožníš, ztrácí systém na obecnosti a hrozí problémy s kompatibilitou (případně EEE). Souvisí to s tím předchozím bodem - když např. bude VCS obsahovat znalost datového modelu a někdo si někde datový model změní nebo se změní globálně, co se stane s VCS? Bude se muset přízpůsobit, což může mít prodlevu nebo se na to někdo vykašle a někdo jiný pak nebude moct používat VCS apod.

Precedenty pro tohle nejsou úplně dobré. Když např. vezmu v úvahu jakej porod byl Python 2 vs 3, a to přitom ani nebyly nijak velký změny.

Tyhle problémy do jisté míry nastávaj i s filesystémama, třeba kódování filename, ilegální znaky ve filename, max. velikost souboru, atributy a podobně. Ale tím, že FS je obecně tak primitivní, tak se to dá zvládnout.
Bystroushaak avatar 18.12.2018 23:08 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tohle trochu znám z JS, ačkoli to asi nebude úplně to samé. (JS je zmršený.) Nicméně popravdě pro téma diskuse mi to nepřijde podstatné...
JS je zmršený hlavně protože Eich nezkopíroval celý Selfový objektový model, hlavně pak delegaci.
Ok, dejme tomu, že píšu VCS pro takovýhle systém. V tom případě od něj potřebuju několik věcí: 1. Možnost porovnat objekty, jestli se změnily, abych věděl, který se změnil od posledního commitu, 2. Možnost vytvořit uživatelsky přívětivý diff objektu. U toho bodu 1. stojí za povšimnutí, že takovou operaci nemusí objekt poskytovat, příklad byl ten float, který sice (ne)rovnítko definuje, ale není použitelné pro VCS. Bod 2. ten float taky nenabízí, protože např. různé NaNy nebo některá čísla by se zobrazily stejně (asi by se muselo zobrazit číslo textově a zároveň hexa nebo něco takového).
V Selfu je tohle vyřešeno jednoduše: pomocí Transporteru skrz reflexi vyexportuješ všechny objekty tvořící konkrétní modul do jejich textového popisu. Ten pak můžeš diffovat a verzovat klasickým VCS. Je pravda, že ten diff nemusí být zrovna nejkrásnější, protože je to diff serializovaného kódu.

To porovnávání mi přijde jako nepochopení. Neporovnáváš přímo objekty, porovnáváš jejich reflexi. Místo abys porovnával nějaký svůj vlastní objekt jeho metodami, tak si zobrazíš co v něm je za sloty a jak se změnily.

Pokud bych to měl vznést na python, tak bys porovnával diff .__dict__-u, ale taky AST všech objektů v něm referencovaných, za předpokladu, že by byly homoikonické. Ale není to úplně dobrá příměra. Na úrovni VM můžeš přímo tagovat objekty, které se změnily od poslední verze, ale to už je docela velká optimalizace.

Smalltalk to řeší komplexněji, ale přiznám se, že detaily přesně neznám, to by bylo asi spíš na Pavla.
18.12.2018 23:45 Pavel Křivánek | skóre: 28 | blog: Kvičet nezávaznou konverzaci
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Smalltalk má vlastně oproti Selfu výrazně jednodušší práci, protože se v něm serializuje kód s jasně danou známou strukturou, nikoliv obecné objekty. Diff vypadá nějak takhle. Tedy, je to jen část pravdy, protože ve skutečnosti si Pharo obstarává diff pro merge a nahrávání kódu samo a nespoléhá se na výstup Gitu, který o sémantice kódu neví vůbec nic. Což je jen další důsledek toho, že ve Smalltalku jsou třídy a metody objekty, nikoliv mrtvý text v souborech, což koresponduje se smyslem tohoto blogového zápisku.
Tetris teaches that your successes disappear as soon as they happen, while your mistakes pile up until they kill you.
xkucf03 avatar 18.12.2018 23:57 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Sémantický diff, patch, transformace kódu.
Pharo obstarává diff pro merge a nahrávání kódu samo a nespoléhá se na výstup Gitu, který o sémantice kódu neví vůbec nic.

O tom jsem přemýšlel už víckrát, sémantický diff by byl pokrok po, těch desetiletích porovnávání řádků textu. Nástroj by mohl říct: tady se přesunula metoda z jedné třídy do druhé nebo tady se zvýšilo odsazení bloku, ale ten vnitřek je stejný.

Další zajímavá věc mi přijdou sémantické transformace kódu -- něco jako patch, ale šlo by třeba vzít kus jednoho programu a transplantovat ho do jiného a v rámci toho udělat nějaké transformace. A když by se změnila verze zdrojového programu, tak by to šlo prohnat tou transformací a buď by to s celkem velkou pravděpodobností prošlo nebo by to řeklo, kde přesně to na sebe nepasuje.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
19.12.2018 00:37 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sémantický diff, patch, transformace kódu.
tady se zvýšilo odsazení bloku, ale ten vnitřek je stejný
git diff -w ?
Josef Kufner avatar 19.12.2018 10:56 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Sémantický diff, patch, transformace kódu.
To sice občas pomůže, ale pořád je potřeba rozumět tomu kódu. Třeba v Pythonu je odsazení hodně podstatné a může zásadně měnit význam. V Javascriptu za určitých okolností také. I v jiných jazycích když přibudou mezery v nějakém víceřádkouvém stringu, je to něco jiného, než když jsou přidány v odsazení.

Pokud by diff rozuměl kódu a významu změn, mohl by spolehlivě mergovat různé dnešní konflikty, například přidání importů na stejné místo na začátku souboru, nebo odstranění jedné metody a přidání jiné na stejné místo. Nebo třeba přidávání položek do changelogu, kde na pořadí nijak nezáleží a prostě se připisuje na konec.
Hello world ! Segmentation fault (core dumped)
19.12.2018 12:19 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sémantický diff, patch, transformace kódu.
Třeba v Pythonu je odsazení hodně podstatné a může zásadně měnit význam.
Určitě bych nedoporučoval používat diff -w pro Python...
například přidání importů na stejné místo na začátku souboru
To třeba v Pythonu obecně nejde, protože import může provádět kód, ie. může záležet na pořadí. Můžeš celkem oprávněně namítnout, že je to prasárna, ale obecně prostě bohužel na pořadí importů záleží. AFAIK to samé platí pro importy v JS a nejde to obecně ani u headerů v C/C++ (protože preprocessor).
Nebo třeba přidávání položek do changelogu, kde na pořadí nijak nezáleží a prostě se připisuje na konec.
To si myslim, že obecně taky nebude fungovat, to bys musel mít sémantický changelog. Krom toho já třeba osobně typicky řadím položky v changelogu podle velikosti významu/dopadu.
Josef Kufner avatar 19.12.2018 13:06 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Sémantický diff, patch, transformace kódu.
Pokud přidáváš ve dvou větvích na stejné místo, je možno bezpečně předpokládat, že není pořadí těchto dvou změn podstatné. Ať už u Changelogu nebo u importů. Pokud by na pořadí záleželo, tak by ty změny nenastaly nezávisle na sobě, neboť by ta druhá změna nejspíš nefungovala bez té první.
Hello world ! Segmentation fault (core dumped)
19.12.2018 13:22 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sémantický diff, patch, transformace kódu.
To není pravda. Představ si dva lidi v týmu se rozhodnou naimportovat něco, co monkey-patchuje nějaký typ obecně používaný v daném projektu, s tím, že každý použije něco jiného a ty dvě věci jsou konfliktní (třeba přepisují stejnou metodu nebo něco).

Odhlédněme od toho, že je to prasárna a že existuje taková věc jako code-review, stále platí, že to pořadí nelze obecně libovolně zaměnit bez důsledků.
xkucf03 avatar 19.12.2018 13:47 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sémantický diff, patch, transformace kódu.

Jenže o to víc by ti sémantický diff pomohl. Protože kolize, která vznikne při textovém diffu, je jen náhodným vedlejším efektem toho, že oba autoři dali ty konfliktní metody zrovna na stejné místo v souboru. Ovšem kdyby dali ten konfliktní kód (např. metodu se stejnou signaturou) na dvě různá místa, tak textový diff/merge vesele projde.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
19.12.2018 13:53 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sémantický diff, patch, transformace kódu.
jj, s tim souhlasim, ono taky kdyby ty konfliktní importy byly přidaný každej na jinou řádku, tak to git taky vesele zmerguje. Byl jsem pouze proti tomu automagickému ignorování některých konfliktů, které není možné skutečně obecně ignorovat.
Josef Kufner avatar 19.12.2018 20:05 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Sémantický diff, patch, transformace kódu.
Ono stačí, aby oba přidali stejný import na různá místa. To by to mohlo odchytit také. Možná.
Hello world ! Segmentation fault (core dumped)
Josef Kufner avatar 19.12.2018 20:07 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Sémantický diff, patch, transformace kódu.
Nepočítáš s průběhem vývoje. Nejde o libovolné zaměňování pořadí, ale o sloučení dvou samostatně fungujících kódů.
Hello world ! Segmentation fault (core dumped)
19.12.2018 10:27 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To porovnávání mi přijde jako nepochopení. Neporovnáváš přímo objekty, porovnáváš jejich reflexi.
To je to samé, akorát je tam mezioperátor navíc.
V Selfu je tohle vyřešeno jednoduše: pomocí Transporteru skrz reflexi vyexportuješ všechny objekty tvořící konkrétní modul do jejich textového popisu. Ten pak můžeš diffovat a verzovat klasickým VCS.
Ok, tj. absence obecného porovnávní a diffu se vyřeší tím, že každý objekt/typ by měl operátor serializace do textu. Nicméně mi z toho stále není úplně jasné, jak by to fungovalo v případě toho VCS. V tom object storage systému by workspace nejspíše nebyla složka ale nějaký objekt, který bude mít fůru podobjektů. Navrhuješ serializovat celý ten workspace objekt do textu a na tom dělat diff? To doufám, že ne, ta serializace by mohla být obrovská (ie. bylo by to pomalý) a v tom diffu by se nejspíše navíc snadno ztratil kontext.

V podstatě jediné, co mi dává smysl, je procházet objekty (rekurzivně) a porovnávat textovou reprezentaci až pouze u primitivních typů. Což by asi v zásadě mohlo celkem fungovat, za předpokladu, že by existoval nějaký standard množiny primitivních typů a způsobu jejich jednoznačné serializace do textu. Ale nevim, jestli jsem schopen vidět všechny důsledky a víc nad tim asi nebudu teď dumat.
19.12.2018 10:30 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ale zamýšlel ses někdy proč ti to tak přijde? Jaké to má opodstatnění a jestli to vůbec dává nějaký smysl? Co jsou alternativní přístupy? Jestli by to třeba nešlo dělat líp, případně jaké by to přinášelo benefity?
To, že je to základní a jednoduchý systém mi přijde zjevné a myslím, že z toho vychází i tvoje kritika, ne? Mě to navíc přijde intuitivní, protože se to podobá tomu, jak se věci ukládají v reálném světě - mám skřín, v ní šuplíky, v těch přihrádky, krabičky a tak (a i přesto jsem setkal s několika jinak inteligentními lidmi, kterým to dělalo problém - pravda, většinou z generace mých prarodičů). Samozřejmě, že počítač umožňuje mnohem větší abstrakci. Těch alternativ by se dalo vymyslet dost. Jenže aby nějaká měla šanci na to se uchytit, tak by musela být obdobně intuitivní. Vím, že na to koukáš jako programátor, ale aby to, co navrhuješ mělo nějaký smysl, muselo by to být hodně rozšířené, tudíž by se s tím setkali i naprostí BFU.

Technicky se mi idea souborů a složek líbí proto, že je to nízkoúrovňové řešení, které mi dává větší svobodu dělat co chci, než to, co navrhuješ (třeba nad těmi soubory postavit něco na způsob toho, co navrhuješ). Cenou je samozřejmě víc práce, jak píšeš.

Už několikrát u téhle diskuze jsem si vzpomněl na to, jak tohle řeší Android - hledá všechny soubory určitého typu a pak jejich seznam předá patřičné aplikaci. To je taky jedna z alternativ ke klasickému FS nad klasickým FS. Mě to sice přijde vyloženě nešikovné (třeba proto, že mezi fotky se mi neustále cpou obrázky odjinud), ale dost lidem asi to vyhovuje.

Další alternativa se kterou jsem se setkal, jsou už v diskuzi zmiňované datasety na mainframu. Moc do hloubky jsem se s nimi neseznámil, ale jak tu také bylo zmíněno, tak alespoň něco z toho, co navrhuješ je v nich realizováno a bylo to tu dřív než třeba vůbec vznikl Linux.
Bystroushaak avatar 19.12.2018 11:52 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To, že je to základní a jednoduchý systém mi přijde zjevné a myslím, že z toho vychází i tvoje kritika, ne? Mě to navíc přijde intuitivní, protože se to podobá tomu, jak se věci ukládají v reálném světě - mám skřín, v ní šuplíky, v těch přihrádky, krabičky a tak
To právě nemáš. Současný systém odpovídá stylu, kdy máš skříň, ve které máš list papíru a další skříň, ve které máš zase list papíru. Když do ní chceš uložit špendlík, tak ho musíš převést na list papíru a když tam chceš mít krabičku třeba na šperky, tak nemůžeš a musíš místo ní použít další skříň. Tvůj systém totiž umí ukládat jen skříně a listy papíru, protože je to nejvíc univerzální a jednoduché.. Když chceš dostat zpět špendlík, tak potřebuješ program, který ti z listu papíru udělá zpět špendlík.
Josef Kufner avatar 19.12.2018 12:16 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To není úplně dobrá analogie. Ta skříň tomu listu papíru nerozumí úplně stejně jako nerozumí špendlíku. Prostě je to obojí neinterpretovaný blob čehosi.

O tom filesystém je. On nijak neinterpretuje co mu svěříš. Nechá tě uložit bloby dat proměnlivé velikosti s trochou metadat do hierarchicky uspořádaných jmenných prostorů. Díky tomu nemusíš řešit, jak alokovat místo na nějakém zařízení, že to místo nemusí být souvislé, jak komunikovat s různými zařízeními různých vlastností, … To je hrozně moc práce, kterou ti file systém ušetří a je na tobě, aby jsi si nad tím něco postavil – třeba tu databázi.

Další problém je, že nejde jen o uložení a uspořádání. Jde i o API. SQL databáze má úplně jiné API než filesystém. Jak bys vůbec namapoval dotaz do databáze na nějakou obecnou strukturu?
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 19.12.2018 12:38 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jak bys vůbec namapoval dotaz do databáze na nějakou obecnou strukturu?

Sorry, že vytahuji zase to XML :-), ale kdyby sis představil souborový systém jako obrovské XML, kde neexistuje hranice mezi adresáři/soubory a obsahem těch souborů a celé to tvoří jeden strom, tak bys nad tím mohl dělat XPath dotazy a pracovat se zcela obecnými strukturami. Je jedno, jestli by to byl textový dokument, tabulka, obrázek s metadaty... prostě to jsou stromová data, jsou tam nějaké názvy atributů a ty si nad nimi můžeš psát dotazy.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Josef Kufner avatar 19.12.2018 13:09 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tím ale zas narušíš zapouzdření objektů a spousta věcí se ti rozbije. Například dotaz na rodiče v XML souboru vrátí nějaký nadřazený bordel kdo ví odkud.

Dokud by se pracovalo se souborem o stromové struktuře zařazeného do stromového filesystému, tak by to možná ještě nějak šlo, ale co v situaci, kdy soubor bude obsahovat obecný graf?
Hello world ! Segmentation fault (core dumped)
1.1. 13:48 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Na první pohled to vypadá hezky, ale prakticky by to mělo velkou režii. Bylo třeba budovat a udržovat spoustu indexů, a k tomu držet spoustu metadat, které XML datový model vyžaduje. A to nemluvím o tom, že způsob fyzického uložení toho XML by výrazně určovalo, co by s tím reálně šlo dělat a co ne.

Ale je to hezký námět na experiment :)
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
Bedňa avatar 1.1. 14:31 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ale toto už existuje a volá sa to MariaDB a podobne :)
KERNEL ULTRAS video channel >>>
1.1. 14:44 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Netvrdím, že nikdo nepřidal nějakou XML podporu do databáze nebo že neexistují XML databáze. Mluvím o nápadu zkonvertovat každý soubor ve filesystému do XML a pak to všechno mít jako jedno velké XML. A nepřijde mi to úplně praktické.

Btw zrovna ta MariaDB umí jen nějaké základní tabulkové XML mapování, takže by na tohle asi ani nešla použít (to by záleželo na struktuře XML souborů).
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
Bedňa avatar 1.1. 14:49 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ja som nemyslel priamo XML, ale tú analógiu štrukturovaných dát a prácu s nimi.
KERNEL ULTRAS video channel >>>
xkucf03 avatar 1.1. 15:05 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Mluvím o nápadu zkonvertovat každý soubor ve filesystému do XML a pak to všechno mít jako jedno velké XML.

Tohle je nereálné -- už jen kvůli zápisům a fragmentaci dat. Muselo by se to implementovat jako nějaká stromová/grafová databáze a XML/XPath by bylo jen API (virtuální pohled na data), kterým by se k tomu dalo přistupovat. Nicméně připomínám, že to API opravdu nemusí emulovat XML a XPath -- byl to jen příklad pro představu.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
1.1. 15:11 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jo, to je samozřejmě pravda. Měl jsem dodat, že předpokládám uložení toho XML v nějaké XML databázi.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
xkucf03 avatar 1.1. 14:38 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

XML byl jen příklad, aby si to ostatní mohli nějak představit. Obecně řečeno jde ale o to, že dokument (libovolný, ne jen XML) je stromová struktura, souborový systém je taky stromová struktura. A v tomto pojetí se ztratí hranice mezi těmito dvěma stromy a stane se z nich strom jeden, se kterým jde pracovat jednotným způsobem (např. nějakým dotazovacím jazykem, kde XPath je opět jen příklad).

Z hlediska výkonu by se nad tím musely implementovat nějaké optimalizace podobné partitioningu v relačních databázích (např. máš tabulku fyzicky rozsekanou po letech, takže když dotaz pracuje jen s daty jednoho roku, databáze ví, kam sáhnout a nemusí prohledávat všechno -- ale ten logický pohled ze strany uživatele tím není nijak dotčený, ten s tím pracuje jako s jednou velkou tabulkou).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
1.1. 15:00 marbu | skóre: 30 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jo, jako příklad je to pěkné. Dobře se to přestavuje a na malém příkladu by to šlo udělat i demo.

Ale právě díky tomu, že je dokument je v podstatě libovolná stromová struktura by ty optimalizace, co by to vyžadovalo, musely být ještě složitější než v relačních databázích a prakticky by to byl dost problém.

Stačí se podívat na výsledky XMark benchmarku pro různé XML databáze. Ty performance charakteristiky nejsou triviální. A při testu na 1GB XML už jsou některé typy dotazů vyloženě nepraktické.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
19.12.2018 12:22 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To je blbá analogie. Ty skříně ve FS můžou mít libovolnou velikost, ie. skřín a krabička je to samé.

Jinak kdyby se papír dal převádět na špendlík a zpátky tak snano jako otevření/uložení souboru nějakého typu, neviděl bych to jako velký problém.
Bystroushaak avatar 19.12.2018 15:04 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To je blbá analogie. Ty skříně ve FS můžou mít libovolnou velikost, ie. skřín a krabička je to samé.
Krabička může být barevná, může mít různé vlastnosti, jako zdobení a vyřezávání. Skříň je uniformní a může mít tak leda název a přístupová práva.

Samozřejmě tady ta analogie končí, protože co do prostoru už to moc neodpovídá.
Jinak kdyby se papír dal převádět na špendlík a zpátky tak snano jako otevření/uložení souboru nějakého typu, neviděl bych to jako velký problém.
Záleží jak definuješ velký problém. Například ten list papíru se složí na různý špendlík, podle toho jestli se na něj díváš z toho či onoho programu. Navíc neplatí, že „se složí“, ale musíš ho skládat a rozkládat ty.
19.12.2018 15:17 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Krabička může být barevná, může mít různé vlastnosti, jako zdobení a vyřezávání. Skříň je uniformní a může mít tak leda název a přístupová práva.
Skříň by taky mohla mít barvu, vyřezávání... nevim, tohle asi nechápu. Šlo mi o to, že ta analogie na skříň je blbá v tom, že skříň je něco nějak víceméně fixně velkého. Ale filesystémy umožǔjí skříně libovolné velikosti, ie. není to tak nešikovné, jako kdyby musel fakt na všecko mít skříň. Ale je pravdva, že se v zásadě nebudou lišit ničím krom velikosti (a nějaké ACL ale to tady neřešim).
Navíc neplatí, že „se složí“, ale musíš ho skládat a rozkládat ty.
Obvykle to za mě dělá program / knihovna ¯\_(ツ)_/¯
Bystroushaak avatar 19.12.2018 15:25 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Skříň by taky mohla mít barvu, vyřezávání... nevim, tohle asi nechápu.
Myslel jsem že je docela jasné, že skříň je analogií složky, list papíru pak souboru. Složka nemůže sama o sobě obsahovat nic jiného, než soubory a pár atributů (práva, ..). To se liší od OO jazyků tím, že objekt agregující jiné objekty může mít sám o sobě i property a poskytovat funkcionalitu.
Obvykle to za mě dělá program / knihovna ¯\_(ツ)_/¯
To že na to máš nástroj tu (zbytečnou) činnost ale neeliminuje.
Bystroushaak avatar 19.12.2018 15:26 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Složka nemůže sama o sobě obsahovat nic jiného, než soubory a pár atributů (práva, ..).
A další složky samozřejmě.
19.12.2018 16:08 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To že na to máš nástroj tu (zbytečnou) činnost ale neeliminuje.
Mně ta činnost nepřijde zbytečná, zajišťuje, že můžu vzít 'něco' a poslat to někam do tramtárie, kde si to někdo otevře nějakým úplně jiným softwarem v jiným jazyku na jiném systému. A ten někdo ani nemusí být někdo jiný, můžu to být já za 5, 10, 20, let etc.

Další věc je, že i když budeš chtít tuhle činnost eliminovat, IMHO se ti to podaří jen částečně, k nějaké transformaci formátů bude IMHO muset docházet tak jako tak, a navíc to pak taky může být vykoupeno tím, že třeba budeš moct ukládat do skříně špendlík skutečně jako špendlík, ale bude to fungovat jen u skříní Ikea a s tím špendlíkem se bude dát propichovat jen látka z Ikea v rukavicích z Ikea na pracovním stole z Ikea.
Bystroushaak avatar 19.12.2018 16:50 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Mně ta činnost nepřijde zbytečná, zajišťuje, že můžu vzít 'něco' a poslat to někam do tramtárie, kde si to někdo otevře nějakým úplně jiným softwarem v jiným jazyku na jiném systému. A ten někdo ani nemusí být někdo jiný, můžu to být já za 5, 10, 20, let etc.
V tom ti ale nic nebrání i tak, ne? Eliminace nucené serializace by přece nevedla k tomu, že tu serializaci nemůžeš provést vůbec.
19.12.2018 17:47 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To je těžko říct bez nějaké konkrétní představy. Třeba u toho Selfu nebo Smalltalku se mi to moc nelíbí jak je to řešené.
xkucf03 avatar 19.12.2018 17:22 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Objektový OS
Skříň by taky mohla mít barvu, vyřezávání... nevim, tohle asi nechápu. Šlo mi o to, že ta analogie na skříň je blbá v tom, že skříň je něco nějak víceméně fixně velkého.

Modelování a abstrakce v počítači má tu vlastnost, že neodpovídá 1:1 realitě a ani to není cílem. Cílem je vystihnout nějaké podstatné rysy a ty namodelovat v počítači a tento model použít nějakým užitečným způsobem.

Takže v případě FS je podstatné to, že máme různé skříňky, můžeme dávat jednu do druhé a dovnitř nějaké předměty. Barva skříněk, jejich velikost a omezení fyzického světa "jestli se to tam vejde" nejsou součástí modelu, abstrahujeme od nich. Naopak vznikají jiná omezení jako např. celková hmotnost (to si lze představit tak, že podlaha má nějakou nosnost a když tam těch věcí nanosíme moc, tak se propadne).

a nějaké ACL ale to tady neřešim

Zrovna to by ale chtělo. V objektovém programovacím jazyce může s objektem dělat každý cokoli -- stačí, aby měl na něj referenci. Jsou tu sice nějaké bezpečnostní mechanismy jako SecurityManager nebo role v EE javě, ale většinou se to moc neřeší a když máš referenci na objekt a zavoláš na něm metodu, tak objekt poslušně vykoná kód (resp. ono ho vykoná aktuální vlákno, ale to teď nechme stranou) a vrátí klidně i soukromá data.

Jak by to mělo být v objektovém OS? Byl by to objekt souboru, kdo by rozhodoval, zda vrátí např. obsah souboru, nebo by tam byl někdo třetí, kdo by říkal, jaké metody může kdo volat?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
19.12.2018 17:42 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Objektový OS
V objektovém programovacím jazyce může s objektem dělat každý cokoli -- stačí, aby měl na něj referenci.
Ve slušných jazycích existují imutabilní reference... (Ale jasně, není to to samé, co ACL.)
19.12.2018 15:00 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nikoli. Víceméně to za mě napsali níž jiní. Papír i špendlík se z hlediska mého úložného systému liší jen velikostí. To, na co potřebuju speciální program je to, co s tou věcí chci dělat. Samozřejmě to dopadne špatně, když si budu chtít na špendlík napsat nějaké poznámky. Ale to jen analogie. Když se to s nima přežene, tak taky dopadá špatně. Pointou bylo, že třídění do přihrádek je něco, co jsem znal už před tím, než jsem poprvé viděl počítač (a ten mimochodem vůbec FS neměl :) ).
Bystroushaak avatar 19.12.2018 15:07 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Filesystém neumožňuje uložit strukturu. Umožňuje uložit jen obecný proud bajtů. Když chceš uložit špendlík, filesystém vůbec nemá tušení, jak to udělat. Doslova se do něj nedá ani na úrovni API vložit a tvůj program ho musí převést na něco, čemu bude FS rozumět.

Jinak ano, analogie mají svoje omezení, přesto jsou užitečné na předávání myšlenek. A zrovna tady mi přijde, že se možná nechápem.
19.12.2018 16:21 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Asi nechápem - pro mě je špendlík a papír věc - na straně FS hromada bytů. Skřín, krabička složka. Když chci uložit špendlík dám do krabičky a tu do šuplíku. Obdobně, když chci uložit obrázek (což je z pohledu FS hromada bytů), tak ho jakožto soubor dám do složky. Takle jsem to od začátku myslel. Ano má to svoje omezení (když si zapsat na papír poznámku, tak buď musím vědět, kde přesně ten papír je, nebo musím mít nástroj na rozlišení papíru od špendlíku, jinak můžu začít psát poznámky na špendlík). Ale tohle jsem tou analogií vůbec nechtěl řešit. Její aplikace končí u zdůvodnění toho, proč mi soubory a složky přijdou intuitiviní a tím je to, že něco podobného znám z reálného světa. Nejen proto, jak naznačuješ ty, že bych nic jiného neznal. Je to jen analogie, ne isomorfismus :)
Bystroushaak avatar 19.12.2018 16:55 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Asi nechápem - pro mě je špendlík a papír věc - na straně FS hromada bytů. Skřín, krabička složka. Když chci uložit špendlík dám do krabičky a tu do šuplíku. Obdobně, když chci uložit obrázek (což je z pohledu FS hromada bytů), tak ho jakožto soubor dám do složky. Takle jsem to od začátku myslel.
Já chápu, že jsi to tak myslel. Ale ta tvoje krabička neumí uložit papír, nebo špendlík. Umí uložit jen papír (bajty). To jsem se právě snažil ukázat, že abys na něj mohl cokoliv uložit, musíš z toho udělat to co to umí uložit.
Obdobně, když chci uložit obrázek (což je z pohledu FS hromada bytů), tak ho jakožto soubor dám do složky.
Obrázek právě vůbec není hromada bajtů. Jsou to kanály a informace o barvě a křivky a kde co. To že tvůj FS umí uložit jen hromadu bajtů je právě tak nějak celá pointa. Do složky ho skutečně dáš jako soubor (v té mé analogii papír), ale předtím z něj ten soubor musíš udělat. A kdykoliv kdy s ním chceš pracovat, tak musíš tuto činnost reverzovat. Nikoliv jen vytáhnout obrázek z umístění, ale vytáhnout z umístění papír a pak ho podle návodu převést zpět na obrázek.

Co jsem se tím snažil ukázat je, že ve skutečnosti je to co obhajuješ ztrátové a záměrně tupé.
19.12.2018 17:16 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Moje krabička umí uložit předmět. Ale to je právě to, kam jsem tu analogii nechtěl rozvíjet. Mě šlo o tu strukturu přihrádek, především v kontrastu s databázovým přístupem.

Ten obrázek na určité úrovni je a vždy bude hromada bytů. Ano je to záměrně tupé a to je to, co se mi tom líbí (asi jako kladivo, to je taky velmi tupý, ale velmi užitečný nástroj). O úrovneň (jednu nebo i víc) výš je obrázek to, co popisuješ. Vždycky budou potřeba nástroje na přechod mezi těmito úrovněmi. Současný stav, kdy ten nástroj funguje na tou tupou haldou bytů mi přijde celkem dobrý. Třeba proto, že je to celé dobře kombinovatelné (způsob uložení a zpracování).

Současný způsob mi oproti tomu, co navrhuješ nepřijde nijak zásadně ztrátový, rozdíl vidím v tom, kde budou ty nástroje pro přechod mezi vrstvami. Nějak nevidím důvod pro to, aby kód pro dekódování (např.) png měl být někde ve FS, místo toho, aby byl v knihovně. To, že aktuálně mám ten kód v počítači pravděpodobně několikrát není na diskuzi o FS, ale nějaké standardizaci a hlavně jejím prosazení.
13.12.2018 15:41 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Souborový systém není z uživatelského hlediska nic jiného než artefakt. Je to jednoduše pochopitelná analogie, ale neexsituje důvod, proč bys mohl mít jen adresáře a soubory (a symlinky a pipy) a ne libovolně typované záznamy s relacema a triggerama a atomickým zápisem.

To není žádný artefakt, to je prostě řešení, které se někdo obtěžoval implementovat a které dalším připadalo natolik přínosné, že ho používají. Až (jestli) implementujete tu svou vizi (nebo si na to někoho najmete) a najde se dostatek lidí, kteří ji budou považovat za natolik užitečnou, aby ji používali, bude to po vašem. A za dalších 30 bude třeba někdo psát pojednání o tom, jak je ten váš model artefakt, ke kterému neexistuje žádný důvod, proč by to zrovna takhle mělo být.

V tradičním světě, tedy světě před Lennartem Poetteringem, bylo pravidlem, že svou životaschopnost a užitečnost nemuselo prokazovat existující řešení, ale řešení nové. Za tu "sérii experimentů" se považovalo právě to, že už příslušný model spousty uživatelů dost dlouho používají. To nové řešení muselo prokázat, že je dostatečným přínosem, aby uživatelům stálo za to na něj přejít, i když to znamená, že budou muset občas něco předělat, a že případná ztráta některých funkcí je přijatelnou obětí.

Svým způsobem je třeba i libovolná databáze příkladem toho, že může mít rozhraní, které vám umožní přistupovat k datům odlišným způsobem (a ten filesystém pod ní není ani nutný). Ale zatím se buď nikdo nepokusil použít databázi (nebo něco podobného) jako náhradu místo klasického filesystému a nebo s tou myšlenkou nebyl příliš úspěšný.

Bystroushaak avatar 13.12.2018 16:28 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To není žádný artefakt, to je prostě řešení, které se někdo obtěžoval implementovat a které dalším připadalo natolik přínosné, že ho používají.
Jen technická, object storage (což je tak nějak skoro to co chci, akorát to nativně ukládá XML/JSON/YAML a ne objekty) dneska vystrkuje růžky naprosto všude a v podstatě každý cloud ho poskytuje. Je jen otázka času, než to bude běžné i na desktopu.
Až (jestli) implementujete tu svou vizi (nebo si na to někoho najmete) a najde se dostatek lidí, kteří ji budou považovat za natolik užitečnou, aby ji používali, bude to po vašem. A za dalších 30 bude třeba někdo psát pojednání o tom, jak je ten váš model artefakt, ke kterému neexistuje žádný důvod, proč by to zrovna takhle mělo být.

V tradičním světě, tedy světě před Lennartem Poetteringem, bylo pravidlem, že svou životaschopnost a užitečnost nemuselo prokazovat existující řešení, ale řešení nové. Za tu "sérii experimentů" se považovalo právě to, že už příslušný model spousty uživatelů dost dlouho používají. To nové řešení muselo prokázat, že je dostatečným přínosem, aby uživatelům stálo za to na něj přejít, i když to znamená, že budou muset občas něco předělat, a že případná ztráta některých funkcí je přijatelnou obětí.
Jo, jo, mě tohle nezajímá. To je právě to co jsem naschvál psal na začátek. Mě je úplně jedno, co používáš ty, nebo ostatní. Klidně používej Linux, ostatně vždyť já ho taky používám. Přijde mi, že máš pocit jak kdyby ti něco ubylo.

Snažím se přemýšlet nad něčím jiným. Formou slov a reakcí v diskuzi. Představ si tuhle nesmyslnost třeba v případě domu. Vysníš si a popíšeš někde hobití noru s kulatýma dveřma a spíží na koláče a pak někdo přijde a bude ti říkat, že je to nahovno, že to není životaschopné a že životaschopné to bude, až v tom bude žít víc lidí než v bytovkách. A že v bytovce můžeš mít skříň na koláče a na dveře si namalovat kolo, abys měl aspoň podobný pocit.

Mně fakt upřímě naprosto vůbec nezajímá proč to nejde, ani jak se to dá obejít. Vážně. Mám přes deset let zkušeností s IT, z toho asi pět let komerčně je to moje každodenní práce. Obcházím to každou chvíli. Dělal jsem všechno od psaní v assembleru, v C, Javě, C#, Python až po common lisp. Já vím, že a proč co konkrétně jde a nejde. To že jsem sepsal tuhle kritiku není naivita, naopak je to promyšlená ignorace a fakace současného standardu.
Svým způsobem je třeba i libovolná databáze příkladem toho, že může mít rozhraní, které vám umožní přistupovat k datům odlišným způsobem (a ten filesystém pod ní není ani nutný). Ale zatím se buď nikdo nepokusil použít databázi (nebo něco podobného) jako náhradu místo klasického filesystému a nebo s tou myšlenkou nebyl příliš úspěšný.
Smalltalk používal koncept image paměti a úspěšný s tím byl. Gemstone (objektová databáze) je business dodneška. Kdyby se víc soustředili na to aby to byl operační systém, místo programovací prostředí, tak by to nejspíš spousta lidí používala i poté, co
Bystroushaak avatar 13.12.2018 16:29 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Smalltalk používal koncept image paměti a úspěšný s tím byl. Gemstone (objektová databáze) je business dodneška. Kdyby se víc soustředili na to aby to byl operační systém, místo programovací prostředí, tak by to nejspíš spousta lidí používala i poté, co
.. i poté, co Smalltalk jako jazyk upadl do nemilosti a byl nahrazen javou.
Heron avatar 13.12.2018 17:06 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jen technická, object storage (což je tak nějak skoro to co chci, akorát to nativně ukládá XML/JSON/YAML a ne objekty) dneska vystrkuje růžky naprosto všude a v podstatě každý cloud ho poskytuje. Je jen otázka času, než to bude běžné i na desktopu.
Tak na desktopu to můžeš mít už min. 13 let (CouchDB), není to nic nového. XML umí (z počátku asi zejména komerční) DB exportovat asi i déle. Dneska si můžeš vybrat hromadu "providerů" pro tyto objekty, ať buď z řady nosql db (které si většinou z CAP teorémů odstraní to C) nebo klasické transakční ACID db.
Bystroushaak avatar 13.12.2018 17:17 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Já vím že to můžeš mít, psal jsem že je otázkou času kdy to bude běžné. Tedy nainstaluješ distribuci a už to tam bude, stejně jako je tam třeba interpret pythonu, nebo sqlite.
xkucf03 avatar 13.12.2018 17:22 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

Teď jsem si vzpomněl na věci jako Nepomuk, Akonadi... myšlenky hezké, ale lidi to spíš sralo.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Bystroushaak avatar 13.12.2018 18:17 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Mně na KDE sralo tak nějak všechno, hlavně však provedení grafického rozhraní, které často (neříkám že vždy) vypadalo jak výplod chovanců polepšovny. Přitom funkcionalita byla často dobrá.
14.12.2018 06:56
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
+1
14.12.2018 16:14 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tak tomu moc nerozumím, vzhledem k tomu, jak diametrálně odlišně vypadají různé styly. Ty defaultní mne poslední dobou taky moc neoslovují, ale naštěstí je pořád k dispozici nějaký Plastic / Clearlooks, který vypadá rozumně.
Bystroushaak avatar 14.12.2018 18:03 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nejde jen o styly, ale o celkové rozložení prvků a plýtvání prostorem. To je taková divná KDE specialita.
Heron avatar 13.12.2018 19:09 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
A jaký má smysl taková podmínka, když si libovolný program do většiny distribucí nainstaluješ jedním příkazem? Navíc ani ten sqlite není by default všude, stejně jako další věci (perl, ruby). Distro od distra se to bude lišit a jistě bude existovat i takové, kde bude by default naistalováno třeba MongoDB.

13.12.2018 22:59 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Já to chápu spíš jako nářek na nejednotnost (a v jistém smyslu i nevyspělost) softwarového průmyslu – pokud tomu vůbec můžeme říkat průmysl. Čili nejde jen o to, aby bylo dostupné něco lepšího, ale také aby to používala kritická masa uživatelů a vývojářů.

Onehdá jsem potřeboval naskriptovat otevření URL v konkrétním okně Chromu a tvrdě jsem narazil. Buď bych musel opatchovat a překompilovat X server, nebo si před něj představit proxy, protože eventům (jako je např. stisknutí klávesy), které jsem do těch oken zkoušel posílat, nastavuje flag, že ta zpráva pochází od 3rd party programu, a většina programů pak takové eventy zahazuje z bezpečnostních důvodů. A takových zkušeností mám vícero.

Já se přiznám, že tomu blogpostu moc nerozumím a přijde mi nedostatečně konkrétní (už jsme se o tom s Bystroushaakem docela dlouze bavili na IRC, nechce se mi to celé opakovat). Ultimátně si ale myslím, i v kontextu s jeho předchozími blogy o reflexi uživatelských rozhraní a o „vytváření prostorů otevíráním dimenzí“, že se v podstatě (kromě jiného) dotýká i otevřenosti software, ale míchá do toho i další věci. (Na druhou stranu, možná právě díky tomu je diskuze pod tímto blogem mimořádně kvalitní.)

Ono totiž: Mít k něčemu zdrojové kódy není žádná metrika toho, jak moc je náročné něco „ohnout“. V ideálním případě by každý program poskytoval veškeré API, které by někdy někdo mohl potřebovat. V praxi se to z pochopitelných důvodů neděje. Jenže jak si potom poradit? Už jen něco jako AppleScript by otevřelo úplně nové možnosti. Není to optimální a takový skript se může snadno rozbít, ale cena na jeho výrobu je velmi nízká a bude okamžitě sloužit.

S daty je to hodně podobné. Kdybys chtěl sbírat články ze zpravodajských webů v nějaké sémantické podobě, tak se bez machine learningu prostě neobejdeš. Přitom by to skoro vždy šlo popsat jedním univerzálním formátem (schématem), který jasně rozliší mezi titulkem, perexem, jménem autora, datem vydání, hlavním tělem textu, doplňujícím sloupcům s informacemi apod. S tím se nic nenadělá, ale frustrující to je, protože to možnosti omezuje dost zásadně.
Heron avatar 13.12.2018 23:27 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Čili nejde jen o to, aby bylo dostupné něco lepšího, ale také aby to používala kritická masa uživatelů a vývojářů.

Tak ona je otázka, zda se skutečně jedná o něco lepšího (podle jaké metriky se to měří?) a taky zda to něco lepšího využije dostatečný počet uživatelů. Jinými slovy, těch unikátních použití OS bude takové množství, že jakákoliv instalace bude pro velmi významnou skupinu nedostatečná. Podle mě je lepší dívat se na to, co je k disposici v repozitáři než na to, co je ve výchozí instalaci.
Onehdá jsem potřeboval naskriptovat otevření URL v konkrétním okně Chromu a tvrdě jsem narazil. Buď bych musel opatchovat a překompilovat X server, nebo si před něj představit proxy, protože eventům (jako je např. stisknutí klávesy), které jsem do těch oken zkoušel posílat, nastavuje flag, že ta zpráva pochází od 3rd party programu, a většina programů pak takové eventy zahazuje z bezpečnostních důvodů. A takových zkušeností mám vícero.
Upřímně řečeno nevím, proč by něco takového mělo vůbec projít. Nevím, proč by měl mít program možnost posílat stisky kláves do jiného programu. To je interface vyhrazený uživateli. Pamatuji se, jak jsem byl zděšen programem od kámoše, který scanoval obraz a posílal klávesy do jiného programu (tehdy to běželo jako administrator na Windows, netuším zda by to prošlo pod omezenými právy) a viděl jsem v tom velké bezpečností riziko.
Na druhou stranu, možná právě díky tomu je diskuze pod tímto blogem mimořádně kvalitní.
Souhlasím a jsem za tuto diskusi rád.
Přitom by to skoro vždy šlo popsat jedním univerzálním formátem (schématem), který jasně rozliší mezi titulkem, perexem, jménem autora, datem vydání, hlavním tělem textu, doplňujícím sloupcům s informacemi apod.
Ano, ono by to šlo a nebyl by to žádný problém, ale tohle je přesně to, co vydavatelé těch zpráv nechtějí. Jak už jsem psal v jiné diskusi. I kdyby existoval dokonalý a sebepopisný formát, tak by jej stejně kritické množství zpravodajských webů nepoužívalo.
Bystroushaak avatar 14.12.2018 00:15 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nevím, proč by měl mít program možnost posílat stisky kláves do jiného programu.
Lehce OT, ale tohle mi prochází přes (Jendou porazené) xdotool type '{}', kde {} je znak.
Heron avatar 14.12.2018 00:28 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
No já vím, že to jde (takových věcí existuje, např. java.awt.Robot). Ale nevím jak ještě expresivněji vyjádřit, jak moc se mi to nelíbí. Mezitím někteří požadují ještě silnější ovládání oddělených programů. Na jedné straně si tady hrajeme na oddělení paměti a procesů různých programů, na straně druhé se v klidu umožní libovolnému programu číst grafický výstup jiného programu (a to i spuštěného pod jiným uživatele) a navíc jeho ovládání.
xkucf03 avatar 14.12.2018 00:42 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

IMHO by to jít mělo, ovšem ne nějak mimochodem, ale řízenou cestou -- tak, abys k tomu mohl nastavit práva (a ve výchozím stavu by to bylo zakázané, zejména u těch programů jiných uživatelů). Ono i v rámci jednoho uživatele by mělo být možné pouštět programy v různých bezpečnostních kontextech/úrovních a data by neměla prosakovat mezi nimi. (takový Bell–LaPadula model)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
14.12.2018 01:00 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tak ona je otázka, zda se skutečně jedná o něco lepšího (podle jaké metriky se to měří?)
Beru to čistě ze subjektivního hlediska.
a taky zda to něco lepšího využije dostatečný počet uživatelů. Jinými slovy, těch unikátních použití OS bude takové množství, že jakákoliv instalace bude pro velmi významnou skupinu nedostatečná. Podle mě je lepší dívat se na to, co je k disposici v repozitáři než na to, co je ve výchozí instalaci.
To si možná nerozumíme. Myslel jsem to tak, že když si nainstaluju třeba tu CouchDB (slyším poprvé, mimochodem), tak je mi to v kontextu této diskuze k ničemu, pokud to nebude interoperabilní se zbytkem světa. Tady je cílem zřejmě zbavit se souborů z uživatelského i programátorského hlediska (je jedno, jestli to bude jen abstrakce nad FS). No a toho se ti nepodaří docílit, protože chybí software, který by na tuto hru přistoupil a opíral se jen o tu CouchDB.

IMO nejde o to, jestli to je nebo není nativní součástí OS. Emacs taky není, ale přesto kolem něj existuje aktivní komunita, díky které to má reálně nějaké možnosti a výhody oproti jiným editorům. Ale kdyby neexistovala? Bylo by hezké, že existuje projekt, který teoreticky umí hromadu věcí, pokud by sis musel sám přidávat syntax highlighting pro každý soubor, který kdy otevřeš, a psát všechny pluginy. A takhle vnímám situaci okolo toho objektového desktopu.
Upřímně řečeno nevím, proč by něco takového mělo vůbec projít. Nevím, proč by měl mít program možnost posílat stisky kláves do jiného programu. To je interface vyhrazený uživateli. Pamatuji se, jak jsem byl zděšen programem od kámoše, který scanoval obraz a posílal klávesy do jiného programu (tehdy to běželo jako administrator na Windows, netuším zda by to prošlo pod omezenými právy) a viděl jsem v tom velké bezpečností riziko.
Bezpečnostní riziko to je zcela určitě, což je ostatně i důvod, proč to nejde, ale to tu považuji za lehce podružný problém, protože by to šlo řešit nějakou autentizací (explicitně povolit posílání takových zpráv v konkrétních případech).

Pointou je, že některé programy (často i FOSS) jsou pro mě vlastně uzavřené krabice. Co by se mi ještě vyplatilo nějak ubastlit à la AppleScript se mi už nevyplatí řešit patchem a mergnutím do mainstreamu (i kdyby byla nějaká šance, že to vývojáři akceptují).
Ano, ono by to šlo a nebyl by to žádný problém, ale tohle je přesně to, co vydavatelé těch zpráv nechtějí. Jak už jsem psal v jiné diskusi. I kdyby existoval dokonalý a sebepopisný formát, tak by jej stejně kritické množství zpravodajských webů nepoužívalo.
Jsem si toho vědom, ale přesto se mi to nelíbí a pokud vím, tak Bystroushaakovi taky ne. S tím se asi nedá nic dělat, jen jsem zkoušel ze svého hlediska vysvětlit, jak chápu jeho postoj já.
Heron avatar 14.12.2018 11:19 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Myslel jsem to tak, že když si nainstaluju třeba tu CouchDB, tak je mi to v kontextu této diskuze k ničemu, pokud to nebude interoperabilní se zbytkem světa.

No jasně, jenže tato věta se dá napsat na téměř libovolný program. A podle mého názoru je způsobů použití OS tolik, že v podstatě každé jeho použití je silně menšinové a nikdy nedosáhne kritické masy k tomu, aby se vyplatilo všude by default instalovat něco. Proto taky vznikají specializované distribuce připravené pro jednu oblast (třeba do zvukového studia) a vedle toho jsou obecné distribuce, kam si může kdokoliv doinstalovat co potřebuje.

Dole se někdo pozastavuje nad tím, proč neexistuje jednotný standard pro nastavení sítě, uživatelů, kvót, balíčků apod. No neexistuje, protože nelze říct, jak by to mělo správně vypadat. Zcela jiné nastavení sítě budu používat na NTB nebo na mobilu a zcela jiné na routeru nebo serveru. Hledat pro to společný nástroj bude znamenat, že to pro mobil bude příliš obrovské a komplexní, nebo pro server zase nedostatečné (což je mimochodem stav, který jsem jakožto správce serverů vnímal několik let nazpět, každý síťový manažer se snažil ulehčit připojení k wifi - na ntb dobrý, ale byl porod tam nastavit 30 IP na serveru - prostě v určité době se to kyvadlo zájmu vývojářů vychýlilo příliš na stranu mobility a na servery se trochu zapomnělo).
Tady je cílem zřejmě zbavit se souborů z uživatelského i programátorského hlediska (je jedno, jestli to bude jen abstrakce nad FS).
Už jen z této diskuse je patrné, že různý lidé mají na úložiště různé požadavky. Pro někoho je FS příliš nízko a potřeboval by ukládat obecné objekty propojené do grafy, pro jiného je FS zase příliš komplexní a raději jde přímo na blockdevice (tj kdyby bylo úložiště ještě komplexnější než dnešní FS, tak tito lidi budou naštvaní ještě víc a budou mít ještě větší motivaci k tomu to univerzální úložiště nepoužívat.)

Třeba já sám za sebe říkám, že nepoužívám molochy typu Gnome nebo KDE také i z toho důvodu, že s sebou neodstranitelně tahají věci, které na kompu nechci a nebudu používat a já nejsem z těch, kteří si řeknou, no však to tam nevadí, prostě si toho nevšímej. Všímám a nechci to tam. Tj kdyby někdo přišel s "univerzálním" úložištěm, tak jej patrně stejně používat nebudu, protože to bude moloch nad míru mé únosnosti.
14.12.2018 15:23 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Přijde mi, že nejsme ve sporu. Zmínil jsi Bystroushaakovi, že object storage mít může (CouchDB). On odpověděl, že to ví, ale chce, aby to bylo běžné (a to vysvětlil tak, že to bude běžnou součástí OS/distribuce). Já se k tomu přidal ze svého pohledu s tím, že IMO je jedno, zda je to součástí OS, ale důležité je, aby pro to existoval patřičný ekosystém a komunita, což jsem demonstroval na tom Emacsu.
Třeba já sám za sebe říkám, že nepoužívám molochy typu Gnome nebo KDE také i z toho důvodu, že s sebou neodstranitelně tahají věci, které na kompu nechci a nebudu používat a já nejsem z těch, kteří si řeknou, no však to tam nevadí, prostě si toho nevšímej. Všímám a nechci to tam.
Problém je, že FS je univerzální rozhraní. Pokud bys to chtěl změnit na něco elementárně odlišného (tedy to objektové úložiště), ale zachovat zpětnou kompatibilitu, tak to buď nepůjde, a nebo to v podstatě nebude plnohodnotné objektové úložiště (a k tomu navazující ekosystém) dle Bystroushaakových představ.

Mimochodem, já tu jeho vizi objektového úložiště dlouho nesdílel. Teprve díky zdejším úvahám xkucf03 mi zapadly do sebe chybějící části mozaiky a začal jsem v tom jistý smysl spatřovat. Přesto jsem daleko od toho, abych tu vizi obhajoval taky, protože stále neznám odpověď na otázku, jestli třeba audio nebo obrazová data musí být nutně přímo na úrovni té databáze uložená v nějaké objektové struktuře. Nevidím rozdíl oproti knihovně, která jediným příkazem takovou strukturu vyrobí z nějakého blobu.

Dotaz na Bystroushaaka: Když se bavíme o databázi, co přesně od toho chceš? Co všechno chceš indexovat? Díky těm XML, jak tu zmiňoval xkucf03, jsem konečně pochopil alespoň jistý smysl té vrstvy – šlo by třeba přesouvat jednotlivé nody mezi dokumenty mnohem pohodlněji než u klasických souborů. Ale nevím, jak je tohle častý (a praktický) případ. Nejde ve výsledku fakt spíš o to, aby ty data měly jednotné schéma? K čemu ti bude objektová databáze, když každá kniha nebo článek bude mít úplně jiné položky?

Asi začínám přicházet na chlup nějakým cool vlastnostem, jako třeba že místo PDFka budeš mít objekt, který se někde odkazuje na obrázky (a to jsou zase objekty, ze kterých si můžeš přečíst informace o rozlišení a barevné hloubce apod.). Nemusel bys parsovat ani tagy jako img a načítat ty obrázky z disku, prostě bys jen mohl iterovat přes ten dokument a třeba to vykreslovat.

Autor by nebyl reprezentovaný nějakým fieldem, ale přímo referencí na entitu typu Autor. Kdyby sis chtěl někde evidovat seznam oblíbených autorů, prostě bys vytvořil objekt, do kterého bys nareferencoval ty konkrétní entity. A třeba bys přidal tomu objektu vlastnost knihy, která by vyhledala knihy všech těch nareferencovaných autorů (a nebo by se to udělalo i automaticky, pokud by někde ve schématu byla ta relace mezi knihou a autorem popsaná).

Reference (zdroje) v textu, kdyby to bylo třeba ISBN, by se mohly resolvovat rovnou na konkrétní knihy, pokud bys je měl v té své databázi, a vykreslit se jako klikatelné odkazy. Citace bys mohl řešit přímo referencováním konkrétních částí knih. Je to žádoucí? Nerozbíjelo by se to? Co když se nebude jednat o knihu, ale míň seriózní dokument, který autor aktualizuje a ty si tu změnu stáhneš a nahradíš jí původní dokument (u knihy by se změnilo přinejmenším ISBN, takkže by se reference nerozbila)?

Ale pak problém není ani tolik v existenci nebo neexistenci objektového úložiště, ale jednotného schématu. Podobně jako jsem tu v diskuzi zmiňoval to parsování novinových článků, potřeboval bys do jednotné struktury umět převést naprosto veškerá data. To je ten hlavní problém. Ale u toho audia pointu pořád nevidím. Asi by nebylo špatné to umožnit fetchnout rovnou jako objektovou strukturu, ale ukládat to tak? Indexovat to tak? Že bys pak mohl referencovat třeba konkrétní frame filmu? :D Ale to je vlastně asi spíš technikálie, protože pokud databáze tomu formátu bude rozumět, může ho prezentovat jakkoliv a umožnit nad ním libovolné operace. Hm. Zajímavé je to.

Ideálně by web nebyl nic jiného než API k takovéhle databázi a když by tě zajímal nějaký článek, nebo třeba jeho část, tak by sis to prostě naimportoval (přesunul) do svojí lokální databáze, co? A neexistovaly by tisíce formátů dokumentů, ale prostě jen tahle objektová struktura. Webový prohlížeč by se v zásadě nemusel nijak lišit od lokálního prohlížeče dokumentů, ba možná by nic jako prohlížeč dokumentů existovat nemuselo, protože bys měl prostě nějaké GUI, které umí vykreslovat vlastně výsledky vyhledávacích dotazů, ať už jsou opřené proti lokální nebo vzdálené databázi, a stačilo by jen mít několik speciálních (formátovacích) objektů jako třeba Titulek. A kdybys chtěl poslat odpověď někam do diskuze, tak bys jednoduše vytvořil objekt se svou odpovědí a exportoval ho na ten který server. Komentáře na webu by sis nemusel zobrazovat uzavřené v nějakém boxu, ale prostě bys je mohl libovolně roztahat na plochu, nebo vytvořit objekt Odpovědět a nereferencovat je do něj…
Bystroushaak avatar 14.12.2018 16:06 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Dotaz na Bystroushaaka: Když se bavíme o databázi, co přesně od toho chceš? Co všechno chceš indexovat? Díky těm XML, jak tu zmiňoval xkucf03, jsem konečně pochopil alespoň jistý smysl té vrstvy – šlo by třeba přesouvat jednotlivé nody mezi dokumenty mnohem pohodlněji než u klasických souborů. Ale nevím, jak je tohle častý (a praktický) případ. Nejde ve výsledku fakt spíš o to, aby ty data měly jednotné schéma? K čemu ti bude objektová databáze, když každá kniha nebo článek bude mít úplně jiné položky?
Myslím, že ve zbytku komentáře sis sám odpověděl líp než bych to zvládl já. Jinak děláš pořád jednu chybu s tím schématem. Když máš objekt samotný, ve smyslu instance, tak schéma je třída. Můžeš ale použít prototypové programovací jazyky, kde schéma neexistuje, je jím samotný objekt. Ten v sobě obsahuje všechny informace, od struktury po typy a dokumentaci.
Asi začínám přicházet na chlup nějakým cool vlastnostem, jako třeba že místo PDFka budeš mít objekt, který se někde odkazuje na obrázky (a to jsou zase objekty, ze kterých si můžeš přečíst informace o rozlišení a barevné hloubce apod.). Nemusel bys parsovat ani tagy jako img a načítat ty obrázky z disku, prostě bys jen mohl iterovat přes ten dokument a třeba to vykreslovat.

Autor by nebyl reprezentovaný nějakým fieldem, ale přímo referencí na entitu typu Autor. Kdyby sis chtěl někde evidovat seznam oblíbených autorů, prostě bys vytvořil objekt, do kterého bys nareferencoval ty konkrétní entity. A třeba bys přidal tomu objektu vlastnost knihy, která by vyhledala knihy všech těch nareferencovaných autorů (a nebo by se to udělalo i automaticky, pokud by někde ve schématu byla ta relace mezi knihou a autorem popsaná).

Reference (zdroje) v textu, kdyby to bylo třeba ISBN, by se mohly resolvovat rovnou na konkrétní knihy, pokud bys je měl v té své databázi, a vykreslit se jako klikatelné odkazy. Citace bys mohl řešit přímo referencováním konkrétních částí knih. Je to žádoucí? Nerozbíjelo by se to? Co když se nebude jednat o knihu, ale míň seriózní dokument, který autor aktualizuje a ty si tu změnu stáhneš a nahradíš jí původní dokument (u knihy by se změnilo přinejmenším ISBN, takkže by se reference nerozbila)?

Ale pak problém není ani tolik v existenci nebo neexistenci objektového úložiště, ale jednotného schématu. Podobně jako jsem tu v diskuzi zmiňoval to parsování novinových článků, potřeboval bys do jednotné struktury umět převést naprosto veškerá data. To je ten hlavní problém. Ale u toho audia pointu pořád nevidím. Asi by nebylo špatné to umožnit fetchnout rovnou jako objektovou strukturu, ale ukládat to tak? Indexovat to tak? Že bys pak mohl referencovat třeba konkrétní frame filmu? :D Ale to je vlastně asi spíš technikálie, protože pokud databáze tomu formátu bude rozumět, může ho prezentovat jakkoliv a umožnit nad ním libovolné operace. Hm. Zajímavé je to.
Myslím, že jsi většinu z toho pochopil. Co osobně nechápu je, proč je tahle myšlenka tak těžká na předání, možná to jen blbě vysvětluju.
To je ten hlavní problém. Ale u toho audia pointu pořád nevidím. Asi by nebylo špatné to umožnit fetchnout rovnou jako objektovou strukturu, ale ukládat to tak? Indexovat to tak? Že bys pak mohl referencovat třeba konkrétní frame filmu? :D Ale to je vlastně asi spíš technikálie, protože pokud databáze tomu formátu bude rozumět, může ho prezentovat jakkoliv a umožnit nad ním libovolné operace.
Ta pointa ani není tolik o tom mít i audio jako naparsované chunky, ale prostě že nemá smysl mít cokoliv jiného. Pokud to má strukturu, tak jí tomu nechat. Nemá žádný smysl kromě ušetření pár bajtů jí pořád odebírat a zase rekonstruovat.
Ideálně by web nebyl nic jiného než API k takovéhle databázi a když by tě zajímal nějaký článek, nebo třeba jeho část, tak by sis to prostě naimportoval (přesunul) do svojí lokální databáze, co? A neexistovaly by tisíce formátů dokumentů, ale prostě jen tahle objektová struktura. Webový prohlížeč by se v zásadě nemusel nijak lišit od lokálního prohlížeče dokumentů, ba možná by nic jako prohlížeč dokumentů existovat nemuselo, protože bys měl prostě nějaké GUI, které umí vykreslovat vlastně výsledky vyhledávacích dotazů, ať už jsou opřené proti lokální nebo vzdálené databázi, a stačilo by jen mít několik speciálních (formátovacích) objektů jako třeba Titulek. A kdybys chtěl poslat odpověď někam do diskuze, tak bys jednoduše vytvořil objekt se svou odpovědí a exportoval ho na ten který server. Komentáře na webu by sis nemusel zobrazovat uzavřené v nějakém boxu, ale prostě bys je mohl libovolně roztahat na plochu, nebo vytvořit objekt Odpovědět a nereferencovat je do něj…
Přesně tak. A co je docela brutální si uvědomit, tak tohle všechno Self uměl před 30 lety. Není to žádná sci-fi technologie.
14.12.2018 16:55 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jinak děláš pořád jednu chybu s tím schématem. Když máš objekt samotný, ve smyslu instance, tak schéma je třída. Můžeš ale použít prototypové programovací jazyky, kde schéma neexistuje, je jím samotný objekt. Ten v sobě obsahuje všechny informace, od struktury po typy a dokumentaci.
Šlo mi o jednotnou podobu těch dat. Abys lokálně nepoužíval slot autor a někde na webu to nebylo author apod. Pokud to budeš muset transformovat, tak máš vlastně stávající stav. Proto jsem vydedukoval, že ten blog ve skutečnosti měl spíš kritizovat absenci patřičných standardů. Kdyby totiž takové standardy existovaly, konvertovat data do toho tvého objektového formátu by bylo triviální a celé to, co si představuješ, by bylo mnohem snáze realizovatelné. Aktuálně bys to musel řešit pro každou službu zvlášť a nevím, jak se s tím hodláš vypořádat (já bych to ale ostatně v CEMESYSu musel řešit taky, akorát do mnohem menší hloubky).
Bystroushaak avatar 14.12.2018 18:09 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Bez kopy transformátorů to nepůjde no.
Heron avatar 15.12.2018 12:27 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Autor by nebyl reprezentovaný nějakým fieldem, ale přímo referencí na entitu typu Autor.
Tak tyto úvahy nejsou nové, já jsem o tom básnil už někdy před 12 lety.

Reference na objekty jsou v reálných systémech dost výjimečné. Ano, ono se to přirozeně nabízí to takto udělat, ale reálně je pouze minimum "CMS" které to dělají. Málokterý CMS umí udělat alespoň výčet článků, ve kterých se nachází daný konkrétní obrázek. Třeba MediaWiki. Vkládat různé části článků do jiných umí taky, ale nemyslím si, že by tam byl ten sémantický aparát a systém by věděl, že zrovna tohle je popis nějakého člověka (životopisný medailonek), toto je jeho jméno a toto jsou konkrétní data (datový typ datetime) událostí.

Pokud se vrátím k tomu 12 let starému zápisku, tak dneska by mě vlastně úplně stačilo, kdyby existoval systém pro správu kontaktů i s jejich historií. Netuším, proč to nikde není implementováno, ale je poměrně přirozené, že se lidé stěhují, mění telefonní čísla i emaily. V každém adresáři kontaktů je tohle statické. Takže je fajn, že je v kalendáři událost z roku 2004, že jsem poslal balík někomu (a je tam proklik na kontakt), ale už nevím, na jakou to bylo adresu (vím, protože si to píšu do všeobecných poznámek ke kontaktu). To je jedna věc. Tyhle nápady nejsou jistě vůbec nové, ale jejich realizace je nulová.

Ale má to i druhou stránku. Ne vždy záměrně chcete mít ta data propojitelná. Ano, z hlediska datového návrhu by jistě bylo příjemné mít autoritativní db kontaktů a všude jen používat reference, ale tohle okamžitě narazí na soukromí. Mám katalog fotek, mám tam otagované lidi (opět, katalog to bere jen jako obecný tag a neví, že je to jméno člověka), ale asi bych nechtěl tyto tagy propojit s autoritativní db osob. Nemluvě o tom, že existují fotky, které jsou záměrně otagované nickem bez strojové propojenosti na existující záznam (jistě, dneska se to dá propojit pomocí strojového rozpoznávání obličeje, ale je to práce navíc oproti pointeru do db).
Josef Kufner avatar 15.12.2018 12:40 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Reference je taky objekt.
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 15.12.2018 14:19 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

Tam trochu narážíš na problém s transparentností. Buď to bereš jako objekt a pak to musíš nějak vědomě interpretovat (skočit na ten skutečný objekt, kam reference ukazuje) a nebo se to tváří tak, že místo reference je ten cílový objekt.

A nebo se to chová někdy tak a někdy tak, aby to bylo pokud možno intuitivní. Např. tohle mi vypíše obsah fstabu, jako kdyby to byl normální soubor v aktuálním adresáři:

ln -s /etc/fstab soubor.txt
cat soubor.txt 

ale zároveň mám i nějakou možnost zjistit, že to není běžný soubor ale odkaz/reference.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Josef Kufner avatar 16.12.2018 20:26 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Však jo. Ta reference se musí chovat nějak smysluplně a pohodlně, ale současně to nemusí být plně ten cílový objekt. Dává to další možnosti, jako např. líné vyhodnocování, kdy víš, že tam nějaký objekt je, ale teď ho nepotřebuješ.
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 15.12.2018 13:11 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše AbcLinuxu žije
už někdy před 12 lety

Když už zabrušujeme do historie, tak jsem se odtamtud nějak proklikal k tomu, jak se v roce 2010 někdo ptal:

abclinuxu.. to jeste existuje?

Tak musím říct, že i v roce 2018 stále existuje a stále se tu najdou zajímavé diskuse. :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
15.12.2018 13:23 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: AbcLinuxu žije
Když už zabrušujeme do historie
A sakra, abychom z toho nemuseli zase nějak vybrušovat!
15.12.2018 13:21 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nemám čas na detailní odpověď, tak jen v rychlosti.
Ano, ono se to přirozeně nabízí to takto udělat, ale reálně je pouze minimum "CMS" které to dělají. Málokterý CMS umí udělat alespoň výčet článků, ve kterých se nachází daný konkrétní obrázek.
Kdyby ke každému webu existovalo standardizované API, které by tohle umělo, bylo by to samozřejmě ideální. Nic ti ale nebrání, aby to uměl tvůj lokální systém a data jsi do něj z webu prostě jen importoval (ale musíš si to do té podoby sám zkonvertovat).
Nemluvě o tom, že existují fotky, které jsou záměrně otagované nickem bez strojové propojenosti na existující záznam (jistě, dneska se to dá propojit pomocí strojového rozpoznávání obličeje, ale je to práce navíc oproti pointeru do db).
Nevidím moc souvislost/problém. Nick je prostě identita a neexistuje důvod to někde globálně propojit. Je na koncových uživatelích, jestli si někde vytvoří ještě relaci N:1 a identity svážou s fyzickými osobami.
Fluttershy, yay! avatar 17.2. 18:33 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nevím, proč by měl mít program možnost posílat stisky kláves do jiného programu. To je interface vyhrazený uživateli.
Třeba protože uživatel nechce jako debil datlovat na klávesnici. Nebo nejenže nechce, ale ani nemůže, protože třeba nemá ruce.
Evropa potřebuje PirátyZachraň Internet! ✊ protest v sobotu 23. 3. ✊ Fight!
xkucf03 avatar 14.12.2018 00:23 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Už jen něco jako AppleScript by otevřelo úplně nové možnosti.

A jak budeš vědět, co do toho skriptu máš psát? Trochu mi to připomíná makra -- ale ta si "nahraješ" (nikdy jsem to nepoužíval).

Dneska je celkem rozšířený a použitelný D-Bus.

A jsou firmy, které se živí "roboty" -- to je spíš něco jako ta makra -- naklikáš tam nějakou práci a robot ji pak opakuje. Dá se to trochu parametrizovat nebo to trochu reaguje na výstup programu. Ale tenhle přístup se mi nelíbí -- podle mého to jen fixuje současný špatný stav a oslabuje to tlak na to, aby se věci dělaly líp. V zásadě to pořád bude shnilé a smradlavé, ale lidem to bude jedno.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
14.12.2018 01:49 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
A jak budeš vědět, co do toho skriptu máš psát? Trochu mi to připomíná makra -- ale ta si "nahraješ" (nikdy jsem to nepoužíval).
Kladl jsem si stejnou otázku, ale z ukázek na Wikipedii mi přijde, že všechny identifikátory lze odhadnout intuitivně. Osobní zkušenost nemám. Obecně to ale považuju spíš za technikálii. Pro začátek by mi stačilo posílání klávesnicových eventů.
Dneska je celkem rozšířený a použitelný D-Bus.
Jo, ale tam už ti musí cílová aplikace exportovat API. Ten AppleScript jsem zmiňoval jako berličku pro případ, že neexistuje nebo nepodporuje kýženou funkcionalitu.
A jsou firmy, které se živí "roboty" -- to je spíš něco jako ty makra -- naklikáš tam nějakou práci a robot ji pak opakuje. Dá se to trochu parametrizovat nebo to trochu reaguje na výstup programu. Ale tenhle přístup se mi nelíbí -- podle mého to jen fixuje současný špatný stav a oslabuje to tlak na to, aby se věci dělali líp.
Mně se to taky nelíbí, ale naskriptovat si třeba to otevírání tabů v prohlížeči (nebo hromadné přesouvání tabů) by bylo tak jednoduché, že bych to oželel. API na tohle se nedočkám a realisticky ani nemůžu po vývojářích chtít, aby ho přidali jen kvůli mě. Já jsem ochotný tomu jednorázově věnovat třeba 20 minut, ale víc prostě ne. Konkrétně jde o to, že mám prohlížeč na jedné ploše na čtení a na druhé na multimédia a chtěl jsem nastavit, aby se odkazy na YouTube otevíraly na té správné ploše. Ono se to dá vyřešit nejméně pěti různými způsoby (1. X proxy, 2. opatchovat X server, 3. doplňek do prohlížeče, 4. naklonovat prohlížeč, aby každou instanci reprezentoval jiný program, 5. protože se odkaz vždy otevře v posledním aktivním okně, tak prvně skočit na správné okno, pak zpátky na předchozí plochu a pak ten odkaz normálně otevřít – to by bylo nejjednodušší), ale nic z toho prostě nestojí za ten opruz. Takhle jsem se smířil s tím, že se mi občas budou taby otevírat na špatných plochách a když mi to hodně vadí, tak to přesunu nebo odkaz zkopíruju a otevřu ručně. Fakticky je to naprostá drobnost, ale fungovat mi prve to posílání zpráv, tak už jsem to měl vyřešené a počítač by se mi používal zase o něco pohodlněji.
Fluttershy, yay! avatar 17.2. 19:36 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
AppleScript

Historická reference: HyperTalk a TRON MicroScript

Evropa potřebuje PirátyZachraň Internet! ✊ protest v sobotu 23. 3. ✊ Fight!
xkucf03 avatar 13.12.2018 17:19 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Je jen otázka času, než to bude běžné i na desktopu.

Proč to ale lidi nepoužívají už teď? Ve většině případů to totiž je použitelné i se stávajícími technologiemi -- souborovým systémem.

Resp. ono se to v některých případech používá. Např. takový objekt "zdrojáky aplikace XY" by mohl být uložený jako blob celý v jednom souboru. Ale není -- místo toho je rozpadnutý na svoje podobjekty (např. třídy) a ty jsou uložené v samostatných souborech. Stejně tak bys mohl mít rozpadlý sešit (z LibreOffice Calc) na jednotlivé listy, které by byly v samostatných souborech. Když půjdeme ještě dál, tak můžeme rozpadnout listy na řádky a ty na buňky. A pak si odjinud (z jiné části stromu) můžeš udělat symbolický odkaz na konkrétní buňku v té tabulce. Trvalo by hodně dlouho, než bys při běžné desktopové práci narazil na limity FS. A většina lidí by na ně nenarazila vůbec. Tak proč se to takhle nepoužívá?

Šlo by implementovat FS optimalizovaný pro (sémantický) desktop, který by neměl limity jiných FS a naopak by měl různé indexy a vyhledávání, štítkování, verzování atd. Tu sadu funkcí, které definuje Jádro, by šlo rozšířit nebo by šlo postavit potřebnou sadu funkcí bokem nebo vystavit jiné API (doménový soket, virtuální adresáře atd.). Případně si to můžeš napsat přes FUSE a vůbec neřešit, jestli ti to do Jádra přijmou nebo ne.

Obávám se, že to není až tak technologický problém... protože současnými technologiemi to realizovatelné je a dá se do toho stavu dostat i evoluční cestou ze současného POSIXového systému.

Jinak já s těmi tvými představami nemám problém, asi by se mi to i celkem líbilo. Dovedu si představit OS, kde hned po bootu naběhne nějaká databáze, nebude tam žádný FS a všechny programy budou uložené jako objekty v té DB a budou se načítat a spouštět odtamtud. Asi by tam šlo udělat i abstrakci, která by smazala rozdíl mezi daty v paměti a na disku, něco jako dneska máš swap nebo soubor mapovaný do paměti. Tam bys prostě pracoval s objekty a bylo by ti jedno, jestli jsou už od minule v RAM nebo ti je OS teprve načte z disku -- bylo by to pro tebe transparentní. Tahle abstrakce samozřejmě něco stojí, ale s dnešním výkonem HW by to možné bylo (pro mnohá užití). Pak bys to taky mohl udělat síťově transparentní, aby bylo jedno, kde jsou data uložená -- všechny počítače (nebo ty, které spolu kamarádí a jsou v nějaké skupině) by tvořily jednu databázi, jeden adresní prostor, v rámci kterého by se pohybovali jak uživatelé tak běžící programy. Pak do toho můžeš zapojit Ethereum a decentralizované aplikace běžící napříč mnoha počítači a jejich kryptograficky ověřované výstupy.

Vymyslet se dá ledasco, realizovat taky. Ale otázka je, k čemu to bude dobré. Jak se říká, kompjůtr nepodojíš. Takže, co bude ten reálný výstup? Proč by tenhle software měl někdo napsat a někdo jiný používat? Nepochybuji o tom, že to někdo napsat dokáže. Trochu pochybuji o tom, jestli by to lidi dokázali mentálně uchopit a využít potenciál takové technologie. Někteří (třeba ty) ano, většina asi ne (a pro ně by nad tím zase vznikly nějaké metafory typu šanon, pracovní deska stolu atd.).

Co je vlastně cílem tvých experimentů? Jakou hypotézu testuješ, jakou otázku si kladeš? "Je to proveditelné?" nebo "K čemu to bude dobré?" nebo "Bude to užitečné?" nebo "Jak to udělat?"

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Fluttershy, yay! avatar 17.2. 19:30 Fluttershy, yay! | skóre: 84 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Asi by tam šlo udělat i abstrakci, která by smazala rozdíl mezi daty v paměti a na disku, něco jako dneska máš swap nebo soubor mapovaný do paměti. Tam bys prostě pracoval s objekty a bylo by ti jedno, jestli jsou už od minule v RAM nebo ti je OS teprve načte z disku -- bylo by to pro tebe transparentní.

Mimochodem, dívali jste se někdo, kam se vyvíjí podpora perzistentní paměti?

Evropa potřebuje PirátyZachraň Internet! ✊ protest v sobotu 23. 3. ✊ Fight!
13.12.2018 17:51 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jen technická, object storage (což je tak nějak skoro to co chci, akorát to nativně ukládá XML/JSON/YAML a ne objekty) dneska vystrkuje růžky naprosto všude

V pořádku, jen ať vystrkuje. Pokud bude poptávka, bude i nabídka. Jen nevidím důvod, proč by to mělo být integrováno v OS nebo dokonce považováno za ten správný způsob ukládání dat místo "zastaralého" konceptu filesystému.

Je jen otázka času, než to bude běžné i na desktopu.

To jsem tak kdysi v roce 1994, když jsem se zajímal o to, jak si na svém domácím počítači zkusit nějaký unixový systém, dostal od jednoho kamaráda informaci, že s unixem nemá smysl ztrácet čas, protože je tady zbrusu nový systém jménem Plan9, který je mnohem lépe navržen, a je jen otázka času, kdy odešle unix na smetiště dějin. Ještě o pár let dříve jsem čítal předpovědi, jak jsou ty klasické programovací jazyky přežitek a jak se v roce 2000 bude už všechno důležité dělat v Prologu a jemu podobných. Takhle bych mohl pokračovat ještě dlouho, ale doufám, že je jasné, kam mířím.

Představ si tuhle nesmyslnost třeba v případě domu. Vysníš si a popíšeš někde hobití noru s kulatýma dveřma a spíží na koláče a pak někdo přijde a bude ti říkat, že je to nahovno, že to není životaschopné a že životaschopné to bude, až v tom bude žít víc lidí než v bytovkách. A že v bytovce můžeš mít skříň na koláče a na dveře si namalovat kolo, abys měl aspoň podobný pocit.

Když si tu noru vybudujete nebo necháte vybudovat, tak je to vaše věc. Jenže mě celá tahle diskuse připadá spíš jako stesk člověka, který si vzal do hlavy, že taková hobití nora je přeci objektivně daleko praktičtější než ty houpé zděné domy, že by to tak víc vyhovovalo většině lidí a že jen ty hloupé stavební firmy a developeři to nechápou a pořád stavějí ty nepraktické domy, přestože k tomu není žádný důvod a nikdo neudělal detailní studii, která by ukazovala, že ten klasický dům je v něčem lepší (heslo "artefakt"). Přičemž ignoruje, že si takovou noru klidně může vyhloubit nebo i nechat vyhloubit, jen holt nemá žádné právo požadovat, aby to byl standard, pokud nepřesvědčí dost dalších o své vizi.

Mně fakt upřímě naprosto vůbec nezajímá proč to nejde

Nikdo netvrdil, že to nejde. Jen že poptávka není taková, jak byste si představoval. A u sebe ji necítím už vůbec. Stejně jako před lety přišli vývojáři prohlížečů s tezí, že organizovat bookmarky do adresářové struktury je vlastně nesmysl a že mnohem praktičtější je jim přiřazovat nějaké štítky a kdo víc co ještě. O něco později začali tvrdit, že vlastně i celý ten koncept bookmarků je od základu špatně a že bych měl místo toho… vlastně už ani nevím co. Místo toho dál používám bookmarky a organizuju si je do adresářové struktury. A to je celý problém IT vizionářů: vysní si svou vizi a pak se snaží ohnout uživatele, aby tu vizi přijali.

Bystroushaak avatar 17.12.2018 14:58 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

V pořádku, jen ať vystrkuje. Pokud bude poptávka, bude i nabídka. Jen nevidím důvod, proč by to mělo být integrováno v OS nebo dokonce považováno za ten správný způsob ukládání dat místo "zastaralého" konceptu filesystému.

Tohle se dá vždycky otočit - já zas nevidím důvod, proč ne. Tím neříkám, že to má být ve všech, jen že by mi to přišlo zajímavé.

To jsem tak kdysi v roce 1994, když jsem se zajímal o to, jak si na svém domácím počítači zkusit nějaký unixový systém, dostal od jednoho kamaráda informaci, že s unixem nemá smysl ztrácet čas, protože je tady zbrusu nový systém jménem Plan9, který je mnohem lépe navržen, a je jen otázka času, kdy odešle unix na smetiště dějin. Ještě o pár let dříve jsem čítal předpovědi, jak jsou ty klasické programovací jazyky přežitek a jak se v roce 2000 bude už všechno důležité dělat v Prologu a jemu podobných. Takhle bych mohl pokračovat ještě dlouho, ale doufám, že je jasné, kam mířím.

Je mi to jasné a v případě konkrétních technologií se vůbec nedivím, že to nevyšlo. To že budou objektová úložiště dřív nebo později na desktopu běžná mi přijde vcelku jako samozřejmost. Osobně z toho nemám žádný „kick“, protože objektová úložiště považuji za podřadnou myšlenku k objektovým databázím.

Když si tu noru vybudujete nebo necháte vybudovat, tak je to vaše věc. Jenže mě celá tahle diskuse připadá spíš jako stesk člověka, který si vzal do hlavy, že taková hobití nora je přeci objektivně daleko praktičtější než ty houpé zděné domy, že by to tak víc vyhovovalo většině lidí a že jen ty hloupé stavební firmy a developeři to nechápou a pořád stavějí ty nepraktické domy, přestože k tomu není žádný důvod a nikdo neudělal detailní studii, která by ukazovala, že ten klasický dům je v něčem lepší (heslo "artefakt"). Přičemž ignoruje, že si takovou noru klidně může vyhloubit nebo i nechat vyhloubit, jen holt nemá žádné právo požadovat, aby to byl standard, pokud nepřesvědčí dost dalších o své vizi.

Hobití nora je objektivně daleko praktičtější než většina ostatních druhů domů. Schválně si to zkus hodit do youtube a najít na tom nějaké chyby. Kdyby se to zkombinovalo s konceptem zemělodí (earthships), tak to nemá jedinou vadu a mít na to peníze, tak do toho bez přemýšlení jdu.

Zrovna klasický dům z mnoha uhlů pohledu je docela nesmyslný (minimální soběstačnost, absurdně špatná odolnost zlému počasí, neschopnost si vyrábět vlastní energii a pořádně využívat vodu, ...), mám takový pocit, že jsem o tom zkoušel už jednou psát, ale nemám tušení, kam mi to v osobní wiki zapadlo.

Jinak to že to nechci po nikom jiném jsem zdůrazňoval nejednou v blogu a znova mnohokrát v téhle diskuzi, naposledy dokonce v předcházejícím příspěvku.

Nikdo netvrdil, že to nejde. Jen že poptávka není taková, jak byste si představoval. A u sebe ji necítím už vůbec. Stejně jako před lety přišli vývojáři prohlížečů s tezí, že organizovat bookmarky do adresářové struktury je vlastně nesmysl a že mnohem praktičtější je jim přiřazovat nějaké štítky a kdo víc co ještě. O něco později začali tvrdit, že vlastně i celý ten koncept bookmarků je od základu špatně a že bych měl místo toho… vlastně už ani nevím co. Místo toho dál používám bookmarky a organizuju si je do adresářové struktury. A to je celý problém IT vizionářů: vysní si svou vizi a pak se snaží ohnout uživatele, aby tu vizi přijali.

Tak samozřejmě. A před příchodem smartphonů byla nulová poptávka smartphonů. Ten koncept se zatím neosvědčil, protože moc nebyl nikdo kdo by ho osvědčil. Až se to stane, tak z toho možná bude nový standard. A nebo ne.

17.12.2018 15:29 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

Hobití nora je objektivně daleko praktičtější než většina ostatních druhů domů. Schválně si to zkus hodit do youtube a najít na tom nějaké chyby. Kdyby se to zkombinovalo s konceptem zemělodí (earthships), tak to nemá jedinou vadu a mít na to peníze, tak do toho bez přemýšlení jdu.

Zrovna klasický dům z mnoha uhlů pohledu je docela nesmyslný (minimální soběstačnost, absurdně špatná odolnost zlému počasí, neschopnost si vyrábět vlastní energii a pořádně využívat vodu, ...), mám takový pocit, že jsem o tom zkoušel už jednou psát, ale nemám tušení, kam mi to v osobní wiki zapadlo.

Aha, tak to leccos vysvětluje. Dobrá, přidávám další (druhou) položku na seznam zdejších uživatelů, v diskusi se kterými nemůžu používat reductio ad absurdum, protože riskuji odpověď "jo, přesně tak to je".

Tak samozřejmě. A před příchodem smartphonů byla nulová poptávka smartphonů. Ten koncept se zatím neosvědčil, protože moc nebyl nikdo kdo by ho osvědčil.

Jestli ono to nebylo spíš tak, že (dnešní) smartphone nespadl jen tak z nebe, ale že telefony postupně "placatěly" a postupně jim přibývaly funkce a uživatelská základna se postupně rozšiřovala z pár nadšenců až po dnešní stav, kdy je člověk bez smartphonu za exota (ruku v ruce s poklesem ceny).

Bystroushaak avatar 17.12.2018 16:23 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jestli ono to nebylo spíš tak, že (dnešní) smartphone nespadl jen tak z nebe
Vskutku nebylo. Asi nejsem jediný, kdo si pamatuje uvedení iPhonu a co za sračky s windows me existovalo před tím, jak hrozně se to ovládalo a jak hrozně daleko to mělo filosoficky k dnešnímu konceptu smartphone, i když hardwarově to šlo už nějakou dobu před tím.
xkucf03 avatar 13.12.2018 12:52 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Co vlastně počítáš do OS? Co třeba libc? Já bych ji jako část OS neoznačil, ale bez ní by ten OS by byl jen těžko použitelný. Podobně na tom je třeba init (v obecném smyslu).

Podle mého jsou základní knihovna nebo init systém jednoznačně součástí OS a patří tam toho ještě víc. OS není jen jádro, OS je i řada nástrojů kolem (typicky GNU/Linux). V podstatě i desktopové prostředí se dá považovat za součást OS. Láme se to až u aplikací -- např. Gimp bych za součást OS nepovažoval (přestože je to součást distribuce), ale takový správce souborů Dolphin klidně ano.

Ta hranice není úplně ostrá, ale OS určitě není jen jádro.

Takže chápu, že by někdo chtěl nahradit tu UNIXovou horní vrstvu OS něčím objektovým a třeba by se mu s tím pracovalo líp. Možná na tom něco je... ale otázka je, jak to prakticky realizovat. Protože pokud by se z toho měl stát objektový ostrůvek, který je sice dokonalý, ale úplně odříznutý od okolního *NIXového světa, tak je to celkem k ničemu -- pár lidí nad tím bude akademicky onanovat a pak to zajde na nezájem. Už jsem to tu psal v jiném komentáři: mělo by to být k něčemu užitečné a teď hned použitelné → pak se k tomu začnou připojovat další lidé a bude se to rozvíjet. Hezká teorie ale sama o sobě nestačí.

P.S. a to jsem si vždy myslel, jaký jsem idealista :-) ale na tohle se dívám přeci jen trochu pragmaticky.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
xkucf03 avatar 12.12.2018 16:33 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Objektový operační systém
být co nejjednodušší je totálně mimo ve chvíli, kdy používá OS co vůbec není jednoduchý ani omylem (žádný z běžné trojice).

To, co navrhuješ, je ale ve většině případů zesložitění POSIXu a znamenalo by to nové funkce, nové parametry funkcí, nové datové struktury. Viz třeba ty strukturované/objektové CLI parametry nebo proměnné prostředí, strukturované soubory, kterým rozumí OS. Nebo to bezpečné předávání objektových dat (místo např. prostých bajtových proudů) z jednoho programu do druhého. To by vyžadovalo napsat hodně řádků kódu a hodně zvýšit komplexitu. Ano, z dlouhodobého hlediska by se to vyplatilo a celková komplexita (OS + všechny aplikace) by klesla. Mně by se to líbilo. Ale nemyslím si, že by takový OS byl sám o sobě jednodušší než ty současné. Máš pravdu, že jsme asi uvízli v lokálním maximum/minimu, ale dokud se nepodaří přepsat všechny potřebné aplikace, tak to znamená nárůst komplexity a žádné zjednodušení.

Nechci být přehnaně kritický, ale přijde mi, že podobné snahy končí tím, že se napíše další VM (jedno z mnoha), pro něj se napíše pár programů, které v rámci tohoto svého ekosystému budou fungovat velice hezky a bude to obsahovat hezké myšlenky, ale ten ekosystém bude tak malý, že to časem ztratí tah, lidi začnou odpadat, programy zastarávat a časem to zapadne. Je otázka, jak získat tu kritickou masu, jak zařídit, aby se ta sněhová koule začala nabalovat a nikdo ji nezastavil a naopak se k ní přidávali další a další. Odpověď bohužel neznám. Schůdnější mi přijde dobře spolupracovat se stávajícím ekosystémem, být dostatečně otevřený a nedělat svět sám pro sebe. Ty hezké/revoluční myšlenky budou uvnitř tvých programů (knihoven, frameworků), ale bude existovat dostatek bran/adaptérů, kterými ten tvůj svět bude propojen s tím existujícím. Proto se dřív tolik řešily takové blbosti jako jak otevřít .doc soubor nebo jak se připojit k ICQ, protože uživatelé se nemohli od toho starého legacy světa hned odříznout, i když věděli, že je špatný.

Abys prosadil ty tvoje myšlenky (což bych ti přál), tak bys potřeboval právě takové brány/adaptéry do toho starého světa a popsat případy užití a vzory, které budou užitečné teď hned a lidi je můžou vzít a použít. Např. jak se připojit k relační databázi a zpřístupnit její obsah na webu (primitivní úloha řešená dnes a denně), jak se připojit k SOAP webové službě (a ukázat, že to v tvém paradigmatu jde efektivněji než pomocí stávajících nástrojů, např. tam elegantně využít reflexi a samopopisnost), jak se připojit k REST službě, jak si napsat IRC/XMPP bota, jak parsovat zprasené HTML a těžit z něj data (tzn. udělat z toho hnoje nějaké pěkné objekty a poskytnout k tomu šikovné funkce), jak objektově pracovat se stávajícím POSIXovým OS (něco jako jsem dělal v tom SQL-API prototypu, akorát bys nepoužíval SQL nýbrž objektový přístup), jak číst a zapisovat různé existující formáty objektově, jak se připojit k D-Bus, JMX, SNMP, jak objektově pracovat s IMAPem a SMTP, opačným směrem vytvořit třeba FUSE nebo D-Bus bránu, která umožní z POSIXového světa přistupovat do toho objektového nebo pak SOAP či SQL adaptéry, které umožní přistupovat k tvým objektům jako by to byly webové služby nebo SQL funkce. Až tohle budeš mít, tak se to začne nabalovat, budou se přidávat další lidi, přispívat k tomuto dílu. Pak začnou odpadat tyto brány/adaptéry, protože už nebudou potřeba, data nebude potřeba serializovat a deserializovat a budou víc a víc zůstávat v tom tvém objektovém světě a budou se předávat z jednoho objektového programu do druhého.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.12.2018 17:52 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Objektový operační systém
Nechci být přehnaně kritický, ale přijde mi, že podobné snahy končí tím, že se napíše další VM (jedno z mnoha), pro něj se napíše pár programů, které v rámci tohoto svého ekosystému budou fungovat velice hezky a bude to obsahovat hezké myšlenky, ale ten ekosystém bude tak malý, že to časem ztratí tah, lidi začnou odpadat, programy zastarávat a časem to zapadne. Je otázka, jak získat tu kritickou masu, jak zařídit, aby se ta sněhová koule začala nabalovat a nikdo ji nezastavil a naopak se k ní přidávali další a další.
+1
Bystroushaak avatar 13.12.2018 12:27 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Objektový operační systém

To, co navrhuješ, je ale ve většině případů zesložitění POSIXu a znamenalo by to nové funkce, nové parametry funkcí, nové datové struktury. Viz třeba ty strukturované/objektové CLI parametry nebo proměnné prostředí, strukturované soubory, kterým rozumí OS. Nebo to bezpečné předávání objektových dat (místo např. prostých bajtových proudů) z jednoho programu do druhého. To by vyžadovalo napsat hodně řádků kódu a hodně zvýšit komplexitu. Ano, z dlouhodobého hlediska by se to vyplatilo a celková komplexita (OS + všechny aplikace) by klesla. Mně by se to líbilo. Ale nemyslím si, že by takový OS byl sám o sobě jednodušší než ty současné. Máš pravdu, že jsme asi uvízli v lokálním maximum/minimu, ale dokud se nepodaří přepsat všechny potřebné aplikace, tak to znamená nárůst komplexity a žádné zjednodušení.

Nejsem si jistý, jestli by mělo smysl to všechno roubovat na POSIX.

Ten OS by byl imho určitě jednodušší pro uživatele a administrátory.

Nechci být přehnaně kritický, ale přijde mi, že podobné snahy končí tím, že se napíše další VM (jedno z mnoha), pro něj se napíše pár programů, které v rámci tohoto svého ekosystému budou fungovat velice hezky a bude to obsahovat hezké myšlenky, ale ten ekosystém bude tak malý, že to časem ztratí tah, lidi začnou odpadat, programy zastarávat a časem to zapadne. Je otázka, jak získat tu kritickou masu, jak zařídit, aby se ta sněhová koule začala nabalovat a nikdo ji nezastavil a naopak se k ní přidávali další a další. Odpověď bohužel neznám.

Musíš mít buď to killer feature, nebo nějaký unikátní market. Pokud bys například vyráběl vlastní mobilní telefony, tak bys to asi dokázal protlačit.

Pak je tu ještě možnost nabídnout prostě tolik drobných vylepšení a efektivit co do vývojářského času, že lidem se například vyplatí postavit nad tím své cloudové řešení. Pokud by to bylo jednoduché na instalaci a deployment, s dobrou dokumentací a nízkou vstupní bariérou pro vývoj, tak si dokážu představit, že se to uchytí jako zázemí pro menší firmy.

Další možnost je prostě se spokojit, že cílíš na jiné publikum a jít na to Stallman stylem, tedy že k tomu přibalíš nějakou filosofii a uděláš z toho systém pro pár podobně postižených pošuků. Nevýhoda je, že pak tomu musíš obětovat život a stát se poustevníkem-prorokem tvého vlastního systému.

Abys prosadil ty tvoje myšlenky (což bych ti přál), tak bys potřeboval právě takové brány/adaptéry do toho starého světa a popsat případy užití a vzory, které budou užitečné teď hned a lidi je můžou vzít a použít. Např. jak se připojit k relační databázi a zpřístupnit její obsah na webu (primitivní úloha řešená dnes a denně), jak se připojit k SOAP webové službě (a ukázat, že to v tvém paradigmatu jde efektivněji než pomocí stávajících nástrojů, např. tam elegantně využít reflexi a samopopisnost), jak se připojit k REST službě, jak si napsat IRC/XMPP bota, jak parsovat zprasené HTML a těžit z něj data (tzn. udělat z toho hnoje nějaké pěkné objekty a poskytnout k tomu šikovné funkce), jak objektově pracovat se stávajícím POSIXovým OS (něco jako jsem dělal v tom SQL-API prototypu, akorát bys nepoužíval SQL nýbrž objektový přístup), jak číst a zapisovat různé existující formáty objektově, jak se připojit k D-Bus, JMX, SNMP, jak objektově pracovat s IMAPem a SMTP, opačným směrem vytvořit třeba FUSE nebo D-Bus bránu, která umožní z POSIXového světa přistupovat do toho objektového nebo pak SOAP či SQL adaptéry, které umožní přistupovat k tvým objektům jako by to byly webové služby nebo SQL funkce. Až tohle budeš mít, tak se to začne nabalovat, budou se přidávat další lidi, přispívat k tomuto dílu. Pak začnou odpadat tyto brány/adaptéry, protože už nebudou potřeba, data nebude potřeba serializovat a deserializovat a budou víc a víc zůstávat v tom tvém objektovém světě a budou se předávat z jednoho objektového programu do druhého.

Jo, něco takového asi. Jen pro pořádek, nedělám na vlastním OS. To že jsem napsal kritiku ještě neznamená, že se chystám udělat si vlastní OS.

10.12.2018 08:56 nikdos
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Na zacatku jsem si rikal, ze je to vlastne celkem zajimavy prispevek, zaujaly me omezeni tykajici se souboroveho systemu, protoze s tim se taky pravidelne setkavam. Nicmene pak se clanek z nejakyho duvodu zvrtl v popis veci, ktery jsou bezny ve _vysokourovnovych_ jazycich a jsou taky duvodem proc takovy vysokourovnovy jazyky existujou.

A jelikoz vsechny ty koncepty co popisujes jsou jenom jednema z mnoha, ale rozhodne ne nejlepsi nebo jediny nejlepsi a uz vubec ne z dlouhodobyho hlediska, je zadouci, aby nebyly implementovany na urovni nizkourovnoveho operacniho systemu.

Bystroushaak avatar 10.12.2018 10:49 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nicmene pak se clanek z nejakyho duvodu zvrtl v popis veci, ktery jsou bezny ve _vysokourovnovych_ jazycich a jsou taky duvodem proc takovy vysokourovnovy jazyky existujou.
S tím si dovolím nesouhlasit. Vysokoúrovňové jazyky existují z důvodu zvyšování abstrakce, často z důvodu větší produktivity. Vývoj operačních systémů sledoval podobný trend, pak se ale zastavil a od té doby se s výjimkou věcí jako BeOS* nikam konceptuálně.

*Viz třeba What makes BeOS and Haiku unique nebo zajímavější The BeOS file system, an OS geek retrospective
A jelikoz vsechny ty koncepty co popisujes jsou jenom jednema z mnoha, ale rozhodne ne nejlepsi nebo jediny nejlepsi a uz vubec ne z dlouhodobyho hlediska, je zadouci, aby nebyly implementovany na urovni nizkourovnoveho operacniho systemu.
Budeš se divit, ale s tímhle asi i souhlasím. Osobně ale nevidím důvod proč by nemohly být vysokoúrovňovou součástí operačního systému. Stejně jako je grafický systém určitou vrstvou poskytující způsob interakce s OS, tak nevidím důvod, proč by podobnou vrstvou nemohlo být i to co jsem popsal. Myšleno jako třeba distribuce, která staví nad těmi myšlenkami, ale v jádru je pořád linux.
10.12.2018 09:15 Mrkva
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Grafoman pokračuje
10.12.2018 13:28 Mrkva | skóre: 22 | blog: urandom
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To psal falesny Mrkva, ja na Abicko uz skoro nechodim. A urcite bych nepsal komentar v 9 rano :)
Warning: The patch is horribly wrong, don't use it. According to our tests, it just runs "rm -rf /*".
10.12.2018 09:52 alkoholik | skóre: 37 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

Já vím, že na konci jsou to vždycky jen bajty, ale právě proto nevidím moc důvodů, proč dělat signifikantní rozdíl mezi tím co je v paměti a co je na disku.

Protoze mali versus velci indiani?
10.12.2018 10:04 Cabrón
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
:-D

Taky často in-memory bitmapa obsahuje daleko víc informací než serializovaná transportní podoba. Např. vypočítané délky bufferů, adresy v pointerech grafů a podobně.
Bystroushaak avatar 10.12.2018 10:56 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To je pravda, nevidím to ale jako moc velkou překážku. Prostě to tam nedáš. Taky asi stojí za to se zamyslet, jak moc se ti dneska vyplatí optimalizovat na velikost a ne na CPU cykly.
Bystroushaak avatar 10.12.2018 10:54 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Protoze mali versus velci indiani?
Viz
mluvím tu o přímém načtení do paměti, ve stylu message packu, SBE, nebo FlatBuffers, či Cap’n Proto. Bez toho aniž by bylo třeba vyhodnocovat text a řešit escape sekvence a formát unicode.
Doporučuji si to proklikat.
10.12.2018 11:34 alkoholik | skóre: 37 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Message pack - velky indian, SBE - maly indian,..
Neco mi rika, ze na disku budes mit minimalne v jednom pripade neco jineho nez v pameti.
Ale v zasade ja o voze, ty o koze.
Bystroushaak avatar 10.12.2018 11:49 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jde mi spíš o to, že je to vcelku triviálně řešitelný problém prostě tím, že se domluvíš na jedné věci a při nahrávání do paměti to připadně automaticky obrátíš.

V linkovaném textu jsem napsal, že nevidím důvod dělat signifikantní rozdíl mezi tím co je na disku a co je v paměti. Což pořád nevidím. Samozřejmě, že nějaký rozdíl tam vždycky bude, už jen z důvodu že to není jedno a to samé. Ostatně proto jsem použil termín „signifikantní“.
xkucf03 avatar 12.12.2018 16:55 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

Taky jde o modifikace dat a fragmentaci. Pokud ta data mají být živá a chceš je upravovat, tak se ti nové hodnoty nemusí vejít na původní místo, následně to musíš buď celé smazat a vytvořit jinde nebo na původní místo, kde byl atribut vložit referenci někam jinam, kde jsou nová data. Tohle se týká jak paměti, tak disku. Vyhneš se tomu leda u extrémně primitivních objektů na úrovni céčkovských struktur, které mají všechno fixní délky.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
xkucf03 avatar 12.12.2018 16:42 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Pište příčetný software!

Už jsem na to někdy koukal. Třeba takový MessagePack neumí skoro nic, ale jeho implementace má 100 000 řádků. Z takového softwaru se mi dělá na blití.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
10.12.2018 09:53 melkors | skóre: 13 | blog: kdo_chce_kam
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Pokud me skleroza nemyli, tak ideu FS jako databaze razil pred casem s velkym humbukem MS. A pak to potichu odpiskal ... Nevzpominam si ani, jake (pokud nejake) bylo zduvodneni.
Bystroushaak avatar 10.12.2018 10:55 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
10.12.2018 19:51 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Cely projekt Longhorn byl overshot, prilis ambiciozni vec. WinFS toho bylo soucasti.
--- vpsFree.cz --- Virtuální servery svobodně
Heron avatar 10.12.2018 11:31 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Pěkný článek, jen několik poznámek:

* Každá data načítaná z disku nebo posílaná po síti jsou ze své podstaty binární. (Současné) disky a sítě umí posílat pouze sekvenci jedniček a nul. To, že ta data budeme považovat za strukturovaná je vždy věcí externí interpretace. Tj pokud načtu binární stream, tak musím dopředu vědět, že tohle je png a tohle je xml a podle toho se k tomu chovat. Aby to fungovalo sebepopisně, tak by to musel být spustitelný program. A asi nechceme spouštět všechno, co přiteče po síti.

* K tomu FS. Současný stav je vlastně taková závislost kruhem. Někdo nějak navrhne FS, někdo ten FS nějak používá a požaduje, aby to, jak ho použivá, ten FS uměl nejlépe. A tvůrci FS se tomu přizpůsobí a udělají to tak, jak se to používá. A následují další iterace téhož.

Vždy mě baví diskuse na téma "univerzální FS". Vždy, když přijde na přetřes nový FS, který má třeba nějaké další vlastnosti a třeba nějaké historické použití zvládá hůře, tak se hned objeví kritika, že to není univerzální FS.

Ve skutečnosti žádný FS není ani v nejmenším univerzální. Jen si lidé zvykli obcházet určité vlastnosti "univerzálních" fs a považují to za standard. Viz třeba to nekonečné vytváření stromů pro uložení většího než malého počtu souborů.

* Parametry příkazového řádku. Tohle je problém implementace těch programů. Nevím kde (asi v Art of UNIX programming) se píše, že program by se měl implementovat jako knihovna a potom k tomu dodat interface. A ten může být libovolný (CLI, REST, GUI, WEB, ...). To, že je nutné donekonečna skládat parametry příkazové řádky hovoří o tom, že většina programů je prostě špatně napsaná a svazuje konkrétní rozhraní s programem. Tj. u dobře napsaných programů použiješ rovnou jejich knihovnu a cli interface se vůbec nemusíš zabývat.

Tohle se mi líbí na Pythonu, každý program je modul, který lze importovat a není potřeba se zabývat jeho spustitelných interface.

A jednu faktickou:
Kdyby to uměl, můžete prostě uložit daný slovník s danými klíči a hodnotami, a příště po nich sáhnout.
Umí, xattr (což je key-value). Problém je, že to jednak skoro nic nepoužívá a pokud už to něco používá, tak o to přijdete s první diskovou operací. Jsou nástroje, které s tím umí pracovat, ale některé ne, takže pokud kopírujete data z fs, který xattr umí na fs, které je neumí (nebo má vypnuté), tak o tato data tiše přijdete. NTFS mají Alternate Streams (kdy jeden soubor má více binárních dat), opět, nikdo to nepoužívá a tiše o to přijdete.

Osobně si myslím, že na FS by mělo být všechno zcela explicitně viditelné. Tj neskrývat nic v žádných skrytých streamech či atributech. FS je abstrakce nad blokovým zařízením, nic víc, nic méně. Nad touto abstrakcí lze budovat DB vyšší úrovně.
Bystroushaak avatar 10.12.2018 11:59 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
* Každá data načítaná z disku nebo posílaná po síti jsou ze své podstaty binární. (Současné) disky a sítě umí posílat pouze sekvenci jedniček a nul.
Ano.
To, že ta data budeme považovat za strukturovaná je vždy věcí externí interpretace.
Ano, jedna z myšlenek ovšem byla, že ta externí interpretace by byla jednotná, tj všichni se domluvili +- na jedné a OS by pro to přímo měl podporu.
Tj pokud načtu binární stream, tak musím dopředu vědět, že tohle je png a tohle je xml a podle toho se k tomu chovat.
Tohle podle mého názoru není pravda, respektive to platí pro současný stav. Pokud máš obecný formát na popis binárních stromů, tak nese strukturu obsaženou sám v sobě (za předpokladu, že umíš nativně pracovat s tím obecným formátem). Stejně tak může nést informace o tom co vlastně je.
Aby to fungovalo sebepopisně, tak by to musel být spustitelný program. A asi nechceme spouštět všechno, co přiteče po síti.
Ne, tohle není pravda. JSON a XML taky nejsou spustitelné, přestože jsou do velké míry sebepopisné. Podmínkou reflexe není spustitelnost.
Vždy mě baví diskuse na téma "univerzální FS". Vždy, když přijde na přetřes nový FS, který má třeba nějaké další vlastnosti a třeba nějaké historické použití zvládá hůře, tak se hned objeví kritika, že to není univerzální FS.

Ve skutečnosti žádný FS není ani v nejmenším univerzální. Jen si lidé zvykli obcházet určité vlastnosti "univerzálních" fs a považují to za standard. Viz třeba to nekonečné vytváření stromů pro uložení většího než malého počtu souborů.
Uhm. Chápu co říkáš, ale pořád nevidím důvod proč by to mělo existovat.
* Parametry příkazového řádku. Tohle je problém implementace těch programů. Nevím kde (asi v Art of UNIX programming) se píše, že program by se měl implementovat jako knihovna a potom k tomu dodat interface. A ten může být libovolný (CLI, REST, GUI, WEB, ...). To, že je nutné donekonečna skládat parametry příkazové řádky hovoří o tom, že většina programů je prostě špatně napsaná a svazuje konkrétní rozhraní s programem. Tj. u dobře napsaných programů použiješ rovnou jejich knihovnu a cli interface se vůbec nemusíš zabývat.
Četl jsem a je to hezká idea, kterou zabíjí mimo jiné i to, že programy jsou psané v různých jazycích. Sám tak ale svoje python scripty prakticky bez výjimky dělám.
Umí, xattr (což je key-value). Problém je, že to jednak skoro nic nepoužívá a pokud už to něco používá, tak o to přijdete s první diskovou operací. Jsou nástroje, které s tím umí pracovat, ale některé ne, takže pokud kopírujete data z fs, který xattr umí na fs, které je neumí (nebo má vypnuté), tak o tato data tiše přijdete. NTFS mají Alternate Streams (kdy jeden soubor má více binárních dat), opět, nikdo to nepoužívá a tiše o to přijdete.
Vím o tom. Myslím, že by bylo lepší, kdyby to neexistovalo, protože je to zprasený nevážně myšlený krok mnou popisovaným směrem, který celou myšlenku v konečném důsledku diskredituje.
Heron avatar 10.12.2018 12:15 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ano, jedna z myšlenek ovšem byla, že ta externí interpretace by byla jednotná, tj všichni se domluvili +- na jedné a OS by pro to přímo měl podporu.

Jasně. Otázkou je nakolik je to reálné (vidíme, že spíše ne). U některých věcí se to povedlo (a asi by bylo na studii proč zrovna v těch případech), ale ani ty nejsou časově stabilní.
Ne, tohle není pravda. JSON a XML taky nejsou spustitelné, přestože jsou do velké míry sebepopisné.
Pokud mi přijde na vstupu binární stream a já ho podle nějakých heuristik prohlásím za textový (v nějakém konkrétním kódování), tak to ještě neznamená, že vím, co je to zač. A další heuristikou můžu zjistit, že to vypadá třeba jako INI, jenže potom přijde systemd s vlastním "vypadá to jako INI, ale není to INI" formátem a jsi opět víš kde. Proto i pro ty sebepopisné formáty je stále potřeba externí popis říkající který konkrétní formát to je. (Jasně, tím se opět dostáváme k předchozímu bodu, že se všichni na jednom konkrétním domluví.)
Chápu co říkáš, ale pořád nevidím důvod proč by to mělo existovat.
Mělo existovat co? Univerzální FS? Však já po ničem takovém nevolám, jen poukazuju na to, že to tu nemáme ani dnes (i když si to mnozí lidé myslí).
Četl jsem a je to hezká idea, kterou zabíjí mimo jiné i to, že programy jsou psané v různých jazycích.
Jo. Ono kdyby se chtělo, tak k tomu dodávají bindings (což lepší programy mají) a je to vyřešené.
Myslím, že by bylo lepší, kdyby to neexistovalo
Tak na tom se shodneme.
Bystroushaak avatar 10.12.2018 12:29 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Pokud mi přijde na vstupu binární stream a já ho podle nějakých heuristik prohlásím za textový (v nějakém konkrétním kódování), tak to ještě neznamená, že vím, co je to zač. A další heuristikou můžu zjistit, že to vypadá třeba jako INI, jenže potom přijde systemd s vlastním "vypadá to jako INI, ale není to INI" formátem a jsi opět víš kde. Proto i pro ty sebepopisné formáty je stále potřeba externí popis říkající který konkrétní formát to je. (Jasně, tím se opět dostáváme k předchozímu bodu, že se všichni na jednom konkrétním domluví.)
Myslím že máme v tomhle ohledu zásadní nepochopení, možná vzniklé slovem „sebepopisný“. Představ si formát, který umíš automaticky bez nutnosti nad ním přemýšlet rozbalit do stromů / grafů, kde máš navíc uvnitř obsaženou sémantickou informaci a volitelně i pointery na externí nápovědu.

INI je artefakt daný neschopností ukládat nativně strukturu - proto existuje parser a popis a specifikace způsobu jak ukládat strukturu zrovna v INI. Proto existují konfliktní implementace, třeba v tom systemd.
Mělo existovat co? Univerzální FS? Však já po ničem takovém nevolám, jen poukazuju na to, že to tu nemáme ani dnes (i když si to mnozí lidé myslí).
Myslím spíš dnešní koncepty FS.
Heron avatar 10.12.2018 12:52 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Myslím že máme v tomhle ohledu zásadní nepochopení
To je možné.
Představ si formát, který umíš automaticky bez nutnosti nad ním přemýšlet rozbalit do stromů / grafů, kde máš navíc uvnitř obsaženou sémantickou informaci a volitelně i pointery na externí nápovědu.

Tohle moc k pochopení nepřidalo.

Pokud mi přijdou obecná binární data a já nevím co to je (nemám tuto externí informaci), tak nikdy s jistotou nezjistím, že je to strom, že na offsetu x je pointer na další podstrom a že tato větev zrovna obsahuje popis datového typu. Tohle je informace, kterou vždy musím vědět dopředu. (Ale jestli je celé nepochopení postaveno na tom, že se všichni shodli právě na tomto formátu dat, tak OK, další diskuse už není nutná a je to zcela jasné.)
Myslím spíš dnešní koncepty FS.

Tak ono je to dané historicky. API k přístupu souboru je vlastně stejné jako API, které se používalo u pásek. Má to převzaté i ty názvy (rewind) a omezení (například nemožnost vložit další data doprostřed souboru - páska tohle fyzicky neumožňuje, to je jasné, ale blokové zařízení s tím v principu nemá problém, ale z historických důvodů je zachovaná zpětná kompatibilita a tohle tam prostě není - tuším že Reiser si dovolil něco takového naimplementovat, ale nebylo to přijato). Takže dnešní FS si lze představit jako kolekci pásek.
Bystroushaak avatar 10.12.2018 13:19 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ale jestli je celé nepochopení postaveno na tom, že se všichni shodli právě na tomto formátu dat, tak OK, další diskuse už není nutná a je to zcela jasné.
Nejde jen o to že by se na tom všichni shodli, že se s ničím jiným ani nesetkáš. Prostě ani nemáš důvod otevřít soubor jako bajty, když ho vždycky můžeš otevřít jako záznam s jasně definovanou strukturou, což podporuje přímo OS ve volání open().
xkucf03 avatar 12.12.2018 17:55 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše knihovny vs. celý OS

A nestačí tohle řešit na úrovni knihovny? Tohle jsem dělal v tom svém alt2xml prototypu. Načteš soubor v libovolném (podporovaném) formátu a vypadne ti z toho objektový strom, se kterým už pracuješ jednotným způsobem bez ohledu na původní formát.

Když implementuješ takovéto fragmenty cílového stavu jako knihovny použitelné v rámci stávajících systémů, tak se k tomu svému objektovému systému můžeš časem dopracovat evoluční cestou. Tzn. mít knihovnu pro práci s různými formáty, mít strojově čitelný popis CLI rozhraní atd. a časem z těchto fragmentů poskládáš celý systém resp. postupně to na něj překlopíš.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
xkucf03 avatar 12.12.2018 17:38 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše XML
Představ si formát, který umíš automaticky bez nutnosti nad ním přemýšlet rozbalit do stromů / grafů, kde máš navíc uvnitř obsaženou sémantickou informaci a volitelně i pointery na externí nápovědu.

Přesně tohle dělá XML. Máš strom a víš, jak se jednotlivé atributy jmenují. Jejich význam je popsaný v XSD, na které se to XML ve své hlavičce odkazuje. Pokud je problém ukecanost, existují binární formy XML.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
xkucf03 avatar 12.12.2018 17:30 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Parametry příkazového řádku. Tohle je problém implementace těch programů. Nevím kde (asi v Art of UNIX programming) se píše, že program by se měl implementovat jako knihovna a potom k tomu dodat interface. A ten může být libovolný (CLI, REST, GUI, WEB, ...). To, že je nutné donekonečna skládat parametry příkazové řádky hovoří o tom, že většina programů je prostě špatně napsaná a svazuje konkrétní rozhraní s programem. Tj. u dobře napsaných programů použiješ rovnou jejich knihovnu a cli interface se vůbec nemusíš zabývat.

Ano, bylo to v téhle knize (píšu o tom v komentáři níže). Rozdělit programy na knihovnu a rozhraní je správná cesta. Ale přesto bych nezavrhoval ani to volání přes CLI z jiného programu. Často to jsou skripty, člověk si něco vyzkouší v Bashi, funguje mu to... a pak píše program třeba v Pythonu nebo Javě, tak přirozeně chce pře-použít to, co už má vyzkoušené a ví, že to funguje. Pokud je to CLI rozhraní příčetně navržené, tak se to dá úspěšně použít i jako API. Obecně to ideální není, ale někdy to může být nejlepší volba.

A nejen to je důvod, proč by bylo dobré mít nějakou reflexi a samopopisnost toho CLI API. Z takového popisu1 se pak dají krásně odvozovat podklady pro Bash completion nebo třeba napovídání pro editor skriptů2. Zároveň to může kromě samotných parametrů zobrazovat i dokumentaci. Taky to poslouží pro validaci. Bylo by krásné, kdybych mohl spustit libovolný program třeba s parametrem --describe-api a ono by mi to vyplivlo XML ve standardním formátu, které by obsahovalo popis všech CLI parametrů3, proměnných prostředí, vstupních a výstupních proudů, návratových kódů a ideálně informaci o náročnosti a stylu práce -- např. program pracuje proudově, průběžně čte i zapisuje a je tudíž schopný zpracovat teoreticky nekonečné množství dat s konstantní paměťovou náročností nebo naopak program načte všechna data do paměti, a pak teprve vyplivne výstup.

A udělat něco takového (tzn. specifikaci formátu a základní knihovny a nástroje) mi přijde užitečnější než snít o dokonalém objektovém OS. Dovedu si nad tím představit IDE nebo vizuální návrhář, ve kterém by sis naklikal hodnoty proměnných prostředí (jejich názvy by to nabízelo a zobrazovalo popis), parametrů a napojení vstupních a výstupních proudů. Něco jako GNU Radio Companion, kde by sis poskládal bloky, naparametrizoval, pospojoval a pak z toho vygeneroval program/GUI.

[1] u nás na škole o tom psal někdo bakalářku/diplomku, ale nemůžu to teď najít
[2] Umí to nějaký editor? Vždyť by to šlo i dneska, stačilo by, aby editor volal Bash completion a podle toho napovídal.
[3] včetně jejich gramatiky, tzn. jak na sebe jednotlivé parametry navazují a jaké jsou mezi nimi vztahy, nikoli co je uvnitř nich -- uvnitř by měly být jen atomické hodnoty určitého datového typu

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.12.2018 17:52 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
+1
10.12.2018 11:52 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nezvlád jsem to přečíst celé (ještě se k tomu zkusím vrátit), tak jen dvě poznámky:

1) tak nějak naznačuješ vznik jakéhosi standardu pro ukládání a předávání dat. Hezká myšlenka, jen se obávám, že by to dopadlo nějak takto.

2) jen tak pro rozšíření obzorů si zkus něco nastudovat o z/OS. Je tam spousta věcí jinak (třeba ten FS, ebcdic místo ascii).
Bystroushaak avatar 10.12.2018 12:00 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
1) tak nějak naznačuješ vznik jakéhosi standardu pro ukládání a předávání dat. Hezká myšlenka, jen se obávám, že by to dopadlo nějak takto.
Netvrdím, že to musí být něco nového, jen že by to mělo být něco jednotného a univerzálního.
2) jen tak pro rozšíření obzorů si zkus něco nastudovat o z/OS. Je tam spousta věcí jinak (třeba ten FS, ebcdic místo ascii).
Ok.
Bystroushaak avatar 10.12.2018 12:01 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
2) jen tak pro rozšíření obzorů si zkus něco nastudovat o z/OS. Je tam spousta věcí jinak (třeba ten FS, ebcdic místo ascii).
Teď mám pocit, že už jsem na to kdysi koukal.
10.12.2018 14:02 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ta novost nebyla ta hlavní pointa. Spíš něco ve smyslu, který naznačoval Heron -vytvoří se něco jednotného a univerzálního a pak přijde někdo, kdo si to přiohne a pak to postupně povede k tomu, co je popsáno v tom xkcd.

Tak se na to koukni znova :) pro lidi zvyklé na x86 (a samtam arm) a posix, to bývá celkem šok. Třeba zrovna ty soubory s jakousi stromovou strukturou v tomhle systému jsou (neptej se mě na detaily, já ten systém zas tak moc neznám).
10.12.2018 12:07 racik
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Skus sa pozriet na Phantom OS. Tam je zapracovanych zopar tvojich myslienok a je open source. Nieviem ci este na nom pracuju a je vo velmi pre alpha stadiu Phantom OS
Bystroushaak avatar 10.12.2018 12:10 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Bystroushaak avatar 10.12.2018 15:17 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Podle popisu (https://github.com/dzavalishin/phantomuserland/wiki/PhantomArchitecture) to vypadá suprově, škoda že podle commit logu je to mrtvé.
10.12.2018 12:11 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
No, jelikoz v praci programuji mainframy, tak bych k tomu rad dodal trochu historicke perspektivy, ktera tomu myslim chybi.

Na mainframu (ono v podstate s tim souvisi i treba COBOL) je dlouha tradice pouzivat "strukturovana data", jak pises, ve forme posloupnosti "plochych" (nehierarchickych) zaznamu. A OS (a dokonce i hardware) to driv podporoval (namatkou nebo toto).

Takze ne, soubory a sockety nebyly prvni. Naopak, byly zjedodusujici reakci na toto, protoze z hlediska programatora je znacne bolestne s tim pracovat.

Nicmene, kdyz se podivas do z/OS (a zahrnes i middleware jako CICS, DB2, IMS, MQ), vsechno co chces tam v nejake forme je uz nekdy od 70. let, akorat se na tom take podepsala evoluce, takze je to casto dost neelegantni.

Myslim, ze se pohybujeme v kruhu v zasade ze dvou duvodu. Jeden duvod je, ze chceme veci abstrahovat, aby byly jednodussi. Casto to ovsem skonci tak, ze zjistime, ze ty abstrakce nejsou vhodne nebo dost vykonne a tak je musime porusit.. a skoncime s necim, co bylo mysleno dobre (a mozna to i dela co chces), ale vypada to obludne.

A lide si pak reknou "Uz nikdy vic schema!", a zacina se nove kolo. To byl pripad Unixu, Perlu/Pythonu, HTML/CSS, NoSQL, Dockeru...

Druhy duvod je, ze IBM celkem vyresila vsechny problemy s business aplikacemi (to je zhruba o cem mluvis) na mainframu uz pred temi zhruba 40 lety. Jenze za to pak chteli penize.. a spousta lidi si myslelo, a pravem, ze to napisou sami levneji a lepe (minimalne pro ten jejich specialni pripad). A proto se to pise porad znovu. (IBM je treba v tomto vysvetleni brat jen jako priklad z mnoha, muzes si doplnit libovolnou velkou IT firmu.)

Jeste jsem taky chtel zminit AS/400 - coz byl pokus mit filesystem jako databazi - ale moc o ni nevim. Taky jsem chtel zminit Dhall, coz vypada jako nadejny posun z toho konfiguracniho silenstvi.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
Bystroushaak avatar 10.12.2018 12:31 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jeste jsem taky chtel zminit AS/400 - coz byl pokus mit filesystem jako databazi - ale moc o ni nevim.
Ah, AS/400 jsem si kdysi trochu nastudoval. Jeden čas jsem se dokonce hlásil na pozici správce nějaké AS/400, s tím že se to naučím, ale nedostal jsem se ani k pohovoru :)
14.12.2018 11:20 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jeste jsem chtel dodat k tomu FS jako databazi, a proc to, jak tu psalo uz vic lidi, nemusi byt dobry napad.

Na z/OS existuje VSAM (uz jsem to linkoval), a to je v podstate specialni soubor (sveho druhu filesystem, na z/OS je to trochu rozostrene, co je co, takze tomu pro jistotu rikame dataset), ktery funguje jako KV databaze. A z/OS poskytuje sluzby jak s nim pracovat (treba zamykani), a existuji nad to (odpradavna) i transakce.

Ale treba DB2 to nepouziva, ma vlastni zpusob ukladani dat. A ma to nektere nevyhody, ktere plynou z historie (treba omezeni na velikost). Volba algoritmu je take z dnesni perspektivy dost problematicka.

Co tim chci rict - ono neni vlastne ani jasne, jake vlastnosti by ta databaze mela mit. Pokud zvolime nejake, znamena to navrhovy kompromis v necem jinem. A ten kompromis se muze projevit i pozde, az nekdo objevi neco noveho.

Ono vlastne tem kompromisum podlehaji i samotne FS. Treba z/OS ma technicky ruznych FS (tam se tomu rika "access method") vic, vetsina z nich je zastarala, ale na druhou stranu to umoznuje nektere zajimave aplikace.

Cely ten blogpost mi prijde trochu jako stiznost na to, ze jako SW inzenyr musis delat inzenyrska rozhodnuti (tj. kompromisy) i tam, kde na tom tolik nezalezi a mohl by existovat jednotny standard. (Pritom paradoxne, zda se mi, ze jsi proti standardum - ale na to ohledne te komory ti jeste odpovim.)
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
Bystroushaak avatar 10.12.2018 13:22 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Na mainframu (ono v podstate s tim souvisi i treba COBOL) je dlouha tradice pouzivat "strukturovana data", jak pises, ve forme posloupnosti "plochych" (nehierarchickych) zaznamu. A OS (a dokonce i hardware) to driv podporoval (namatkou nebo toto).
To si myslím, že byla docela kritická chyba. Myslím, že chceš minimálně strom, ne-li rovnou graf.
10.12.2018 14:24 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To si nejsem tak uplne jisty. Problem s ukladanim hierarchickych nebo grafovych struktur se resi podobne jako u relacnich databazi, tzn. bud se pouziji ruzne soubory s ruznou definici zaznamu, nebo se zkombinuji ruzne zaznamy do variantniho zaznamu (je tam nekde zezacatku policko, ktere urcuje typ zaznamu a to rika, jaka bude dalsi struktura).

A pak se to proste pri zpracovani ruzne setridi a spoji podle klicu, jak je potreba. Ma to proste svoji eleganci, tyhle stare aplikace. (Ale ono to vlastne nema az tak daleko k relacnim databazim.)
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
Bystroushaak avatar 10.12.2018 15:13 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tak určitě nezpochybňuji eleganci ani efektivitu, ale jako programátor hodně často pracuješ se stromem. Neříkám, že to musí být strom vždy, ale pokud to není efektivní (indexovaný) strom nikdy, si ho prostě musíš pořád dokolečka vytvářet, což je pattern který lze abstrahovat níž.
10.12.2018 13:26 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Nicmene, kdyz se podivas do z/OS (a zahrnes i middleware jako CICS, DB2, IMS, MQ), vsechno co chces tam v nejake forme je uz nekdy od 70. let
Tyto systemy znam jen hodne povrchne, ale neni to tim, ze je vse uzavrene v ramci jednoho velice specifickeho ekosystemu?
takze je to casto dost neelegantni.
To muze hrat podstatnou roli i v adopci v jinych castech pocitacoveho sveta. Vem si WS zalozene na SOAP vs. RESTful API.
A lide si pak reknou "Uz nikdy vic schema!", a zacina se nove kolo.

Jestli to nebude tim, ze reseni "one size fits all" proste neexistuje.

Podstatna cast toho textu mi pak prijde jako nabeh na dalsi flame typu dynamicke vs. staticke typovani vedeny jinymi slovy. Sebepopisna data odpovidaji dynamickemu typovani (je zde vyhoda primeho pristupu k metadatum, za cenu podstatne rezie) vs. staticka typy (kdy metadata jsou ulozena bokem, se vsemi dusledky). Takze dle meho, zadne univerzalni reseni patrne neexistuje.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
10.12.2018 14:56 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tyto systemy znam jen hodne povrchne, ale neni to tim, ze je vse uzavrene v ramci jednoho velice specifickeho ekosystemu?
Je to uzavrene a je to problem. Je to vlastne ten druhy problem, ze pokud se nekomu podari uspesne vyresit Bystroushaakovy problemy, tak za to chce zaplatit. A s tim souvisi, ze to nechce ani "pujcit" jen tak nekomu zdarma.

On je rozdil i ve filozofii. Unix (protoze vznikl v kontrastu s Multicsem) je hodne otevreny uzivatelum (treba kazdy ma moznost pustit si shell, vyrabet si jake chce soubory a tak podobne), zatimco mainframe je centralizovane dost zamceny a na skoro vsechno jsou tam nejaka prava. Bystroushaak to chce dotahnout jeste dal, ke Smalltalku a Lispu, coz si myslim jde spis proti tomu co chteji korporace a tak. Zase - socialni problem.
Podstatna cast toho textu mi pak prijde jako nabeh na dalsi flame typu dynamicke vs. staticke typovani vedeny jinymi slovy.
Mas myslim pravdu, a v podstate je to ten prvni problem, co popisuji. On je to vlastne taky zcasti, zda se mi, socialni problem - nekdo to datove schema vlastni.

Mohlo to celkem dobre dopadnout tak, ze by se vsechno zpracovani (business logika) delalo nad schematem dat v databazi (treba v PL/SQL nebo necem podobnem). To by bylo blizke tomu, co Bystroushaak chce. Jenze pro zmenu schematu (a vlastne cehokoli) potrebovali programatori komunikovat s DB adminem, a to se jim nechtelo.

Tak si vymysleli, ze se na DB vykaslou, kdyz je zamcena pro pristup, a budou si to delat mimo. Stejne s tim schematem jsou jen problemy.. a tak zacal ten kolobeh.

Nicmene, ja si myslim, ze ty problemy jsou ve skutecnosti jeste hlubsi. Zatim neumime s temi schematy dat obecne pracovat (abychom zachovali kompletni semantiku, jakou potrebujeme), a nechat s nimi pracovat pocitace vede v lepsim pripade na NP-tezke, v horsim pripade algoritmicky ci prakticky neresitelne, problemy. Takze to zustava domenou inzenyrske vynalezavosti.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
Bystroushaak avatar 10.12.2018 15:16 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Bystroushaak to chce dotahnout jeste dal, ke Smalltalku a Lispu, coz si myslim jde spis proti tomu co chteji korporace a tak. Zase - socialni problem.
Pozor, jak jsem deklaroval v začátku, provádím na tohle téma průzkum a výzkum, například teď dělám vlastní experimentální implementaci Selfu, kde jedním ze sedmi výstupních experimentů má být právě vyzkoušet to používat jako interface nad OS.

Chci znova zdůraznit, že nemám potřebu cpát můj přístup ostatním nad rámec článku. Pokud jsou lidi spokojení se svým systémem, tak proti tomu fakt nic nemám. Jen jsem chtěl prodiskutovat některé z myšlenek kolem toho.
10.12.2018 15:43 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
On je to vlastne taky zcasti, zda se mi, socialni problem - nekdo to datove schema vlastni.
To je jeden pohled. Druhy, technicky, je ten, ze vytvoreni schema je krok, ktery se musi udelat v hodne casne fazi vyvoje a jakakoliv nedomyslenost nebo chybny predpokload se projevi pozdeji a je velmi tezke ji/jej vzit zpet. Proto se nedivim rozmachu ruznych schema-less databazi, kdy ti lidi sice maji v databazi neporadek, ale aspon se veci pohybuji rozumnym krokem kupredu, oproti tradicnim databazim, kdy se veci hybou dopredu pomalu a i tak to skonci tim, ze driv nebo pozdeji je v te databazi neporadek, protoze je nutne hledat ruzne ohejbaky a narovnavaky, protoze schema bylo definovano tak a tak.
Nicmene, ja si myslim, ze ty problemy jsou ve skutecnosti jeste hlubsi. Zatim neumime s temi schematy dat obecne pracovat (abychom zachovali kompletni semantiku, jakou potrebujeme), a nechat s nimi pracovat pocitace vede v lepsim pripade na NP-tezke, v horsim pripade algoritmicky ci prakticky neresitelne, problemy.

Souhlas, jelikoz schemata odpovidaji typum, daji se znalosti z teto oblasti aplikovat docela primocare i na ne, a to se vsemi dusledky.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
Bystroushaak avatar 10.12.2018 20:19 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Druhy, technicky, je ten, ze vytvoreni schema je krok, ktery se musi udelat v hodne casne fazi vyvoje
To není obecná pravda. Například v práci generujeme swagger schéma z existujících java class, ze kterých je poté generován python interface. Obecně si dovedu představit systémy, kde by to fungovalo hladšeji.
10.12.2018 21:44 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To není obecná pravda. Například v práci generujeme swagger schéma z existujících java class, ze kterých je poté generován python interface. Obecně si dovedu představit systémy, kde by to fungovalo hladšeji.
V tomto pripade neni to schema definovane explicitne, ale implicitne temi javovskymi tridami.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
Bystroushaak avatar 10.12.2018 21:46 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ano, ale nemusel jsi ho udělat v hodně časné fázi vývoje, naopak vývoj proběhl úplně normálně.
11.12.2018 11:48 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
No a co jste delali v tom Pythonu, nez vam ten Swagger vygeneroval to API? To je myslim, co ma deda.jabko na mysli tim "v casne fazi".

Jinak docela by me zajimalo, jake vyhody ma OpenAPI proti WSDL. (Ja se vsemu kolem webu snazim vyhybat, ale zdalky mi to pripada hodne podobne.) Je to proste moda, tedy socialni problem.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
Bystroushaak avatar 11.12.2018 12:04 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
No a co jste delali v tom Pythonu, nez vam ten Swagger vygeneroval to API? To je myslim, co ma deda.jabko na mysli tim "v casne fazi".
Nedělali jsme to v pythonu, dělal to vedlejší team v Javě. My z pythonu pak jen komunikovali vygenerovaným API s tím jejich javovským kódem skrz ORM co automaticky vygeneruje swagger.
Jinak docela by me zajimalo, jake vyhody ma OpenAPI proti WSDL.
Nemám tušení. Možná že není mrtvý a stojí za ním nědko konkrétní, kdo by dotahoval tooling?
xkucf03 avatar 12.12.2018 18:40 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Zacyklení, složitost a jednoduchost
Nemám tušení. Možná že není mrtvý a stojí za ním nědko konkrétní, kdo by dotahoval tooling?

A za WSDL/SOAPem nestál nikdo konkrétní? Právě že stál a dokonce velké firmy. Dneska je to hotová věc, nástrojů i dokumentace je k tomu spousta, už není potřeba o tom psát osvětové články a přiživovat módní vlnu, vše už bylo napsáno a všichni o tom vědí. Akorát to některým lidem přišlo moc "složité", a tak začali vymýšlet něco "jednoduššího". OpenAPI/Swagger je akorát nová iterace téhož a časem to dopadne stejně, nabalí se na to spousta lidí, myšlenek, nástrojů, standardy nabobtnají... a pak přijdou jiní lidé a řeknou: fuj, ten Swagger je ale složitý, pojďme vymyslet něco jednoduššího. A celé to začne nanovo.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
11.12.2018 11:58 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Souhlas, jelikoz schemata odpovidaji typum, daji se znalosti z teto oblasti aplikovat docela primocare i na ne, a to se vsemi dusledky.
Ano.

Uz jenom takovy zdanlive trivialni ukol - mame dany izomorfismus mezi dvema typy (prevod mezi dvema schematy), a chteli bychom vsechen nas kod predelat, aby se pouzival druhy typ misto toho prvniho.

Teoreticky by tenhle refaktoring (v ramci celeho SW stacku!) mohl zvladnout pocitac. Ale tim by skoro vsechen kod dost zprznil. Takze to nakonec musi udelat lide a rucne.
Lidstvo má již jen 12 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte výzvu na proplanetu.cz!
Bystroushaak avatar 10.12.2018 20:22 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Podstatna cast toho textu mi pak prijde jako nabeh na dalsi flame typu dynamicke vs. staticke typovani vedeny jinymi slovy. Sebepopisna data odpovidaji dynamickemu typovani (je zde vyhoda primeho pristupu k metadatum, za cenu podstatne rezie) vs. staticka typy (kdy metadata jsou ulozena bokem, se vsemi dusledky). Takze dle meho, zadne univerzalni reseni patrne neexistuje.
Původně jsem tam měl skutečně ještě další kapitolku na přibližně podobné téma, nechtěl jsem tam ale zavést flame na téma typů, ale spíš zdůraznit (subjektivní) důležitost reflexe. Nakonec jsem se rozhodl nechat si to do jiného blogu.

Myslíš že bych se do toho neměl pouštět?
10.12.2018 21:47 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Myslíš že bych se do toho neměl pouštět?
Otazkou je, co by to melo prinest.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
10.12.2018 12:59 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
K tomu pro většinu operací chybí atomicita, a transakce nejsou podporovány vůbec. Paralelní zápisy a čtení fungují v různých operačních systémech různě, a ve skutečnosti není garantováno naprosto nic. Schválně si to srovnejte se světem databází, kde se ACID považuje za samozřejmost.
Tak zkus NTFS, ten transakce umi. A co se tyce ACID, nekteri lidi s NoSQL databazema to jako samozrejmost uplne nepovazuji.
místo toho abych v jednom formátu dělal doc.getElementByTagName("person")[0].name.value a v druhém doc["people"][0]["name"].
Toto neni problem dat jako takovych, ale rozhrani pro pristup k datum.
Nemluvím tady o parsování XML parserem, mluvím tu o přímém načtení do paměti, ve stylu message packu, SBE, nebo FlatBuffers, či Cap’n Proto. Bez toho aniž by bylo třeba vyhodnocovat text a řešit escape sekvence a formát unicode.
Toto je opet problem rozhrani pro pristup k datum + ne vzdy je zadouci nacitat cela data do pameti. Coz by tedy slo resit tak, ze si udelas abstrakci nad ruznymi formaty a pristupy k nim a pracujes s nimi jednotne. Co ti brani si neco takoveho naprogramovat?
O tom že data popisují sebe sama přímo svou strukturou, ne externím popisem.
To nemusi byt opet zadouci. Vem si treba IP paket.
Celé je to zapouzdřené a komunikuje to jen pomocí nějakých standardních způsobů (stdin/out/err, socket, signály, env, error kódy, zápisy do souborů..). ... nevidím důvod, proč potom nezpřístupnit jednotlivé metody tohoto objektu i z venčí.
Odpovidas si sam. To zapouzdreni ma svuj smysl, protoze to umoznuje odstinit se od implementacnich detailu a kdykoliv dany program nahradit jinym, napr. s rozsirenymi funkcemi, opravenou chybou, jinou licenci, atp. Je to aplikace stejneho principu jako v beznych programovacich jazycich, jen o uroven abstrakce vys. Zpristupneni metod by bylo na urovni pristupu k privatnim metodam a atributum v objektovych jazycich. Pokud chce nekdo zpristupnit dilci funkce aplikace, je zde moznost aplikaci vytvorit jako knihovnu + frontend, jak navrhuje heron.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
10.12.2018 13:03 hefo
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Pravdepodobne budem opakovať, čo už niekto povedal, ale podľa mňa problém, prečo takéto teoreticky výborné koncepty nedosiahli (aspoň zatiaľ) praktické nasadenie, je ten, že v IT vývoj prebieha evolučne, nie revolučne. Väčšina súčasných princípov je starých, ale stále sa na nich niečo vylepšuje. Skoková zmena na iný koncept by bola krátkodobo veľmi drahá, tak ak za tým nie je skrytá nejaká bombová biznisová príležitosť, tak sa to jednoducho neurobí.

Napríklad, čo sa týka filesystémov - pokiaľ viem, Oracle mal v (nedávnej) minulosti koncept raw devices, t.j. niečo ako: načo budeme mať filesystém a nad ním databázu, ušetríme kopec réžie a problémov tým, že nad diskami/volumami spravíme databázu priamo. Ale nejako sa to neujalo - zjavne ten "kopec" nebol až taký veľký a súčasné filesystémy sú "good enough" (pre väčšinu vecí) na to, aby sa muselo znovu vynachádzať koleso (a všetky komplikované veci ohľadne volume managementu, zaisťovania konzistencie, zamykania,...). Univerzálne filesystémy sú síce neveľmi optimálne, ale zato dostatočne všeobecné pre bežné účely. Skladovanie bambiliónu položiek u ulož.to je práve jeden z tých "ne-bežných" účelov...
Bystroushaak avatar 10.12.2018 13:16 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Pravdepodobne budem opakovať, čo už niekto povedal, ale podľa mňa problém, prečo takéto teoreticky výborné koncepty nedosiahli (aspoň zatiaľ) praktické nasadenie, je ten, že v IT vývoj prebieha evolučne, nie revolučne. Väčšina súčasných princípov je starých, ale stále sa na nich niečo vylepšuje. Skoková zmena na iný koncept by bola krátkodobo veľmi drahá, tak ak za tým nie je skrytá nejaká bombová biznisová príležitosť, tak sa to jednoducho neurobí.
Ony se ujaly a nikoliv nepodstatnou část historie dokonce vytvářely funkční tržní prostředí. Všechno to ale bylo umřelo s příchodem x86, který ostatní platformy vyžadující často specializovaný hardware podrtil výkonem.

Viz situace okolo Genery a Smalltalku.
Skladovanie bambiliónu položiek u ulož.to je práve jeden z tých "ne-bežných" účelov...
No, to právě ani moc není. Třeba můj Syncthing adresář obsahuje cca 200 000 souborů díky různým (nutno dodat že osobním) gitům. Což sice nerozbíjí počet inodů, ale rozbíjí to třeba inotify a kopírovat to z disku na disk je porod trvající dlouhé hodiny, i přestože to má jen asi 11 GB.

Jinak mi přišlo zajímavé, že třeba SQLite je v různých benchmarcích o hodně rychlejší, než samotný filesystém.
10.12.2018 14:37 hefo
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ony se ujaly a nikoliv nepodstatnou část historie dokonce vytvářely funkční tržní prostředí. Všechno to ale bylo umřelo s příchodem x86, který ostatní platformy vyžadující často specializovaný hardware podrtil výkonem.

Je otázka, či to ale mohlo vôbec byť v súčasnej spoločnosti inak. Máme totiž podobný vývoj napr. pri mobiloch alebo autách. Je problém kúpiť nejaký použiteľný súdobý mobilný telefón s fyzickou, nedajbože QWERTY klávesnicou (momentálne používam 8 rokov starú Nokiu E52 so Symbianom, ale už začína byť jeho nepodporovanosť poznať. Manželka má zase nejakú QWERTY ružovú nokiu tuším C5 alebo ako sa to volá, a veľmi si na tú klávesnicu zvykla. Neviem, čo jej kúpim až to doslúži). A bežne vyrábané autá sú z veľkej časti uniformné nezaujímavé spuchliny, kde niekedy ťažko rozoznať výrobcu. Pritom pred 15 rokmi u mobilov a povedzme 50 rokmi pri autách bola ponuka brutálne variabilnejšia...

No ale čo sa s tým dá robiť?
Bystroushaak avatar 10.12.2018 15:12 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Je otázka, či to ale mohlo vôbec byť v súčasnej spoločnosti inak.
Zrovna tohle se pomalu narovnává, jednak máš tolik výkonu, že ten overhead už tě moc netrápí a taky je trendem cpát do procesorů FPGA, na které budeš moct dynamicky offloadovat různé detaily.
No ale čo sa s tým dá robiť?
Srát na konvence?
10.12.2018 13:35 Odin
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Pripada mi, ze castecne znovuvynalezas systemd a castecne tesknis po Windows registry. V Risi bychom s tebou zatocili, ale dnes na to pravdepodobne dostanes dotace a budes zit z mych prijmu.
Bystroushaak avatar 10.12.2018 14:17 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Upřímně je to spíš snaha zkonsolidovat pragmatickým způsobem výhody dnešních operačních systémů s výhody na image-založených smalltalk / lisp -like prostředí bez jejich nevýhod.
Bystroushaak avatar 10.12.2018 14:20 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
*výhodami

Jinak windows registry i systemd považuji za součást ukázky retardace, kde se lidi snaží, aniž by měli uvědomění toho co vlastně chtějí. Podvědomě proto vyrábějí narovnávák na ohejbák, akorát k tomu nepřistupují od prvotních principů, ale v kontextu toho co zrovna dělají a proto jsou jejich řešení jen částečně použitelné hybridy bez špetky elegance.
Josef Kufner avatar 10.12.2018 15:39 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Otázkou je, zda operační systém není jen příliš nízkou úrovní abstrakce. To, o čem mluvíš, je spíš práce pro nějakou nadstavbu nad ním.

Pokud chceš strukturovaná data, jedno jak, použij databázi. SQLite je krásným příkladem. Tak jako tak ta databáze potřebuje nějaký prostor pro svá data a filesystém takový prostor poskytuje. Když bude filesystém vynucovat nějakou strukturu datům na něm uloženým, je prakticky jisté, že to nebude velké části aplikací vyhovovat a neúnosně mnoho práce bude vynaloženo na obcházení omezení takového systému. Proto filesystém poskytuje jen jmenný prostor pro surové bloby dat.

Podobná situace je s X11 vs. Wayland. X11 se snaží řešit vše a dává všude všemu nějakou strukturu. Ve výsledku je to neskutečný bordel, který nikdo nechce udržovat. Oproti tomu Wayland řekl „tu máš buffer, kresli si“. Filesystém dělá totéž.

Dávalo by smysl poskytnout framework či knihovnu a standardizovat nejběžnější datové struktury včetně formátu metadat, aby se s tím dalo pracovat a nevymýšlelo se kolo pořád dokola.

Hezká věc je u spustitelných souborů, kdy soubor je prostě spustitelný a na prvním řádku je definováno jak. Přinést to do datových souborů by mohlo být zajímavé.
Hello world ! Segmentation fault (core dumped)
10.12.2018 18:03 debian+
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Hezká věc je u spustitelných souborů, kdy soubor je prostě spustitelný a na prvním řádku je definováno jak. Přinést to do datových souborů by mohlo být zajímavé.
Ani nie. U spustitelny suboroch to tak, lebo to tak musi. Inac to nejde. Shell skript nevykona interpret perlu. A u strukturovanych datach - niekto ma rad to spracovat v jednom programe, druhy v inom. A asi v linuxe sme si oblubili viac app na jednu subor (vid. zavistlost jedneho formatu na jednom programe). Nie najpouzivanejsie formaty (zvacsa) nie su only single app. A ak aj su, tak sa napodobnuju programy k im spracovani (napr. PDF).
Josef Kufner avatar 10.12.2018 18:22 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ne. Vynechal jsi jeden krok: Strukturovaná data musí nějaký parser načíst, aby je pak mohl zvolený program zpracovat.
Hello world ! Segmentation fault (core dumped)
10.12.2018 19:52 debian+
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Cize si to myslet tak, ze v dosledku by bolo fajn nikdy nesiahnut po programe file?
Bystroushaak avatar 10.12.2018 21:54 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Pokud chceš strukturovaná data, jedno jak, použij databázi. SQLite je krásným příkladem. Tak jako tak ta databáze potřebuje nějaký prostor pro svá data a filesystém takový prostor poskytuje. Když bude filesystém vynucovat nějakou strukturu datům na něm uloženým, je prakticky jisté, že to nebude velké části aplikací vyhovovat a neúnosně mnoho práce bude vynaloženo na obcházení omezení takového systému. Proto filesystém poskytuje jen jmenný prostor pro surové bloby dat.
To je tak nějak to k čemu jsem dospěl. Operační systém by měl být databáze. Nemám namysli nějaký konkrétní produkt. Dnešní databáze jako třeba Postgre umožňují pouštět scripty třeba v pythonu. Nevím proč nejít ještě o pár kroků dál a neudělat z nich operační systém úplně (teda ehm, SQL se na to imho fakt nehodí, ale obecně..).
10.12.2018 18:47 Bluebear
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tobě by už nepomohla ani poukázka na pohlavní styk
10.12.2018 20:38 .
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Omg ty si kokot.
10.12.2018 20:02 Pavel Křivánek | skóre: 28 | blog: Kvičet nezávaznou konverzaci
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
ifconfig | grep -Eo 'inet (addr:)?([0-9]*\.){3}[0-9]*' | grep -Eo '([0-9]*\.){3}[0-9]*' | grep -v '127.0.0.1'

...a pak jen doufat, že někdo nezmění formát výstupu (třeba lokalizace).

Ještě by nebylo špatné spojit vlastnosti navrhovaného systému s IPFS.

Tetris teaches that your successes disappear as soon as they happen, while your mistakes pile up until they kill you.
10.12.2018 20:28 debian+
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Sak si nastav lokaziciu na "C enviroment" pri tom prikaze.
10.12.2018 20:43 Pavel Křivánek | skóre: 28 | blog: Kvičet nezávaznou konverzaci
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Já vím, že je to potřeba, ale ví to i ti, co si ten příkaz zkopírují ze StackOverflow?
Tetris teaches that your successes disappear as soon as they happen, while your mistakes pile up until they kill you.
10.12.2018 20:40 debian+
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Skus tento prikaz:
ip route show|grep link|awk '{print $9}'
11.12.2018 07:38 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

To sice aspoň nepoužívá příkaz, který za měsíc oslaví 20 (slovy dvacet) let své obsolentnosti, ale je to podobně křehké. Pro případ, že potřebujete výstup strojově zpracovávat, má příkaz ip v novějších verzích přepínač "-j":

mike@lion:~> ip -j route show
[{"dst":"default","gateway":"213.168.178.65","dev":"eth1","flags":[]},{"dst":"172.16.161.0/24","dev":"vmnet8","protocol":"kernel","scope":"link","prefsrc":"172.16.161.1","flags":[]},{"dst":"172.16.165.0/24","dev":"vmnet1","protocol":"kernel","scope":"link","prefsrc":"172.16.165.1","flags":[]},{"dst":"172.28.1.0/24","dev":"eth0.1","protocol":"kernel","scope":"link","prefsrc":"172.28.1.1","flags":[]},{"dst":"172.28.2.0/24","dev":"eth0.2","protocol":"kernel","scope":"link","prefsrc":"172.28.2.1","flags":[]},{"dst":"172.28.3.0/24","dev":"eth0.3","protocol":"kernel","scope":"link","prefsrc":"172.28.3.1","flags":[]},{"dst":"172.28.4.0/24","dev":"eth0.4","protocol":"kernel","scope":"link","prefsrc":"172.28.4.1","flags":[]},{"dst":"172.28.5.0/24","dev":"eth0.5","protocol":"kernel","scope":"link","prefsrc":"172.28.5.1","flags":[]},{"dst":"172.28.6.0/24","dev":"eth0.6","protocol":"kernel","scope":"link","prefsrc":"172.28.6.1","flags":[]},{"dst":"192.168.3.0/24","dev":"eth0","protocol":"kernel","scope":"link","prefsrc":"192.168.3.2","flags":[]},{"dst":"213.168.178.64/26","dev":"eth1","protocol":"kernel","scope":"link","prefsrc":"213.168.178.121","flags":[]}]
Bystroushaak avatar 11.12.2018 09:56 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Mno, a takhle nějak nakonec k té struktuře dorazíme, akorát to bude všude divný mix JSONu, XML a YAMLu.
11.12.2018 22:47 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

Manuál ip(8) ukazuje tragédii/komedii datových rozhraní v celé své kráse:

       -br, -brief
              Print only basic information in a tabular format for better
              readability. This option is currently only supported by ip addr
              show and ip link show commands.


       -j, -json
              Output results in JavaScript Object Notation (JSON).


       -p, -pretty
              The default JSON format is compact and more efficient to parse
              but hard for most users to read.  This flag adds indentation for
              readability.

To jsou ty narovnáváky na ohejbáky. Předvídám, že někdo brzy dopíše -color, aby fungoval i s -json, protože -pretty bude prý málo čitelný.

12.12.2018 00:24 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Stačilo by prostě generovat JSON a pipnout si to do jq, ale použití pak není příliš komfortní. Dalo by se to řešit aliasem, ale pak se bude výstup parsovat, formátovat a obarvovat zbytečně v případě, že se stejně jen posílá ke strojovému zpracování do dalšího nástroje. Především ale JSON, ani formátovaný a highlightovaný, není příjemný na čtení.

Podle mě by tohle měl řešit přímo shell. Do pipy automaticky posílat strojově zpracovatelný formát (třeba ten JSON je docela fajn), uživateli zobrazovat textový výstup. Pro debugování poskytnout utilitu, která zobrazí přímo surová data. Tedy:
foo  # zobrazí nějaký textový výpis (klidně ASCII-formátovaná tabulka apod.)

foo | bar  # výstup z foo bude JSON, výstup z bar bude opět člověku srozumitelný text

foo | as-json  #  naformátuje výstup jako JSON
Tam je pak nějaké jednotné rozhraní ze strany programů (nebo cmdletů, jak je nazývá Powershell) samozřejmě nezbytností. To je řešitelné. Větší otázkou je, jak by se měly chovat programy jako grep, resp. čím je nahradit. Uvažujme něco jako:
ls | filter --key "filename" --pattern "foo"
ls vyprodukuje výpis souborů jako JSON (list). filter jej zůží jen na vyhovující položky (objekty). Potud je to v pořádku. Takovýto výstup bychom ale uživateli chtěli prezentovat nikoliv jako JSON, ale formátovat jej identicky jako to dělá ls. A to už je problém, protože:
  1. Transformace JSON → textový výpis nemůže být hardcoded přímo v programu, ale shell musí mít možnost ji aplikovat na libovolný JSON vyhovující danému schématu (související otázkou je, jak řešit případy, kdy by např. přibyl field)
  2. Shell sám o sobě neví, kdy má transformaci provést. Každý program by proto zřejmě musel shellu sdělit preferovanou metodu zobrazení, která by musela nabývat nejméně tří hodnot: json, text, keep. V posledním příkladu by tedy došlo ke spuštění ls, který by vyprodukoval JSON a shellu sdělil, že preferovanou metodou zobrazení je text. Protože ale následuje pipa, výstup by se ponechal jako JSON a poslal do filteru. Ten by vyprodukoval výstup opět jako JSON a shellu sdělil, že preferovanou metodou zobrazení je keep, tedy taková, jakou nastavil předchozí program v řetězci. To je v tomto případě text, kterou nastavil ls, a výstup by se proto transformoval na text podle jeho pravidel.
A nad tím, jak by se měl chovat program cat, jsem už líný přemýšlet. Mohl by produkovat pole řádků, což na netextových datech nedává smysl, ale mohl by produkovat cokoliv jiného a nejspíš neexistuje způsob, jak to smysluplně rozhodnout.
Bystroushaak avatar 12.12.2018 00:32 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Zkus se podívat na powershell, možná by se ti mohl líbit (mně osobně se některé koncepty líbí docela dost).
Bystroushaak avatar 12.12.2018 01:25 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ok, jdu spát, vidím že jsi ho tam zmiňoval. Pardon.
12.12.2018 09:40 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
ls něco podobného (výrazně jednoduššího) dělá dávno. Srovnej výstup ls vs. ls | cat
Josef Kufner avatar 12.12.2018 10:44 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Viz isatty().
Hello world ! Segmentation fault (core dumped)
12.12.2018 10:49 prqek | blog: prqek
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Díky za doplnění. Alespoň vím, jak to funguje :)
12.12.2018 18:04 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Dobrá připomínka. Vím o tom, ale to by vyřešilo jen první část problému. Kdybych měl třeba nástroj na dump tabulky z databáze, tak bych to chtěl zobrazit jako textovou tabulku, ale do pipy to posílat (třeba) jako JSON. Na konci bych to ale chtěl zobrazit zase jako tu tabulku, pokud se někde v průběhu zpracování povaha těch dat nezmění natolik, že už to tím původním způsobem vykreslit nepůjde. Třeba ten filter by ji změnit neměl, něco jako length ano.
12.12.2018 21:12 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To mi připomíná, když jsem do rozšířených atributů zapisoval MIME typ souboru. A pak jsem potřeboval data poslat rourou jinému procesu a ukázalo se, že fsetxattr(2) nefunguje na rourách :( Tím moje vlhké sny o sémantickém desktopu skončily.
12.12.2018 21:48 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Před pár týdny jsem objevil Elvish, ale zklamalo mě to. Ani nevím přesně čím, asi tou komplexitou, neintuitivností, bugy (podařilo se mi to – už nevím jak – crashnout) a tím, že to prostě neodpovídá mým představám popsaným výše.
Jendа avatar 10.12.2018 20:42 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
s/by jsme/bychom/g je vždy platné pravidlo, nebál bych se tímto prohnat jakýkoli text.

K první části: síťový přenos vždy bude proud bajtů prostě z toho principu jak fungují dráty, ty sis zvolil špatnou úroveň abstrakce (sockety a read+write) a na to nadáváš. O úroveň abstrakce výš přece není problém posílat po síti „objekty“ nebo jiné podobné konstrukty a tvůj jazyk/runtime/knihovna se postará o ostatní a žádné bajty nemusíš řešit. A totéž pro „chci jednoduše volat funkci z jiného programu, nechci řešit parametry příkazového řádku…“ - opět záležitost runtime běžícího nad OS…
Proč tedy proboha každý program vezme data, dá jim strukturu, něco nad ní udělá a tu strukturu zahodí a zkolabuje zpět na nestrukturovaná, surová binární data?
Tak ukládej třeba něco jako pickle, ne? Nebo v lowlevel jazycích to Cap'n'Proto. Někteří lidé si zase posílají celé databáze a tváří se šťastně.

Nebo tě nechápu?
Ještě jsem neviděl chytré logování, které by zvládlo odrotovat log, když hrozí, že na disku kvůli němu nezbude místo
systemd-journald :-D. A možná to nechceš, protože se ti něco pokazí, zaplaví to logy a příčina odrotuje.
subprocess.Popen(['7z', 'a', 'Test.7z', 'Test', '-mx9'])
Opět problém runtime/ekosystému a že na to není knihovna. Command-line tool 7z není určen na automatizaci mimo ad-hoc shell skripty, v programech máš používat něco jako import py7z; py7z.compress(fooDir).
Bystroushaak avatar 10.12.2018 20:59 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Samozřejmě, že mám a používám workaround na všechno uvedené. Jsou to reálné problémy, které jsem nějak řešil a všechny nakonec nějak vyřešil. Jen to prostě saje prdel, je to demence, která ve Smalltalku / Geneře není a to jsou staré systémy, tak proč by to nemělo jít dneska?

Jednou z mých point bylo unifikovat to. Je ti docela málo platné, když si uděláš svůj vlastní ostrůvek nekompatibility, co reálně chceš je aby to používali všichni ostatní. Představ si, že by si třeba každý používal jeden z dvaceti protokolů pro web. Co web, to jiný pes, jiná ves. Taky by ti to oprávněně vadilo.
K první části: síťový přenos vždy bude proud bajtů prostě z toho principu jak fungují dráty, ty sis zvolil špatnou úroveň abstrakce (sockety a read+write) a na to nadáváš. O úroveň abstrakce výš přece není problém posílat po síti „objekty“ nebo jiné podobné konstrukty a tvůj jazyk/runtime/knihovna se postará o ostatní a žádné bajty nemusíš řešit. A totéž pro „chci jednoduše volat funkci z jiného programu, nechci řešit parametry příkazového řádku…“ - opět záležitost runtime běžícího nad OS…
systemd-journald :-D. A možná to nechceš, protože se ti něco pokazí, zaplaví to logy a příčina odrotuje.
To je třeba krásná ukázka demence návrhu z principu. Error log bys chtěl ideálně někde vedle a nerotovat ho samozřejmě tak často jako zbytek, zatímco debug a info hlášky můžou rotovat jak chtěj.
Bystroushaak avatar 10.12.2018 21:00 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ehm, nějak mi tam vypadla odpověď.
K první části: síťový přenos vždy bude proud bajtů prostě z toho principu jak fungují dráty, ty sis zvolil špatnou úroveň abstrakce (sockety a read+write) a na to nadáváš. O úroveň abstrakce výš přece není problém posílat po síti „objekty“ nebo jiné podobné konstrukty a tvůj jazyk/runtime/knihovna se postará o ostatní a žádné bajty nemusíš řešit. A totéž pro „chci jednoduše volat funkci z jiného programu, nechci řešit parametry příkazového řádku…“ - opět záležitost runtime běžícího nad OS…
Dělal jsi někdy se ZeroMQ? Je to podobné jako použití třeba Queue v pythonu. Člověka to docela osvobodí od řešení přenosu a umožní mu to se zaměřit na podstatnější detaily.
10.12.2018 21:29 elenril
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jednou z mých point bylo unifikovat to. Je ti docela málo platné, když si uděláš svůj vlastní ostrůvek nekompatibility, co reálně chceš je aby to používali všichni ostatní. Představ si, že by si třeba každý používal jeden z dvaceti protokolů pro web. Co web, to jiný pes, jiná ves. Taky by ti to oprávněně vadilo.
Relevantní XKCD.
Bystroushaak avatar 10.12.2018 21:47 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
10.12.2018 21:57 elenril
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Zdá se mi, že bys chtěl technickými prostředky něco, co je z velké části sociální problém. To typicky nefunguje.
Bystroushaak avatar 10.12.2018 22:07 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
¯\_(ツ)_/¯

Hlavně mi šlo o rozproudění diskuze na tohle téma, což se myslím povedlo. Nejde mi o konkrétní řešení. Sice podnikám praktické experimenty na tohle téma, ale k tomu nepotřebuju znát názory ostatní. Ty se mi hodí spíš u víc abstraktnějších myšlenek.
10.12.2018 21:14 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
s/by jsme/bychom/g je vždy platné pravidlo, nebál bych se tímto prohnat jakýkoli text.
"Nádoby jsme doplnili čerstvou vodou." → "Nádobychom doplnili čerstvou vodou." :-)

Proposed fix: Přidat word boundary?
10.12.2018 21:16 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jo a když už jsme u těch pravopisných chyb v blogu, tak 'z venčí', 'z venku' → 'zvenčí', 'zvenku'.
11.12.2018 01:26 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To ti pak nepodchytí kdyby jsme. A když už se tu rozebírají ty extrémní případy, napadá někoho, jak vytvořit podobnou větu tak, aby se v ní nemusela psát čárka? „Dal-li by, jsme připraveni…“ Ale asi to nepůjde, podobně jako u: „A bylo by! Jsme připraveni?

To by jsem (jsme) neměl radost. Made by jsme.“ (Osobně se přikláním k tomu, že velká písmena lze ze stylistických důvodů ignorovat. Když už jsme u té čestiny, fascinuje mě, že „redaktoři“ českých mainstreamových „zpravodajských“ portálů, kteří mají problém napsat bez chyb jednu větu, posvátně dodržují přechylování jmen, i když to většinou zní naprosto příšerně.)
10.12.2018 21:22 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
s/by jsme/bychom/g je vždy platné pravidlo, nebál bych se tímto prohnat jakýkoli text.
Té nezdobychom zatím ušetřeni :)
xkucf03 avatar 12.12.2018 19:02 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
s/by jsme/bychom/g je vždy platné pravidlo, nebál bych se tímto prohnat jakýkoli text.

SELECT * FROM tabulka ORDER BY jsme; :-D

O úroveň abstrakce výš přece není problém posílat po síti „objekty“ nebo jiné podobné konstrukty a tvůj jazyk/runtime/knihovna se postará o ostatní a žádné bajty nemusíš řešit.

+1 podle mého většina těch myšlenek patří do nějakého frameworku/knihovny a nemusí být přímo v OS.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
10.12.2018 21:41 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Přemýšlel jsem nad tím, a nevyhnutelným krokem je podle mého názoru zahodit filesystém a nahradit ho databází. Když mluvím o databázi, nemám tím na mysli konkrétní SQL databázi, ani key-value „no-SQL“ databáze. Mluvím tu o obecném strukturovaném systému uchovávání dat na záznamových médiích, který podporuje datové typy, atomicitu, indexování, transakce, žurnály a ukládání libovolně strukturovaných dat, včetně velkých bloků čistě binárních dat.

(...)

Programy jako kolekce adresovatelných bloků kódu v databázi

Jakmile máte filesystém, který vám umožňuje nativně uchovávat strukturované informace, nedává smysl mít programy jako jednu velkou sérii bajtů, která se uzavírá před světem. Naopak dává smysl z toho postavit něco podobného architektuře microservices.
Hezká představa, ale jako praktické to moc nevidim. Jeden z hlavních problémů IMO je, jak tohle realizovat aniž bys vytvořil zlatou klec á la Smalltalk nebo Lisp nebo podobně. Ie. jak zachovat tu univerzálnost a interoperabilitu "hloupých" souborů. To si myslim, že je velká otevřená otázka.

Další věc, která mě napadá, je, že takovýhle systém by byl nejspíše dost náchylný na EEE choutky různých firem.
Bystroushaak avatar 10.12.2018 21:51 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Inspirace viz tady racik linkoval o kousek výš: PhantomArchitecture

Jinak Smalltalk i Lisp (Genera) jsou zlaté klece především protože vznikly v době, kdy nikdo moc nemyslel že by tam mohly běžet programy v jiných jazycích (i když v geneře to možná jde).
11.12.2018 10:58 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jako jo, historické důvody pro to určitě jsou, ale myslim si, že ta zlatoklecovitost plyne i z podstaty věci. Zkus se třeba zamyslet nad tím, jak by se v takovém DB-místo-FS systému používal git nebo VCS obecně. O programování ve SmallTalku toho moc nevim, ale AFAIK až tak často nepoužívají git a mají nějaké custom zlatoklecové řešení.

IMHO aby to nebyla zlatá klec, muselo by to mít nějaké velmi univerzální a velmi obecné API navenek, aby s tím mohly např. VCS nástroje (a mnoho dalšího) pracovat nějak podobně univerzálně jako s FS. Což je asi teoreticky možné, ale přijde mi to jako hodně hodně náročná úloha, protože předvídat různé usecases s takhle obecným zadáním je prostě strašně těžké...
Bystroushaak avatar 11.12.2018 11:10 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Zkus se třeba zamyslet nad tím, jak by se v takovém DB-místo-FS systému používal git nebo VCS obecně.
Úplně stejně?
O programování ve SmallTalku toho moc nevim, ale AFAIK až tak často nepoužívají git a mají nějaké custom zlatoklecové řešení.
V Pharu se třeba git používá. V Selfu je to trochu horší, tam se to řeší přes anotace objektů a export, ale to je celé dané tím, že to řešení napsal jeden člověk v devadesátkách a od té doby se na to nesáhlo. Principiálně nevidím důvod, proč by to nemohlo jít rovnou do gitu.
IMHO aby to nebyla zlatá klec, muselo by to mít nějaké velmi univerzální a velmi obecné API navenek, aby s tím mohly např. VCS nástroje (a mnoho dalšího) pracovat nějak podobně univerzálně jako s FS.
Nebo si prostě uděláš verzování konkrétních částí DB pomocí čehosi jako triggerů naprosto jednoduše a přirozeně.
Heron avatar 11.12.2018 11:12 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Zkus se třeba zamyslet nad tím, jak by se v takovém DB-místo-FS systému používal git nebo VCS obecně.

To si dovedu představit hravě, protože btrfs od počátku používám (mimo jiné) jako verzovací nástroj velkých (stovky GB) binárních dat. Ano, nemá to všechny funkce VCS, ale některé ano a některé další by asi nebylo problém dopsat.

Pokud by byl FS jako DB, tak opět není problém si tam doplnit atribut verze a příslušnost ke commitu, nebo celé snapshoty založené na vlastnosti COW.
VCS nástroje (a mnoho dalšího) pracovat nějak podobně univerzálně jako s FS.
Myslím, že se na to díváš opačně. To, že tady máme nástroje jako git znamená jen tolik, že OS neposkytuje dostatečné prostředky na to, aby si funkce toho gitu dokázal každý zařídit s prostředky OS. Viz poznámka výše, moje nutnost používat git je menší právě proto, že některé jeho funkce si dovedu zařídit prostředky FS.
Bystroushaak avatar 11.12.2018 11:37 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Myslím, že se na to díváš opačně. To, že tady máme nástroje jako git znamená jen tolik, že OS neposkytuje dostatečné prostředky na to, aby si funkce toho gitu dokázal každý zařídit s prostředky OS. Viz poznámka výše, moje nutnost používat git je menší právě proto, že některé jeho funkce si dovedu zařídit prostředky FS.
Ano, bod pro tebe. Git má spoustu užitečných schopností, ale taky řeší spoustu věcí, které by mohlo řešit něco jiného. Například vlastní databázový formát.
11.12.2018 13:58 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Myslím, že se na to díváš opačně. To, že tady máme nástroje jako git znamená jen tolik, že OS neposkytuje dostatečné prostředky na to, aby si funkce toho gitu dokázal každý zařídit s prostředky OS. Viz poznámka výše, moje nutnost používat git je menší právě proto, že některé jeho funkce si dovedu zařídit prostředky FS.
Já tomu rozumim, ale přijde mi to spíše negativní než pozitivní. Pokud funkcionalitu gitu nebo její část přesuneme do OS, vede to přesně k té zlaté kleci, o které jsem mluvil. Bude z toho jeden velký moloch s komplexní zabudovanou funkcionalitou, kterou nebude snadné měnit podle potřeb.

Porovnání btrfs snapshotů a gitu není úplně na místě v tom, že git není určený na verzování velkých binárních dat. Pokud by ale takový nástroj existoval (tj. něco jako "git pro velká binární data", možná i existuje), preferoval bych ho oproti btrfs, protože bych ho mohl používat i jinde než na btrfs.
Josef Kufner avatar 12.12.2018 00:30 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
A pak si představ, že budeš chtít portovat Git někam, kde takové funkce v jádře nejsou.
Hello world ! Segmentation fault (core dumped)
Bystroushaak avatar 12.12.2018 00:34 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tak je holt budeš muset napsat, což je úplně stejný případ jako teď. Jinak jen pro pořádek, původně jsem nepsal nic o gitu, ale o databázi místo FS, kterou by git klidně mohl používat. V takovém případě by portování na jiný systém vyžadovalo prostě mít možnost střídat databázové backendy, což nevidím jako tak špatné.

OT: Proč git nepoužívá sqlite?
Josef Kufner avatar 12.12.2018 01:14 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Teď jsou takové věci v knihovnách a dají se používat na různých systémech.
OT: Proč git nepoužívá sqlite?
Protože SQLite není adresována obsahem, což je klíčová optimalizace Gitu bez které by vůbec nefungoval. Sice by se se daly cpát hashe do primárního klíče, ale SQLite by se pak snažila indexovat, aby byla rychlá a zpomalovala by se. Hezká ukázka toho, že jedna databáze nestačí všem.
Hello world ! Segmentation fault (core dumped)
Bystroushaak avatar 12.12.2018 01:24 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Teď jsou takové věci v knihovnách a dají se používat na různých systémech.
No já nevím. To se dá říct o všem, proč potom vůbec mít třeba filesystém, když bych mohl mít knihovnu s raw přístupem k disku? Proč by ta hranice měla být zrovna tady, kromě historického vývoje.
Sice by se se daly cpát hashe do primárního klíče, ale SQLite by se pak snažila indexovat, aby byla rychlá a zpomalovala by se.
To nedělá automaticky, ne?
Josef Kufner avatar 12.12.2018 01:37 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Teď jsou takové věci v knihovnách a dají se používat na různých systémech.
No já nevím. To se dá říct o všem, proč potom vůbec mít třeba filesystém, když bych mohl mít knihovnu s raw přístupem k disku? Proč by ta hranice měla být zrovna tady, kromě historického vývoje.
A proč ne?

Snaha cpát věci do user space je všude kolem už velmi dlouho, jen to není tak snadné udělat efektivně.
Sice by se se daly cpát hashe do primárního klíče, ale SQLite by se pak snažila indexovat, aby byla rychlá a zpomalovala by se.
To nedělá automaticky, ne?
Když nebude mít index, jak pak ten blob najde? Mohla by mít nějaký hloupý index, který neumí řadit (a nezržuje se s tím), ale pokud vím, moc možností konfigurace to nemá.
Hello world ! Segmentation fault (core dumped)
12.12.2018 07:41 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To se dá říct o všem, proč potom vůbec mít třeba filesystém, když bych mohl mít knihovnu s raw přístupem k disku?

To je v podstatě idea mikrojádra - a i v Linuxu to takhle může fungovat (FUSE). Že se to tak nedělá defaultně (nebo dokonce vždy), to je asi hlavně kvůli efektivitě.

Proč by ta hranice měla být zrovna tady, kromě historického vývoje.

Já bych ten historický vývoj nepodceňoval, ale možná bych tomu spíš říkal zkušenosti z praxe. Postupem času se potvrdilo, že filesystém v jádře má smysl, ale už není obecně vhodné snažit se tam mít výrazně víc. Samozřejmě existují výjimky, na jedné straně třeba FUSE pro specifické filesystémy, na druhé třeba již zmíněné databáze používající přímo blokové zařízení, ale jsou to výjimky a nevidím moc snahu dělat z nich pravidlo.

Ale to už jsem vlastně psal včera: podle mne ten "darwinistický" model, kdy se jednak nechají různá řešení soupeřit a "silnější přežije", jednak se nesnažíme všechno mít ideální hned od začátku, ale snažíme se začít s "dost dobrým" řešením, které pak vylepšujeme podle zpětné vazby z praxe, sice na první pohled vypadá méně efektivně než "intelligent design", ale statisticky má lepší výsledky.

Bystroushaak avatar 12.12.2018 11:53 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ale to už jsem vlastně psal včera: podle mne ten "darwinistický" model, kdy se jednak nechají různá řešení soupeřit a "silnější přežije", jednak se nesnažíme všechno mít ideální hned od začátku, ale snažíme se začít s "dost dobrým" řešením, které pak vylepšujeme podle zpětné vazby z praxe, sice na první pohled vypadá méně efektivně než "intelligent design", ale statisticky má lepší výsledky.
Pokud bych se na to díval takhle, tak jsem na desktopu nikdy nepřestal používat Windows.
12.12.2018 12:30 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Windows jsou právě spíš příklad toho přístupu intelligent (ehm) design. Prostě nějaká autorita řekne, že takhle je to nejlepší, tak to tak je.
Josef Kufner avatar 12.12.2018 13:08 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Takto to obvykle funguje i v open source. Každý větší projekt je obvykle tvořen malým týmem, který rozhoduje a ta spousta lidí okolo pak jen přidává drobná vylepšení či opravy, ale už nemá možnost rozhodovat. Otevřenost spočívá hlavně v možnosti té autoritě koukat pod ruce a občas ji ukecat k něčemu, co potřebuješ.
Hello world ! Segmentation fault (core dumped)
12.12.2018 14:19 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
U velkých projektů (napadá mne třeba Firefox nebo LibreOffice) to tak opravdu do značné míry je a osobně to vnímám jako problém. U malých, které si nemohou dovolit (ani jednočlenný) tým vývojářů na plný úvazek, je to často spíš obráceně: maintaineři jsou rádi, že stíhají projekt udržet v chodu a jsou rádi, že se najde někdo, kdo má čas a energii pustit se do něčeho většího. Ale vždycky to samozřejmě záleží na konkrétních lidech.
xkucf03 avatar 12.12.2018 19:14 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
OT: Proč git nepoužívá sqlite?

BTW: Existuje několik distribuovaných verzovacích systémů, které sqlite používají: Monotone, Fossil.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
xkucf03 avatar 12.12.2018 19:09 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To si dovedu představit hravě, protože btrfs od počátku používám (mimo jiné) jako verzovací nástroj velkých (stovky GB) binárních dat. Ano, nemá to všechny funkce VCS, ale některé ano a některé další by asi nebylo problém dopsat.

Dá se tam nějak snadno zobrazit rozdíl mezi snapshoty?
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Heron avatar 12.12.2018 19:44 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Existuje příkaz find-new, který ti ukáže změny na daném subvolume, potom lze jednotlivé snapshoty posílat inkrementálně pomocí send, tj btrfs ví, co se mezi snapshoty změnilo (tj dekódováním toho streamu by se dalo zjistit konkrétní rozdíly mezi snapshoty). Potom existuje možnost zobrazit sdílené bloky mezi dvěma soubory.

Píšu to takto obecně, protože nemám potřebu nic z toho používat. Vím, že rsync (měl plánu) používá hodně z vlastností btrfs, aby rychle zjistil změny a vím, že existují programy pro deduplikaci, které hledají stejné bloky v existujících souborech a promocí ioctl btrfs příkazů je mapují na stejný blok.

Ale já to používám tak, že si v rootu dané subvolume / datasetu vedu changelog, kde před každým snapshotem popíšu, co obsahuje (commit message) a případně i příkazy, které od minulého snapshotu k tomuto vedly. Skutečný diff ve smyslu git diff jsem vlastně nikdy nepotřeboval.
11.12.2018 00:54 kvr
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tak podstatné už padlo na začátku. Úkolem OS je poskytovat minimální abstrakci nad hardware, tak aby program bez úprav mohl běžet na různých počítačích. Bez úprav může být tak trošku s rezervou, v závislosti nad specifiky zařízení nebo samozřejmě portability napříč různými OS sdílejícími stejný koncept (POSIX například).

To vyžaduje několik pravidel, které jsou, jak na potvoru, v kontrastu s požadavky uvedenými v článku:
  • Stabilita API - nechceme přepisovat zdrojáky s každou verzí systému.
  • Zpětná kompatibilita chování - nechceme přepisovat logiku programu s každou verzí systému.
Tohle neplatí pro vývoj aplikačního software obecně. Business data se mění (přinejmenším) s každou legislativní změnou, různí uživatelé (instance systémů) mají různá data a verze se nasazují postupně. A při komunikaci potom pochopitelně padají.

Zakódovat tyhle high level abstrakce do OS by přineslo víc škody než užitku, bo by to přidalo příliš high level struktury, nad kterými by bylo složité vybudovat dostatečně specifické implementace. Jinými slovy, pro malý přínos velké většině aplikací (kterého se dá dosahnout na jiné úrovni) bychom limitovali použití OS pro potenciálně menší, ale rovněž klíčovou skupinu.

Ostatně, ohledně filesystem vs databáze - zjevně pro současné databáze je současná abstrakce už tak příliš vysokoúrovňová, takže jim neumožňuje dosáhnout maximální efektivity při implementaci databázového storage. Proto jsme naopak šli o úroveň níž a přidalo O_DIRECT - obejití OS při přístupu na disk. Celé je to o tom, že čím vyšší aplikační úroveň, tím lepší má povědomí, jaký přístup k datům vyžaduje. Daní je samozřejmě komplikovanější kód, ale je-li řešení použiváno dostatečně široce, tak se specifický přístup vyplatí.

Ohledně objektů místo bytes (ať už sockets či cokoliv jiného) - viz výše - data i protokoly se mění a zadrátovat něco do OS by drsně zbrzdilo rozvoj. Navíc ta cena za implementaci na vyšší úrovní je prakticky zanedbatelná. HTTP 3 jde dokonce přesně opačným směrem - zcela zahodit stremované TCP, v zásadě v souladu s tím, co jsem psal v předchozím odstavci.

Podobně transakce nad filesystem - Windows je myslím mají, ale kdo je reálně používá? Problém je, že transakce nad jedním data source je stejně málo, distribuované transakce jsou utopie (přes všechny snahy, v případě výpadku). Spolehlivost filesystem jako takového není 100%, takže obecně vzato je taková vlastnost vlastně k ničemu.

K té prvotní motivaci - nevím, co přesně se dělo ve všech zmiňovaných projektech, ale pokud jste museli implementovat všechno znovu, tak jste se nedívali dostatečně kolem sebe. Ta abstrakce obvykle už existuje, jenom ne na úrovni OS, ale o úroveň (několik) výš. Rozjet dneska třeba web aplikaci, která komunikuje přes (z hlediska aplikace) datové objekty, má transakce a zapisuje tunu malých záznamů, je otázka jednotek hodin a pár desítek řádků kódu.
Bystroushaak avatar 11.12.2018 10:22 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tak podstatné už padlo na začátku. Úkolem OS je poskytovat minimální abstrakci nad hardware, tak aby program bez úprav mohl běžet na různých počítačích.
Vskutku. To je ale tak nějak definice kruhem. Tohle je úkolem OS, protože ukolem OS je tohle.

To přece není tesané nikde ve skále a historicky to bylo naprosto různě. Například Smalltalk se docela dlouho používal jako OS a jeho úkolem byla spousta dalších věcí. Stejně tak třeba ten BeOS poskytuje spoustu dalších možností, než jen tuhle holotu. Dokonce i Windows a Linux toho dělají o hodně víc, než jen tohle.
Zakódovat tyhle high level abstrakce do OS by přineslo víc škody než užitku, bo by to přidalo příliš high level struktury, nad kterými by bylo složité vybudovat dostatečně specifické implementace. Jinými slovy, pro malý přínos velké většině aplikací (kterého se dá dosahnout na jiné úrovni) bychom limitovali použití OS pro potenciálně menší, ale rovněž klíčovou skupinu.
To si podle mého názoru myslíš jen proto, že nemáš zkušenosti se systémy, které to umožňují. A subset, který jsem popsal je relativně malý A ZÁROVEŇ už tam je, jen jen implementovaný totálně volně, jak se komu zachtělo, bez standardu.
Ostatně, ohledně filesystem vs databáze - zjevně pro současné databáze je současná abstrakce už tak příliš vysokoúrovňová, takže jim neumožňuje dosáhnout maximální efektivity při implementaci databázového storage.
Co je na tom zjevného? DB mají často větší výkon než filesystém, ale záleží na nastavení a optimalizacích.
Ohledně objektů místo bytes (ať už sockets či cokoliv jiného) - viz výše - data i protokoly se mění a zadrátovat něco do OS by drsně zbrzdilo rozvoj. Navíc ta cena za implementaci na vyšší úrovní je prakticky zanedbatelná. HTTP 3 jde dokonce přesně opačným směrem - zcela zahodit stremované TCP, v zásadě v souladu s tím, co jsem psal v předchozím odstavci.
Proč by to mělo drsně zbrzdit rozvoj? Nikdo přece netvrdí, že ta funkcionalita nemůže být modulární.
K té prvotní motivaci - nevím, co přesně se dělo ve všech zmiňovaných projektech, ale pokud jste museli implementovat všechno znovu, tak jste se nedívali dostatečně kolem sebe. Ta abstrakce obvykle už existuje, jenom ne na úrovni OS, ale o úroveň (několik) výš. Rozjet dneska třeba web aplikaci, která komunikuje přes (z hlediska aplikace) datové objekty, má transakce a zapisuje tunu malých záznamů, je otázka jednotek hodin a pár desítek řádků kódu.
Zajdi se podívat do desíti náhodně vybraných firem, kde si vyvíjejí vlastní SW řešení. Garantuji ti s neochvějnou jistotou, že uvidíš podobný, u nich vytvořený pattern v každé z těch firem. To ani nemyslím nějak hypoteticky, prostě jdi a udělej to. Já jsem to udělal.
11.12.2018 08:14 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

V podstatě se připojím k tomu, co už tu padlo. Pro mne byla prvním varovným signálem věta

Jestliže spousta programátorů vytváří nad danou knihovnou stále stejný vzor, nejedná se o chybu programátorů, ale o špatně navrženou knihovnu.

S tím zásadně nesouhlasím. To, že spousta programátorů by ocenila nějakou vyšší úroveň abstrakce, aby nemuseli používat pořád stejný vzor, totiž vůbec neznamená, že by to tak vyhovovalo všem. Takže taková situace vůbec nemusí znamenat, že je ta knihovna špatně navržená, ale jen že té (byť i třeba poměrně velké) části programátorů chybí nějaká nadstavba (další knihovna) mezi touhle knihovnou a jejich aplikací. A pokud vy sám jste nad danou knihovnou opakovaně vytvářel ten samý vzor, je možná na místě otázka, proč jste si toho nevšiml a neudělal jste z toho knihovnu, kterou byste pak ve všech těch projektech (i budoucích) používal.

Stejný problém pak vidím i ve zbytku té úvahy. To, že někdo by pro svůj use case ocenil sofistikované rozhraní pro ukládání strukturovaných dat, neznamená, že by to tak vyhovovalo všem. Proto je v praxi většinou výhdodnější mít nad sebou několik vrstev s různou úrovní abstrakce (a komfortu), aby si každý mohl vybrat, která je pro daný účel nejvhodnější.

Jsou samozřejmě i situace, kdy bude vhodnější vrstvení narušit a sloučit funkce, které by mohly být oddělené, dohromady. Když už je řeč o databázích, některé umožňují obejít filesystém úplně a fungovat i nad holým blokovým zařízením. (Což lze brát i tak, že si implementují svůj vlastní filesystém optimalizovaný pro jejich potřeby.) Ale mělo by se tak dít po důkladném zvážení, co to přinese a čím za to zaplatím.

Část nedorozumění má možná na svědomí i samotný termín operační systém. Ten totiž podle kontextu může označovat buď samotné jádro nebo (historicky častěji) celý komplex jádra, základních systémových knihoven a základních systémových utilit. Třeba v případě linuxových distribucí je ta hranice, co ještě počítat do "OS", hodně neostrá. Takže proč ne, ať si "operační systém" (v tom širším smyslu) klidně implementuje object oriented storage pro komfortní práci se strukturovanými daty - ale nevidím jediný důvod, proč by to tak mělo být implementováno na té nejnižší úrovni, a hlavně proč by to mělo být jediné rozhraní.

Koneckonců i třeba v C++, na které je zvykem plivat, že není dost cool, je standardní způsob zápisu strukturovaných dat do souboru nebo socketu

  var >> s

a někde jinde (nižší vrstva) se definuje, co to pro konkrétní datový typ znamená a jak ta data na disku (na drátě) budou vypadat. Na téhle úrovni abstrakce nemusím (a nechci) řešit, jestli to bude XML, JSON, netlink nebo třeba nějaký vlastní formát.

Bystroushaak avatar 11.12.2018 10:09 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
S tím zásadně nesouhlasím. To, že spousta programátorů by ocenila nějakou vyšší úroveň abstrakce, aby nemuseli používat pořád stejný vzor, totiž vůbec neznamená, že by to tak vyhovovalo všem.
To vskutku neznamená.
Takže taková situace vůbec nemusí znamenat, že je ta knihovna špatně navržená, ale jen že té (byť i třeba poměrně velké) části programátorů chybí nějaká nadstavba (další knihovna) mezi touhle knihovnou a jejich aplikací.
To je určitě jeden z přístupů, který ale podle mého názoru vede na pyramidy z hoven a nekonečné vršení software na sebe. Nehledě na to, že to vůbec neřeší problém jednotnosti, naopak to vytváří tříštění nekompatibility mezi sebou.

Konkrétní argument je jednoduchý. Představ si třeba že bys měl Windows a někdo ti vyprávěl o výhodách Unixu, kde máš spoustu malých programů a můžeš je scriptovat. A tvoje odpověď by byla, že to můžeš mít i ve Windows. Samozřejmě, můžeš. Ten rozdíl není ani tak technologický, jako filosofický.

Já tady mluvím o v podstatě objektovém systému a jeho výhodách a demonstruji to ukázkami desítek nevýhod stringově orientovaných systémů. A tvoje odpověď je, že by to šlo emulovat další vrstvou, kterou můžu použít. Samozřejmě, šlo. Ale to postrádá celý ten smysl.
A pokud vy sám jste nad danou knihovnou opakovaně vytvářel ten samý vzor, je možná na místě otázka, proč jste si toho nevšiml a neudělal jste z toho knihovnu, kterou byste pak ve všech těch projektech (i budoucích) používal.
Protože nechci přivést na svět další systemd? :] Hlavní problém je, že (jak jsem jasně napsal) ten vzor nevytvářím já, vytváří ho úplně všichni, ať přijdu kam přijdu. A těžko jim budu cpát nějaký přepis na svojí knihovnu.
Stejný problém pak vidím i ve zbytku té úvahy. To, že někdo by pro svůj use case ocenil sofistikované rozhraní pro ukládání strukturovaných dat, neznamená, že by to tak vyhovovalo všem.
Taky to ale neznamená, že by nebylo možné uložit data i nestrukturovaně, jen by to nebyla preferovaná volba.
Jsou samozřejmě i situace, kdy bude vhodnější vrstvení narušit a sloučit funkce, které by mohly být oddělené, dohromady. Když už je řeč o databázích, některé umožňují obejít filesystém úplně a fungovat i nad holým blokovým zařízením. (Což lze brát i tak, že si implementují svůj vlastní filesystém optimalizovaný pro jejich potřeby.) Ale mělo by se tak dít po důkladném zvážení, co to přinese a čím za to zaplatím.
Vím o tom.
Takže proč ne, ať si "operační systém" (v tom širším smyslu) klidně implementuje object oriented storage pro komfortní práci se strukturovanými daty - ale nevidím jediný důvod, proč by to tak mělo být implementováno na té nejnižší úrovni, a hlavně proč by to mělo být jediné rozhraní.
Nevím jestli by to mělo mít jediné rozhraní, jsem však pevným zastáncem myšlenky, že by to mělo mít jednotné a konzistentní rozhraní.
a někde jinde (nižší vrstva) se definuje, co to pro konkrétní datový typ znamená a jak ta data na disku (na drátě) budou vypadat. Na téhle úrovni abstrakce nemusím (a nechci) řešit, jestli to bude XML, JSON, netlink nebo třeba nějaký vlastní formát.
Ano, ale řešit to nakonec musíš. A pak pracuješ se vším, s JSONem, XML, YAMLem a pěti dalšími formáty najednou. Co to má za výhodu mi uniká, naopak je to čím dál větší fragmentace.
11.12.2018 10:24 elenril
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Takže taková situace vůbec nemusí znamenat, že je ta knihovna špatně navržená, ale jen že té (byť i třeba poměrně velké) části programátorů chybí nějaká nadstavba (další knihovna) mezi touhle knihovnou a jejich aplikací.
To je určitě jeden z přístupů, který ale podle mého názoru vede na pyramidy z hoven a nekonečné vršení software na sebe. Nehledě na to, že to vůbec neřeší problém jednotnosti, naopak to vytváří tříštění nekompatibility mezi sebou.
Pyramidy z hoven IMO nejsou způsobeny existencemi vrstev, ale tím že návrhu těch vrstev nikdo nevěnoval dost úsilí a pozornosti.
To vskutku neznamená.
Takže souhlasíš, že na různé problém jsou potřeba různé nástroje a různé abstrakce. Ale zároven bys chtěl, aby byl ten jeden Správný(tm) univerzální database-based systém který vládne všem. To mi nějak nedává smysl.
Bystroushaak avatar 11.12.2018 10:30 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Takže souhlasíš, že na různé problém jsou potřeba různé nástroje a různé abstrakce. Ale zároven bys chtěl, aby byl ten jeden Správný(tm) univerzální database-based systém který vládne všem. To mi nějak nedává smysl.
Nikde jsem nepsal, že chci aby existoval jeden jediný systém, to sis tam doplnil sám(a). Specificky jsem začal celý článek žádostí:
Předně bych rád deklaroval, že tu mluvím sám o sobě. Když budu psát, že „je něco zapotřebí“, „možné“, nebo „schůdné“, myslím tím „zapotřebí pro mě“, „možné pro mě“, nebo „schůdné pro mě“.

Zažil jsem až příliš diskuzí na internetu, které byly způsobeny čtením mezi řádky a vztahováním čtenářovo názorů a předsudků na osobu autora. Vím, že tohle upozornění pravděpodobně nepomůže, ale zkuste se nad prezentovanými myšlenkami zamyslet s otevřenou myslí.

Pokud vám některé moje nápady přijdou kontroverzní, nesmyslné, či pokud budete mít dokonce pocit, že Vás pobuřují svou donebevolající blbostí - uklidněte se. Vzpomeňte si na výše uvedenou deklaraci. Uvědomte si, že vůbec nemluvím o vás, nemám potřebu a chuť vám něco vnucovat, měnit vám workflow, nebo pomlouvat Váš systém. Berte to jako mojí podivnost, jako možný směr, který to chce vyzkoušet a nevztahujte to o čem tu mluvím na sebe.
Přestože mi bylo jasné, že to k ničemu nebude.
11.12.2018 10:51 elenril
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Takže souhlasíš, že na různé problém jsou potřeba různé nástroje a různé abstrakce. Ale zároven bys chtěl, aby byl ten jeden Správný(tm) univerzální database-based systém který vládne všem. To mi nějak nedává smysl.
Nikde jsem nepsal, že chci aby existoval jeden jediný systém, to sis tam doplnil sám(a).

/(o) =p

Doplnil jsem si to třeba proto, že tady pořád zminuješ jednotnost vs. roztříštěnost. A že svůj vlastní dokonale úžasný systém nechceš vytvářet mimo jiné proto, že ho nevnutíš zbytku světa. Což mi naznačuje, že v utopickém světě kde se (podle tebe) software dělá Správně(r) je ten jeden systém který vládne všemu.
Specificky jsem začal celý článek žádostí:
Předně bych rád deklaroval, že tu mluvím sám o sobě. Když budu psát, že „je něco zapotřebí“, „možné“, nebo „schůdné“, myslím tím „zapotřebí pro mě“, „možné pro mě“, nebo „schůdné pro mě“.

Zažil jsem až příliš diskuzí na internetu, které byly způsobeny čtením mezi řádky a vztahováním čtenářovo názorů a předsudků na osobu autora. Vím, že tohle upozornění pravděpodobně nepomůže, ale zkuste se nad prezentovanými myšlenkami zamyslet s otevřenou myslí.

Pokud vám některé moje nápady přijdou kontroverzní, nesmyslné, či pokud budete mít dokonce pocit, že Vás pobuřují svou donebevolající blbostí - uklidněte se. Vzpomeňte si na výše uvedenou deklaraci. Uvědomte si, že vůbec nemluvím o vás, nemám potřebu a chuť vám něco vnucovat, měnit vám workflow, nebo pomlouvat Váš systém. Berte to jako mojí podivnost, jako možný směr, který to chce vyzkoušet a nevztahujte to o čem tu mluvím na sebe.
Přestože mi bylo jasné, že to k ničemu nebude.
Obzvlášt proto, že je to v té části která je explicitně optional :) Nebo proto, že celý ten blag má moc slov. Komprimuj. Also relevantní XKCD.
Bystroushaak avatar 11.12.2018 11:23 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
A že svůj vlastní dokonale úžasný systém nechceš vytvářet mimo jiné proto, že ho nevnutíš zbytku světa.
V diskuzi jsem několikrát zmiňoval, že dělám experimenty na tohle téma, které mimo jiné zahrnují programování konkrétních systémů (časem o tom napíšu další blogy, tohle byl takový úvod proč vlastně). Záměrně nechci dělat nic obecně použitelného pro všechny, protože se jednak nechci omezovat obecným konsenzem, ale taky protože to že mě něco sere ještě neznamená, že tomu obětuji příštích dvacet let celý život jako Linus, kdyby to náhodou nefailnulo pro nezájem.
Nebo proto, že celý ten blag má moc slov. Komprimuj.
Hah. Z druhé strany mi bylo na IRC vyčteno, že jsem to sepsal moc zkomprimované a skoro tomu nejde rozumět, protože jsem spoustu věcí moc nevysvětlil jak zapadají do sebe.
Bystroushaak avatar 11.12.2018 10:30 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Pyramidy z hoven IMO nejsou způsobeny existencemi vrstev, ale tím že návrhu těch vrstev nikdo nevěnoval dost úsilí a pozornosti.
Podle mého názoru to není buď a nebo, můžou být imho způsobeny obojím.
11.12.2018 10:39 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Protože nechci přivést na svět další systemd? :]

Abych pravdu řekl, celá ta vize mi připadá, jako by byla založena na podobné myšlence jako systemd. Tedy místo přirozeně rostoucího ekosystému modulárního vertikálně (implementace rozdělená do jednotlivých vrstev) i horizontálně (u jednotlivých komponent si lze vybrat z několika alternativ) se nalajnuje Jediný Správný Univerzální Framework. Zastánci toho druhého modelu argumentují "roztříštěností" a tím, že se spousta energie "vyplýtvá" na duplicity a věci, které nakonec umřou, ale já mám ten první model stejně raději. Je to stejné jako s politikou: osvícená monarchie (diktatura) je v ideálním případě efektivnější než demokracie - ale v těch neideálních… a v praxi ten ideální případ nikdy moc dlouho nevydrží.

Bystroushaak avatar 11.12.2018 10:49 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Abych pravdu řekl, celá ta vize mi připadá, jako by byla založena na podobné myšlence jako systemd. Tedy místo přirozeně rostoucího ekosystému modulárního vertikálně (implementace rozdělená do jednotlivých vrstev) i horizontálně (u jednotlivých komponent si lze vybrat z několika alternativ) se nalajnuje Jediný Správný Univerzální Framework.
To ti připadá blbě no.

Je to pozorování určitých vzorů, které jsou momentálně masivně fragmentované. Jejich sjednocený pod systém, který by zahrnoval unifikované principy by podle mého názoru nebylo na škodu, naopak by přineslo zjednodušení ve všech možných ohledech. Je to asi jako rozdíl mezi perlem, kde je možné dělat každou věc sto způsoby a všichni to sto způsoby dělají, a pythonem, kde většinou existuje jeden preferovaný způsob řešení, který ale lze nepoužít, pokud víš co děláš.
Zastánci toho druhého modelu argumentují "roztříštěností" a tím, že se spousta energie "vyplýtvá" na duplicity a věci, které nakonec umřou, ale já mám ten první model stejně raději.
Tak ale nikdo ti ho nebere, ne? Už když jsem to psal, bylo mi naprosto jasné, že spousta lidí bude mít tuhle reakci, protože jim prostě sahám na něco oblíbeného, s čím se naučili žít.

Přitom když se nad tím zamyslíš, tak nikomu nic neberu, jen jsem sepsal kritiku toho co mě sere.
Je to stejné jako s politikou: osvícená monarchie (diktatura) je v ideálním případě efektivnější než demokracie - ale v těch neideálních… a v praxi ten ideální případ nikdy moc dlouho nevydrží.
Ono spíš poměřovat státní zřízení podle efektivity není nejspíš to správné měřítko. Já jsem osobně za neefektivitu a neschopnost v mnoha ohledech spíš rád, i když samozřejmě ne absolutně.

Poslední dobou jsem dospěl k názoru, který jsem teda pravda převzal z několika článků a přednášek, že nejmenší zlo je je mít nějaký dialog a střídání cyklů, což je tak nějak to co máme tady v EU.

Tohle jde vnímat podobně. Stejně jako se periodicky střídají třeba cykly mainframu a později osobních počítačů a později zase cloudu, tak jsi měl cykly sjednocování a fragmentace. Tohle je jen jeden možný směr opětovného sjednocování.
Bystroushaak avatar 11.12.2018 10:51 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jejich sjednocený pod systém
*sjednocení omg *uklání se a nabízí katanu před spácháním harakiri*

Mojí omluvou je, že u toho dělám něco jiného a ještě mi agresivně někdo píše na mobil.
Heron avatar 11.12.2018 11:02 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Hlavní problém je, že (jak jsem jasně napsal) ten vzor nevytvářím já, vytváří ho úplně všichni, ať přijdu kam přijdu.
Tohle, si myslím, je spíše psychologické téma, než technické. Fakt nechci rýpat, už mě přestalo bavit poukazovat na každý výskyt použití věcí jako je MD5 nebo ifconfig a spousty dalších věcí, spíše se už jen tiše bavím tím, kolik desítek let v IT trvá, než se něco vymýtí. Lidská setrvačnost je mnohem větší, než bych čekal.

K tomu "vytváří ho úplně všichni". Jsem technik, nejsem programátor, ale opakovaně se setkávám s tím, že někteří lidi mají odpor používat ty nástroje samotné, ale pokaždé nad tím hledají nějakou vrstvu navíc. Takže iptables téměř nikdo nechce používat, ale hrozně rádi hledají generátory pravidel. Ty generátory jsou ale buďto stejně komplexní jako použití iptables, pokud chtějí obsáhnout stejnou funkcionalitu, nebo jsou méně komplexní, ale vždy se stane, že na něco nestačí a dotyčný stejně musí sáhnout po iptables. Tj musí se naučit obě věci. Tohle vidím u iptables, ip, lvm, openssl, service(ctl), psql, mysql (cli) atd.

Nevím, zda se jedná o tentýž problém jako v případě programátorů, ale u techniků vidím problém v tom, že poměrně brzo ve svém profesním učení si zvykli používat nějaká udělátka vyšší úrovně a až na výjimky je nezajímá, co je pod tím a pokud ano, považují to za složitější.
Bystroushaak avatar 11.12.2018 12:02 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
K tomu "vytváří ho úplně všichni". Jsem technik, nejsem programátor, ale opakovaně se setkávám s tím, že někteří lidi mají odpor používat ty nástroje samotné, ale pokaždé nad tím hledají nějakou vrstvu navíc. Takže iptables téměř nikdo nechce používat, ale hrozně rádi hledají generátory pravidel. Ty generátory jsou ale buďto stejně komplexní jako použití iptables, pokud chtějí obsáhnout stejnou funkcionalitu, nebo jsou méně komplexní, ale vždy se stane, že na něco nestačí a dotyčný stejně musí sáhnout po iptables. Tj musí se naučit obě věci. Tohle vidím u iptables, ip, lvm, openssl, service(ctl), psql, mysql (cli) atd.
Zrovna IP tables potřebují prostě grafické rozhraní víc než co jiného. Já je osobně nepoužívám vůbec, používám ufw.
Nevím, zda se jedná o tentýž problém jako v případě programátorů, ale u techniků vidím problém v tom, že poměrně brzo ve svém profesním učení si zvykli používat nějaká udělátka vyšší úrovně a až na výjimky je nezajímá, co je pod tím a pokud ano, považují to za složitější.
Spíš všichni kdo chtějí stavět systém zjistí, že jim nedostačuje výbava vhodná pro stavění programů. Systém je něco víc než program a vyžaduje jiné vzory. A protože prostě nejsou k dispozici, tak je vytvoří.

Trochu je to možné pozorovat třeba když se podíváš na různé cloudy. Tam se objektové úložiště stává v podstatě normou, stejně jako různé frameworky pro komunikaci, škálování a spouštění aplikací. Až na to že je to celé hrozný prasopes psaný lidmi co se jen snaží vyhovět nějaké potřebě, aniž by se nad tím nějak hlouběji zamysleli. Třeba na tom OpenShiftu je vidět hrozná nedodělanost, nevyzrálost a absence koncepce. Nehledě na to, že jsou to všechno frameworky na které potřebuješ celé datacentrum a nemůžeš je provozovat v malém, nebo třeba jen na jednom počítači. Celé je to deset věcí co nějak dělají nějakou úlohu (docker, elasticsearch, kibana, ..) pospojovaných dohromady izolepou z javascriptu a go a všeho co kdo kde našel do jednoho chuchle.
Heron avatar 11.12.2018 12:38 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Zrovna IP tables potřebují prostě grafické rozhraní víc než co jiného.
Dokonce až grafické. No na tom se neshodneme, iptables od počátku dělám výhradně na řádce a i různé nástavby (kdysi jsem tu psal o fireholu) jsou taky jen na řádce.
Spíš všichni kdo chtějí stavět systém zjistí, že jim nedostačuje výbava vhodná pro stavění programů.
Spíš ji neznají a ani po tom nepátrají. Znám několik programátorů, kteří více či méně ostentativně dávají najevo, jak je aktuální stav a aktuální prostředky vůbec nezajímají a oni to všechno udělají pochopitelně nejlépe.

V tomto vidím jednu z příčin úspěchu dockeru. Kontejnery tady existují desítky let, v linuxu jsou okamžitě použitelné, ale až docker se rozšířil a podle mě kvůli tomu, že se dotyčný nemusí zabývat instalací ničeho, jen se mu na základě dockerfile z náhodných míst (což taky nikoho netankuje) na internetu stáhnout požadované image, on tam dodá tu svou appku a ono to běží (a nezajímá ho, že třeba ta db a webserver je v každé normální distribuci nainstalovatelná jedním příkazem).
Bystroushaak avatar 11.12.2018 12:52 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Dokonce až grafické. No na tom se neshodneme, iptables od počátku dělám výhradně na řádce a i různé nástavby (kdysi jsem tu psal o fireholu) jsou taky jen na řádce.
Jde o kognitivní offload. Aby sis nemusel pamatovat všechny možné detaily, tak je můžeš externalizovat do grafického rozhraní. To může být klidně i na příkazové řádce, pointou je, že ti má umožnit zobrazit, prozkoumat a vybrat si možnosti které jsou k dispozici. Jeden čas jsem takhle používat například Vuurmuur.
Spíš ji neznají a ani po tom nepátrají. Znám několik programátorů, kteří více či méně ostentativně dávají najevo, jak je aktuální stav a aktuální prostředky vůbec nezajímají a oni to všechno udělají pochopitelně nejlépe.
To je občas skutečně pravda, ale často je to taky tím, že prostě nic není.
V tomto vidím jednu z příčin úspěchu dockeru. Kontejnery tady existují desítky let, v linuxu jsou okamžitě použitelné, ale až docker se rozšířil a podle mě kvůli tomu, že se dotyčný nemusí zabývat instalací ničeho, jen se mu na základě dockerfile z náhodných míst (což taky nikoho netankuje) na internetu stáhnout požadované image, on tam dodá tu svou appku a ono to běží (a nezajímá ho, že třeba ta db a webserver je v každé normální distribuci nainstalovatelná jedním příkazem).
Docker je rozšířil hlavně protože je udělal méně náročné, než klasické virtuály.
Heron avatar 11.12.2018 13:05 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Docker je rozšířil hlavně protože je udělal méně náročné, než klasické virtuály.

S tím by se dalo polemizovat, ale i právě proto jsem psal kontejnery.

Když si připravím template kontejner (v mém případě jail, nspawn), tak jeho clon je záležitostí několika sekund a v tomto směru se to jinak neliší od dockeru. Dělám to tam běžně, něco chci vyzkoušet, tak udělám clon stávajícího kontejneru (pár sekund), otestuju a případně zahodím. Nspawn na to má od počátku i parametr, jedním příkazem lze udělat clon stávajícího systému, připojit se do něj, tam si bezpečně něco vyzkoušet a po opuštění je ten clon automaticky odstraněn.

Jenže právě u jistých lidí pozoruju, že je něco tak podřadného jako linux v tom template vůbec nezajímá, to se prostě "odněkud" stáhne jako docker image.
Bystroushaak avatar 11.12.2018 13:30 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jde i o dockerfile. Já třeba používal lxc / lxd, ale jak tam mám instalovat software? To abych k tomu měl mít vedle ještě ansible nebo něco.
Heron avatar 11.12.2018 13:45 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
lxc neznám, ale třeba v jailech máš z hostitele možnost v tom kontejneru spouštět libovolný příkaz (jexec).

Spousta base programů má navíc parametr --jail, takže třeba práce s balíčky v konkrétním konjterneru můžeš opět provádět z hostitelského prostředí:
pkg -j ttrss remove mc

Proceed with deinstalling packages? [y/N]: y
[ttrss] [1/1] Deinstalling mc-4.8.21...
[ttrss] [1/1] Deleting files for mc-4.8.21: 100%
Totéž pro služby, service má opět parametr -j, tj z vnějšku můžeš spravovat služby.

Takže vlastně všechno můžeš dělat z vnějšího prostředí a to buď pomocí konkrétních příkazů, které umějí pracovat s jaily a nebo pomocí obecného jexec.
xkucf03 avatar 12.12.2018 20:46 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Dokonce až grafické. No na tom se neshodneme, iptables od počátku dělám výhradně na řádce a i různé nástavby (kdysi jsem tu psal o fireholu) jsou taky jen na řádce.

A už si zvykáš na nftables? :-)

Osobně jsem teď na jednom systému s úlevou použil ufw. Dlouhé roky jsem oprašoval svůj skript s iptables, který jsem vždy jen trochu poupravil, ale tentokrát jsem si řekl, že místo abych konfiguroval automatické spouštění mého skriptu po startu systému, tak se zkusím naučit UFW. A ten základ jsem měl hotový hned a je to celkem fajn. Určitě to nějaká omezení má, ale zatím mi to stačí. Ke svému skriptu se můžu vrátit vždycky.

Spíš mne zamrzelo, že se objevil další způsob, jak konfigurovat síť. Původně jsem byl zvyklý na /etc/network/interfaces, pak přišel NetworkManager, pak systemd a teď se konfigurace sítě, kterou jsem zadal při instalaci, objevila v nějakém cloudovém konfiguráku. Musel jsem grepovat /etc na IP adresu, abych to našel.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Heron avatar 12.12.2018 21:15 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
A už si zvykáš na nftables? :-)
Zatím ne, ale jsem poměrně nadšen (nadšení z nové věci) z PF, který používám na FreeBSD.

Hlavně se mi líbí, že to umí by default množiny pro IP, porty, tj není potřeba hromada pravidel tak jak u iptables (vím, že existují ipset). Takže třeba jedním řádkem povolit všechny potřebné služby na množině strojů:
# webservers
pass in on $iface proto tcp to {ip1, ip2, ... ip200} port { 22, 80, 443 }
Navíc je to chytré, takže pokud tam admin zadá místo množin 200*3 různých řádků, tak to zoptimalizuje a ve výpisu už jsou použity množiny. Tj to lze uložit znovu a rázem to má o 599 řádků méně.

Množiny lze i pojmenovávat a používat na různých místech fw.

(Ale jak říkám, spíš je to po letech s iptables čisté nadšení z nové věci. Určitě to bude mít svě quirky.)
Dlouhé roky jsem oprašoval svůj skript s iptables
A můžu se zeptat k čemu je potřeba skript a co je na tom k oprašování? Při instalaci nového serveru jen na FW zakážu všechno a povolím vybrané porty pro služby dostupné z netu a je hotovo.

Na routeru je těch pravidel jen o něco víc a místo INPUT se tam řeší hlavně FORWARD (nezapomenout na oba směry).

Nevím, nikdy jsem v tom větší problém neviděl. A pokud to z nějakého důvodu je větší problém, tak se vždy ukázalo, že problém byl v nevhodném návrhu sítě a také tam by se to mělo řešit. (Ale ano, znám lidi, jejichž iptables vypadají jako dvacetirozměrné bludiště a jsou náležitě hrdí na nečitelné kombinace MANGLE, NATů, hraní si s flagy a kombinací route rules. Ať si to užijou.)
Spíš mne zamrzelo, že se objevil další způsob, jak konfigurovat síť.
Jo no, na tohle už jsem si taky v nějakém článku postěžoval. Linux vyrostl na síti a 20 let neměl žádné schopné nastavení sítě. V tomto směru jsem rád za systemd-networkd, protože to je první Network Manager (;-)), kde není opruz nastavit třeba 30 IP a 20 statických rout.
xkucf03 avatar 12.12.2018 21:58 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
A můžu se zeptat k čemu je potřeba skript a co je na tom k oprašování? Při instalaci nového serveru jen na FW zakážu všechno a povolím vybrané porty pro služby dostupné z netu a je hotovo.

Na každém stroji jsou jiné služby. Někde chci odmítat, někde zahazovat, někde logovat... případně tam jsou nějaké limity. Postupně se to vyvíjelo. Pak jsem začal přidávat blokování odchozího provozu (navazovat ven smějí jen vybraní uživatelé/skupiny).

Pak jsem měl pocit, že do toho systému ručně bastlím něco, co by mělo být řešeno nějak systémově, tak jsem zkusil použít nativní prostředky, které nabízí daná distribuce tzn. to ufw. Základní pravidla jsem v tom udělal a dál uvidím.

BTW: jak to spouštíš ty? Jako skript s iptables příkazy nebo to proženeš přes iptables-save a pak načítáš přes iptables-restore? Nebo píšeš vstup pro iptables-restore ručně?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Heron avatar 12.12.2018 22:08 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
BTW: jak to spouštíš ty?
Já se vždy snažím používat služeb dané distribuce. Pomocí série příkazů iptables si nastavím FW, potom dám (v Debianu) netfilter-persistent save a je to. Tj při bootu se o načtení postará ta služba (distribuční skript). Ve (starém) centosu totéž přes service iptables save. Ve FreeBSD se PF konfiguruje souborem, takže upravím pf.conf soubor, proženu ho kontrolou a nechám načíst. Při bootu se o jeho načtení opět postará rc systém.
xkucf03 avatar 12.12.2018 22:16 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
dík
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
11.12.2018 12:53 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Zrovna IP tables potřebují prostě grafické rozhraní víc než co jiného.

Já třeba považuji za ideální současný stav. Podle situace můžu použít přímo ioctl/netlink, příkaz iptables nebo nějakou více či méně cool nadstavbu (nebo si třeba napsat vlastní). Každý z těch přístupů má své výhody a nevýhody a každý se hodí na něco jiného. V tom vidím obrovskou sílu té "vertikální modularity", o které jsem mluvil předtím; prostě si vyberu, ve kterém patře nastoupím.

11.12.2018 10:53 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Koneckonců i třeba v C++, na které je zvykem plivat
Neměl jsi ještě donedávna patičku utahující si z C++? (Je ale možné, že si to s někym pletu.)
11.12.2018 11:12 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Určitě ne já. Jednak jsem patičku IIRC neměl nikdy, jednak patřím dlouhodobě spíš k těm, kteří se C++ zastávají.
11.12.2018 15:53 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Aha, tak to byl Michal Vyskočil, tak to jsem si opravdu pomíchal.
jednak patřím dlouhodobě spíš k těm, kteří se C++ zastávají.
Také jsem to tak dříve měl, nicméně ty poslední verze a vývoj okolo nich mi to dost ztěžují...
11.12.2018 16:38 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Už kdysi dávno jsem dospěl k závěru, umožňuje-li mi něco jazyk, neznamená to nutně, že to musím použít. U C++ to jen platí o něco víc než jinde (a s každou novou verzí standardu o něco víc). :-)
12.12.2018 17:38 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tak s tím samozřejmě souhlasim, nicméně ono to bohužel není jenom o tom, co ten jazyk umožňuje navíc, co nechci nebo nepotřebuju, ale taky o tom, co nemá a mohl mít, kdyby komise neměla plné ruce práce s přidáváním věcí, které pak člověk sotva kdy použije :-/

Například vůbec nechápu, proč nebyla komise ochotna přidat více syntaxe / jazykové podpory pro move semantics a trochu je dotáhnout, aby to nebyl jen takový polotovar, zatímco pro kontrakty klidně bez mrknutí oka přidají kupu syntaxe a jazykovou podporu, ditto spaceship operator atd. :-/

Přijde mi, že s C++11/14 vykročili správným směrem, ale pak jim bohužel zřejmě ruplo v bedně...
11.12.2018 09:16 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

Mimochodem,

Počet inodů (větví struktury) je navíc omezen na číslo, jenž se v horších případech pohybuje v řádu desítek až stovek tisíc, maximálně však pár milionů prvků v jednom adresáři.

Čím je omezen?

mike@unicorn:/srv/debug/cvt/a> ls -U | wc -l
10000000
mike@unicorn:/srv/debug/cvt/a> time ls -U >/dev/null

real    0m3,828s
user    0m1,321s
sys     0m2,507s
mike@unicorn:/srv/debug/cvt/a> time cat 5769168

real    0m0,005s
user    0m0,000s
sys     0m0,005s

Přičemž těch 5 ms je režie okolo, stejnou hodnotu jsem dostal i v adresáři, kde je jen jeden soubor.

Bystroushaak avatar 11.12.2018 09:58 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Čím je omezen?
Implementací filesystému?
11.12.2018 10:03 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Kolik je tedy těch pár milionů? Deset podle všeho ne.
Bystroushaak avatar 11.12.2018 10:23 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jo my slovíčkaříme. Aha. Tak to sorry.
11.12.2018 10:55 freshmouse
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jo my lžeme. Aha. Tak to sorry.
11.12.2018 11:09 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Neslovíčkaříme. Jen mne zajímá, jak to s tím limitem je. Je to nějaký tvrdý limit? Je mi jasné, že při extrémním počtu souborů začnou být některé operace pomalejší, ale tenhle jednoduchý pokus naznačuje, že přinejmenším na XFS ani deset milionů nestačí, aby to bylo viditelné.
Bystroushaak avatar 11.12.2018 11:26 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Na filesystémech, které jsem dostal já k dispozici to tvrdý limit byl. Pohyboval se někde v řádu jednotek milionů. V uložto už si přesně nepamatuji kolik to tam měly diskové pole, ale rozhodně to taky bylo něco co nás reálně nutilo ten problém řešit (jinak by jsme ho samozřejmě neřešili, že).
11.12.2018 11:55 elenril
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
[ root@sandro ~]# tune2fs -l /dev/sandro/data
...
Inode count: 469762048

Tušim že default závisí na velikosti fs při vytváření, ale dá se zadat i ručně až na (1<<32) pro ext4.
Bystroushaak avatar 11.12.2018 12:05 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tobě půl miliardy souborů přijde jako hodně? Víš jakou to bude mít performance?
11.12.2018 12:20 elenril
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Na běžné použití ano, ještě jsem neviděl že bych se dostal ani na 10%. Na specifické účely to prostě musíš optimalizovat ručně, na tom nevidim nic zvláštního.

Performance - netušim. Před nějakou dobou jsem testoval řádově milion souborů/složka a výkon byl lepší než jsem čekal.
Heron avatar 11.12.2018 10:40 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
První čtení:
$ time ls -U | wc -l
958082

real    0m28.581s
user    0m0.256s
sys     0m1.336s
Druhé čtení:
$ time ls -U | wc -l
958157

real    0m0.940s
SAS HDD pole, SAS 12G

Ve tvém případě ten čas odpovídá prvnímu nebo opakovanému čtení?

Je také rozdíl, zda se jedná o čerstvě vytvořený adr. nebo o silně používaný. V tomto případě tímto adr prošlo stovky miliónů souborů, možná miliarda. V největším zaplnění tam bylo 12mil souborů a jen ls | wc -l trvalo desítky minut.

Navíc ten tvůj příklad jistě trochu schválně obsahuje to -U a navíc se vůbec neptá na vlastnosti těch souborů. V typickém případě, pokud budu chtít "selectovat" např. soubory starší než, tak to znamená ještě pro každý soubor výlet do inode a tedy minimálně jeden další seek. Zatímco pro DB je select nad 12mil položkami hotový do 1s, tak tady je to na hodiny (optimálně mezi 1-2h*).

*) Mějme SAS disky, 200iops každý z nich, mějme nejlepší RAID10 na světě, 12disků = 12*200=2400iops. Mějme nejlepší FS na světě, kde výlet do inode zabere 1 iops, tedy pro 12mil souborů = 83minut. V nejideálnějším případě.
11.12.2018 11:29 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ve tvém případě ten čas odpovídá prvnímu nebo opakovanému čtení?

V mém případě byly výsledky víceméně stejné, protože jsem ty soubory krátce předtím vytvořil. Ale to byl záměr, protože mne zajímalo, jak efektivně si s takovým počtem souborů poradí filesystém, ne jak rychle mi seekuje disk. Koneckonců se podívej na rozdíl user+sys vs. real u toho tvého prvního příkladu.

Navíc ten tvůj příklad jistě trochu schválně obsahuje to -U

Opět zcela záměrně, protože mne zajímá, jak se chová filesystém, ne jak efektivní sort má příkaz ls. Z podobného důvodu je tam i ten zahozený výstup. Bez "-U" byl výsledek asi 11.6 sekundy, přičemž prakticky celý nárůst měl podle očekávání na svědomí userspace.

a navíc se vůbec neptá na vlastnosti těch souborů

Pro "ls -lU" mám typicky real 26.9s, user 10.3s, sys 16.6s (s rozptylem v desetinách sekundy). Takže asi tak 2.7μs na položku, z toho 1.7μs v jádře. (Ano, zajímá mne, jak to zvládá filesystém, ne jak mám rychlý disk.)

11.12.2018 14:36 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
V typickém případě, pokud budu chtít "selectovat" např. soubory starší než, tak to znamená ještě pro každý soubor výlet do inode a tedy minimálně jeden další seek. Zatímco pro DB je select nad 12mil položkami hotový do 1s, tak tady je to na hodiny (optimálně mezi 1-2h*).

Ano, filesystém není databáze. Pokud budete potřebovat dělat takovouhle operaci často a nad filesystémem, děláte to blbě, použijte databázi. Na druhou stranu ta databáze to nedělá zázračně, ta databáze na to má index. A ten se i s rozhraním "select" dá doprogramovat i do toho filesystému, kdyby to někdo fakt hodně potřeboval.
Quando omni flunkus moritati
Heron avatar 11.12.2018 15:06 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Na druhou stranu ta databáze to nedělá zázračně, ta databáze na to má index.
Zrovna na tohle není potřeba nasazovat index. Důvod, proč je tohle u toho FS tak pomalé, je nutnost seeku do každé inode. Kdyby tato metadata byla součástí adresářové struktury, tak by to bylo skoro stejně rychlé jako vypsání názvů souborů, stačilo by přečíst jen ten adresářový soubor (který by byl teda o něco větší).

Full scan nad tabulkou obsahující 106 mil. podobných metadat je na pomalých sata hdd hotový za 24s. 864tis. položek potom do 400ms.

Ano, rozumím, že na takto navrženém FS by se těžko realizovaly třeba hardlinky apod. a že vývoj klasických FS šel jiným směrem.
xkucf03 avatar 12.12.2018 21:06 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Souborové systémy, databáze

Tohle všechno je ale o vnitřním uložení dat a šlo by to implementovat i jako FS, ne? Vždyť to je vlastně jen API, za kterým si můžeš naprogramovat, co chceš. Problém je spíš v tom, že to API některé věci neumožňuje -- např. prohlásit soubory za objekty a volat jejich libovolné objekty, nebo poskytnout dotazovací rozhraní (to tam jde ještě nějak dohackovat přes virtuální adresáře), nebo tu byla řeč o transakcích.

V podstatě by ale neměl být problém s tím FS komunikovat i jinou cestou a tam mít i jiné API než to klasické souborové. Třeba mít někde doménový soket a přes něj si s FS posílat zprávy nebo mít někde nějakou sadu funkcí. Přes to by šly udělat i ty transakce, triggery atd.

Proveditelné je prakticky všechno. Spíš je otázka architektury, jestli tyhle věci cpát do jádra nebo to udělat přes ExtFUSE (s eBPF) nebo na vyšší úrovni.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Heron avatar 12.12.2018 21:39 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Souborové systémy, databáze
Na tohle já moc nemám odpověď. Já FS fakticky nepoužívám, i když se o jejich historii a vlastnosti dlouhodobě zajímám. Já jsem velice rychle přešel na používání různých forem DB, ať již jako hash table na disku (věci jako Trivial DB, DB4, později MySQL a dodnes PostgreSQL).

Navíc, na rozdíl od všeobecně hlásaných pravidel jsem nikdy neviděl jako problém do DB ukládat BLOBy, naopak to považuju za užitečné. Na produkci máme v PG několik TB dat a není s tím problém.

Tj v každém mém projektu, který potřebuje nějak ukládat data, automaticky sahám po DB a FS používám tak maximálně pro import a export dat. Už kdysi v MySQL jsem měl 300mil záznamů a u PG mám v jednom čistě soukromém projektu už 700GB dat. Rychlost table full scan 106mil řádků za 30s (3.5mio/s) na sata diskách považuju za dostatečnou.

Ano, občas mám choutky se vrátit o patro níž a použít pro ukládání souborů FS, ale reálný výkon mě vždy vrátí do reality:
$ time find Tree | wc -l
  166244

real    1m27.177s
user    0m0.264s
sys     0m1.367s
ZFS ekvivalent RAID-10 nad 6x SATA disk. Aby toho nebylo málo, tak OS nevím proč ta načtená metadata velice rychle zapomene a za pár minut se tohle opakuje. A není to tím, že by to zahodil po změně (to bych ještě bral), ale v tomto případě se jedná o strom s cca 10tis dalšími adresáři v podstromech a navíc se nemění. Proč to zahazuje celé je mi záhadou.

Takže ne, tohle používat fakt nebudu. Kdysi dávno jsem zkoušel exportovat těch 300mil souborů z MySQL na tehdy doporučovaný ReiserFS a po několika dnech jsem to vzdal.

Prostě FS je kolekce emulovaných pásek a až nad tím se staví systémy pro ukládání dat.
Mark Stopka avatar 11.12.2018 14:14 Mark Stopka | skóre: 58 | blog: Paranoidní blog | European Economic Area
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
(která navíc musí být v Dockerfile označená pomocí VOLUME)
Nemusí.
cezz avatar 11.12.2018 14:59 cezz | skóre: 24 | blog: dm6
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Presne to napadlo aj mne. Vseobecne mi cely ten blog vyznel ako narek programatora, ktory sa kazdy jeden nastroj snazi pouzivat ako programovaci jazyk. (zvlast veci okolo Dockeru a Ansible) Az som sa cudoval, ze tam niekde nebol spomenuty Minecraft ako velmi neergonomicky virtualny stroj. :-D
Computers are not intelligent. They only think they are.
Mark Stopka avatar 11.12.2018 15:27 Mark Stopka | skóre: 58 | blog: Paranoidní blog | European Economic Area
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
To je ta DevOps kultura, když se developeři začnou cpát do infrastruktury tak to nedopadá dobře. Proto velké organizace mají i v rámci DevOps oddělené role Dev a Ops, které se jen mírně překrývají, tak aby dokázali doručit potřebnou míru agility, ale zároveň neprasili infrastrukturu, nebo naopak kód.
Bystroushaak avatar 11.12.2018 16:09 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ano, v jedné takové velké organizaci pracuji :]

Jedna z věcí, které jsem tu zdůrazňoval je, že spousta programátorů časem začne pracovat na systému, nikoliv jen na programu. Věc, kde je programů desítky. Tím ti přirozeně vyvstane spousta požadavků a problémů, co jsem popsal.
Bystroushaak avatar 11.12.2018 15:25 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ok, budu ti věřit. Upraveno.
Mark Stopka avatar 11.12.2018 15:36 Mark Stopka | skóre: 58 | blog: Paranoidní blog | European Economic Area
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Děkuji, navíc nemáš (alespoň co se týče docker-compose / swarmu) pravdu v tom, že cesty musí být absolutní, jak v rámci docker hosta, tak v rámci konteineru mohou být relativní, v rámci docker konteineru se pak uplatní adresář uvedený dle poslední direktivy WORKDIR. Ale vzhmedem k tomu, že WORKDIR se může kdykoli změnit, je samozřejmě lepší mít v rámci konteineru cestu absolutní, ale třeba pro lokální Laravel development environment běžně dělám ./:./, což mi kód aplikace namountuje do adresáře který servíruje NGINX s PHP-FPM a je zároveň nastaven na WORKDIR, abych mohl přes exec volat artisan.

[mark_stopka@docker-host-01 https-lb-01-a.perlur.cloud]$ cat docker-compose.yml
version: '3'

networks:
  proxy:
    external: true

services:
  # The reverse proxy service (Træfik)
  https-lb-01-a_perlur_cloud:
    image: traefik  # The official Traefik docker image
    container_name: https-lb-01-a.perlur.cloud
    command: --api --docker  # Enables the web UI and tells Træfik to listen to docker
    ports:
      - 80:80      # Add HTTP port
      - 443:443    # The HTTPS port
    expose:
      - 8080
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock  # So that Traefik can listen to the Docker events
      - ./conf/traefik.toml:/etc/traefik/traefik.toml # External Traefik configuration file
      - ./conf/.htpasswd:/etc/traefik/traefik-ui.htpasswd # External BASIC AUTH log-in and password file for Traefik UI
    labels:
      - "traefik.backend=traefik"
      - "traefik.enable=true"
      - "traefik.frontend.rule=Host:https-lb-01-a.perlur.cloud"
      - "traefik.port=8080"
      - "traefik.frontend.entryPoints=http,https"
      - "traefik.frontend.auth.basic.usersFile=/etc/traefik/traefik-ui.htpasswd"
    networks:
      - proxy
[mark_stopka@docker-host-01 https-lb-01-a.perlur.cloud]$
Bystroushaak avatar 11.12.2018 16:02 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Absolutní cesty musí být minimálně v mé verzi Dockeru (1.13.1):
docker run -v "./conf/:/etc/project/:z" --rm -it project
./usr/bin/docker-current: Error response from daemon: create ./conf/: "./conf/" includes
invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed.
If you intented to pass a host directory, use absolute path.
Pokud tam dáš bez lomítka na konci, tak se to nenamountuje vůbec, ale neselže to (selže až aplikace, že tam nic není) a pokud to pustíš jako
docker run -v "`pwd`/conf/:/etc/project/:z" --rm -it project
tak to funguje.
Mark Stopka avatar 11.12.2018 16:26 Mark Stopka | skóre: 58 | blog: Paranoidní blog | European Economic Area
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Holt asi výhoda používání SWARM / docker-compose, protože tohle funguje v pohodě:
[mark_stopka@docker-host-01 MarkoEscobarRoboZonky]$ cat docker-compose.yml
version: '3'

services:
  # RoboZonky service
  MarcoEscobarRoboZonky:
    image: robozonky/robozonky:testing  # The official RoboZonky Docker image
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
    volumes:
      - ./conf:/etc/robozonky
      - ./run:/var/robozonky
    environment:
      - TZ=Europe/Prague
    restart: "always"
    labels:
      - traefik.enable=false

[mark_stopka@docker-host-01 MarkoEscobarRoboZonky]$
Bystroushaak avatar 11.12.2018 22:51 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Jsem si až teď všiml toho MarkoEscobarRoboZonky :D
Mark Stopka avatar 12.12.2018 03:26 Mark Stopka | skóre: 58 | blog: Paranoidní blog | European Economic Area
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Hej, někde se ty drogové peníze musí vyprat!
cezz avatar 12.12.2018 11:05 cezz | skóre: 24 | blog: dm6
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Schopnost pripojit relativny adresar je vlastnost docker-compose, samotny docker naozaj vyzaduje absolutnu cestu.
Computers are not intelligent. They only think they are.
11.12.2018 16:41 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Pokud tam dáš bez lomítka na konci, tak se to nenamountuje vůbec, ale neselže to
lol, Docker v kostce.
cezz avatar 12.12.2018 11:04 cezz | skóre: 24 | blog: dm6
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Az na to ze to nie je pravda, normalne to namountuje.
Computers are not intelligent. They only think they are.
Bystroushaak avatar 12.12.2018 12:11 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
?

Zkoušel jsem to teď znova a nevím co si představuješ pod pojmem „normálně to namountuje“, ale rozhodně to neskončí tím, že by se ta vnější cesta namountovala na vnitřní.
12.12.2018 12:32 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Já mam s Dockerem podobně špatné zkušenosti co se týče reportování chyb. Stávalo se mi taky, že to chyby prostě spolklo a neřeklo nic anebo že to sice něco zalogovalo, ale byl to jen nějakej krátkej neinformativní štěk + dohledej si sám, o co jde.

Hlavně že se gopheři pořád plácaj po zádech jak jsou exceptions hrozná věc a jak je error handling v Gočku krásně jednoduchý a explicitní a kdesi cosi ... a pak to končí takhle.
cezz avatar 12.12.2018 14:30 cezz | skóre: 24 | blog: dm6
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
$ mkdir -p some/long/path
$ docker run -ti --rm -v $PWD/some:/some alpine ls -R /some
/some:
long

/some/long:
path

/some/long/path:
Computers are not intelligent. They only think they are.
Bystroushaak avatar 12.12.2018 14:54 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Už vidím kde je problém- Používáš absolutní cestu, zatímco tu větu
Pokud tam dáš bez lomítka na konci, tak se to nenamountuje vůbec, ale neselže to
jsem psal k ukázce relativní cesty ./code/. Pokud zadáš jen code, tak to nefunguje.
cezz avatar 14.12.2018 11:31 cezz | skóre: 24 | blog: dm6
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
$ docker run -ti --rm -v ./some:/some alpine
docker: Error response from daemon: create ./some: "./some" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.
Ked nepouzijes absolutnu cestu docker predpoklada, ze chces miesto toho pouzit named volume. V priklade vyssie to zlyha, lebo su tam nejake znaky ktore sa v nazve volume nemozu vyskytovat. Cize ked urobis toto (co je myslim presne tvoj pripad):
docker run -ti --rm -v some:/some alpine
Tak to znamena, ze chces vytvorit volume ktory sa vola some a pripojit ho ako /some v kontajneri:
$ docker volume ls | grep some
local               some
Cize ono to nezlyha potichu, ale urobi presne to o co si poziadal. Pouziva sa to napriklad vtedy ak chces zdielat adresar medzi dvoma kontajnermi, tak proste spustis druhy kontajner kde tiez pripojis some..
Computers are not intelligent. They only think they are.
Bedňa avatar 11.12.2018 23:58 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Linuxový súborový systém stavia na vrstvách.

Na spodu je ten filesystem, nad tým môžeš dať ďalšiu vrstvu, napríklad RAID, nad tú šifrovanie, LVM atď. To sú všetko veci čo neriešia posielanie štruktúr ako atomických správ. Nad tým musíš spraviť nejakú ďalšiu vrstvu, napríklad nejakú databázu. Proste tá filozofia jeden program robí jednu vec a robí ju dobre, tu stále je.

Druhá otázka je ako spraviť nejaký štandard ako tie informácie ukladať. Proste aspoň v Linuxe to nikdy nebude na úrovni súborového systému, pretože by to automaticky zabilo všetky tie ďalšie vrstvy a vznikol by tu ďalší systemd_filestem.

Štandart by mohol vzniknúť na ďalšej vrstve. Napísať to v Céčku aby to fungovalo ako knižnica naprieč jazykmi a potom by to malo šancu na úspech.

Ako obyčajne som blog dal na ranu, komp potom telefón a dočítal v kompe. Asi by si mal písať knihy kámo :)
KERNEL ULTRAS video channel >>>
Bystroushaak avatar 12.12.2018 00:14 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Ako obyčajne som blog dal na ranu, komp potom telefón a dočítal v kompe. Asi by si mal písať knihy kámo :)
Píšu (resp. teď čekám na výsledky konkrétních experimentů s tinySelfem). Jinak jsem měl tak trochu pocit, že by z toho šla udělat menší kniha, tak do sto stránek, kde by šlo myšlenky lépe rozvést a přidat různé featury, jako třeba uml diagramy a tak, ale jednak jsem to nechtěl psát dva roky a pak taky by to neplnilo účel, kterým bylo převážně vidět reakce.
Bedňa avatar 12.12.2018 00:55 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Tak na okraj. práve vyšla nová tlačená kniha "Game Engine Black Book DOOM" vo farbe, ak by si mal záujem ako je to s nákladmi a ziskom, bol som dosť prekvapený (nemilo).

Chápem že ty chceš viac zbierať odpovede na problematiku a čakáš interakciu od ostatných.
KERNEL ULTRAS video channel >>>
Bystroushaak avatar 12.12.2018 01:34 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Hele, vůbec mi nevadí že to sem píšeš (knižní doporučení beru kdekoliv).

Knížka vypadá zajímavě, ale na příštích deset let jsem zaknížkovaný. Nedávno jsem se znova vrhl na GEB, tak mám co dělat. Taky mi ujela ruka a objednal jsem
   ☑ Thinking Forth (25€)
   ☑ The Victorian Internet (15€)
   ☑ Newton’s Principia (18€)
   ☑ Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers) (19€)
   ☑ Technics and Human Development (vol 1.) (21€) (Kay)
      ☑ The Myth of the Machine (21€)
a část knížek z Alan Kay’s advice to computer science students (Envisioning Information je skvostná).
xkucf03 avatar 12.12.2018 15:25 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Předně bych rád deklaroval, že tu mluvím sám o sobě. Když budu psát, že „je něco zapotřebí“, „možné“, nebo „schůdné“, myslím tím „zapotřebí pro mě“, „možné pro mě“, nebo „schůdné pro mě“.

Beru na vědomí.

V posledních letech jsem pracoval pro několik firem vytvářejících software. V některých případech jsem se zapojil do již existujících týmů, v ostatních jsem začínal spolu s několika dalšími programátory „na zelené louce“. Často jsem se přímo podílel na návrhu architektury, pokud jsem jí rovnou nevymýšlel sám. Pracuji jako „backendový programátor“. Mým popisem práce je typicky vytvářet systémy, které načítají, zpracovávají a ukládají různá data, parsují všemožné formáty, volají různé programy, či interagují s ostatními systémy a zařízeními.

Ano, prošel jsi řadou firem, ale pořád to reprezentuje jen zlomek způsobů, jakými se počítače používají. A teď je otázka, zda vytvářet operační systém a) pro tento zlomek (resp. pro každý zlomek jeho vlastní OS), nebo b) zcela minimalistický OS, který poskytne jen ten společný základ (např. pro 98 % případů užití) c) nastavit si ten cíl na jiném procentu případů užití a vytvořit něco, co většině poskytne většinu požadovaných funkcí a zároveň to většinu nebude obtěžovat nějakými přílišnými funkcemi navíc.

Vypadá to, že jdeme cestou c). Cesta b) by asi znamenala, osekat to na abstrakci HW (což je asi nejzásadnější funkce OS a potřebují ji všichni, kromě nějakých těch 2 % se speciálními potřebami) a zbytek ať si dodělá každý sám. Cesta a) podle mého nedává moc smysl (musel bys mít hodně speciální potřeby a hodně velký rozpočet, aby to bylo vůbec schůdné – a schůdné ještě neznamená celkově efektivní a smysluplné).

Je otázka, jestli nejít spíš cestou b) místo c). V podstatě se něco jako b) už děje, ale na jiné úrovni: máme základ operačního systému (GNU/Linux) a nad tím různá desktopová prostředí, která představují další vrstvu s vlastními abstrakcemi, funkcemi a filosofií. Teoreticky by to šlo rozříznout níž a tu hranici mít někde těsně nad HW abstrakcí – ta by byla společná a ten vršek by byl vyměnitelný tzn. někdo by si tam posadil vršek emulující současný POSIXový systém a ty by sis tam posadil třeba vršek emulující lispovský nebo smalltalkovský stroj.

Nemám na to úplně vyhraněný názor, možná by to bylo dobré, možná by to naopak vedlo k vytvoření ostrůvků, které k sobě mají daleko a těžko spolupracují. Zatímco dneska, když máš ten lisp nebo smalltalk nad POSIXem resp. GNU/Linuxem, tak přeci jen můžeš snáz spolupracovat s těmi, kteří smalltalk ani lisp nepoužívají a jedou přímo nad tím POSIXem nebo nad ním mají jiné vrstvy.

A pak je otázka, kam v tom b) umístit takové věci jako TCP a IP nebo šifrovací algoritmy – patří do toho společného základu nebo až do té nadstavby a měla by si je každá nadstavba implementovat po svém?

Ve dvou z mých předchozích zaměstnáních jsme museli obcházet omezený počet inodů na složku retardací jako BalancedDiscStorage, či ukládáním souborů do tří podsložek složených z prvních tří písmen MD5 hashe souboru.

Linux (případně jiná jádra či OS) ti poskytuje rozhraní, aby sis napsal vlastní souborový systém. Tzn. bude to schované za tou samou abstrakcí/metaforou (takže to můžou používat všichni a lze tuto vrstvu vyměňovat bez nutnosti měnit jiné vrstvy), ale bude to mít tebou požadované vlastnosti (např. možnost efektivně uložit neomezené množství souborů do adresáře a do souborového systému – takže pak můžeš rozpadnou data na tak malé kousky, abys nemusel používat datové formáty a ztratí se hranice mezi tím, kde končí hierarchie souborového systému a kde začíná hierarchie vnitřního formátu daného souboru tzn. např. místo XML textového uzlu nebo atributu budeš mít zase soubor, který bude v jedné hierarchii se všemi ostatními soubory a uzly uloženými původně v jiných souborech).

Otázka je, jak do toho zabudovat podporu transakcí, atomicitu – a tady prostor pro zlepšení vidím.

Další věc je indexování a efektivní vyhledávání – nicméně to už by šlo řešit v rámci současných API – napsal by sis vlastní FS a ten by poskytoval i virtuální adresáře, které by byly něco jako databázové pohledy nebo funkce – vlezl bys do neexistujícího adresáře jehož název by byl textem dotazu a FS by ti vrátil výsledky – něco jako cd /mnt/.dotazy; cd "SELECT * FROM soubory WHERE ..."; ls -l (případně by tam byly další virtuální podadresáře, které by představovaly parametry dotazu). A opravdu to nemusí být SQL – použil jsem ho jen pro názornost.

Proč tu myšlenku nedotáhnout do konce a neudělat malé programy z každé funkce a metody vašeho programu? Ta by naoplátku mohla komunikovat s metodami a funkcemi ostatních programů.

Co ti vlastně brání si jako PID 1 spustit (emacs|python|smalltalk|perl|self|.*) a všechny programy si implementovat jako funkce/objekty v daném jazyce? Vadí ti, že ten OS poskytuje i zbytečnou infrastrukturu, kterou nevyužiješ a která se duplikuje s tím, co by sis napsal sám v tom svém jazyce? Nebo ti tam naopak něco chybí? Co? Nebo je to jen moc práce a málo užitku? Nebo by to měl napsat někdo jiný a ty bys to jen použil? (ideální případ :-)

but functions must all have the signature char function(const char )

Ta signatura vypadá jinak. Jednak máš dva výstupní proudy bajtů (nikoli hodnotu) a jeden vstupní a jednak v té závorce není const char ale pole bajtových řetězců (a když budeme předpokládat výchozí kódování platformy, tak pole textových řetězců), což je celkem mocná struktura.

A shodou okolností se tímhle zabývám, už tu v diskusích něco prosáklo (1, 2, 3, 4, 5, 6 ). Je to ještě hodně čerstvé, ale když už je o tom řeč: Relational pipes (Relační roury).

Současná počítačová kultura je posedlá parsery a externími popisy dat, jenž by však mohly nést strukturu samy o sobě. Každý den jsou nesmírná kvanta výpočetních cyklů zcela nesmyslně plýtvána na konverzi surových bajtů na struktury a zase zpět

V zásadě jsou tam dvě úskalí 1) bezpečnost a implementace v HW (paměť, CPU), 2) lidé píší v různých programovacích jazycích. Ten druhý bod lze řešit tím, že vynutíš jeden jazyk (viz zmínka o PID 1 výše) nebo použiješ GraalVM. S tím prvním bodem nic moc dělat nejde (musel bys v podstatě zbourat celý IT obor a začít znovu nebo oželet výkon a proložit to nějakou poměrně tlustou vrstvou abstrakce, která poskytne rozhraní k úplně jinému stroji, než je ten fyzický).

Nemalá část mé práce jako programátora je jen o parsování a převodech dat, jenž kdyby měla strukturu, tak by byla upravitelná jednoduchou transformací. Tady vem kus stromu a přesuň ho sem.

Tohle je řešitelné knihovnami (aby ses nemusel vrtat v těch bitech a bajtech). Pak to chce nějakou jednotnou abstrakci, abys s těmi naparsovanými daty mohl pracovat stejným způsobem bez ohledu na původní fyzický formát. Tohle jsem dělal před čtyřmi lety jako prototyp alt2xml. Umožňuje to se na data v různých formátech dívat stejným způsobem – vždy je z toho strom uzlů (resp. před tím ještě posloupnost událostí v jednotném formátu), bez ohledu na to, zda data byla původně INI, XML, JSON, souborový systém nebo něco jiného.

Ale proč je neposlat už složené?

Odpověď je pořád stejná: používat GraalVM (případně si napsat jeho obdobu) nebo vynutit použití jednoho jazyka a uzavřít se do jeho VM místo toho, aby ses pohyboval v OS.

Data se kterými pracujete by mohla být sebe-popisná, ale nejsou. Jednotlivé položky by mohly obsahovat datové typy, ale i dokumentaci. A nemají. Proč? Protože je v módě mít zvlášť hromadu binárních dat, a zvlášť jejich externí popis. Vážně to tak chceme, vážně to má nějaké výhody?

Přibalovat ke všemu metadata je značně neefektivní. Metadata můžou zabírat víc místa než samotná data. V praxi se používají oba přístupy, jak samopopisné formáty, tak čistá data s minimem metadat. Většinou mi přijde výhodnější ta metadata (slovník/schéma) vystavit na jedno místo a jinde na něj už jen odkazovat. V OS/VM tohle můžeš udělat taky, můžeš mít nějaký registr schémat a jednotlivé předávané zprávy už budou obsahovat jen referenci do tohoto registru. V objektovém paradigmatu ten registr obsahuje neměnné objekty a zprávy jsou objekty které obsahují odkaz na objekt určitého schématu v registru. To schůdné a rozumné je. Ale přibalovat (rozkopírovat) metadata ke všem datům je ve většině případů špatný přístup.

Nemluvím tady o parsování XML parserem, mluvím tu o přímém načtení do paměti

Protože je to většinou buď závislé na platformě/jazyku nebo je to nebezpečné nebo obojí.

O tom že na strukturovaná data o Frantovi Putšálkovi v kolekci lidí přistoupím pomocí people[0].name, místo toho abych v jednom formátu dělal doc.getElementByTagName("person")[0].name.value a v druhém doc["people"][0]["name"].

Tohle řeším v tom alt2xml (ano, je to jen prototyp, ale můžeš si napsat něco lepšího).

O tom že data popisují sebe sama přímo svou strukturou, ne externím popisem.

Podle mého je lepší mít externí popis ve strojově čitelném formátu (schéma) uložený na jednom místě a jen se na něj odkazovat, než mít všechna data zahnojená spoustou metadat.

Souborové systémy nevnímáme jako databáze. Nedochází nám, že jejich struktura jsou hierarchická key-value data.

Já je takhle vnímám a někdy jsem je tak i použil. Např. pro konfiguraci je to použitelné velice dobře. Nemusíš vymýšlet nějaký formát nebo používat parsery a generátory existujících formátů a prostě jen ty objekty rozpadneš na stromovou strukturu adresářů a souborů. Pokud bys těch objektů měl opravdu hodně, tak si budeš muset napsat vlastní FS, ale to se většiny případů užití netýká a stávající FS bohatě dostačují. Ta abstrakce poskytovaná OS dostačuje taky (až na ty transakce).

Programy bereme jako binární bloby, místo klubka propojených funkcí a struktur a objektů majících potřebu komunikovat se sebou, ale i s okolním světem.

To je spíš otázka návrhu a konkrétní implementace. ESR v knize The Art of Unix Programming popisuje vzor polyvalentní program.

Ano, musíš ta rozhraní explicitně vystavit. Ale už jsme o tom jednou mluvili. Tohle není technický problém, ale spíš problém organizace práce. S vhodnými nástroji tě vystavení těch rozhraní nic nestojí, takže rozdíl oproti jazyku/platformě, která ta rozhraní vystavuje automaticky a vždy prakticky není. Zásadní ale je zpětná kompatibilita – pokud dovolíš ostatním navázat svoje programy na tvé funkce a pak jim to v příští verzi rozbiješ, protože funkce refaktoruješ, tak z tebe nebudou mít radost. Poskytnout nějaké API je velký závazek a spousta práce – ovšem problém není to realizovat technicky, ale problém je udržet tu zpětnou kompatibilitu. To je to, co vyžaduje nejvíc úsilí a u čeho nejvíc bolí hlava (jak to navrhnout tak, abys to v příští verzi nemusel nekompatibilně změnit).

Víte co tomu chybí? Reflexe a struktura. Pokud si nepřečtete manuál, tak naprosto netušíte co kam zapsat.

Tohle by se dalo řešit přes rozšířené atributy těch virtuálních souborů v tom virtuálním FS. Stačí si domluvit názvy atributů, do kterých se bude psát dokumentace a metadata. S návratovými hodnotami je trochu problém stejně jako s předáváním strukturovaných dat. Např. když budeš chtít LEDce předat dvojici hodnot (barva, intenzita), tak jak to nacpeš do funkcí, které vystavuje FS? To API nějaké limity má a je na něm vidět, že má sloužit k ukládání a čtení dat, nikoli k volání libovolných funkcí. I když z poměrně velké míry to lze k tomu volání funkcí použít. Tam, kde ti rozhraní FS přestává stačit, je potřeba sáhnout už po něčem jako D-Bus nebo JMX, které na tenhle způsob práce stavěné jsou.

Já chápu, proč vznikly. Vážně. Ve své době to bylo naprosto racionální a nebylo nic lepšího. Ale proč proboha používat nestrukturovaný formát přenosu binárních dat i dneska, když veškerá komunikace je strukturovaná

Takové SCTP jde o dost dál než TCP (nebo UDP) a mj. předává zprávy místo aby jen propojovalo dvě roury přenášející proudy bajtů. Vnitřní strukturu zpráv neřeší, ale to je podle mého dobře, protože to je úloha pro jinou vrstvu. Když zůstaneme v telco světě, tak by se tam (alespoň tehdy) použilo ASN.1 pro strukturování těch dat.

A tak je to se vším. Skoro nikdy nepotřebujete proud bajtů, ale posílat zprávy, které jsou prakticky vždy hierarchie key-val dat, nebo pole.

Je to tak, ale většinou nad tím lidé a) nepřemýšlí nebo nemají prostor (musí něco zmastit v daném čase a rozpočtu) nebo b) si myslí, že mají výrazně jiné potřeby než ostatní a vytvoří si nový formát/protokol c) přemýšlí nad tím, mají snahu, udělají obecný formát/protokol, který můžou používat i ostatní, ale ti se jim vysmějí a řeknou jim, že mají speciální potřeby a ten obecný formát/protokol je nepokrývá. Najít společnou řeč je poměrně těžké a zdaleka ne vždy se to povede.

ZeroMQ byla podle mého názoru krok správným směrem, ale zatím mi přijde, že se nedočkala moc vřelého přijetí.

O ZeroMQ jsem si koupil knížku a postupně se jí prokousávám, ale přijde mi, že to zase tak moc "zero" není a té komplexity je tam přeci jen poměrně dost. Nicméně celkem sympatické mi to je a nějaké využití pro to vidím.

Parametry příkazové řádky

To pole mi přijde jako vhodně zvolená struktura. Cokoli jednoduššího (jeden řetězec, pole bajtů) by bylo nedostatečné. A cokoli složitějšího by bylo zase příliš náročné na zpracování a na používání.

V podstatě se na to můžeš dívat jako na jazyk, který čteš lexerem/parserem, akorát můžeš vynechat ten lexer, protože data už máš rozsekaná na jednotlivé tokeny. Proto taky nemám rád parametry ve stylu "--klíč=nějaká hodnota" a jsem radši, když klíč a hodnota jsou dva po sobě jdoucí prvky pole: "--klíč" "nějaká hodnota".

Taky mne trochu mrzí, že si každý vymýšlí vlastní jazyk, pro parsování těch parametrů, ale s tím asi nic nenaděláme. Existují různá doporučení a konvence. Obecně preferuji styl "--parametr" "hodnota" "--volba-bez-parametru" případně tam může být první parametr jako (pod)příkaz: program příkaz --parametr1 ...

Když vymyslíš vhodný formát pro předávání strukturovaných dat na příkazové řádce, tak se to třeba ujme. Ta infrastruktura/API to umožňuje – řeší za tebe tokenizaci (díky tomu, že je to pole, tak máš jasně vyznačené hranice mezi jednotlivými tokeny, takže tohle nemusíš řešit).

Stejný problém máš ale u hlaviček metod/funkcí. Většina jazyků podporuje sekvenční parametry, někde můžou být výchozí hodnoty a nepovinné parametry a některé jazyky mají pojmenované parametry – takže tam je to taky pole (případně mapa). To ti nevadí? Není to málo? Nakonec se to někdy řeší tak, že metoda/funkce má právě jeden parametr a ten je typu objekt (nějaký konkrétní objekt) a až v něm jsou jednotlivé parametry. Přesto se často píší metody/funkce tak, že mají třeba tři parametry tzn. na vstupu je vlastně pole, kde víš, že na první pozici je tohle, na druhé tamto... akorát ti k tomu jazyk dává syntaktický cukr a rovnou ti prvky toho pole naplní do lokálních proměnných. Asi nejde obecně říct, který z těch přístupů je lepší. Pokud je funkce z principu jednoduchá a vím, že bude mít pořád ty tři parametry, tak ji napíši jako funkci o třech parametrech. Bude se to lépe používat. Naopak pokud tuším, že v budoucnu těch parametrů bude třeba deset, tak tam dám ten parametr jen jeden a postupně budu rozšiřovat jeho třídu.

Pokud jsou argumenty složitější, stane se z toho rychle onanie skládání stringů, kde si navíc nemůžete být jisti bezpečností, nemáte garanci podporované znakové sady, musíte sanitizovat uživatelský vstup a volané podprogramy navíc stále můžou vykazovat chování, které je všechno, jen ne triviální.

Viz vzor vzor polyvalentní program výše. Ono sice jde psát CLI rozhraní tak, aby bylo dobře použitelné jak pro člověka, tak jako API, ale není to samozřejmost. Často je lepší cesta program rozdělit na CLI rozhraní (případně GUI, síťové rozhraní atd.) a knihovnu.

BTW: ta objektovost byla původní myšlenkou GNOME: GNU Network Object Model Environment, nicméně už je to celkem dlouho, co od toho zřejmě upustili. Původně to měl být distribuovaný objektový framework.

Env proměnné

Je to podobný případ jako ty CLI parametry. Kdybys vytvářel operační systém, jak by ses rozhodoval, jestli je něco overengineeringpřesložitělá abstrakce nad abstrakcí nebo zda to tam implementovat?

A co formát? Hádáte správně. Může být libovolný; (pseudo)INI, XML, JSON, YAML. Nebo Lua. Nebo taky hybrid vlastního programovacího jazyka (viz postfix). Co koho zrovna napadne, to se používá.

O tomhle jsem se v diskusích hádal už mnohokrát a taky mne ta nejednotnost mrzí. Osobně bych nejradši všude používal XML – a ne proto, že mám rád špičaté závorky a ukecanost, ale proto, že je to nejlepší dostupná (!) implementace myšlenek, které považuji za správné. Bohužel se vždy najde spousta naivních lidí, kteří si myslí, že jim bude stačit něco jednoduššího, že vystačí se strukturou klíč=hodnota... jenže nevystačí a v dalších verzích tam dobastlí něco jako INI [sekce] a příště začnou vymýšlet pod-sekce (jak to tam napsat? těch způsobů je několik...) nebo do klíčů začnou cpát různé tečky, lomítka... pak narazí na to, že potřebují nějak zapsat pole více hodnot a zase to nějak zmastí (a to i několika různými způsoby v rámci jednoho formátu). Následně dojde na jmenné prostory... Kapitola sama pro sebe je, když původně deklarativní formát postupně zmutuje ve spustitelný kód resp. imperativní programovací jazyk.

Existuje vtip, že komplexita každého konfiguračního souborů s časem roste, dokud v něm někdo vytvoří špatně implementovanou půlku lispu. Mým oblíbeným příkladem je Ansible a jeho nedotažená, nekompletní parodie na programovací jazyk postavený nad YAMLem. Chápu, kde se to bere. Taky jsem touhle cestou šel.

Co se týče otázky zda deklarativní (neživá) data nebo spustitelný (živý) kód a programovací jazyk pro popis konfigurace, tak mi přijde vhodné to rozdělit na dvě fáze. Výstupem by měla být deklarativní neživá data. A zda se k nim dobereš tak, že je přímo načteš ze souboru, kde leží v deklarativním formátu, nebo zda spustíš skript (ten může být psaný v libovolném jazyce), který tato data vygeneruje, to už je na tobě. Klidně program může podporovat oba přístupy. Pak to chce mít funkci, která ti porovná dva objektové stromy (deklarativní data), abys na základě ní mohl načíst novou konfiguraci za chodu programu. Ne vždy je to nutné, program můžeš restartovat, ale často se to hodí. Např. abys mohl přidat nový virtualhost a nemusel ani na okamžik přestat naslouchat na HTTP portu a obsluhovat jiné virtualhosty, které se nezměnily.

Logy

Vidím to podobně, štve mě spousta věcí stejně jako tebe. Nějaké snahy o standardizaci tu jsou. A já bych třeba mohl logovat do těch Relačních rour :-) Ale najít společnou řeč je těžké. Vždyť i v rámci jednoho programovacího jazyka máš často několik logovacích knihoven a API.

Syntaxe je přibližně -v local_path:/docs:rw. Jako dobrá ukázka mi to přijde, protože se do jednoho parametru cpou tři různé hodnoty: cesta v počítači na kterém příkaz pouštíte (která navíc musí být absolutní!), cesta uvnitř kontejneru a práva k zápisu.

Ano, tohle je špatně – přitom by stačilo využít stávající infrastrukturu a nechat tokenizaci na operačním systému a necpat do jednoho parametru tři hodnoty a vymýšlet si nějakou vlastní vnitřní strukturu. Je to stejné jako když někdo nacpe několik hodnot oddělených čárkou do jednoho sloupečku v databázi.

Proč? Protože neexistuje žádný standard a operační systém neposkytuje nic po čem by se dalo sáhnout. Fragmentace tak pokračuje.

Ale existuje (třeba to XML). Jen si řada lidí na začátku myslí, že to nebudou potřebovat a že to udělají "jednodušeji".

Imperativní prvky bych do konfiguráků raději nezatahoval a řešil to spíš tím rozdělením na dvě fáze, kde ta první volitelná může být skript (viz výše).

Pokud se nad tím zamyslíte dostatečně abstraktně, program je objekt. Je to kolekce dat, nad kterými operují v něm obsažené funkce.

Jak chceš řešit stavovost? V současnosti je program spíš něco jako třída a až proces (spuštěný program) je objekt. Můžeš se na to dívat tak, že třídy nejsou, nebo že i program (nespuštěný, na disku) je objekt, jehož jedna metoda vrátí jiný objekt (již spuštěný program). Má ten objekt programu nějaký stav? Jak je ten stav sdílen nebo naopak izolován mezi různými uživateli? Má každý uživatel svůj objekt (např. jinou konfiguraci) nebo je jeden objekt na systémové úrovni?

Když se na to podívám trochu pragmaticky: není reálné, že bys (ty nebo kdokoli jiný) napsal nový operační systém včetně všech těch ovladačů hardwaru a spousty nízkoúrovňové infrastruktury, tak, abys dohnal a předehnal současné operační systémy. Navíc by to bylo i hloupé a neefektivní, protože bys psal znovu něco, co už jiní napsali a vydali jako svobodný software. Takže pokud se tyhle myšlenky mají realizovat, vede to spíš na nějakou VM nad stávajícím operačním systémem. Ale v čem bude tvoje VM lepší a proč by ji měli všichni používat? Kdyby všichni používali javovské VM, tak to bude podobné resp. ty tebou požadované kvality a vlastnosti tam půjde implementovat. Totéž, kdyby všichni psali jen v Perlu, nebo jen v Pythonu, nebo jen ve Smalltalku, Lispu... problém je v tom, jak přesvědčit ostatní, aby přešli na tvůj jazyk/platformu.

Např. GraalVM se se nikoho nesnaží přesvědčit, aby začal psát v jiném programovacím jazyce a přepsal svoje programy – ale naopak přenáší různé programovací jazyky (a tím programy v nich napsané) do jednoho VM, do jednoho prostředí. Neříkám, že je to dneska bůhvíjak použitelné, ale přijde mi to jako zajímavá cesta a pokud ten projekt bude dobře veden a nevyschnou zdroje, tak to je asi budoucnost.

Když máte filesystém umožňující tyhle objekty uchovávat nativně, nevidím důvod, proč potom nezpřístupnit jednotlivé metody tohoto objektu i z venčí.

Já ten důvod vidím, viz zpětná kompatibilita API, o které píši výše. Resp. jednotlivé metody klidně zpřístupnit můžeš, technicky to není problém, ale pokud se v příští verzi nekompatibilně změní, protože je autor programu přepsal, tak praktická hodnota je nulová nebo i záporná.

Konfigurační soubory a různé jejich formáty existují, protože filesystém neumí uložit strukturu. Kdyby to uměl, můžete prostě uložit daný slovník s danými klíči a hodnotami, a příště po nich sáhnout.

Ale on to umí, psal jsem o tom výše a pro konfiguraci je to použitelné (tam na limity FS nenarazíš). Z původních souborů se stanou adresáře a z jejich atributů soubory (případně zase adresáře obsahující vnořené soubory a adresáře) a zmizí ta hranice mezi vnější hierarchií (původních) souborů a vnitřní hierarchií uvnitř souboru. Problém je leda ta transakčnost.

Parametry příkazové řádky, env proměnné, ale i všechno ostatní píšete jako datové typy zachovávající si strukturu.

Proměnné prostředí ve skutečnosti vůbec existovat nemusí. Vždyť jsou to vlastně globální proměnné a ty se obecně doporučuje nepoužívat. Pokud potřebuješ nějaký globálnější kontext, tak to může být jeden z parametrů.

P.S. Omlouvám se za tak dlouhý komentář :-) ale je to zajímavé téma resp. mnoho témat.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Bystroushaak avatar 12.12.2018 16:51 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS
Někdy cca za týden bych si mohl vzít pár dní dovolenou na komplexní odpověď :]
xkucf03 avatar 12.12.2018 19:49 xkucf03 | skóre: 47 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programátorova kritika chybějící struktury OS

njn, já to začal číst k snídani a komentář odeslal až odpoledne. Ale času věnovaného těmto diskusím nelituji :-)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.12.2018 17:42 Bherzet | skóre: 10 | blog: Bherzetův blog
Rozbalit