Vlákno názorů k článku
Vývojáři jádra začali odstraňovat podporu procesorů 486 od alobalova_ciapocka - Nechapem co maju proti 486. Sviezi boot na...

To nikdo neví, protože to reálně nikdo neřeší a nikoho to netrápí. Pokud se na to podíváme z pohledu řízení rizik, tak i kdyby na platformě 486 byla kritická zranitelnost co umožňuje jednoduchou eskalaci práv, tak reálný dopad takové chyby je nulový -> nikdo nebude investovat čas a prostředky do opravy, protože je to neobhajitelné.

Bavíme se tu o platformě, co byla zastaralá před ~30 lety. Pochybuju, že to zařízení používá někdo jinak než v režimu muzeum, kdy má radost kdykoliv se to podaří nabootovat. Pokud bych takovou věc měl, tak tam budu bootovat něco s jádrem max 3.2, ale spíš něco dobového jako 2.0 či 2.2. Takže jestli na tom teoreticky lze po půl hodině nabootovat aktuální jádro je stejně jedno.

Nicméně pokud jste takový fanda 486 procesoru, můžete po skončení podpory SLTS jádra 6.12 dělat dále jeho podporu a backportovat tam nové funkcionality. To je přeci výhoda toho otevřeného kódu, ne?

15. 4. 2026, 19:59 editováno autorem komentáře

Viz opravdový pokus se 486 z doby relativně nedávné (2018 = méně než 30 let :))
https://yeokhengmeng.com/2018/01/make-the-486-great-again/

Jádro 4.14, do textového loginu bootoval jen cca 11 minut. Kdyby ta 486 byl poslední linuxový počítač na světě, tak by se to snad i dalo používat. Pořád se na tom třeba dá sázet v TeXu, pokud uživatel vystačí s ViM a 80x25 znaky...

Ta 486 v tom videu je ve skutečnosti Am5x86 na 133 MHz se 64 MB RAM. Tedy nejrychlejší 486ka co byla vyrobena s RAM co je násobně větší než bylo v době 486 běžné (osobně jsem svou 486 dostal postupně ze 4 MB RAM až na 16 MB RAM. Na počátku 1 MB = cca 1000 Kč). Takže nějaká běžná dobová 486 co najdete někde u příbuzných bude ještě násobně pomalejší.

Hehe, tú Am5x86 si pamätám, to sme mali doma v mojej puberte. Pretaktovanú na 160 MHz lebo na štandardnom nastavení to nefungovalo kvôli nejakému bugu na základnej doske (alebo v BIOSe?).
Pamätám si, že na to, aby to stíhalo prehrávanie mp3ojok, bolo treba vo Winampe tuším znížiť výstupnú vzorkovaciu frekvenciu na polovicu. A enkódovanie do MP3 nemalo veľmi ani zmysel skúšať, minúta súboru trvala, ak ma pamäť neklame, cca. pol hodiny. Ale na tú dobu super, väčšina spolužiakov nemala počítač žiadny.

Na 160MHz a 4MB RAM běžel DOSAMP naprosto v pohodě na všechny současné MP3 . Přes noc pak procesor obsluhoval BBSku a Fido 2:420/19.4

Kdybych byl fanoušek retra,,tak bych na 486 měl dos a hromadu dobových aplikací, dbase, Fox pro, Quatro pro, Lotus 123, Autocad, PageMaker,Venturu, WordPerfect, překladače od borlandu atd...

80x25 znaku neni omezeni platformy 486 ale grafiky. Da se prepnout do lepsich modu. 486ky minimalne nejakou tu VGA, casteji spise SVGA mely.

Ohanite se bezpecnosti, ale zaroven by jste bez vahani pouzil nejake zastarale jadro.

Pan je koukam odbornik na slovo vzaty :D

Dokud jsem offline, je to jedno. A doba 486 byla převážně offline.

Celá tahle diskuze je zbytečná. 486 na normální práci už desetiletí nikdo nepoužívá úplně stejně jako nejezdíme do práce koňským povozem nebo vlakem poháněným parní lokomotivou.

Eh, síťová komunikace není jediný možný vektor útoku. Souhlasím, že ve spoustě stávajících nasazení 486 ta bezpečnost kernelu dost možná nebude hrát až takovou roli, ale argument offline sám o sobě nestačí.

Linux meni vnitrni ABI protoze je to linux. Je to jeho vlastnost. Kdyby nemenil je to jiny operacni system.

Vyvojar se s tim musi smirit nebo vybrat jiny OS pro svuj projekt.

Patrne jedna z nejblbejsich vlastnosti, neustale to generuje spoustu zbytecne prace.
Typicka zmena je prejmenovani nebo prehazeni parametru funkce, ne funkcni zmena.

16. 4. 2026, 10:09 editováno autorem komentáře

