Názory k článku Collapse OS: operační systém do světa Falloutu

V casti 2. se pise:

Výhodou Collapse OS je fakt, že případná portace na další mikrořadiče a mikroprocesory by měla být relativně snadná..

V casti 4 je zmineno, ze asembler obsahuje pouze jadro jazyka Forth. Znamena to tedy, ze v pripade "kolapsu" by bylo mozne prezit pokud bych mel alespon jeden funkcni cip s Collapse OS? Jak bych OS na chip dostal kdybych zadny pripraveny nemel? Jak by probihal bootstrap na jiny cip a jak na cip stejneho typu? V bodu 4 se pise, ze portace na jine cipy by byla mozna, ale vysledek by byl pomaly protoze Forth? Jak bych tedy mel postupovat abych prezil?

Pro nový nebo nepodporovaný čip (když nebudete mít ROM se zavaděčem) je nutné "nějak" vytvořit právě ten zavaděč. K tomu slouží cross compilace, ale ano - musíte mít alespoň jeden připravený počítač, co to zvládá, třeba Arduino s nějakými ledkami nebo displejem, aby bylo vidět, co děláte.

V úplně mezním případě není ani zapotřebí programovat ROM (tedy spíš EEPROM nebo EPROM). Pokud je k dispozici SRAM, tak by správný bastlíř dokázal ji na jednom počítači naplnit bootstrap kódem a "zaživa" (bez výpadku napájení) ji přepojit do nového počítače.

(což je další věc, která ve světě PC už je prakticky nemožná v běžných podmínkách)

(což je další věc, která ve světě PC už je prakticky nemožná v běžných podmínkách)

Proc ne? Prave naopak, nalit BIOS do nejake seriove flashky jde s par spinaci a odpory ... recovery BIOSy maji leckdy i okolo 64kB, neni potreba plnit celou flash.

to jo, jenze ty mikroprocesory nedokazi primo komunikovat se seriovou Flash. To by chtelo stary dobry BIOS jeste v EPROM/EEPROM na DIL a s osmibitovou sbernici.

No ty historicke ne, to je pravda, myslel jsem to spis tak, ze je jednodussi mozna nalit novy BIOS do seriove flashky, nez do ((E)E)PROM.

Nicmene jde to pouzit treba pro RP2040, ESP32, apod- nicmene to uz jsou tak slozite obvody, ze po nejake apokalypse asi nebudou fungovat. Predstava ze budu nad plamenem pajet QFN56 mi prijde az skoro usmevna :-). Ale jak o tom premyslim, asi by to nakonec slo. Bud rozdelat ohen pod nejakym platem, pres kulicky cinu merit teplotu, a tu se snazit udrzet, nebo pouzit nejaky nahraty 'hrebik' jako pajecku, teplotu lze opet overit skrz kousek cinu.

Treba ATOMy a jine SOC dokazou tu spi adresovat "nativne" (v legacy modu, tj. pro F000:0000) - resil jsem to u zabugovaneho Avotonu - SPI flash bios je na dedikovanem SPI portu na cpu - takze to nabootuje, ale jakmile to provedl prvni LPC transakci ( out 0x80 na debug port ) tak to uz chciplo. Pokud by tam byl bios az za LPC, tak to ani nenabootuje.

Tak EEPROMka by šla "naprogramovat" jen s pár přepínači (v nouzi stačí jen drátky), pár odpory, pár ledkami(aby jsme vubec viděli, co tam dáváme, ale nejsou nutné) a vhodným kondenzátorem. A pak spoustou trpělivosti:)

https://i.imgur.com/RmM8Fcd.jpeg

Toto by programatory naucilo psat male a efektivni programy! :)

Hmm to je pravda. Je to nekolik stovek bajtu, to by jeste asi bylo zkousnutelne (i kdyz tedy rucne delat vsechny adresy je prace pro vraha). Diky za pripomenuti.

Takto som programoval PROM MH74S287 (256x4bit) do môjho prvého počítača so Z80 niekedy na začiatku 90. rokov. Iný počítač som nemal. Fungovalo to.

Úplně jednoduše - pomocí klávesnice, ale chce to mít před kolapsem na papíře či lépe na hliněných tabulkách, ty vydrží víc. Za starých časů to byl zcela běžný postup...

Ovšem ty tabulky musí být vypálené. Ještě by to šlo tesat do kamene. :-)

