Linus kukázná a i486 támogatást a Linux kernelből

Kernel

A napokban Linus utalt arra, hogy 2022 lehet az év, amikor kipics kiebrudalják a 486 támogatást a Linux kernelből:

In other words, our non-Pentium support is ACTIVELY BUGGY AND BROKEN right now.
We got rid of i386 support back in 2012. Maybe it's time to get rid of i486 support in 2022?
So I *really* don't think i486 class hardware is relevant any more. Yes, I'm sure it exists (Maciej being an example), but from a kernel development standpoint I don't think they are really relevant.

At some point, people have them as museum pieces. They might as well run museum kernels.

Részletek itt, itt és itt.

Itt az ideje!
82% (663 szavazat)
Korai még, de lassan (1-2-3 éven belül) valóban kukázható.
8% (65 szavazat)
Ne. Merjétek!
9% (76 szavazat)
Összes szavazat: 804

( Caro | 2022. 10. 29., szo – 10:10 )

5.x kernelt tettem fel 486-ra, ami nekem ment is.

De ha amúgy is bugos, teszteletlen, akkor szerintem is kuka! Korabeli géphez korabeli OS-t. P3 alatt biztosan nem próbálkoznék egy modern disztróval (persze régi disztró alá is tehető új kernel), de az összes P3 is tele van meltdown, spectre stb. problémákkal, ami miatt egy modern kernellel valószínű még inkább használhatatlan lesz.

az összes P3 is tele van meltdown, spectre stb. problémákkal,

Mióta van a processzorokban spekulatív végrehajtás? P3-ban nincs amúgy se hyperthreading, se nem multi-core, emiatt sok manapság trendi sérülékenység ott nem is értelmezett.

Spekulatív végrehajtás: Pentium Pro, 1995.

Sok helyen azt írták, hogy egészen eddig vissza is nyúlik a meltdown, de utánanéztem, a PII valóban nem tűnik érintettnek:

https://blog.stuffedcow.net/2018/05/meltdown-microarchitecture/

És egy helyen azt olvastam, hogy a P3-at sem érinti a spectre... de sok a dezinformáció sajnos. Na akkor hajrá Coppermine, hajrá Tualatin! ;)

( Botond | 2022. 10. 29., szo – 12:19 )

Szerkesztve: 2022. 10. 29., szo – 12:23

Hiányolok egy olyan opciót, hogy "5 éve kellett volna".

"At some point, people have them as museum pieces. They might as well run museum kernels."
Így van. Használjanak 5.10-et! Még 4 évig kapnak frissítést.

( carlcolt | 2022. 10. 29., szo – 12:45 )

Szerkesztve: 2022. 10. 29., szo – 12:45

Ket kerdesem van:

  1. Mennyi RAM van a legnagyobb teljesitmenyu i586-ot nem tudo de i486-ot tudo jelenleg is hasznalatban levo gepben?
  2. Mennyi RAM kell egy Linux kernel 6.0 LFS/Gentoo + Xorg + Fluxbox + init rendszer futtatasahoz?

Attol tartok, a masodik mar most nagyobb mint az elso. Ha masert nem, az aramfogyasztasuk miatt mar semmikeppen nem hasznalnak ilyen CPU-t ott, ahol van penz RAM-ra azota. Eszerint a tamogatas tok felesleges.

De, és mai napig aktívan kaphatók is ilyen embedded processzorok, pl. a Vortex86 széria, ami ráadásul valami 1Ghz-ig megy. Igaz mintha az újabb verziókban lenne támogatás az alapvető Pentium utasításokhoz is.

Szóval ez a "486 kinekkell" ez szokás szerint extrémen szűklátókörű. Azt is viccesnek tartom, hogy pl. a 486-nál korábbi Motorola 68k-kon még simán megy egy modern kernel is, igaz nem gyorsan. De megy. Meg hát, az nem egy szénné-ácskapcsolt architektúra, de ennél még fontosabb, hogy kb. senkinek nincs szem előtt ergó nincs is útban amikor a modern szemetek bugjait tákolják körbe. Szóval szegény 486 támogatás rosszkor van rossz helyen.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

m68k: aki kezdetektől fogva 32 bites, annak könnyű :)