OpenBSD už nějakou dobu vyžaduje minimálně 586 a hardwarový FPU.
Poslední verze spustitelná na 486 byla někdy okolo šestkové řady, než přešli na LLVM/Clang pro sestavování systému a udělali spousty změn okolo. Ale i daleko předtím ta podpora byla taková všelijaká, protože to víceméně roky nikdo nepoužíval a pravidelně netestoval - pamatuji si na dobové bug reporty, kdy to třeba několik vydání nechodilo než někdo napsal, že to ze zajímavosti zkusil spustit na nějaké i486 z kumbálu a zjistil, že je třeba asi opravit loader :)

NetBSD jsem už tu někde zmiňoval. To je naprosto specifický projekt, který z široké podpory nejrůznějších i historických platforem udělal jeden z hlavních cílů projektu a kompletně tomu podřídili spousty ostatních aspektů. Tohle je jejich nika.
Ale samozřejmě zas spousty ostatních fíčur v porovnání s Linuxem ten systém nemá, je relativně pomalý, zdaleka nemá infrastrukturu jako rozšířené linuxové distribuce atp.
Pro i386 platformu jsou dvě sestavení jádra, první je výchozí, druhé legacy pak s povolenou ISA. Takže třeba pro stroj s 486kou bez PCI je potřeba udělat instalaci přes sérový terminál (nebo na disk z druhého stroje) a pak tam vyměnit jádro.

Jinak si samozřejmě furt můžete pořídit
https://www.ebay.com/sch/i.html?_nkw=Pentium+Overdrive
:)

Samé odvážné myšlenky :)

Koneckonců Pentium Overdrive už jsem tu zmiňoval, to byl taky retrofit do původních socketů. I když s RISC-V to asi ještě nikdo nezkoušel.

Na technologické patenty vždycky platila v USA lhůta 20 let, takže Pentium z roku 1993 by mělo být v těch zásadních věcech v pohodě. Otázka jsou pak věci okolo, asi by se na tebe stejně sesypali a řešilo by se jestli tam třeba nejsou nějaké kousky jejich mikrokódu a jak jsi ho případně (ne)použil při vývoji svého.
Asi ne že by se do toho někdo chtěl hrnout. Jeden Vortex86 už tu je - 486 + TSC, čímž se specifická díra, řekl bych, asi zaplácla.. :)

Jinak obecně myslím, že navzdory stížnostem to Linux stran podpory architektur a fíčur balancuje vcelku dobře. Člověk musí přihlédnou k obrovskému rozsahu projektu minimálně co se přispěvatelů týká, šíři toho nasazení a nejrůznějším požadavkům.
A právě nemám pocit, že by se případná rozhodnutí nedala ovlivnit nebo zvrátit.. a je to ovlivněno primárně zájmem (firem, vývojářů, uživatelů). Tzn. pokud ho někdo projeví snahu, prostředky a bude to dávat trochu smysl, může lecos fungovat dál, aniž by to apriori brzdil nějaký gatekeeper. Stejně jako se tam třeba některá technologie může vrátit (např. ten XIP, co jsi zmiňoval).

A jako moc vzrostla komplexita toho RTOS? Jak moc vzrostly nároky na ten systém? Například, mám tu fotky z digitálního foťáku. V roce 2003 měly rozlišení cca 2200x1700 (3.6MPix) a cca 500kB. Nyní to mám 50MB RAW se 14bity a 36MPix. Zobrazuji to na 4K monitoru proti 1280x1024 z roku 2003.

Vzrostly ekvivalentně nároky i v tom RTOS? Nebo to pracuje s furt stejnými datovými toky a odezvami?

Na druhou stranu, roku 2000 jsem programoval nějaký PIC16Fněco. Pár kB všeho... Nyní mi tu leží ESP32 s 16MB RAM a 8MB SPI flash a běží mi na tom webserver. Myslím si, že by svým výkonem uměl konkurovat i té 486.

Na atmega8 network stack nebudete typicky provozovat, ale nikdo vam nebrani aby jste pouzil aktualni Arduino IDE vcetne soudobych knihoven.

Mixujete sw s vykonem/featurama.

Ty zase mixuješ naprosto nesrovnatelné světy - svět PC, kde se nároky na vše nějak zvedly, a svět MCU, kde jsou do jisté míry ty požadavky stále stejné. Takže pokud někde jde, aby stále stačilo stejné MCU a stejně náročný RTOS, tak jinde to prostě tak není. Viz třeba zpracování fotografií nebo videa. Nebo zkus to Arduino IDE pustit na té 486.

Na druhou stranu, před pětadvaceti lety nikdo neměl potřebu MCU připojovat k ethernetu/wifi. Dnes je to v podstatě základ a nevím, jak by taková atmega8 zvládla upočítat WPA3.

15. 4. 2026, 18:31 editováno autorem komentáře

WPA3? jestli jsem dobre nasel, tak WPA3 PSK pouziva AES-128.

Na AVR mam tohle AES napsany, reknete mi kolikrat se to pouzije u pripojeni do site a reknu vam kolik to realne bude trvat.