Lepší je sklo. Dá se i hromadně rozmnožovat. Akorát se s ním nesmí mlátit, ale to s těmi tabulkami také ne.

Neni sklo amorfne? Po par tisicrociach by to mohlo stratit tvar :-)

No... Pokud pominu věci typu kalkulačka, tak třeba na té konzoli by bylo asi praktičtější rozchodit CP/M.

jj taky jsem si říkal + tam přihodit nějakou Luu nebo další značně ořezaný jazyk, protože Forth mi sice osobně nevadí, ale určitě to není mainstream.

Jenže autor chtěl zajistit přenositelnost a to je u CP/M problém (řešil se například přes XLT16 pro 16bit CP/M) + taky to, aby ten systém někdo někdy dokázal pochopit jako celek.

Ale ano - je to celé postavené na technologiích, které další rozšiřování spíš neumožňují nebo to celé zesložiťují.

Mne sa tento počin páči, keďže niekedy v rokoch 1986-1996 som si napísal v assembleri vlastnú implementáciu jazyka Forth, spočiatku na kamošovom ZX-Spectru, neskôr na Didaktik Gama.
U mňa to celé začalo popisom jazyka Forth, ktorý vyšiel na pokračovanie v Amatérskom Rádiu. Takže príjemná nostalgia.
Tiež som išiel podobnou cestou, väčšina bola napísaná v jazyku Forth a celé to zaberalo cca 2kB.

Tyn seriál mám doma okopírovaný. Přišlo mi to (po tom, co jsem znal jen BASIC a trošku assembler) dost revoluční a úplně elegantní.

Okrem BASIC a assemblera som mal na kazete Pascal a C.
Editor Pascalu zaberal takmer celú dostupnú RAM a kompilovanie z kazety bola naozaj zábava, ale občas som ho využil.
C sa mi nepodarilo nikdy reálne použiť. Asi som niekde robil chybu a stackoverflow vtedy ešte nebol.
Niekde by som možno našiel zdrojáky, ale sú na 360kB diskete. Mechaniku ešte mám, ale už nemám radič FD na doske. Pamätám si že na ZX-Spectre som musel zakazovať maskované prerušenie, pretože som používal oba indexové registre (IX, IY), neskôr som kód upravil.

Ten seriál jsem četl a pak zkoušel na fig-Forthu pro Atari 800XL. Proti strojovému kódu mi ale Forth přišel výrazně pomalejší.
Myšlenka minimalistického systému je určitě zajímavá, ale lepší by byl nějaký praktický příklad - třeba jak pomocí upravené konzole vyslat rádiový signál SOS.

I guess I feel that I could say that if it isn't solving a significant real problem in the real world it isn't really Forth.

-- Chuck Moore

...ale nemohu říct, že se mi Collapse OS nelíbí :-)

S mikrořadiči z různých zařízeních je docela problém v tom, že mají většinou natvrdo program.

19. 8. 2021, 17:47 editováno autorem komentáře

Jinak nesouvisí to s článkem, ale je to spíš taková blbinka, kterou mi připoměl úvodní obrázek - existuje emulátor terminálu, který má i režim vzhledu fallout - https://github.com/Swordfish90/cool-retro-term

A v něm si můžete spustit zase jinou věc a to hru fallout terminal hack. Bohužel nemůžu už najít odkaz na tu co jsem kdysi zkoušel, ale něco je třeba tady - https://github.com/jibby0/fallout-terminal-clone

Tiez mi to pride ako taka hracka co fakt nema prakticke vyuzitie. A ked uz pride apokalipsa tak mi to moc nepomoze, lebo nembudem mat aby som si ho stiahol, ani HW aby som si to skompiloval.

Ono je asi lahsie zobrat obycajny notebook s Windowsom a pripojit ho k autobaterii ako zohanat 8-bit schopny rozbehat hentu vec, ci kuchat domacu elektroniku aby som nasiel nejake STM-ko.

Ja som na apokalypsu pripravený vlastníctvom niekoľkých "lepších" programovateľných kalkulačiek (Ti-89, HP 50G,...), ktoré dokážu bežať aj niekoľko mesiacov na 4 mikrotužkové baterky (dajú sa použiť aj nabíjateľné nabíjané zo solárnej nabíjačky).

Ono jde o to, že autor Collapse OS předpokládá, že pokud dojde k vážným problémům, budeme potřebovat něco, co jde opravit na koleně (a to notebook není), co jde POCHOPIT a taky, aby se to dalo používat na ovládání nějakých zařízení (tedy styl Arduina).