Jó kérdés egyébként, hogy Linus mire gondolhatott a bughalmokkal, mert itt jó eséllyel nem a proci utasításkészletével lesz a probléma. Azt elvileg nagyrészt megoldja a gcc (vagy esetleg ott vannak ezzel problémák?). Meg az eredeti Pentium nagyon kevés új utasítást hozott, egyik sem tűnik nélkülözhetetlennek a kernel számára.

Sokkal inkább gyanakodnék a 486 era chipset támogatására a mai kernelekben.

Ami viszont azért fura, mert azok a chipsetek elég faékek, különösen a korai non-PCI chipsetek. A PCI chipsetes 486-osok meg soha nem voltak valami nagyon jók.

Szerk:

Elolvastam a leírást, valóban két utasítást hiányol. CMPXCHG8B és RDTSC. Előbbi "rövidebb" változata miatt kukázták a 386-ot is.

Akkori deszkák általában 8 db. 30 pines SIMM vagy 2/4 db. 72 pines SIMM foglalattal rendelkeztek. Előbbibe amúgy extrém ritka és drága, de mintha létezne 16 megás modul. Így elvileg 256 mega. Utóbbiba általában 128-at lehetett pakolni, és az még kapható is.

Ez pedig elég egy kernel, egy normális init rendszer és akár egy icewm futtatásához is. Az egyszerű dolgok ma sem nehezebbek, mint akkoriban. 32 megán bootoltam én valamelyik nem olyan nagyon régi debiant. Install után, mert az installernek kevés volt ennyi RAM.

De az egész kérdés azért irreleváns, amit a többiek is leírtak: ezeken általában már csak célszoftver fut, nem GUI. Igaz, nekik kernel frissítés sem kell talán.

Persze. Ahogy Torvalds is írja, aki még tart is ilyen 486-ot, az retró darabnak tartja, esetleg valami offline beágyazott legacy embedded ipari eszközben, egyik ilyen felhasználásra sem kell modern kernel. Ahol modern kernel kell és minimum hardvert szánnak rá, ott vesznek egy pár dolláros ARM SBC-t vagy mikrovezérlőt, abban lesz fél-egy-kettő giga RAM, már áramfogyasztásban, helyfoglalásban megéri.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( andrej_ v | 2022. 10. 29., szo – 14:01 )

Aki 486-ozik, azért az nem marad ám kernel nélkül, hiszen az 5.10-es LTS jelleggel 2026-ig támogatott. Az, hogy az új 6.x-ből kikerül, az eleve nem hiszem, hogy releváns.

( Raynes v | 2022. 10. 29., szo – 18:14 )

Kicsit a szívem fáj érte, mert nagyon jó emlékeim vannak 486-osokon, de belátom, hogy nem szabad nosztalgiával megítélni, el kell tudni engedni. Ezek a modern kernelek már túl bloatak egy 486-osnak, elmennek még rajta, de kínzóan használhatatlan sebességgel. Ha ez a kernelfejlesztőknek könnyebbség, tudnak helyette a fontosabb dolgokra koncentrálni, akkor legyen, dobják. Aki 486-ra akar unixlike rendszert, a NetBSD-vel jobban jár.

Igazából szerintem már az i586-ot is dobhatnák ugyanezen a logika mentén, de azt azért nem teszik, mert az AMD K6 sorozat is még i586-os besorolású, és abból azért a K6-2/3 majdnem P3 sebességgű, azért azon még eldöcög egy mai kernel úgy, hogy nem teljesen tökön szúrás. 10 év múlva szerintem azt is dobni fogják. Egyébként meg elméleti, mert az összes mainstream disztró évekkel ezelőtt dobta már nem csak az i386-586-ot, de már az i686-ot is, és csak x86_64-re koncentrálnak.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Olyan felkapott lett ez a bloat kifejezés, nincs topic amibe ne lenne beírva egyszer-többször. Úgy látom mindent bloat manapság, ami 17 sor assembly-nél hosszabb forrásból fordul...

Egy új/modern Linux kernelben (nem egy random komplett disztróban!) pontosan mi a bloat?

Azokat a funkciókat, amiket a múmia rendszerek/hardverek nem támogatnak, ne vegyük a bloat csoportba, mert ugye az hardver támogatás, nem felesleges, csak épp az adott régi hardverhez nem kell.

