Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
Projekt TOR se rozhodl ukončit vývoj doplňku TOR Button pro Firefox a naopak začít vyvíjet vlastní prohlížeč TOR Browser postavený na Firefoxu. Důvodem je prý náročnost zprovoznění doplňku TOR ve Firefoxu a problémy s udržováním jeho aktuálnosti a funkčnosti.
Tiskni
Sdílej:
[/rejp]
5.5.2011 17:34
David Watzke | skóre: 74
| blog: Blog...
| Praha
6.5.2011 01:19
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
To co rikas je pravda, ale jen pro beh JavaScriptu a to za podminek, ze vitr fouka od jihozapadu a vcera naprselo .
6.5.2011 22:46
pavlix | skóre: 54
| blog: pavlix
5.5.2011 19:24
jiri.one | skóre: 19
| blog: Jiriho blog
8.5.2011 10:12
jiri.one | skóre: 19
| blog: Jiriho blog
5.5.2011 19:12
xkucf03 | skóre: 49
| blog: xkucf03
Jako další krok napíší operační systém.Zrovna v tomhle případě by to dávalo smysl* – vložíš CD, zapneš počítač a máš bezpečné prostředí, s anonymitou a bez trojských koní. *) tedy ne psát vlastní operační systém – stačí vlastní odrůda nějaké linuxové distribuce.
. U moderních desek se zase dá využít virtualizace.
Tedy si stačí sednout k špatnému počítači a útočník se stejně všechno dozví. Další krok je tedy vlastní důvěryhodný hardware .
) je docela vtipnost (no spíš černý humor).
Někde jinde by to imho nebyl problém, už jen proto, že řešení (u-boot apod.) už existuje. Taky se mě zdá jako blbost používat na zásobník virtuální RAM přes cache. Jiné architektury maj prostě integrovanou přímoadresovatelnou RAM v procesoru. Nejhorší na tom je to, že až budu chtít udělat emulovaný rozhraní pro třeba freedos, tak budu muset stejně k assembleru, protože parametry se nepředávaj v zásobníku ale v registrech.
Konkurenci zkusím jen co vyjde model s 3D grafikou po sw i hw stránce ne horší než GF2 a se 3xSATA a 2xETH přímo v SoC. Nebo alternativa s několika PCIe linkami (v zásadě bych bral i jinou sběrnici, ale musela by umět plnou rychlost periferie, nic přes GPIO bit banging ). Stejně tak jako >=1GB RAM nebo PC kompatibilní slot. A samozřejmě programovací JTAG (ale to je oproti x86 standard). Všechno samozřejmě ne za likvidní cenu třeba >$1000 za desku a koupitelnou v ČR.
. Vlastně se to snažím naprogramovat tak nějak ze setrvačnosti, chuť napsat si vlastní BIOS nastala tak někde na střední, když například na 486 nešlo bootovat z CDROM.
No třeba v tom, že jsem se den patlal v kódu jak se vůbec dostat z reálnýho módu do chráněnýho, aniž bych to musel psát celý v něčem jako nasm. …
A zkoušel jste od nuly někdy nabootovat jinou platformu? Najmě tu, kde je taková různorodost hw?
Na každém procesoru a jeho strojáku najdete řadu úchylností. Pravda, všude se naserete kvůli úplně jiným věcem. Ale můj názor je, že x86 je zlatá platforma. Po porovnání s řadou jiných. Řada lidí si tu myslí, že tráva je u sousedů zelenější.
...Nejhorší na tom je to, že až budu chtít udělat emulovaný rozhraní pro třeba freedos, tak budu muset stejně k assembleru, protože parametry se nepředávaj v zásobníku ale v registrech.
Pročpak? Jako mladík jsem psal low level věci pro DOS, někdy i nahrazoval část DOSu a z Céčka jsem nevyšel. Assembler není vůbec nutný.
(8bitové registry, vůbec existence rozdílného IO a MEM prostoru, pomalé časovače - původní PC má tři na 1.něco MHz, pak se přidali i lepší
Buďme upřímní, existuje v platformě x86 něco, co brání mapovat periférie přímo do paměti a nepoužívat instrukce pro I/O porty?
To, že PC platforma to tak nedělá není primárně věc x86, ale pouze kompatibility se 30 let starými počítači. Ovšem PC není nutně rovno x86.
Tak třeba INT 13h funkce 2 (čtení sektoru z disku). Používá všechny normální registry + jeden segmentovej. Fakt nevím, jak bych v céčku (kompilovaném gcc s -Os) měl bez assembleru (ani inline) číst jednotlivé parametry v registrech
Tím, že si registry někam uložíte a pak s nimi zacházíte jako se strukturou v paměti a používáte nad ní pointery. Obvykle všechny C překladače, které umějí překládat pro 16 bitový režim x86 umějí speciální atributy funkcí typu register, nebo interrupt, kde Vám dokonce registry uloží přímo jako parametry funkce.
Taková funkce pak předá jako parametry funkce hodnoty registrů při jejím zavolání a pokud parametr změníte, na konci ho změní jako registr rovněž. Jeden z parametrů pak je flags. Není pak jediný důvod, proč sáhnout na assembler.
Pokud se hodláte obejít i bez toho, a budete si vymýšlet ještě více, pak stačí v asm napsat funkci pro uložení a obnovení registrů či nějakou emulaci a dále pokračovat v C. Více, než několik desítek řádků v asm není vůbec třeba.
Já jsem ale pochopil z předchozího textu, než že byste si důakldně prostuodval manuály, raději studujete zdrojové kódy jiných systémů a přicházíte na to, co byste v manuálech objevil rychleji. A samozřejmě nepřijdete na vše, co byste se dozvěděl z manuálu.
možná to jde, ale myslel jsem, že kompilátor optimalizuje právě operacemi nad registry
To je mýlka. Kompilátor, který by optimalizoval operaci pouze nad registry – požadavky jsou mnohem výše. Kompilátor optimalizuje celý celek. A Vašimi zásahy ve zdrojáku optimalizace funguje.
Nebo například zápis bufferu na jiný segment. V případě chyby se navíc musí nastavit carry flag. Omezení tu pak ještě je takové, že vlastně BIOS nemůže vědět jak má hluboký zásobník a nemá ani moc oblastí na uchovávání globálních proměnných.
Viz moje odpověď o pár odstavců výše. Vy se pořád divíte něčemu, co před 20 lety v DOSu nebyl problém. Jste v 16 bitech, tedy blok paměti bez segmentování je max. 64 KB. Takže segmentovat se musí. Vše je vyřešeno a programátoři běžně programovali v C včetně vracení carry flagu a nastavování segmentů aniž by nutně sáhli na asm.
Buďme upřímní, existuje v platformě x86 něco ...No právě ta zpětná kompatibilita s 16bitovým 8086 (i když bych řekl, že to sahá až k 8bitům). PC jsem myslel IBM PC na Intelu 8086 a další verze s ním zpětně kompatibilní (tedy ona pokusná deska a můj hlavní počítač), jinak samozřejmě ta zkratka může teoreticky znamenat velmi rychlý kuličkový počítadlo, pokud by ho někdo považoval za osobní počítač. Pokud by se všechny IO porty namapovaly do paměti, tak by to z hlediska přeplácanosti architektury nepomohlo, protože by pak byla z hlediska délky opkódu dost významná instrukce zbytečná (out je zakódováno jediným bajtem), stejně tak jako celý aparát starající se o bezpečnost IO operací.
Tím, že si registry někam uložíte ...Jo tak to je jasný, pokud se mu klíčovejma slovama řekne, že má zachovat takový a takový registr, tak je jasný, že na to má dost informací aby to optimalizací nerozbil. V tomhle případě jsem si nebyl jistý assemblerovskou inline funkcí. Jestliže umí GCC používat registry jako proměnné, tak je to OK (jestli to umí i definovat pointer pro segmentovaný 16bit mód, tak ještě lepší). Nakonec bych to našel, tak daleko jsem se v kódu stejně zatím nedostal. Zvlášť když vím, že tohle uměl i turbo pascal. Mě spíš šlo o to, jestli to umí i nějakej moderní kompilátor v linuxu (ne nic, co umí jen původní normy jazyka C), nejlépe právě GCC. Bylo by totiž blbý v roce 2011 s linuxem používat soft z oné doby (já vím, zastaralost té testovací desky apod. ale to bych si koneckonců mohl rovnou koupit non x86 desku bez zpětné kompatibility a tenhle problém by nevznikl, už právě jen proto, že bych nepotřeboval vlastní "bootloader").
Já jsem ale pochopil z předchozího textu, ...Abych pravdu řekl, tak tohle "just-in-time" studování je mnohem rychlejší (v mém případě) než učení se z manuálu. I když si občas manuál přečtu, tak si z něj věci stejně zapamatuju tak povrchně, že až ho dočtu, tak jsem skoro na nule a při programování bych to musel stejně znova objevovat (je tu určitá mírná pravděpodobnost, že po přečtení manuálu se intuitivně přikloním správnému řešení). Přímo si ale tu informace nepamatuju. Pokud bych si musel data zapamatovat jako básničku na základní škole (ble), tak bych to musel číst mnohem pomaleji a to bych pak možná i byl u metody just-in-time rychlejší. Koneckonců to přepnutí do chráněnýho módu jsem si taky nejdřív přečetl z dokumentace (ale o pár let zpátky
).
Pokud by se všechny IO porty namapovaly do paměti, tak by to z hlediska přeplácanosti architektury nepomohlo, protože by pak byla z hlediska délky opkódu dost významná instrukce zbytečná (out je zakódováno jediným bajtem), stejně tak jako celý aparát starající se o bezpečnost IO operací.
Musíte si vybrat. Jinak jste kverulant. Pokud budete mít I/O v paměti, tak na každé architektuře k tomu máte instrukce, které jsou minimálně 2 bajty, častěji spíše čtyři. I/O porty Vám umožňují jednobajtovou instrukci. I když mě samotnému délka instrukcí přijde plus mínus irelevantní.
Aparát starající se o bezpečnosti I/O prostě namísto I/O mapy bude používat prostředky starající se o bezpečnost paměti. Nehledě na to, že u paměťově mapovaných platforem často výrobci přidávají registry pro ochranu I/O. Mají více práce, než na x86 architektuře. Něco je vždy za něco.
Jo tak to je jasný, pokud se mu klíčovejma slovama řekne, že má zachovat takový a takový registr … Jestliže umí …
To je právě Váš podstatný problém, který jsem zaregistroval hned na začátku. Je hezké, že se učíte příklady z jiných projektů, ale úplnou množinu toho co máte k dispozici získáte jen pouze z manuálů. Proto já osobně nic jiného, než manuály nečtu.
V řadě projektů určité featury také používají chybně a náhodou v intencích, které nepůsobí problémy.
Příklady z cizích projektů může být hezký úvod pro seznamování, ale v určitém momentu buď pristudujete manuál, a nebo si zaděláte na mnoho problémů, které jsou snadno řešitelné, ale Vy je budete měsíce řešit a nevyřešíte, protože trváte na studiu cizích projektů a ne manuálu a základní dokumentace.
Abych pravdu řekl, tak tohle "just-in-time" studování je mnohem rychlejší (v mém případě) než učení se z manuálu.
V počátečních stadiích. Pak v určité chvíli je studování bez manuálu velmi pomalé a začíná rychle vítězit.
Jinak toto není kritika, jen snaha pomoci. Sám jsem nikdy nenaprogramovalpřechod z real do protected módu, ale vše co jste řešil vím, protože jsem si x86 architekturu pročetl z manuálu dříve, než jsem začal něco dělat. A knížka od Brandejse o x86 procesoru je v češtině a naprosto bezkonkurenční.
C je systémový jazyk a jako takový se snaží aby asm byl potřeba co nejméně. Znovu říkám, v dobách DOSu jsem toho v asm napsal dost, ale bylo to více méně z frajeřiny a ze záliby. Nemusel jsem to dělat, C dává dostatečné možnosti abych se bez toho obešel.
V asm je nutné psát jen bootloader a maličké jádro. Dříve se psaly rychlostně kritické věci v asm, ale to už se také nedělá, protože dnešní optimalizace C a ještě lépe C++ je na takové úrovni, že se to nevyplatí.
Navíc napsat rychlý asm kód pro x86 není prdel. Jen možná 1% assembleristů je schopno napsat rychlejší asm kód, než leze z dobrého C/C++ optimalizovaného kompilátoru. Ona ta pravidla rychlosti vykonávání instrukcí jsou velmi složitá a liší se model od modelu.
Sám píšu low level věci v C++, nic lepšího není. Do asm sahám jen v opravdové nouzi.
Sám jsem nikdy nenaprogramoval přechod z real do protected módu, ale vše co jste řešil vím, protože jsem si x86 architekturu pročetl z manuálu dříve, než jsem začal něco dělat. A knížka od Brandejse o x86 procesoru je v češtině a naprosto bezkonkurenční.No to je u mě problém, protože když si to přečtu a pochopím, tak už mě nebaví to zkoušet v reálu
. Já jsem, abych pravdu řekl, ten přechod pořádně pochopil až z disassemblingu jiného BIOSu (ono to v tom athelpu není moc pochopitelný a internet jsem v té době neměl).
Když je dost času, tak lze programovat i v assembleru a efektivněji než v C. Zkoušel jsem jednoduchý printf, ale pak jsem to samý napsal v céčku za půl hodiny, což byl zlomek původního času v assembleru.
x86 není komplikovaná architektura, ale prostě odpovídá dnešním složitostem věcí...Imho je ale složitější než by mohla být. Resp ocenil bych složitost na jiných místech, než na kterých je teďka. ARM má právě výhodu v tom, že je to spíš tržiště než katedrála a není problém, aby si některý výrobce ten hardware učesal. Softwarová kompatibilita je pak stejně pro většinu věcí zachována, zvlášť, když si může upravit kompilátor (GCC) a všechno vždycky překompilovat.
Nejrychlejší strojové kódy jsou mnohem delší...Jo tady by se právě hodila opačná složitost. Realizována například dynamickému přizpůsobení mikrokódu. To ale nejde, protože mikrokód x86 od každého výrobce není příliš open source. To mě například vadí na ARMu, že nemá dokumentovaný jazelle režim.
Já cítím, že Vás Váš způsob baví. Nedejte se mnou od něj odradit. Není nic hezčího, než dělat a mít badatelského ducha. Přeji hodně úspěchů.Jo to jo, thx.
Imho je ale složitější než by mohla být. Resp ocenil bych složitost na jiných místech, než na kterých je teďka.
Unix a Linux je také mnohem složitější, než by mohl být. Protože z projektu, který jede několik desetiletí prostě nějaké kompromisy kvůli zpětné kompatibilitě naděláte.
ARM má právě výhodu v tom, že je to spíš tržiště než katedrála a není problém, aby si některý výrobce ten hardware učesal.
ARM má mnoho problémů už od cpu. Například rychlost jeho I/O a reakcí na přerušení je zoufalá katastrofa extrémního formátu. Těžko najdete platformu, která by měla tak pomalé reakce na vstupy a výstupy jako ARM. Když jsme mluvili o I/O.
Pokud má výrobce udělat rozumně rychlý hw, tak nahrazuje v hw i to, co u jiných platforem, třeba x86 udělá procesor. Protože ARM je v tomhle zoufalý.
Dokonce někteří výrobci už sahají k tak zoufalým krokům, že svůj hw maskují jako koprocesor ARMu a mapují vlastní strojové instrukce do strojáku ARMu, aby to nějak rozumně běželo.
Neidealizujte si žádnou platformu, ARM má problémů mnoho.
Jakýkoli projekt po 15-20 let bude plný nalepováků, různých ústupků zpětné kompatibilitě a různých nesrovnalostí. Jakýkoli.
Podívejte se na unix/linux jak lepí thready, jak lepí unicode do API funkcí, jak lepí lokalizaci do printf a tisíce kousků, se kterými původní unix vůbec nepočítal.
Jak unix válčí s koncepcí XWindows versus využití grafických akcelerátorů naplno.
Ideální věci mohou být max. 5-10 let po začátku, pak se začnou zasírat. A je úplně jedno o čem budeme mluvit.
. Ale nic jinýho nesplňuje mé kritéria výběru.
U ARMu jsem si nějakýho zpomalení, když jsem pracoval se sériovým synchronním portem, nevšiml. Zvlášť když to vlastně ani přes ARM nejelo. Data kopíroval DMA přímo do operační paměti. Abych pravdu řekl, tak mě ani nenapadá v jaké aplikaci by měl ARM přímo číst I/O. Snad kdyby chtěl někdo něco emulovat na GPIO (ale to není příliš potřeba, protože prakticky všechno už je v SoC).
Neidealizujte si žádnou platformu, ARM má problémů mnoho.Hmm idealizoval bych si akorát vlastní platformu
, ale i to není jisté.
. Osobně si myslím, že bych se ve světě x86 se zdvořilostí moc daleko nedostal (schválně zda by se mnou Intel vůbec bavil, kdybych ho požádal o programovací údaje mikrokódu ). S tím, že každý projekt je po čase zaplácaný je jasný, s tím souhlasím. Někdy je ale dobré se na to vykašlat a začít znovu (zhruba jako teďka byly návrhy na arch/arm/ v Linuxu).
To jsou věci, v tom původním C bych fakt programovat nechtěl, u toho BIOSu jsem hned hledal jak přepnout GCC do gnu99 . Bohužel fakt často projde to horší, ale zase celý svět počítačů není zas tak starý, aby to bylo pravidlo, některé jevy mají i docela velkou periodu (většinou jako jinde dobu setrvání nějakého šéfa ve firmě).
Jinak ona ta Java i C++ syntakticky vychází z céčka a i když mají základní prvky pojmenovaný jinak, tak mají stále mnoho společnýho. Pořád to není pořádný jazyk, kterým by šla naprogramovat tvrdá UI.
).
No já pivo nepiju a do hospody půjdu až po zkouškách se spolužákama (pokud teda něco bude). Naopak mě nevadí to probírat i tady, aspoň si to budu pamatovat i další ráno (případně se může objevit někdo jiný a přispět).
Zajímavý, že netají. Já jsem před časem hledal nějaké informace o těch patch slotech a ve fórech bylo spíš psáno, že to maj jako firemní tajemství. Kdyby ten firmware vyvedli přes nějakou přepisovatelnou paměť ven, tak by se děli věci . No je to možný, při přechodu pascal → C jsem taky dlouho v céčku nemyslel. Pro přechod na podobnou syntaxi i když jiný zvyklosti bych měl asi větší problémy. Ale java a c++ považuju i tak za jazyk stejné úrovně jako C.
Nakonec jsem našel hlavní chyby v programu takové, že sice už běží chráněný mód, ale do far jumpu je ještě prostředí 16bitové (a stejná instrukce se chová v obou prostředích právě naopak než při použití prefixu změny prostředí)To je celkem logické, protože instrukce se dekódují podle toho, v jakém režimu zrovna procesor běží. Dlouhý skok hned po přepnutí je popisovaný jako nutnost a to ze dvou důvodů: zaprvé se vyprázdní fronta předdekódovaných instrukcí, zadruhé se musí změnit segmen na selektor v registru CS, hlavně jeho "neviditelné" části. A prefixy 16/32bitů opravdu fungují jen jako přepínač, což je docela problém u assemblerů, které generují prefixy podle nastavení segmentů.
.
Druhá sranda byla v tom, že adresu GDT v GDT () jsem měl jako odkaz na navěští, jenže kompilátor bral ofset podle 16bit módu, takže tam právě chybělo to 0xf0000.
Nakonec jsem si na to vzpomněl, ale zbytečně jsem vyplýtval několik hotflashí BIOSu (a hotplugu disketovky ).
. Holt udělali v Intelu razatní krok na velmi špatném místě.
Další věc je, což je jen otázka zbytečného rovnítka mezi x86 a PC, že řada výrobců používá x86 procesory v real modu, protože neexistuje jenom PC.Jo jako embedded? Koukal jsem se na to v rámci jedné práce a embedded desky založené na x86 maj sice nižší cenu, ale mnohem horší periferie. A mohl bych ještě přidat, že pokud běží v RM, tak mají jen 1MB adresní prostor, kam se fakt MMIO registry nevejdou.
Instrukce v real mode jsou kratší, než v 32/64 bit protected módu, což pro určité případy je super.No to není právě zas až tak moc pravda. Stejná instrukce s 16bit slovem pro 16bit bude ale na 32bit pracovat s 32bit slovem. Kdyby si nevyplýtvali prostor pro opkódy, tak mohla určitá instrukce pracovat vždy se 16bitovým slovem, jedno kde. A instrukce pro 32bitové slovo, by prostě mohla pracovat s tím slovem vždy a stejně. Tohle museli vědět, že 16 bitů nebude stačit a mohli to u Intelu ošetřit už u 8086. Zvlášť když 68k (v době 8086) už skoro plně fungovala na 32bitech (stačilo jen přihodit dráty a povolit větší registry, což se pak i stalo).
) jsem to také zkusil. V BIOSu to bohužel nejde, protože ta paměť je readonly.
No pokud u uC v embedded je 1MB luxus, tak bych tam strčil PIC nebo dsPIC a získal spotřebu tak v mA a v režimu spánku v uA (docela by mě zajímalo jakou by měl PIC vyrobenej v 22nm technologii ).
Fakt? To se mi nezdá, spíš bych řekl, že 8086 se prosadila kvůli verzi 8088 což byla 8086 s 8bitovou sběrnicí (ale vevnitř stále 16bit). To "jednobitové" je překlep? Jinak to totiž moc nechápu. Jestli to měly být jednobajtové, tak to možný je, ale to teda moc velkou kompatibilitu nedělá .
No já bych x86 nazýval to co současný RISC mikrokód emuluje, mikrokód bych x86 nenazýval ani. BTW proč teda už nikdo další režim nepřidal? Koukal jsem se a jediný co jde s mikrokódem dělat je plnit nějaké patch sloty, které maj omezený počet a kapacitu. Docela by bylo dobrý, kdyby se na x86 podporu zadrátovanou vykašlali a programování třeba Core 2 by bylo přímo v mikrokódu.
To co jsem se snažil říct bylo to, aby se ten bit 16/32 v deskriptoru buď vyhodil a nebo aby se nechoval jako XOR. V nejlepším případě, aby se dal nastavovat i v RM. Pokud vím, tak když se GDT načítá ještě před PM, tak mohli změnu udělat aplikovatelnou i bez přepnutí do PM. A nebo přímo RM odstranit a vše řešit virtualizací z VM (a bootovat do zjednodušeného PM). Na 386 to ještě mělo smysl, ubralo by to hodně křemíku.
. Nikde v žádném zákoně není napsáno, že musí být architektura navždy zpětně kompatibilní.
Podle wikipedie ta kompatibilita moc dobrá nebyla
Marketed as source compatible, the 8086 was designed so that assembly language for the 8008, 8080, or 8085 could be automatically converted into equivalent (sub-optimal) 8086 source code, with little or no hand-editing. The programming model and instruction set was (loosely) based on the 8080 in order to make this possible. However, the 8086 design was expanded to support full 16-bit processing, instead of the fairly basic 16-bit capabilities of the 8080/8085.To, že lze každý opkód 8080 jednoznačně převést na 8086 přes nejaký konverzní program nenazývám kompatibilitou strojáku. Je víc než pravdepodobné, že by to šlo konvertovat i na 68k třeba. Segmentace by nebyl u 8086 špatný start, kdyby například vytvořili fyzickou adresu prostým spojením segmentu a offsetu. Získali by rovnou 32bitovou adresu, která by jím déle vydržela a do budoucna by měli dobrý start (podle alternativního vývoje by mohli udělat další transkompilační konvertor na alternativu třeba 386). Zároveň by měli celých 65536 segmentů pro 65536 CP/M programů
. Ani by nemuseli ze začátku implementovat všechny vodiče, klidně by stačil segmentový registr osmibitový. A budoucí problém s bránou A20 by vůbec nevznikl. Pokud by mysleli hodně dobře dopředu, tak by "segmentový" a "offsetový" registr předdefinovali jako zápis do půlek jednoho velkýho 32bit registru a okolo 386 by segmentace přestala existovat, protože by všichni měli flat-mód a stránkování.
Jinak i kdyby to CP/M podporovaný nebylo, tak bych se hodně divil, kdyby kvůli tomu IBM zkrachovalo v tý době . BTW nevzniklo EXE kvůli omezení, že se COMy už nemohly vejít do jednoho segmentu?
Jo, ale neřekl bych, že dnešní Linux je 100% kompatibilní s Linuxem z 90.let a i tak zrovna nekrachuje. Jinak dneska není potřeba taková kompatibilita jako v 80.letech, dneska když si chci program, co používám na x86, spustit i na ARMu, tak ho prostě překompiluju a jsem rázem na jiné architektuře. Už jen logicky, drobná změna v té samé architektuře (viz třeba to PM), by vadila mnohem míň (to PM při resetu by se projevilo prakticky jen v BIOSu, ale z procesoru by zmizel celý jeden mód - RM).
Dejte jim důvod, aby dalším režimem vydělali miliardy dolarů a rádi ho přidají.Hehe o to se tu právě propagací ARMu snažím
. (sice pokud by začal ARM nahrazovat x86 tak nevydělají, ale začnou prodělávat, nicméně ten tlak je stejný)
Emulace je největší výhoda x86. On taky mohl třeba Intel zadrátovat mikrokód 486 a dnes bychom se mu přizpůsobovali. Moc hezká představa to není co?No na druhou stranu pokud bych si musel vybrat z x86, tak zrovna 486 je moje nejoblíbenější, konkrétně ale ne od Intelu, ale poslední od AMD. Zlepšit byla druhá alternativa, první byla zrušit. Jestli stojí zisky Intelu na zachování RM, tak potěš koště
. Pokud ale Intel vidí všude jen zisk a nechá proto svojí architekturu blobovat, tak se vystavuje riziku, že někdo vytvoří něco novýho lepšího (i když třeba jen relativně) a Intel skončí.
Právě zrovna u Perlu je to vtipně paradoxní, právě tenhle semestr jsme se začali učit právě Perl. A já osobně v tom i po tomhle semestru budu pokračovat, Perl mě velmi zaujal (Python jsem vrtošivě zavrhl hned kvůli odsazování).
5.5.2011 20:29
xkucf03 | skóre: 49
| blog: xkucf03
. A zárověň s BIOSem 128kB je už málo místa. A třetí už je tak vepředu, že nepodporuje ani třídu mého nejrychlejšího počítače .
Navíc tuším, že coreboot neimplementuje volání DOSu na to je potřeba speciální projekt, což sežere ještě víc místa.
.
Na druhé straně hw Kindle je opravdu dost ubohý (není hw, není co poškodit) a v krajním případě lze Kindle resetovat.Jo docela štěstí, že ty ADSL modemy maj stěží dost velkej flash na svůj OS. Nějakej červ se tam už nevejde.
Daný balíček musí být digitálně podepsánAha tak nic, to bych si hnedka dal vlastní distribuci.
.
Záruku jsem využil jen jednou, kdy se mě po softwarové stránce rozpadl shitoidní ADSL modem (ale byl/je to můj první ARM ).
6.5.2011 00:07
cezz | skóre: 24
| blog: dm6
Da se s tim Kindlem fungovat na beznych webech? Docela by se mi to libilo na takove to rychle surfovani, kdyz je clovek liny startovat cokoli vetsiho. Je to pohodlnejsi nez bezny smartphone? :)NIE.
Ak sa ma spytas, aky ebook reader, tak jednoznacne kindle. (Mam Kindle 3 WiFi a je super, jedna z najlepsich veci, co som kupil) Ak sa ale pytas, ci sa to da pouzit na browsovanie, tak neda..
Teda, da sa. Ma to aj browser zalozeny na webkite, aj WiFi a ked si priplatis, tak aj 3G konektivitu, ALE:
5.5.2011 22:49
AsciiWolf | skóre: 41
| blog: Blog
Takové projekty už dávno existují.
Já osobně kdysi hojně používal Anonym.OS.
5.5.2011 19:15
xkucf03 | skóre: 49
| blog: xkucf03
myšlenka na vytvoření prohlížeče optimalizovaného pro "práci v utajení" se mi nezdá zase tak špatná+1 akorát bych v takovém případě asi nestavěl na Firefoxu*, ale na něčem lehčím – třeba rekonq nebo arora. *) jako normální prohlížeč je OK, sám ho používám.
A co je potom tohle ? https://www.torproject.org/dist/torbutton/torbutton-1.3.3-alpha.xpi
5.5.2011 18:42
Migi | skóre: 59
| blog: Mig_Alley
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
5.5.2011 18:17
In addition, the project also intends to remove the Torbutton Firefox extension from Mozilla's add-on repository (addons.mozilla.org) and only offer it for experienced users from the Tor project site; maintenance will be discontinued. The developers are currently discussing details on the mailing list.
6.5.2011 20:20
xkucf03 | skóre: 49
| blog: xkucf03
dostat se na spamlist.Proto je ve výchozím nastavení taky zakázaný TCP port 25 ve směru ven.
6.5.2011 23:34
xkucf03 | skóre: 49
| blog: xkucf03
Více si o tom můžeš přečíst tady: What about spammers?
(jasně, jde se přes tor připojit třeba na ssh jiného serveru a spamovat až z něj a tor použít jen na zametení stop – jenže v takovém případě IP daného Tor exitu na černou listinu nedostane, protože nikdo neví, že ten spam jde z ní).
6.5.2011 23:36
xkucf03 | skóre: 49
| blog: xkucf03