Ona dnešní elektronika v různých zařízeních je zbytečně komplikovaná (třeba milionem čidel, které ale můžou hlásit neexistující problémy), ale mnohdy to fakt jde (když půjde do tuhého) nahradit nějakým osmibitovým mikrořadičem.

Akykolvek mikrokontroler nejde opravit na kolene. Dalsia vec je otazka poruchovosti.

To je uz fakt lepsie mat obycajnu kalkulacku a vedomosti s vysokej skoly.

Celkove predstava nejake SHTF situace je u vetsiny lidi myslim dost 'romanticka', realitu asi nikdo nechce zazit. Stejne jako je idealizovany stredovek, prezit v nem by byl asi problem.

Vzpominam pred mnoha lety kdyz vypadl asi na tyden proud. A vezmete si, ze takhle by vypadlo uplne vsechno, vc. zasobovani. A ne na tyden, ale na rok. Uz tehdy jsme meli uplne jine starosti, treba jak pro male dite ohrat nejake jidlo, atd.

To je pravda, opravit nejde, jako žádný integrovaný obvod. Ale jde o to, že když je pravděpodobnost "odchodu" nějakého integrovaného obvodu X%, tak v případě bastl počítače se dvěma čipy to je prostě pořád malé číslo, ale u skutečného PC je to minimálně o řád horší (spíš o víc, s tím, jak tam všechny komponenty jedou na hraně kvůli co nejvyššímu výkonu).

Takový Atmel navíc nepotřebuje ani moc dalších součástek (tedy žádné vysychající kondenzátory, které musí zvládat relativně velké proudy).

[z vlastní zkušenosti - mám tady osmibitové počítače, které stále běží i po třiceti letech. Jeden tak jak došel z výroby, u druhého jsem vyměnil jen zdroj]

"[z vlastní zkušenosti - mám tady osmibitové počítače, které stále běží i po třiceti letech. Jeden tak jak došel z výroby, u druhého jsem vyměnil jen zdroj]"

Podobná zkušenost, 800XL (1984) a C64II (rok na MB nevím, ještě nebyla rozstřelka). U C64 mám i originální zdroj, ale moc mu nevěřím, jelikož se pravděpodobně nedá rozebrat a zkontrolovat/po­vyměňovat podezřelé součástky. Gamu jsem ještě nezkoušel, ale dle slov prodejce má být funkční. Jinak podobně i se šestnáctibity - 500+ (r.v. 1991) nebýt aku článku, nemusel bych na desku sahat. ST (1986) potřebovalo opravit zdroj, MB funkční.

"nahradit nějakým osmibitovým mikrořadičem"

Byly doby, kdy jsem vyhnilé mikrořadiče nahrazoval relátky. A ono to potom fungovalo úplně stejně :)

Tady je ale asi jeste motivace aby ta technologie prezila silnejsi radiaci. Coz u toho notasu pri te mire integrace v cipech s windows moc sance neni.

Tim hur pokud tam jsou non-ecc pameti a korunu tomu nasadi pouziti SSD.
I kdyz prakticky ten HDD muze jit do kytek diky svoji elektronice :-)
Vsude tam jsou obvody s tak vysokou integraci ze vlastne cela myslenka je hodne naivni. Tedy pri dlouhodobem provozu.

U SSD (resp cehokoliv co ma flash) je dost velke procento "soft erroru" - kdy "nevolatilni" datove struktury selzou a neni sance napravy, protoze low level pristup k disku (nebo jine veci) neni.

Mam spousty Intel SSD, ktere na tohle trpi - a to jen z duvodu, ze neni mozne provest "factory reset" na danem disku (tj. zapsat zcela vychozi struktury, ktere udelaj disk prazdnym).

Soft errory jsou vsude bezna vec a prekvapuje mne to prekvapeni :-) Pri cteni z disku, pri operaci z pameti, pri prenosu po sbernicich. Jen se obcas podivejte na interni pocitadla chyb. Servisni monitoring uz jen resi jaka je mira a jaka tendence aby se dana komponenta preventivne vymenila.
Non-ECC pameti jsou docela skvely detektor castic za par babek.