Egyébként nekem 486-osokkal (már) nincsenek nosztalgikus emlékeim, mert azokkal már szívtunk a Windows-zal, meg a rajta futó programokkal. Nem beszélve a mindent jumperekkel állítgatással, az elfogyó portokkal és IRQ lehetőségekkel, a minden apró változtatásért (de szó szerint mindenért) kötelező újraindítással, stb.
Nekem XT-AT kategória nosztalgikus, mert azok fénysebességűek voltak a Commodore gépekhez képest (számomra), és egy új világot nyitottak meg a programozási nyelvek sokaságával (a CBM Basic után értve).

Igen, ebben bűnös vagyok, hogy sokat dobálódzok ezzel a szóval, de lényegtelen, hogy hogyan hívjuk meg hogy említjük-e, mivel létező jelenség sajnos. Nem konkrétan a csak a kódsorok száma a fokmérője, a függőségek száma, libek, API-k mérete, amit az adott szoftver használ, illetve az célja és az általa nyújtott funkciók is számítanak. Persze, a kódsor se lényegtelen teljesen, egy millió kódsoros szoftver az semmiképp nem sovány.

Konkrétan a Linux kernel 30+ millió soros. Ebből persze nincs mind belefordítva egy átlag disztróba, hiszen ebben eleve több architektúra van, meg mindenféle driver és API, de azért csak az x86-os rész mindenféle extra/sallang driver nélkül is elég vaskos, és még ehhez jön mindenféle initrendszer, véletlenszámgenerátort érintő entrópianöveléstől elkezdve mindenféle biztonsági folt, azért elég durva kódtömeg. Szerencsétlen 486-os a kanyarban nincsen, hogy futtatni tudja, ha nagyon keményen fetrengünk rajta, akkor ki lehet belőle azt hozni, amit videón linkeltem, egy tty konzol is 15 percen belül bootol és percekig tölt rajta a legalapvetőbb CLI program, login, stb. is (tehát semmilyen X11-ről meg Waylandről és Gtk, stb.-ről nincs szó). Ezt lehet még soványítani embedded rendszernél egy kicsit, hogy még egyszerűbb sysvinit/suckless initrendszer, grub helyett syslinux vagy lilo, glibc helyett musl, bash helyett busybox, stb., de azért úgy se lesz valami hű de jól futtatható. Persze ezt éppeszű ember nem is várja egy 27-33 éves procitól, hogy modern OS fusson rajta. 486-os eleve nem való már linuxozásra, ha még használatban is van valahol, az valami ipari vezérlés, azt meg valami bare metal futó szoftverre oldják meg, vagy DOS-on futtatják. A 486-osoknak már egy Win95 is sok volt helyenként, de még a legkésőbbi 486-osok (AMD 5x86, Cyric 5x86, 6x86) sem jutottak el addig, hogy a Win98-at normálisan futtassák (98lite-tal kiherélve lehetséges volt rábűvészkedni használhatóra). A korabeli Linux nem ment rajtuk rosszul, de ha nagyon full extrás disztró volt, már akkor sem szárnyalt rajtuk, és a helyzet csak rosszabbodott azóta.

XT-286-os korszak nosztalgikus nálam is, bár megjegyezném, hogy újraindítgatni azt is kellett orrba-szájba. Commodore mikrókhoz képest persze, hogy dimenzióugrás volt, 8 helyett 16 bit, nagyobb memóriaméretek, nagyobb háttértárak támogatása, több utasítás és MHz a prociban, tévé helyett normális monitorkimenet, komolyabb soros/párhuzamos portos lehetőségek, komolyabb munkaalkalmazások voltak rá, egy csomó compiler, stb., engem is lenyűgözött anno. Igazából a 486-os sem volt más, csak gyorsabb, neked azért forr egybe a Windowszal, a 386-486-os korszakban már erőltették a nagy szoftvermultik a PC-k terjesztése miatt a GUI-t, OS/2, Window 1-3.x, Win9x, ebben a korszakban jöttek be a modern BSD-k első verziói (386BSD, FreeBSD, NetBSD), Linux, stb.. Korábban nem nyomták ezeket, mert a hardver túl gyenge, túl drága volt hozzá, nem válhatott tömegcikké, így meg csak egy szűk szakmaibb réteg használta, de az meg jól elvolt a konzolos, nem felhasználóbarát operációs rendszerekkel (DOS és társai).

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Megmondom mi a bloat: ha erre a sokat emlegetett 486-osra felteszel egy Win95 RTM-et és egy Office 97-et, akkor azon teljesen normális sebességgel lehet dolgozni. Az office 97 már weblekérdezéseket is tudott (nyilván a https-től megfekszik, de normál http nem okoz neki gondot).