A o tom to je. Nepotrebuji kupovat jiny zelezo.. kdyz si tam MUZU pustit novy SW.

Jiste - na SSL tunel to nebude*, ale PSK se tim vyresit da.

PS: onen aes kod pochazi z doby kdy jsme na tom atmelu delali hw pro MiTM PoC - sice tam nebylo m8 ale neco s vice flash pameti.. a do site to bylo taky pripojeno. A bylo to cca 20 let zpet co jsem postavi prvni avr+eth hw, kterym jsem zacal embedded vyvoj.

Pokud jsem dobře našel, tak WPA3 nemají PSK, ale SAE, což je modernější alternativa. AES (ne nutně 128) je tam (stejně jako u prakticky všech protokolů) jen část příběhu. Při navázání připojení se využije i nějaká asymetrická kryptografie, pro přenos je pak potřeba i nějaká podoba MAC / AE(AD). A teď jsou otázky:

1. Vleze se všechen kód do paměti čipu, i s ostatním SW? Nevím.
2. Bude samotný přenos dat výkonově OK? Dost možná jo. Zvlášť pokud nepotřebujeme obří objemy dat. Hádám, že tento bod bude ten nejmenší problém.
3. Půjde navázat spojení dostatečně rychle, aby to nepošlo na timeout? Nevím.

Body 1 a 3 mohou někdy jít proti sobě. Optimalizujete SW na velikost kódu, ale ten je pak pomalejší.

Nikdo nerika ze to AES bude pocitat samotna atmega. Vetsina modernich wifi chipsetu si to resi sama.
Mozna jen nejake upgrade obezlicky pro starsi cipsety resi predani raw frame a zpracovani na urovni cpu

> ESP32 s 16MB RAM a 8MB SPI flash a běží mi na tom webserver. Myslím si, že by svým výkonem uměl konkurovat i té 486.

Na ESP32P4 jde hrát Quake, takže té 486 výkonem konkuruje rozhodně.

A bootuje vam 11 minut jako panovi se 486 ? :D

To nevím... Ale na nějakém AVR-ku to jsou jenom 3 hodiny: https://www.youtube.com/watch?v=nm0POwEtiqE (ale podvádí s tím, že init je asi rovnou bash a taky je tam jádro 2.6.X z doby před 14 lety)

A to ESP32-S3, to, zdá se, zvládne za cca 15s: https://www.youtube.com/watch?v=pj0a91vlcGo

Ne, protože tam nikdo nezkouší spouštět Linux. Nějaký RTOS se tam pochopitelně vejde s přehledem, nějaká odrůda DOSu by tam šla vyrobit taky, ale nevím proč by se měl OS jako Linux zkoušet vyhovět všem use cases od kalkulačky po datacentra, to je dost absurdní cíl.

Prostě revertovat ten commit a mergovat do toho všechno ostatní, a opravovat ty rozbité věci. Pokud vám to za to stojí a je to pro vás tak strašně důležité.

Vývojáři jádra už to tam prostě nechcou, a nechcou tam ani emulátor 80-bit FPU, atd... Taková je realita.

16. 4. 2026, 14:31 editováno autorem komentáře

Asi by to nemusel být neřešitelný problém. Mikrotikls udržuje svoji vlastní out-of-tree podporu pro architekturu TILE.

Na to jsem se jich jednou ptal - oni to neudrzuji.
Pouzivaji posledni kernel co to umel a jsou radi ze jim jede binarni toolchain.
Tj jejich reseni je "zamrznout v case".

A vlastne jsem se jich ptal zda zverejni ty TILE zdrojaky nebo toolchain a pry ze ne.

O ty atypicke architektury se zajimam a mam taky TILE hw, bohuzel sbirat podporu po drobkach ze vsech koutu internetu je nemozne - a mrzi me kazda aktivita o smazani nejake podpory, bez poradne archivace stylem: presuneme to do kose.

A az to nekoho bude zajimat, tak vime v jakem kosi to je - odkud se to da pouzit rovnou.

Bohuzel ani git repo vam nerekne co existovalo a bylo smazano - bez toho aniz by jste to explicitne prochazel po commitech.

Aha, to jsem nevěděl. Když byla odstraněna podpora TILE, tak se jich na to někdo ptal, co bude s RouterOSem na TILE CCR, a oni odpověděli, že si podporu udržují out-of-tree. Už si nepamatuji, v jaké verzi kernelu byla podpora TILE odstraněna. RouterOS 7 je postavený nad ver. 5 a tam to asi ještě je. Matně si vybavuji, že to možná bylo odstraněno až ve ver. 6.

Pokud nelze snadno (ani ve forku) udržovat out-of-tree podporu, neplyne z toho, že udržování té podpory stojí netriviální úsilí, které vývojáři mainline mohou věnovat jinam?

17. 4. 2026, 08:14 editováno autorem komentáře