BTW: Doporucuji nepouzivat cesky prepatlany vyraz 'volatilni'. Jeho pouzivani je velmi 'incosiderabilni' a mozna by bylo nutne se 'edukovat' a 'correctnout' toto 'errorove' jednani.

Taky mě to napadlo, ale otázka co lidi budou řešit při radiaci, podle mě to nebude taková idylka jako Fallout, Jestli není ve výsledku, jednodušší mít něco co si člověk teďka "nalije" do nějaké té lepší kalkulačky, tu zapečetí do nějaké odolné schránky, a bude to připravený na "soudný den".

Díky za článek.

Přimlouval bych se za článek o MenuetOS. http://menuetos.net/

Je to sice o pár řádů vyšší liga, ale pořád dostatečně "odchylný" případ od hlavního proudu.

Díky za připomenutí. Mám ho už dlouho na TODO listu, podívám se.

Je to urcite pekne cviceni, ale opravdu ma smysl dneska programovat neco kompletne v assembleru?

Kdyz mrknu na 'protiproud' typu C#, Swift, Rust, ... nebo jen to co se 'deje' v novych C++

Evidentně jim to smysl dává, když už na tom, poměrně živě, pracují desítky let.

Hoby nemusi davat ziaden zmysel.

Tak. Je to prostě takový ekvivalent stavění modelu lodě v láhvi. Hezké, ale praktický užitek nic moc. Akorát krásu OS v assembleru ocení méně lidí.

Kazdy konicek ma nejaky smysl. Jedna se vzdy alespon o aktivni meditaci.

Asi by bolo dobre zmienit aj Jupiter ACE. Forth-ovy domaci pocitac z cias zx80/81.

A kto trocha rozumie FPGA si moze pozriet aj J1 forth-ovy procesor.

O Jupyter ACE chystám celý článek, ale zatím je jen v rozpracované fázi.

A co takový Collapse-Net ?

Nějaký projekt na toto téma občas zahlédnu, ale zkouší v české kotlině někdo něco takového ?
Moje představa by byla decentralizovaná síť bez autorit (i tvůj ISP je pro tebe autorita, protože tě může odstřihnout), stačili by opravdu malé rychlosti na přenos čistě textových zpráv, třeba automaticky přeposílat od baráku k baráku ( od uzlu k uzlu), všechny uzly rovnocenné, fyzických rozhranní může být více, třeba Wifi, IR, LoRa, ..... ale třeba i packet-rádio (AX25) na CB, nebo na PMR, to jsem v devadesátých letech zkoušel a fungovalo to krásně :-) přes pár dalších stanic, ze středních čech až na sever Německa.
Nebylo by to asi nic pro ty různé Facebookáře a Youtubáře, ... a podobné datové chamtivce, ani pro ty, co se rádi realizují spíš formou webových stránek než jejich obsahem, ale při scénáři zmíněném na začátku článku to může mít neocenitelnou informační hodnotu.

A co je zle na aktualno ax25? Podla pouziteho pasma mozes ist aj viac ako standardnych 1200/9600.

A ked nad tym postavys aprs "siet" mas to co si chcel.

Špatné je na tom je jen to, že pokud se nějaká taková síť ještě provozuje tak o ní nevím.
ax25 je docela jednoduchý a hezký, ale líbilo by se mi něco více samo-propojovacího (hledajícího cesty, spojení), přitom s co možno nejjednodušším algoritmem, aby mohla být celá hromada implementací a mohl se mezi nimi rozvinout boj o přežití.

Před nějakou dobou jsem někde narazil na odkaz na tento projekt, díval jsem se na stránky autora a zaujalo mě, že (aspoň podle toho, co tam psal) skutečně věří tomu, že kolaps nastane a na svých stránkách k tomu má i zdůvodnění. Protože Collapse OS podporuje Z80, navrhl jsem mu, ať vytvoří port na ZX Spectrum: argumentoval jsem tím, že v Evropě včetně bývalého komunistického bloku se povaluje spoustu těchto počítačů i jejich různých klonů (autor je pravděpodobně Američan a nemusí to vědět). Po pár mailech jsme došli k tomu, že když nemá reálný HW ZX Spectra, tak nemá motivaci port vytvářet, což si imho lehce protiřečí s tím, že věří tomu, že kolaps reálně nastane a musí se něco dělat... ale co už.

Na druhou stranu port pro ZX Spectrum prý existuje alespoň pro nějakou starší verzi či větev Collapse OS, která byla prý psaná v assembleru Z80.