És ez a ma használt tipikus office funkcionalitás jelentős részét hozta.

Ehhez képest próbálj meg ma egy office 2013-at elindítani akár egy P4-en. Használhatatlanul lassú lesz.

Igen, vannak annak a korszaknak is árnyoldalai. Nekem is nagyon sok energiát vett el ezeknek a vasaknak a felélesztése. Elszoktunk a félóránknént kékhalálozó win 95-win 98-tól is. Ezek nagyon arcon tudják csapni az embert, ha retrózni kezd.

De ha véletlenül minden klappol, akkor jól működik, és használható.

( rpsoft v | 2022. 10. 29., szo – 19:24 )

Halvány gőzöm sincs. Mennyi pluszmunka megtartani? Ki és mire használja?

Azt hiszem, desktopon ma már nem sok mindenre jó, egy 486-os ilyen alkalmazásra nem éri meg az általa felzabált villanyt, egy Raspberry Pi-ra kell cserélni. De lehet, hogy van valami alkalmazása (beágyazott cucc, mérésvezérlő). Azzal egyetértek, amit fent írt valaki, hogy ha gyártanak még ilyen cuccokat, akkor a gyártó beszállhatna a fejlesztésbe 1-2 programozóval vagy némi zsozsóval.

Fogyasztás szempontjából nem csak a 486-ot, hanem sok-sok generációt utána is ver.

Dupla 4k videó kimenet? H.264 hardware dekódolás? Gigabit ethernet?

Épp most kísérletezek egy Mendocino Celeron 533-al. Hiába teszek bele gigabites NIC-t, kb. csak 100 megát képes rajta átpaszírozni. Egyszerűen CPU-ból ennyi futja.

És az egy 33 W TDP-s proci. Az Rpi ennek kb. tizede, de mégis kihajtja a gigabitet. Nyilván egy mai desktop géppel szemben elhasal, de jó eséllyel még a korai P4-eket is magasan veri, töredék fogyasztással.

Itt ír Linus a technikai részletekről. Nem egészen értem, hogy az cmpxchg8b utasítás hogyan függ össze azzal az atomic 64 bit dologgal, de neki hiszek, hogy ez problémás.

Beágyazott cuccra meg nem kell a legújabb kernel.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( DirtY_iCE | 2022. 10. 29., szo – 20:33 )

Eloszor az fbcon scrollback, most ez, 1-2 ev es TPM nelkul a linux se fog elindulni mint a win11.

I hate myself, because I'm not open-source.

Lehet csak pesszimista kirohanásnak szántad, de sajnos nem jársz messze az igazságtól. Minden linuxos kedvenc főhőse, aki semmit nem változott, Lényh-arc Pöttyering pont nem rég feszegette a blogjában, hogy Linuxra is be kellene vezetni ezt a faxányos TPM / secure bootos trusted platform nyomorékságot, hogy csak aláírt initramfs-t tudjál futtatni, és saját fordítású kerneled se lehessen. Az se számít már neki, hogy a MS-nál van, továbbra is bele kell ártania magát a Linuxba, of course. Az túl egyszerű lenne, ha a továbbiakban csak a Windows usereket szivatná.

Tehát felesleges ilyeneket kívánni, meg beírni neki kívánságnak, mint Dévényi Tibi bácsinak, rajta van a csávó az ügyön, tudja, hogy mit kíván a linuxos nép. Ha Mikulással vagy a fa alá nem is érkezik meg, de jövőre az első negyedévbe beleférhet még, ha kellően erőltetett ütemben implementálják és vezetik be. Na, de mindegy, ne bántsuk, Pottering is Isten gyermeke, és ezek szerint szereti, és ez a szeretet rá is fér, mert mindenki más utálja. Joggal.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( g3rg0 | 2022. 10. 29., szo – 23:27 )

A pentium lassan 30 éves. Azért az elég sok.

Kérdés, hogy azok a régi cuccok, amikben 486 van, azokra akar-e bárki friss kernelt rakni.

Ja, Pentiummal se nagyon mennék neki ma már Linuxnak. Elméletileg LFS-t, Gentoo-t, stb. tudsz rá forgatni (modernebb gépen, de a fordítóban i586-os célt beállítva) nagy kínkeserves munkával, és használhatatlanul lassú lenne. De az i586-ot szerintem azért nem dobják, mert az AMD K6-os meg embedded Vortex/VIA CPU-s vasaknak még kell, azokon azért még, mint már írtam, elzötyög egy modern kernel. Persze ez az egész mit támogassunk nagy hűhó a semmiért, azok a disztrók, amik még támogatják egyáltalán a 32 bitet, azok is onnan indulnak, hogy i686 + PAE, azaz Pentium Pro, Pentium 2-3 és régebbi, AMD fronton meg K7 és régebbi, Pentium, Pentium MMX, AMD K6 ki is esett.

Igazából a K7, Pentium Pro, Pentium 2-3 támogatás is nagyon kérdőjeles, mert a disztró esetleg hiába is támogatja, sok szoftvernek (böngészők, médialejátszók, enkóderek, stb.) és hivatalos binárisnak már SSE2 is követelménye, szóval P4 vagy AMD K8 vagy ettől régebbi, hogy használni is tudd valamire. De ha már P4, akkor ha s775-ös, akkor már PentiumD/Core2 területen vagyunk, AMD K8 esetében is szintén, az x86_64 is játszik. Persze ezeket sem értem, hogy ki futtatná már, néhány retróst leszámítva, mert egy RPi-szintű gép is veri ezeket, töredék fogyasztással.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Itt van egy videó, hogy P1 133-ason hogyan fut egy modern, 6-os kerneles, minimalista Gentoo. Fájdalmas. 6 perc a boot, 6 perc egy viszonylag minimalista grafikus X felület (nsCDE). Leállás másfél perc. A tty konzolon egy neofetch futása is rettenet lassú, vagy egy bejelentkezés. Egy moc mp3/midi lejátszás kimaxolja a procit. Kb. semmire sem használható, böngészőt nem is érdemes ilyenen indítani. Még így is jobb, mivel újabb proci, meg 256 mega RAM, a másik videón látszott, hogy ugyanilyen rendszer 5x86 133 MHz-en (egy P1 75 MHz-nek megfelelő 486-os) 12 percig bootolt, grafikus felület teljesen felejtős volt rajta, mp3 lejátszás akadt, igaz abban csak 64 MB RAM volt, ami max. 128-ig lenne bővíthető. Persze, még ki lehetne vágni a kernelből felesleget, meg a rendszerből komponenseket, ha csak embedded rendszer lenne, de akkor is fájdalmasan lassú marad, használhatatlan kategória. Ezen már semmit nem érdemes támogatni, elment mellettük az idő.

Vannak még hasonló videók, Debian 9 egy P3-on (kimaxolva), Arch Linux egy P3-on, CrunchBang egy 400 MHz-es P2-n (512 MB RAM kimaxolva), Lubuntu 13.10 egy Dual Pentium Pro-n (1 GB RAM, meglepően jól fut, igaz ez egy 8 éves disztró, azóta bloatabbak lettek).

Nem csak a Linux, NetBSD egy 486-oson, másik 486-oson, és egy P1-esen. Kicsit reálisabb, kibírhatóbb, de sokkal minimalistább rendszer a Linuxnál, ennek ellenére rém nyögvenyelős, nem sok embernek lenne hozzá idegrendszere.

Szerk.: az se véletlen, hogy már hosszú évek óta a legtöbb ilyen 486-os gép, meg embedded eszköz 2.4 vagy 2.6-os kernelen volt megrekedve. Eleve a RAM sem szokott ezekben sok lenni, már az ki szokta zárni a kicsit is újabb kerneleket. Nem hinném, hogy ezeken bárki is akart volna valaha 5.x és 6.x kerneleket futtatni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( uid_6201 v | 2022. 10. 30., v – 13:40 )

Szerkesztve: 2022. 10. 30., v – 14:00

Eljön az idő, amikor csak x86_64 (2004) lesz támogatva, 32 bites nem. És nem a címezhető RAM miatt, hanem az architektúra fejlődése okán, amiáltal nem kell gyötrődni a régiekkel való kompatibilitással.

Sokan emlékszünk még, i386 architektúrára. Szépen futott rajta a Linux még cooprocessor nélkül is, szoftveres float emulációval. Ennél a szemaforozásra nem volt félbeszakíthatatlan CPU utasítás, global kernel lock kellett. Ez addig kevésbé volt vicces, amíg ilyesmiért a Pentium prociknál 1..2 mag lett megfogva. Aztán ahogy nőtt a magszám, látszott hogy érdemes megszabadulni a global kernel lock-tól és vele az olyan architektúráktól, amely nem támogatja az félbeszakíthatatlan szemafor utasítást.

Vajon a i486 miben korlátozhat?
x86 terén ma már tényleg nem jelentős az olyan hardver, amiben 486 fut. Ezek elvannak még sok évig az 5.x-es Linux kernellel. Már csak az egyre növekvő RAM igény miatt sem érdemes előre rohanni ezeknél a kernelverzióval, hiszen 486 esetén a 32MB EDO RAM már rengetegnek számított. Itt még 4..8 MB RAM volt a normál PC-ben, azon pedig tuti nem indul el a mostani kernel.

VIA Cyrix és hasonló beágyazott procis cuccok Pentium-kategóriák. Azokat még nem érinti az i486 kivonása.

( YleGreg | 2022. 10. 30., v – 19:21 )

Kene egy peticio, hogy mivel a Linux kernel magara hagyja szegeny artatlan 486 usereket, ezert a MS legyen szives felkarolni az ugyet, es pro bono beleheggeszteni a Windows 11 -be a tamogatast. :-)

szegeny artatlan 486 usereket

beágyazott rendszereket, műszer elektronikákat.
Bár kevésbé vicces, van még a közelemben frankó Rohde&Schwarz oszcilloszkóp+analizátor, amiben nap mint nap bootol az XP. Ezért egy sokmilliós műszert csak nem dob ki az ember.
Az mindjuk egy másik szép mese, hogy a hátulján ott van az ethernet csatlakozó, és közben a Windows frissítés meg sehol.

Igény lesz rá, ha mérési adatokat/fotókat/terveket mozgatni kell. Vagy a kezelő kezd lázadozni és szólni a felettesének, vagy már kapásból a főnök kéri, hogy érjenek el egy megosztott mappát. De ahogy volt rá példa (uráncentrifugák) bármilyen adatmozgatás kockázatos.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Nem ritkán automatizált méréseket is csinálunk, például üzemszerű áramkör tesztjei során.
Azaz nem a gombjait nyomogatjuk és a képernyőjét bámuljuk napokon keresztül, hanem mérési adatsort kívülről rákapcsolódva rendszeresen lekér egy számítógép és például saját kiértékelő szoftver, ami több műszerből származó paramétereket egyben értékeli ki.
A műszerből ekkor a kijelző helyett csak a precíz mérőképességet és az ethernet csatlakozást használjuk.

LAN-on vagyunk, de egy esetlegesen LAN-ra bekerülő fertőzés ellen védtelen a műszer. Bár, tulajdonképpen már lassan "oldtimer" védettséggel rendelkezik, hiszen az XP nem célterület.

Egyébként az, amikor nem simán PC-s szoftvered van, hanem valami eszköz része, egyre inkább ránk fog omlani ez a probléma.
  - beágyazott számítógépes, biztonsági upgrade nélküli drága eszközök. Ellenben egyre inkább etherneten lógnak.
  - másik a régi hardver és konfigszoftvere: vannak 20 éves ipari rádió adovevőink. Ha például hatósági frekvenciakijelölés-változás miatt frekvenciát kell váltani
        * keresni kell olyan vasat, ami bírja a DOS/Win98-at (SATA és hasonló kizárt)
        * ezredforduló előtti pilótavizsgás binárissal átkonfigurálni a rádiót
   És akkor a mottó picit másabb jelentéssel: a szoftver elszáll, a hardver megmarad. És a hardver tenné tovább a dolgát, ha a szoftver és futtatókörnyezetének kapcsolata nem lenne idővel problémás.

Én egyre több ilyet látok, hogy vannak ilyen 50-100-200 milliós, vagy még drágább ipari rendszerek, amiket valamilyen dzsunka PC hajt meg. Ha az ledöglik, akkor vége a dalnak. Valószínűleg itt érdemes lenne protokoll-t visszafejteni és újraírni a szoftvert, a kérdés, hogy a befektetés megtérül-e? A legtöbbször vagy a gyártónak sincs meg a forráskód, vagy ellenérdekelt abban, hogy megkapjad, inkább ruházz be újabb pár tíz-száz milliót az új gépre. Valamilyen szinten érthető az ő álláspontjuk is egyébként.

Természetesen van alternatív gyártó, lehet fizetni a présgépért, cimkézőért, mérőberendezésért vagy hasonló eszközért pár 10-100 milliót, és akkor hozzá leszel kötve. De nem csak

szoftveresen problémásak ezek, hanem hardware-esen is, egy idősebb ismerősöm konkrétan abból él, hogy ilyen régi gépeket újít fel, javít meg.

Azt azért áruljátok el nekem légyszi, hogy adva van egy XP, le vannak tiltva a távoli sz*rok mint a windows fájlmegosztás, remote assist, stb. És nem indítasz rajta böngészőt. És persze nem dugsz bele pendrive-ot.

Akkor mi a halál fogja azt az XP-t majd csak úgy megtörni??

Nyilván semmi. Lassan már netre kötve sem, mert olyan régi kernel, hogy már a mostani vírusok se tudják összefertőzni. Így teljesen jó az XP, használja egy csomó régebbi CNC, CT gép, oszcilloszkóp, mérőeszköz, amikhez a gyártó azóta se csinált drivert. A gond az XP-vel akkor van, ha valaki úgy veszi komolyan, mint hajbazer, hogy az a fő OS-e, meg azon próbálja az összes böngészését is átnyomni. Retrózni, legacy, embedded felhasználásra teljesen jó még az XP, abban a szerepkörben nem törögeti senki.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

En nem a frissites miatt aggodnek, hanem a biztonsagi mentes miatt. Nem tudom, a lemez mar SATA, vagy meg PATA? Legyen a fiokban egy csere vinyo, a gepben egy mobil fiok, es ha gebasz van  akkor power off, vinyo ki, vinyo be, power on. Aztan a hibas/virusos vinyora lehet ranyomni a gold image tartalmat. Oke, a meresi eredmenyeket erdemes mashol tarolni, de az mar messzire vezet, meg hat nem hiszem, hogy en most itt ujat mondtam. :-)

( dejo v | 2022. 10. 31., h – 06:50 )

Csak reménykedem, talán lesz olyan sub team a kernelfeljelszők között, akik miután a fő kernelkiadásból kiveszik az i486 támogatást, kidolgoznak és karbantartanak olyan patchet, szkriptet ami visszateszi azt bele.
Ha van vagy lesz rá igény és főleg, ha lesz olyan terjesztés ami az i486 támogatást meg akarja tartani, akkor az ő közreműködésükkel egy ideig még életben tartható ez a vonal is.
Én egy ideje már letettem róla, hogy ezeket a régi vasakat tutujgassam. Szerintem a 10 évnél régebbi gépeknek a múzeumban a helye vagy a nosztalgikus gyűjtőknél, amit a magamfajta öeg motorosok is megcsodálhatnak. :)

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

1. nézd meg akár VirtualBox alatt, mennyi az a legkisebb RAM mennyiség, amelyen egy 6.0-ás kernel bootolni tud minimális szöveges funkcionalitással.
2. ezután vizsgáld meg, mennyi RAM van egy ma még fellelhető i486-os processzoros eszközben.

Ebből érezni fogod az ellentmondást.

Kb. 2-3 mega körülre emlékszem egy zImage-re, amit kifejezetten 486-hoz forgattam, tehát semmi olyan nincs benne, ami modernebb hardverekhez kellene.

Az még kitömörítve is bőven belefér 16 megába. Az még nem volt szokatlan akkoriban.

A nagyobb probléma az initrd, de az meg csak az elkényelmesedés része. Nem muszáj initrd-t használni, el tud indulni a linux közvetlenül a rootfs-ről is.

Amiben van 72 pines SIMM foglalat, oda meg lazán be lehet pakolni 64-128 mega RAM-ot. Ilyenen bootoltam én tinycore-t is, ha jól emlékszem még GUI-val is.

De egy twm, icewm sem lett sokkal nehezebb mint 20 éve. Persze a GTK/Qt fronton más a helyzet.