Linus Torvalds wil Linux-kernelondersteuning voor i486-processors stopzetten

Linux-hoofdontwikkelaar Linus Torvalds overweegt ondersteuning voor oudere i486-processors uit de Linux-kernel te halen. Hij noemt de hardware irrelevant en vindt dat het te veel werk is om het bij te houden.

Torvalds noemt zijn zorgen in een mailwisseling met andere ontwikkelaars van de Linux-kernel. De Linux-oprichter zegt daarin dat hij 'niet denkt dat de i486-class nog relevant is'. Het gaat specifiek om ondersteuning voor oude Intel-processors met een i486-architectuur. Processors die daarop draaien werden voor het eerst geïntroduceerd in 1989, maar volgens een aantal kernelontwikkelaars zijn er in de afgelopen jaren nog verschillende stukken hardware uitgebracht die daarop draaien. Torvalds zegt dat daar dusdanig weinig voorbeelden van zijn dat hij de ondersteuning wil stopzetten. "We hebben i386-ondersteuning stopgezet in 2012. Is het in 2022 dan geen tijd dat te doen voor i486?" vraagt hij zich af.

Het is niet de eerste keer dat het voorstel wordt gedaan. Dat gebeurde een jaar eerder ook al, maar toen waren er nog ontwikkelaars die zich daar tegen uitspraken. Torvalds zegt dat er 'vanuit een kernelontwikkelaarsperspectief' geen relevante reden is om door te gaan met de ondersteuning. Hij schrijft in een andere e-mail dat het veel tijd en werk kost om de hardware te blijven ondersteunen. Niet alleen zou er amper meer dergelijke hardware zijn die Linux nog kan draaien, maar de code werkt vaak ook niet meer.

Reacties (165)

[thomas_n]

Ik kan me inderdaad niet voorstellen dat er nog i486-machines draaien waar het belangrijk voor is een up-to-date kernel te hebben. De machines die er nog zijn zullen, neem ik aan, niet verbonden zijn met het internet of met de allernieuwste randapparatuur. Die kunnen dan prima op een oude kernel blijven draaien.

[szjoin]

En toch zou het me niet verbazen dat bijvoorbeeld de Belastingdienst / diverse oorlosschepen/onderzeëers /overige kritische systemen hierdoor geraakt gaan worden. Maar dat is slechts een onderbuikgevoel...

[yabatopia]

diverse oorlosschepen/onderzeëers

Je kan je natuurlijk afvragen of het de taak van de openbrongemeenschap is om de goede werking van oude oorlogsschepen en onderzeeërs kosteloos te blijven ondersteunen - en er nog veel tijd in te steken. Er is meer dan voldoende geld in de militaire industrie dat ze wel een aantal ontwikkelaars kunnen veroorloven die hun systemen veilig houden. Idem voor de belastingsdienst.

[Killemov]

Geen onderbuikgevoel maar hoogstwaarschijnlijk. Er zijn ook zeker systemen bij diverse overheden die nog steeds draaien op MS-DOS met applicaties waarvan de broncode verloren is gegaan. Of met specifieke hardware die alleen drivers voor MS-DOS heeft. Dus Linus kan wel verder willen, maar een hoop bedrijven kunnen dat niet. (Tenzij herontwikkeling ...)

[VNA9216]

Al denk ik dat het voor dat soort systemen waarschijnlijker is dat ze DOS draaien dan wat toendertijd bij ingebruikname van 486 tijdperk systemen een klein hobby OS was dat nog in de kinderschoenen stond, en waar relatief weinig mensen bekend mee waren. Ik heb zo mn twijfels dat er erg veel belangrijke systemen uit die tijd linux draaien, en daar bovenop ook nog eens geen software updates krijgen en dus geen mogelijkheid hebben om het over te zetten naar modernere hardware, maar wel kernel updates krijgen en hier dus iets van zullen merken.

Aan de andere kant snap ik ook niet helemaal hoe de community dingen beoordeelt, een PC platform als de 486 niet meer willen ondersteunen, maar een jaar of 2 geleden wel Nintendo 64 ondersteuning hebben toegevoegd, want er zullen vast een hoop mensen linux op hun N64 draaien

[Killemov]

Van oude Linux-systemen weet ik eigenlijk maar 1 voorbeeld en de rest is inderdaad DOS. Het staat me bij dat het wel een cruciaal/real-time systeem was ... anders hadden ze het wel op DOS laten lopen.

[itaalol]

Ik vind dat die bedrijven blunders hebben gemaakt als je tegenwoordig nog op zo'n sterk verouderde applicaties oid draait. VOORAL als het bijvoorbeeld een overheidsinstantie is.

Kijkende naar Defensie, vind ik het dan weer niet heel raar omdat hun materieel vaak tientallen jaren oud is. In de zorg wordt er bijvoorbeeld ook nog heel veel met oude technieken gedaan, com poorten zijn hier bijvoorbeeld nog steeds heel veel in gebruik.

[jhhest]

Als het op een eigen netwerk draait, en maar 1 specifieke taak doet.. Wat maakt het uit.

Het wordt eerder een probleem als het apparaat kapot gaat en er zijn betrouwbare onderdelen meer voor te vinden.

[itaalol]

De vraag is wil je dat riskeren als organisatie. Of meer investeren in ontwikkelen door de jaren heen of nihil investeren en hopen dat niets omkiept met als gevolg een schade post waar je u tegen zegt.

[B_FORCE]

Ik niet, maar zoiets hangt sterk af van de context.

Maar er zijn bv machines die nog echt prima werken, zeer specifiek ontwikkeld zijn en dan ook zoveel of meer kosten dan een gemiddelde vrijstaande gezinswoning.

Dat niet alleen, maar bij het vervangen van de machine moet het totale proces en software veranderd worden (als dat al kan!) en zal in veel gevallen de boel voor een geruime tijd stilliggen.
Kosten lopen dan gauw al heel snel op.

Dat allemaal omdat evt enkel een processor oud is?

Ik vind het ook een raar verhaal icm recycling en duurzaamheid.
En nee, tov de machines valt het energieverbruik van de computer in het niet. (Hoewel veel dedicated i486 machines helemaal niet zo onzuinig zijn)

[Reactie gewijzigd door B_FORCE op 2 augustus 2024 07:53]

[itaalol]

In die context ben ik het volledig met je eens maar mag ik zeggen dat je dan kijkt naar een case van een commercieel bedrijf. Dan begrijp ik het volkomen.

Als je kijkt naar overheidsinstanties vind ik het te gek voor woorden a) ze hebben niet als doel zoveel mogelijk winst te behalen tegen zo laag mogelijke kosten en b) hier wordt gebruik gemaakt van persoonsgegevens van miljoenen mensen. Nee oud betekend niet meteen onveilig maar je begrijpt mijn punt hopelijk wel.

Je kan als bedrijf er ook voor kiezen meer "met de tijd mee te gaan" en meer te investeren in ontwikkeling, maar dan komt het stukje winst weer kijken...

[GeroldM]

Specifieke label printers hebben vaak nog een COM poort. Routers en switches (netwerk apparatuur) hebben ook nog altijd deze COM poorten, want deze zijn bijzonder betrouwbaar. Voor sommige toepassingen is dat belangrijker dan snelheid en/of gemak.

[itaalol]

Dat is dan een onderdeel wat gebruik maakt van bewezen technieken in combinatie met doorontwikkelde software o.i.d. Dan is het begrijpelijk, zoals je zegt, in het ziekenhuis willen ze up-time, geen mooi fancy connectortje.

[CAPSLOCK2000]

Ik vind dat die bedrijven blunders hebben gemaakt als je tegenwoordig nog op zo'n sterk verouderde applicaties oid draait. VOORAL als het bijvoorbeeld een overheidsinstantie is.

Ik ook, ook al snap ik wel waarom ze blunderen want het is verschrikkelijk moeilijk en duur om rekening te houden met de toekomst. De echt lastige vraag is of het goedkoper is om rekening te houden met de toekomst (dan moet je alles vooraf goed doen) of met het verleden (dan moet je achteraf terug gaan om de problemen op te lossen). In beide gevallen heb je veel flexibiliteit nodig en dat maakt software snel moeilijker en duurder.

Hoewel ik het snap is mijn sympathie ervoor wel een beetje op. We leven nu lang genoeg met computers en netwerken dat we nu beter zouden moeten weten. Helaas is het nogal het land van de blinden en de doven. Professionele IT'ers zouden daar rekening mee moeten houden en voorzien dat hun spullen 30 jaar of meer mee moeten en dat je dus de mogelijkheid moet hebben om stukken te vernieuwen/vervangen.
Helaas zijn er veel te weinig goed opgeleide IT'ers en zit het vak vol met hobbyisten, zij-instromers en generalisten die de lessen uit het verleden nooit geleerd hebben.

Niet alleen bij de aanbieders maar ook bij de klanten die dus niet eens weten wat ze moeten vragen of wat dat zou moeten kosten. Daardoor wordt er steeds weer gekozen voor software die eigenlijk onder de maat is omdat de goede software veel te duur lijkt. Uiteraard is dat een vorm van "technical debt" die later bij je terugkomt met rente. Dat is meestal te duur want al het geld is al uitgegeven aan de aanschaf van de software.

[itaalol]

Er wordt inderdaad meestal gekeken naar hoe duur het allemaal wel niet is en vervolgens wordt er door een aantal managers die nul IT kennis hebben besloten "geen geld daar aan te verspillen want het draait toch nog?".

Ik heb me wel eens afgevraagd of daar nu niet de fout in de hele denkwijze zit. Kijken naar de toekomst of het verleden en niet naar het heden. Klinkt vrij filosofisch allemaal maar als bedrijf (het gemiddelde bedrijf) hoef je nu ook weer niet altijd het nieuwste van het nieuwste te hebben op het gebied van IT, vaak neemt dit ook weer allerlei issues met zich mee. Denk dat een voorbeeld de cloud is; in plaats van meteen de cloud in willen zodra je er de eerste keer van gehoord hebt eerst een paar jaar wachten, dan inventarissen of dit de oplossing is of dat bijvoorbeeld een hybride oplossing werkt.

IT binnen onze organisatie is nu de transitie naar de cloud begonnen, er draaien een aantal applicaties inmiddels in de cloud en over een paar jaar willen we het gros van wat nu on premises draait in de cloud hebben. Klinkt van de ene kant mooi, en van de andere kant hebben we bijvoorbeeld ook een bedrijfskritieke applicatie draaien op een database die inmiddels ook al uit de extended support is met een framework dat end of life is en dus naar .NET (onze keuze) omgeschreven moet worden. Dit was zo'n gevalletje "het draait toch gewoon?".

Daar heb ik eigenlijk helemaal nog niet over nagedacht maar nu je het zegt ben ik het volkomen met je eens! Een zij-instromer of hobbyist kunnen best hun functie heel goed uitoefenen maar ze denken niet verder, houden over het algemeen geen rekening met alles er om heen. Wat natuurlijk logisch is want dat hebben ze nooit echt geleerd.

En er dan maar 10 jaar aan vast blijven houden omdat het al zoveel gekost heeft en er simpelweg geen geld meer is om toch een keer naar die IT'ers te luisteren

[Reactie gewijzigd door itaalol op 2 augustus 2024 07:53]

[gimbal]

Meestal gevolgen van blunders uit het verleden - bedrijfskritische software laten ontwikkelen waar je geen controle over hebt en waarschijnlijk de specificaties niet van hebt. Dat is een tikkende tijdbom.

De kosten die je nu bespaart door voor optie gemakzucht te gaan zijn de kosten die je meervoudig gaat maken in de toekomst. Maar ja - dat is een ander budget en het probleem van iemand anders.

[itaalol]

Precies dit ja! Ik vind dat nog steeds zo ontzettend vaak op de korte termijn gedacht wordt. Lekker wat centjes besparen maar niet realiseren dat wanneer iets omkiept je zo'n enorme kostenpost hebt waar je mogelijk nooit meer uit komt.

[blorf]

Volgens mij is het niet realistisch. Wat zou een dergelijke 486 met Linux precies moeten doen? Als je nu een SoC van 20 euro koopt kun je gewoon DOS emuleren en de communicatielijnen vervangen met virtuele versies. Veel meer dan dat ga je er niet van nodig hebben, Een 486 is een grap voor zo'n ding.

[Reactie gewijzigd door blorf op 2 augustus 2024 07:53]

[Killemov]

Volgens mij is het niet realistisch.

Wat EXACT is volgens jou niet realistisch? (Aangetroffen bij Rijkswaterstaat ...)

Wat zou een dergelijke 486 met Linux precies moeten doen? Als je nu een SoC van 20 euro koopt kun je gewoon DOS emuleren en de communicatielijnen vervangen met virtuele versies. Veel meer dan dat ga je er niet van nodig hebben, Een 486 is een grap voor zo'n ding.

Voor een klein gedeelte KAN het, maar gebeurt het niet totdat er geen compatibele hardware (MOBOs/Procs/...) kan worden ingezet. En verder veel succes met het emuleren van een ISA-kaart die costum-made is voor RWS en met andere hardware moet communiceren. Dus zeer kort door de bocht: Als een moederbord faalt, dan kan een dienst van de overheid er (tijdelijk) mee ophouden.

[blorf]

Wat exact niet realistisch is, is een situatie waarin een 486, of AT in het geheel daadwerkelijk een vereiste is voor een bepaald systeem om te functioneren. Waar heb je het over|? Data over de seriele poort of een coax-NIC? Beide geen partij voor moderne elektronica.

[Killemov]

Waar heb je het over|? Data over de seriele poort of een coax-NIC? Beide geen partij voor moderne elektronica.

Zelfs DAT is dus vaak onbekend. Bijvoorbeeld iets dat lijkt op een seriële port, compleet anders bedraad is en waar geen documentatie meer van is te vinden. Maar het systeem mag niet down om het te onderzoeken. Succes ermee!

[arjandijk162]

Maar in die context is het updaten naar de laatste Linux compleet irrelevant toch? Of wil je zeggen dat die 25 jaar oude systemen op alle gebieden op to date zijn behalve de cpu? Ik ken oude systemen in werking, maar die draaien al 30 jaar op dezelfde software

[Menesis]

Maar worden dat soort "don't touch it" systemen dan wel geupdate met een nieuwe versie van Linux? Dat is dan toch ook risky?

[blorf]

Bij Rijkswaterstaat? Ze gebruiken een protocol voor keersluizen dat gemaakt is door iemand die nergens meer is te bekennen, en het lukt ook niemand om de serial port baud-rate, parity en codetabel-settings te raden.

[Zezura]

Dat kan je toch reverse engineren.
Al is dat niet zo makkelijk..

[Houtenklaas]

De bitrate (baud is wat anders), parity en aantal databits is kipsimpel met een scope af te lezen. En als je die weet is de codetabel ook niet zo'n geheim meer. En ik ben gewoon hier hoor.

[blorf]

Bij TTL-verbindingen is baud van toepassing. Geen idee waarom, maar de configuratie vereist dat altijd. Van 2400 naar 56K6. Misschien omdat het technisch in het verlengde lag van een modemverbinding, oftewel null-modem. Het draadje is alleen zo kort dat er niks gemoduleerd hoeft te worden. De schakelstroom op de lijn houdt het uit over wat meters.

[Reactie gewijzigd door blorf op 2 augustus 2024 07:53]

[blorf]

Met een scope af te lezen? Niet dat ik dat ooit gebruik, maar dat moet dan wel een behoorlijk slim systeem zijn die snapt wat je zoekt. Hoe wil je een byte die sequentieel over 1 draad gaat in een fractie van een milliseconde weergeven? Misschien met een soort record-optie waarmee je een bepaald tijdsinterval in een hoge frequentie kan registreren en teruglezen.

[Reactie gewijzigd door blorf op 2 augustus 2024 07:53]

[mtak]

De meeste hobby scopes kunnen dit makkelijk tegenwoordig en het real-time decoderen van seriële data is ook vaak een (licentie)optie. Ook die fractie van een seconde valt wel mee. De nyquist frequentie van 9600 baud is ~19KHz. De goedkope hobby scopes hebben al bandbreedtes van 50-100MHz. Dus de scope kan 3 ordes van grootte (1000x) sneller samplen dan nodig is om een 9600 baud signaal uit te lezen.

Voorbeeld: Siglent SDS1202X-E (410 euro) kan I2C, SPI, UART/RS232 en CANbus decoderen met een maximale bandbreedte van 200MHz, op twee kanalen tegelijk. Ik denk dat RWS wel 400 euro aan het budget kan toevoegen

En natuurlijk kan, zelfs met een goedkope scope, de data opgenomen worden en weggeschreven worden naar een USB stick.

[Reactie gewijzigd door mtak op 2 augustus 2024 07:53]

[blorf]

Als er gewoon een controller bij in zit is het geen probleem, maar je hele setup afstellen zodat je een niet gespecificeerde datalink wil kunnen onderscheppen en leesbaar maken heb je denk ik wel een uitdaging. In het geval van 'AT' UART zijn dat blokjes van 5V/2mA. Dan moet je nog steeds iets hebben om de input over een bepaalde tijd op te slaan en dan inzoomen om te ontcijferen vanuit binair.

[Heidistein]

maarmaar, met een oscilloscoop en veul prutsen/nadenken/rekenen kom je echt heel ver! been there, done that. Kostte wel twee dagen om er achter te komen dat het signaal inverted was. Weer omgekeerd, en presto! Letters!
Maargoed, als de codetabel dan inderdaad iets willekeurigs uit het oostblok is

[Killemov]

O.a. . Maar bedankt voor het maken van mijn punt. ( ... en jezelf verbeteren?)

[blorf]

Het was ook heel serieus.Natuurlijk heb je talloze van dergelijke situaties, met name bij overheidstakken.

[vliegendekat]

Voor een klein gedeelte KAN het, maar gebeurt het niet totdat er geen compatibele hardware (MOBOs/Procs/...) kan worden ingezet. En verder veel succes met het emuleren van een ISA-kaart die costum-made is voor RWS en met andere hardware moet communiceren. Dus zeer kort door de bocht: Als een moederbord faalt, dan kan een dienst van de overheid er (tijdelijk) mee ophouden.

Men kan er altijd voor kiezen om een oudere versie van de kernel te blijven draaien en er een extra laag security voor te leggen.

Maar als RWS nog werkt met ISA-kaarten dan is het tijd dat ze daar eens gaan vernieuwen.

[x280]

Succes met je roltrap, slagboom, lift, pin automaat en alle andere apparaten die jaren geleden zijn ontwikkeld en waar nog steeds een heel oud "systeem" in zit.

[blorf]

Een RPI-zero met een RS-232C-kabel... Die roltrap gaat niet kijken of er wel echt een 486 aan de andere kant van de lijn zit.

[x280]

Juist, heeft die ook 400 I/O poorten ? Nee, koeienmelk robot heeft bijvoorbeeld meer dan 10x rs-232.

[blorf]

Een 486 heeft normaalgesproken maar 4 hardwired com-poorten, waarvan meestal 2 ook een fysieke poort hebben. Dus een dergelijke machine ga je daar niet direct mee aansturen. Dat vereist speciale hardware.

[x280]

Precies dat ! Die speciale hardware gaan ze niet even opnieuw maken want meestal weet niemand meer hoe het echt in elkaar zit.

Zo nu en dan wordt er wel een software update gedaan als het echt nodig is.

[vliegendekat]

Die systemen hebben doorgaans geen updates nodig.
Die moet je vooral niet aan het internet vastknopen en als ze draaien, vooral laten draaien.

In de praktijk zal er echter geen i486 architectuur in zitten, want die is niet stabiel genoeg voor dergelijke toepassingen.

Wat er meestal wel in zit is een PLC op basis van vaak een custom PLC van een bepaalde fabrikant.

[SCS2]

Maar, als zoiets al 30 jaar feilloos werkt met een oude Linux versie...
Waarom zou het dan updaten?
Misschien blijft het ongewijzigd gewoon nog decennia draaien.
De "nieuwe functies" worden toch niet gebruikt.

Of hangen ze online?

[Killemov]

Hey! Iemand die wel de realiteit ziet!

[Bazz0847]

Toch zijn ISA-kaarten briljant voor procesbesturing: je kunt de IO direct addresseren vanuit de CPU.

De oude 8-bit kaarten hadden 20 adresbits en 8 databits, en je kunt je kaart naar meerdere adressen laten luisteren. Je kunt zelfs interrupts van de CPU vragen via interrupt-request pinnen (IRQ). Je kent het vast nog van de oude ISA geluidskaarten:
"SET BLASTER A220 I5 D1" --> kaart luistert naar adresbits code 11011100, biedt interrupts aan op pin 5, en schrijft/leest RAM via DMA kanaal 1. Dat zijn letterlijk de pinnen op de ISA-interface, dus je zit heel dicht op de hardware te werken. Ook zijn +12V, +5V en -12V beschikbaar, dus je kunt perfect analoge ingangen/uitgangen maken.

Je kunt hiermee ontzettend eenvoudig een ISA-kaart maken met heel veel digitale en analoge IO (dmv multiplexers) en deze direct in je software addresseren en met de PC bedienen. Simpeler en robuuster dan dit wordt het niet, dus perfect voor kritieke processen. Er zijn ook nog steeds ISA-kaarten te koop voor dit doeleinde (in geval je ze niet zelf wil maken, wat echt kinderspel is). Ga daar maar eens een vervanger voor ontwikkelen, dan moet je met Windows-drivers en PCI-E aan de slag en lever je zeker robuustheid in.

[Reactie gewijzigd door Bazz0847 op 2 augustus 2024 07:53]

[vliegendekat]

Daar bestaan tegenwoordig microcontrollers voor met meer dan 8 keer de snelheid van een i486.
Zeker voor kritieke procesbesturing wilt u graag een losse chip waarop een realtime OS of zelfs helemaal geen OS (en dus bare-metal-code) draait. Ook kunt u kiezen voor een kant en klare PLC waar alle gevalideerde logica en certificeringen al op zitten.
De ISA-kaarten waren dus leuk speelgoed, maar zijn inmiddels oude achterhaalde troep.

En denk erom: Windows is geen realtime OS en daardoor niet geschikt voor kritieke procesbesturing. Mocht u denken van wel, dan wordt u direct uitgelachen en weggedragen door iedereen die ook maar iets van industriële automatisering en/of procescontrole weet. Daarnaast gaat het hier over Linux en niet over Windows.

[svennd]

Dan is het wel tijd dat daar een update voor komt binnen die vereisten, als emulatie het niet kan opvangen dan is dat minstens al 10 jaar een legacy probleem die wacht op een oplossing. Een stevige stroomstoot kan je werking als bedrijf (of overheid) dan al doen omvallen ...

[Killemov]

Yup. Het werk toch al 30+ jaar? Waarom er nu middelen in steken als we toch in crisismode iets nieuws kunnen laten ontwikkelen?

[dasiro]

goed IT-governance om risico's af te kunnen dekken

(bij een overheidsdienst )

[synoniem]

Je hebt het wel over een specifiek onderdeel van RWS wat deze oude meuk nog in gebruik heeft en de mentaliteit heeft van het werkt al 20 jaar zo dus het zal nog 20 jaar zo werken.

[wiezalditzijn]

Is het ook niet tijd voor die bedrijven een update te doen. Ook vanuit veiligheid perspectief

[PageFault]

Hangt af wat de betrokken computer doet. Een niet nader te noemen vliegveld rondom Parijs heeft in 2016 Windows 3.11 uitgefaseerd. Heel veel mensen vonden dat zo gek, ik snap het wel. Daar hing gewoon het radar aan, die vervang je niet zo effe voor een appel en een ei. Zolang dat systeem nooit internet gekoppeld is, zijn de intrusion risico's heel beperkt. Zodra de hardware uit zou vallen, hadden ze sowieso een dik probleem.

[bwerg]

Die systemen zijn er vast wel maar ik neem aan dat die systemen niet elke week updates binnentrekken... Niets belet een gebruiker van het installeren van de huidige versie. Of die van 10 jaar geleden. Die oude versies verdwijnen niet zomaar.

[Creesch]

Aanvullend op wat @bwerg al noemt, dit soort systemen zijn zeer waarschijnlijk niet aangesloten op netwerken of iig een airgapped van het internet i.v.m. security redenen. Daarnaast is het zeer onwaarschijnlijk dat deze applicaties nog verder worden ontwikkeld. Als dat al wel het geval is dan zal het gaan om ontwikkeling van de applicatie zelf waar het besturingsysteem relatief statisch is en er dus ook geen kernel updates nodig zijn.

[Timoo.vanEsch]

OK. Maar wat heeft MS-DOS te maken met Linux?
Als die systemen nu nog draaien op MS-DOS, is daar toch geen Linux voor nodig?

[MacPoedel]

Oké maar dat is dus MS-DOS, niet Linux.

[2green]

Daarom zei hij 'ook'. Hij doelde erop dat daar dan 'ook" 486 systemen kunnen draaien.

[Reactie gewijzigd door 2green op 2 augustus 2024 07:53]

[PrimusIP]

Ik denk dat als die partijen software hebben die dergelijke systemen nodig hebben, dat die software ook MS DOS nodig heeft. En dan een versie uit die tijd. Ik betwijfel dat die software om kan gaan met een nieuwe Linux.

[Verwijderd]

Je kunt de software gewoon schrijven met een oude kernel. Ik zie het probleem niet. Je wilt een te trage computer niet echt aan het internet hangen, of met een telefoonmodem p2p verbinden

[akooijman]

Maar als een overheid antieke code heeft draaien is dat niet het probleem van Linus.

[Scriptkid]

Je vergeet de belangrijkste en minst aangepaste systemen ,

Kernreactoren,

Deze zijn vaak 20-50 jaar oud en draaien nogsteeds op de systemen waarmee ze gekomen zijn en niemand durft ze echte te upgraden omdat de interfaces er simple weg niet voor zijn.

[Timoo.vanEsch]

Nogmaals: Draaien die op Linux dan?

[Scriptkid]

geen idee, claim ik dat ergens dan,

ikzeg alleen dat veel oude hardware in die systemen zit en vaak 386/486 systemen in support bij een nederlandse vendor liggen.

[hound]

Wat is er veranderd aan de reactor en alle systemen eromheen dat een kernelupdate noodzakelijk maakt?

Dit lijkt me juist bij uitstek een case waarbij kernelupdates (bijna) geen rol spelen...

[svennd]

Maar die kregen al helemaal geen updates ook dus dat is nu niet echt een groot probleem toch ?

[RRRobert]

En toch zou het me niet verbazen dat bijvoorbeeld de Belastingdienst / diverse oorlosschepen/onderzeëers /overige kritische systemen hierdoor geraakt gaan worden. Maar dat is slechts een onderbuikgevoel...

ik ken een bedrijf wat fruitsorteersystemen bouwt, waarbij elke passerend stuk fruit gemiddeld acht keer wordt gefotografeerd en op basis van die foto's wordt doorgelaten of uitgeduwd. Die software daarvoor draaide lange, lange tijd op MS-DOS, en later op FreeDOS, om de simpele reden dat ze deze software niet goed aan het werk kregen op allerlei (nieuwere) Windows- en Linux versies.

Is inmiddels al wel weer behoorlijk wat jaren geleden; of ze hier inmiddels al een oplossing voor hebben durf ik niet te zeggen, want ik heb er al een aantal jaren geen contact meer mee. Maar je ziet, soms zijn dit soort verouderde applicaties en besturingssystemen nog verrassend actueel. Datzelfde geldt vaak ook voor oude SoC's en processors; die technologie wordt nog vaak als (inmiddels) spotgoedkope technologie in apparaten toegepast die ver afstaat van de hardware waar ze vele jaren daarvoor waren ontworpen.

[Keypunchie]

In dit (Linux) geval heb je geen patches meer, so what? Dat DOS krijgt ook al een tijdje geen updates meer.

Overigens: als dat zo'n belangrijke toepassing is, dan is het gewoon een kwestie van een nieuwe softwareleverancier. Maar het klinkt alsof ze niet willen betalen voor onderhoud/modernisering van de software.

Nou prima, dan blijven ze lekker doordraaien op oude versies, maar dit is echt geen raketwetenschap hoor.

De keuze dat het mogelijk op termijn in elkaar stort en dat er dan een tijdje veel geld moet worden uitgegeven om handmatig fruit te sorteren/slechtere kwaliteit fruit doorheen komt hebben ze dan blijkbaar als risico geaccepteerd.

[RRRobert]

Dat bedrijf waar ik naar verwees, heeft die software zelf ontwikkeld. Het is dus niet een kwestie van niet willen betalen of onderhouden

[Keypunchie]

Tsja. Respect voor een fruitboer dat ze zelf software ontwikkelen. (en dan heb ik het niet over dat fruitbedrijf in Cupertino)

Maar als je je eigen software niet van DOS naar een moderner OS hebt kunnen porten, dan heb je in principe alleen maar een kennis-uitdaging.

Er is niets dat DOS kan, dat je niet op een moderner OS kunt. Dus tenzij het om drivers gaat van de camera's (en daar dus geen ondersteuning voor is), blijf ik bij me stelling: dit is de goedkope aanpak (en dat is prima) en de bijbehorende risico's, die moet je maar accepteren (en dat is ook te verdedigen).

[Timoo.vanEsch]

Je geeft in je eigen reactie al aan waarom Linux geen 486 meer hoeft te ondersteunen?

[Keypunchie]

Waarom dan? Je kunt toch prima een oud OS op een oud stuk hardware draaien?

Patching doe je vooral om beveiligingsredenen. Zulke legacy systemen moet je dan maar op andere manieren goed afschermen (geïsoleerd netwerk) en het risico van de lekken accepteren.

[Reactie gewijzigd door Keypunchie op 2 augustus 2024 07:53]

[CAPSLOCK2000]

Waarom dan? Je kunt toch prima een oud OS op een oud stuk hardware draaien?

Patching doe je vooral om beveiligingsredenen. Zulke legacy systemen moet je dan maar op andere manieren goed afschermen (geïsoleerd netwerk) en het risico van de lekken accepteren.

Op zo'n oude systemen zal de kernel niet het grootste probleem zijn. De applicaties die er op draaien zijn waarschijnlijk veel erger, wat security betreft. Daar werd in die tijd eigenlijk nog niet over nagedacht, in ieder geval niet op de manier waarop we nu doen. Toen was security er vooral om foutjes te voorkomen, niet om de maffia buiten te houden.

Zelfs als de software 10 jaar nieuwer is dan de CPU dan blijft het problematisch want als er toen al encryptie was dan is die niet meer geschikt voor het hedendaagse internet. Waarschijnlijk lukt het moderne clients niet eens om er mee te spreken, die oude encryptie-algoritmes zijn al weer verwijderd.

Dit soort oude systemen hebben één groot voordeel ten opzichte van nieuwere hardware: ze zijn langzaam!
Als er iets mis gaat, dan gaat het langzaam mis en heb je misschien nog tijd om te reageren.
Met een HD van 100MB en een netwerkkaart van 10mbit lukt het je niet om meer dan 1MB per seconde te "lekken". Tegenwoordig weten we dat flink op te krikken door het on-the-fly te comprimeren maar een CPU van toen was daar niet snel genoeg voor.

Dat gezegd hebbende, als het om kale tekst gaat dan is 1 MB ook al veel data, daar kun je de persoonsgegevens van duizenden mensen in kwijt.

[dog4life]

[...]
Dit soort oude systemen hebben één groot voordeel ten opzichte van nieuwere hardware: ze zijn langzaam!
Als er iets mis gaat, dan gaat het langzaam mis en heb je misschien nog tijd om te reageren.
Met een HD van 100MB en een netwerkkaart van 10mbit lukt het je niet om meer dan 1MB per seconde te "lekken". Tegenwoordig weten we dat flink op te krikken door het on-the-fly te comprimeren maar een CPU van toen was daar niet snel genoeg voor.

Dan is in iets meer dan anderhalve minuut je hele systeem gelekt - dat vind ik toch best snel.

En destijds werd er wel degelijk gebruik gemaakt van compressie, pkzip, arj, zelfs doublespace&stacker. Sjees wat ben ik oud, dat heb ik allemaal op mn 486 gebruikt.

[kdekker]

Ik moest wel grinniken om je reactie, vooral double space (op een 20MB harde schijf, maar dat was nog royaal voor de 486).

[DeDooieVent]

Ook nog steeds spijt dat je nooit een zipdiskdrive hebt aangeschaft?

[Cergorach]

Ik zie een aantal opties:
#1 Inderdaad een oudere Linux kernel draaien zonder beveiligingsupdates en je systemen niet aan een netwerk hangen of dat netwerk moet fysiek zo enorm goed zijn afgeschermd...
#2 Zelf de beveiligingsupdates gaan produceren voor de oudere Linux kernel(s).

Intel hield al lang geleden op met het produceren van 486 CPUs, maar blijkt nog relatief lang dit te hebben gebruikt in embedded systems (max 2009). Afhankelijk van de leverancier en hoe groep diens voorraad was, zouden er best nog (embeded)systemen geleverd kunnen zijn in de afgelopen 10 jaar...

Zoals @Cilph al aangeeft, hoeveel bedrijven zijn dat die dat nog actief gebruiken, ondersteund worden door de leverancier en überhaupt nog gepatched worden. Ik vermoed ook niet veel, maar waar dat wel nog gebeurd zou ik verwachten dat het behoorlijk kritisch is en over het algemeen vrij kostbaar/risicovol om zomaar te vervangen door iets moderns. In een aantal gevallen zal het goedkoper en minder risicovol zijn om het toch te vervangen dan zelf beveiligingsupdates te gaan schrijven... Dan blijf je zitten met een klein groepje bedrijven/mensen die de 'klos' zijn. Maar is Linus T. en de rest van de Linux community verantwoordelijk voor? Ik denk het niet. Maar wat ik wel denk is dat daar van te voren duidelijk guidelines over horen te zijn, we ondersteunen 486 x aantal jaar, ze kunnen er later altijd nog voor kiezen om het toch nog langer te ondersteunen...

Bron:
https://www.wikiwand.com/en/I486

[[Shadow]]

Zou inderdaad kunnen. Echter, ten tijde van de 80486, was Linux nog in een vroeger stadium en werd het nog niet breed ingezet in missiekritische systemen. Toen werd er meer gekeken naar Unix implementaties zoals Sun/Solaris .

[blorf]

Op PC's? Ooit eens Solaris gedraaid toen Sun net was genomen door Oracle. Dat was een behoorlijk zware jongen, ga je enk ik niet op een 486 proberen. En de originele Sun hardware was voor zover ik weet geen i386 32-bit...

[beerse]

Volgens mij is SunOS ooit wel beschikbaar geweest voor de 486. Op https://en.wikipedia.org/wiki/SunOS staat dat er zelfs een SunOS voor de i386 is geweest (https://en.wikipedia.org/wiki/Sun386i). Dat was in de tijd dat SunOS nog beschikbaar was op een wat breder assortiment aan hardware zoals ook voor de 68000. Toegegeven: dat is (net) voor mijn tijd...

[Reactie gewijzigd door beerse op 2 augustus 2024 07:53]

[synoniem]

Ik heb inderdaad nog gewerkt met SunOS op een i386 maar het merendeel van de systemen draaide toen ook al op een SPARC processor. De i386 werd vooral gebruikt als fileserver (3Com LANMAN) omdat er meer en grotere schijven in paste dan in de workstations.

[sympa]

Sun386i was een one off systeem. Bij mijn weten SunOS (bsd based). Later kwam Solaris uit voor x86, dat was de System V gebaseerde generatie.

[PageFault]

Nee, die hadden de SPARC CPU's, die zijn heel anders.

[[Shadow]]

Ik bedoel hem andersom. Op missie kritische systemen werd nog geen Linux gebruikt, maar Unix. Los van wel of niet 486. Solaris draaide toen nog vooral op (ultra)sparcs

[kdekker]

Klopt, ik zag (enterprise) Linux ergens pas na ca 2007 (als ik me goed herinner, kan ook zo nog een aantal jaren later geweest zijn), bijv SuSe SLES7/RHAT ES4. Het is al zo lang geleden dat ik de versies niet meer precies weet. Wel was het een 32-bit port (64-bit deden we pas jaren later). Maar ook toen al was een 486 niet meer in beeld. Core Duo zat volgens mij in die tijd en SSE2 of 3?

[PjotterP]

Je hebt niet per se linus torvalds nodig om kernels die nog de oude cpus ondersteunen verder aan te passen indien nodig.

[Cilph]

Want die updaten een Linux kernel uberhaupt?

[Barsonax]

Die updaten die machines toch niet dus dat lost het ook gelijk weer op

[SpiceWorm]

Tuurlijk draaien er nog hele oude systemen. Maar moeten die de nieuwste kernel versie draaien? Als ze nog niet vervangen zijn, was er geen behoefte aan nieuwe features dus.

Ook lijkt mij dat 486 systemen vaak vervangen kunnen worden door moderner spul.

[biteMark]

Tsja, dat is het mooie van open source: let them fix it! Als het voor hen zodanig belangrijk is dat een recente kernel blijft draaien op i486 dat het de investering waard is dan kunnen ze zelf de nodige aanpassingen doen om dat werkend te houden/krijgen.

Als oude hardware nauwelijks meer gebruikt wordt en het onderhoud vergt (te)veel extra energie dan mag je dat eigenlijk niet van de open source gemeenschap verlangen. Jouw probleem wordt dan ineens hen probleem.

[Docc]

Die systemen wil je echt niet updaten. deze zijn waarschijnlijk al tijden niet geupdate

[Schway]

Dan mogen ze lekker zelf een kernel ontwikkelaar aanstellen

[Tjidde]

Dat het support vanaf volgend jaar stopt betekend niet dat de huidige versie niet meer werkt.

Dus je oorlogsschipsoftware is niet onbruikbaar meer. Neem aan als je een systeem hebt wat draait op i486 dat die niet direct benaderbaar is via het internet. Fysieke toegankelijk is ook geen probleem want iedereen op het schip is als het goed is gescreend.

Hetzelfde geld voor de belastingdienst, je zou niet zo maar hij gevoelige hardware kunnen komen zonder goedkeuringen.

Dan heb ik het nog niet over het feit of je nog wel een systeem wilt hebben wat op een platform gemaakt is dat niet meer geproduceerd word.

[Belboer]

Systemen die zo oud zijn zullen zeer waarschijnlijk ook geen moderne Linux kernel draaien. Als een toepassing afhankelijk is van een dergelijk oud platform zal dat vooral veroorzaakt worden door applicaties die hardware gebonden zijn en die applicaties gebruiken dan ook de libraries van die tijd. Als je daar een moderne Linux distributie op zet die ook moderne kernels ondersteunt zal praktisch zeker je applicatie niet meer werken. Die systemen kan je als een black box beschouwen en laten "as is" laten draaien. Dan maakt het niet uit dat de meest recente kernel de betreffende processor niet meer ondersteunt.

[Verwijderd]

Precies wat ik ook dacht. Er zullen vast nog vele machines of systemen zijn met een 486, maar die lijken mij niet verbonden met het internet, een oudere versie zou dan toch gewoon blijven werken?
Werkt een huidige versie überhaupt -fatsoenlijk- op een 486?

[TheVivaldi]

Ja. Ik heb een hele oude Compaq-laptop waar Enlightenment (werkomgeving/vensterbeheerder) prima op draait. Althans, niet prima in de zin van "hij kan nog mee met de huidige generatie laptops", maar wel prima in de zin van "alles opent en werkt snel genoeg om er nog wat (moderne) dingen op te kunnen doen".

[Scriptkid]

can it run doom

[TheVivaldi]

Absolutely!

[PageFault]

Doom draaide al op een 386

[Stonehawk]

Nou op onze Intel 486 SX was het niet speelbaar. Toegegeven de cpu draaide op 25 MHz en die SX was natuurlijk niet een volwaardige 486.

[MrMonkE]

Ligt er een beetje aan. Als de versie die ze nu gebruiken een bug heeft die in de toekomst wordt getriggered dan hebben ze een probleem. Bijvoorbeeld als ze opeens in 1901 zitten.

[memphis]

De 486 is ook een populaire embedded processor voor vele systemen geweest en zelfs vandaag worden nog 486 embedded systemen verkocht.

[carlo]

Bewijs / link ?

[The Zep Man]

Een oplossing die Linus ook oppert:

I suspect we can just say "oh, well, use LTS kernels".

LTS is natuurlijk ook nog een oplossing om in een aantal jaar (sterk) verouderde hardware te vervangen.

[Wolfos]

Dat hoeft niet het geval te zijn. De laatste CPU's op deze architectuur komen uit 2013, en daar worden nog steeds embedded boards voor gemaakt. Dat kunnen bijvoorbeeld point of sale devices zijn die wel met het internet verbonden zijn.

[GarBaGe]

Ik zag laatst de weegschaal in de AH op tilt slaan en rebooten.
Die draait kennelijk een Debian distributie.
Ik kan me voorstellen dat dit soort embedded spullen nog op relatief oude hardware draaien.
Geen flauw idee of ie netwerk heeft. Wel handig voor management (zoals nieuwe producten/prijzen uploaden naar je weegschaal), maar met een beetje security in gedachten hang je zoiets natuurlijk niet direct aan het internet.

[Aetje]

Voor user systemen, nee. Maar embedded systemen kunnen best nog op dit soort oude architecturen draaien. Of die baat hebben bij nieuwere kernels echter is maar de vraag... dus ik kan me wel voorstellen dat Linus deze antieke zaken niet lange wil ondersteunen.

[Bunga]

Ik twijfel er aan of die machines allen de laatste nieuwe kernel draaien. Die zitten heel waarschijnlijk reeds op een hele oude kernel. Zelfs voor nog steeds relevante en kritieke toepassingen, die zijn heel conservatief met kernel updates. De kans is zelfs groot dat ze hun eigen spin-off kernel onderhouden als het nog zo belangrijk is.

[Zeerob]

Misschien is de 486 wel een van de meest gebruikte processors.
De Intel Management Engine die in bijna elke Intel processor is ingebouwd, schijnt een 486 processor te zijn, en draait op een Minix variant.

[ALittleTooLate]

Ik kan het me ook niet voorstellen. In de tijd van 486 was linux niet de eerste keuze voor embedded oplossingen.

[cappie]

Er zijn genoeg satellieten die nog op 486's draaien aangezien die dingen pas ergens in de '10's certified waren.. processoren met grotere transistoren (lees: oude trage troep) zijn ook minder vatbaar voor crashes door cosmic interference. De Hubble ruimtetelescoop heeft momenteel bijv. nog een 80486, alleen verwacht ik niet dat daar snel een nieuwe versie van Linux op zal gaan draaien 😂

[Reactie gewijzigd door cappie op 2 augustus 2024 07:53]

[davince72]

Los van of het wel/niet terecht is om er afstand van te nemen vraag ik mij gewoon af: Hoeveel i486 specifieke code zit er in die kernel?
Als dat best wat uitzonderingen zijn lijkt het mij logisch om er afstand van te nemen en laat een linux-fork zich daar maar om bekommeren oid.
Als het eigenlijk om vrijwel niets gaat zou ik het ergens zonde vinden om die ondersteuning los te laten, maar dat zegt iemand die het leuk vind om de nieuwste dingen te zien draaien op de oudste hardware....zonder noodzaak ;-)

[Mijzelf]

Ja, dat vraag ik me ook af. Ik heb net in de kernelsource zitten kijken of ik daar achter kan komen, maar dat is niet eenvoudig. Je zou verwachten dat 486 specifieke code wordt gemarkeerd met '#ifdef CONFIG_M486', maar dat komt niet echt voor. M486 staat alleen in een paar Kconfig bestanden.
Het enige substantiële wat ik kan vinden is de floating point emulator, die alleen benodigd is voor de 486SX. Maar misschien zijn de chipset drivers het grote probleem?

[hostname]

De code in de kernel is gesegmenteerd op basis van functie, niet CPU. Je moet zoeken op bijv. CONFIG_X86_CMPXCHG64 of X86_FEATURE_CX8 om de compatibiliteitscode te vinden (de i486 is de laatste CPU die deze features niet heeft).

[--Andre--]

Als iets al hierachter zit, zal het wel een stuk code in assembly zijn. Dus de stukken code die getroffen zijn zullen beperkt zijn.

[Terry A Davis]

Van wat ik begrijp is het zo dat de nieuwe generatie kernel ontwikkelaars niet opgegroeid zijn met oude architecturen en dat het onnodig resources in mankracht kost om oude architecturen te blijven ondersteunen.

[Genosha]

Zo ver ik begrijp ondersteund een Intel i9 13xxx ook nog steeds instructiesets zoals MMX. Linus heeft best een punt en moet naar geluisterd worden. Kan de stabiliteit van Windows ook ten goede komen als alle oude 8/16 bit instructies gewoon geschrapt worden.

[chocomellover]

Wat ik me afvraag is of die oude processoren etc niet in randapparatuur zoals routers etc gebruikt wordt omdat ze gewoon supergoedkoop waren/zijn.

Qua pc's hoef je er geen rekening mee te houden, maar qua andere toepassingen vraag ik het me af.
Alleen daarvoor zal idd een LTS-versie volstaan.

Het is voor een randapparaat (als die al 486 proc bevat) niet echt relevant of die Vulcan ondersteunt of DDR5 of ...

[MSalters]

Zelfs als de chip zelf goedkoop zou zijn (onwaarschijnlijk; de logistieke kosten domineren) dan loop je nog tegen een vervolgprobleem aan: die 486 werkt inderdaad niet meet DDR5, of DDR4, of uberhaupt DDR. Je moet dus ook speciaal geheugen ergens zien te vinden - en alweer, dat zal niet goedkopp zijn vanwege de beperkte schaalgrootte.

Een moderne ARM microcontroller is goedkoper te maken (meer chips per wafer), en kan omgaan met gangbaar geheugen, dus dat is ronduit beter.

[locke960]

https://www.embeddedts.com/products/TS-4400

Het voordeel van dergelijke oude cpu's is dat ze een zeer lage transistorcount hebben en weinig energie gebruiken. 80486DX, 1.2 miljoen transistoren, max 6W bij een productie node van 1000nm.

Als je die op een halfweg recente productie node kunt maken, heb je hele goedkope en heel zuinige cpu's waar al een berg software voor bestaat (nog wel). Iets wat we nodig hebben als we serieus werk willen maken van echter IOT.

Maar ik ben het met je eens, we zijn waarschijnlijk beter af met afgeslankte modernere ontwerpen.

[vrilly]

Ze gebruiken een Vortex86EX(gesimuleerd in een FPGA), die valt eerder onder i586 zonder FPU en wordt nog wel ondersteunt als Linus deze support laat vallen. https://en.wikipedia.org/wiki/Vortex86

486 like x86 Vortex86EX core

[Reactie gewijzigd door vrilly op 2 augustus 2024 07:53]

[MSalters]

Allemachtig, 6W? Een vergelijkbare ARM doet 100 mW of zo.

En 1000 nm productienode is bepaald geen aanbeveling. 130 nm lijkt 8 keer zo klein, maar dat betekent dus dat je 64 keer zoveel CPU's uit een wafer haalt. En ja, de toleranties op 1000 nm zijn groter, maar ook 130 nm is zo volwassen dat je geen yield problemen hebt. Dus je 1000 nm wafers zijn iets goedkoper, maar je chips zijn per stuk zo'n 50 keer duurder.

Wellicht voor de duidelijkheid: de 80486 is nog wel naar de 800 nm node geport, maar niet verder. Dat is dus marginaal goedkoper en marginaal zuiniger, maar het blijft beroerd in vergelijking met ARM.

[locke960]

Die 6W is voor een originele 486DX2-66 op 1000nm. Als je dat port naar een recentere node als 40nm oid wordt het natuurlijk heel veel zuiniger. En omdat het maar 1.2 miljoen transistors per CPU zijn, ook heel goedkoop.

Maar het punt wat ik eigenlijk wilde maken* is dat het voor IOT belangrijk is dat er *echt* goedkope, zuinige hardware komt waar moderne software op loopt die ook nog onderhouden wordt.
Dat kan een 486 CPU zijn, maar ik vermoed dat het verstandiger is daarvoor een moderner cpu ontwerp uit te kleden en echt zuinig te maken.

*En dat er wel degelijk 486 processors met DDR3 support zijn natuurlijk :-)

[MSalters]

Dat is wel behoorlijk veel werk, naar 40 nm porten. Er is een reden dat Intel niet eens de moeite heeft gedaan om 'm naar 600 nm te porten. Het moet natuurlijk wel een 486 blijven, dus volgens de specs die Intel destijds heeft opgeschreven. Want als je een nieuw design gaat maken met nieuwe documentatie, waarom zou je anno 2022 dan nog een ISA-compatible kloon van de 80486 maken? Geen CMOV bijvoorbeeld, terwijl dat juist een efficiente operatie is.

Je zult dus ook een 40 nm proces moeten vinden wat nog om kan gaan met 5 Volt. Pas bij de Pentium ging Intel over naar 3.3 V. En aangezien het 5V blijft, is je zuinigheidswinst beperkt.

[carlo]

Je zult dus ook een 40 nm proces moeten vinden wat nog om kan gaan met 5 Volt. Pas bij de Pentium ging Intel over naar 3.3 V.

De 486DX4-100 was op 600nm, 3.3V en gebruikte daarbij 3,55W met 1,6 miljoen transistors.

[Xander2]

Die 6W is voor een originele 486DX2-66 op 1000nm. Als je dat port naar een recentere node als 40nm oid wordt het natuurlijk heel veel zuiniger. En omdat het maar 1.2 miljoen transistors per CPU zijn, ook heel goedkoop.

Je doelt op de Intel Atom, dat is die 486 in een nieuw jasje :-)

Kan niet opboksen tegen MIPS of ARM qua kosten/efficiëntie.

[chocomellover]

Heden ten dage wel, alleen ik weet niet of dit altijd zo is geweest...

Ik kan me best voorstellen dat Intel in 2007 officieel stopte met maken, alleen dat er rustig nog tot 2015 (random jaartal) randapparatuur op gebaseerd was en dat die randapparatuur nog steeds draait en updates krijgt.

De vlucht van ARM is van relatief kort geleden.

Alleen dit is 100% pure speculatie en ik vind het dan ook goed dat Linus zoiets voorstelt, laat de mensen die de randapparatuur gebouwd hebben / ondersteunen maar naar boven komen en bezwaar maken. Dat is de enige manier om het inzichtelijk te krijgen.

[jhhest]

Ik denk niet dat dat het issue is. Een 486 gebruik je niet omdat het een goedkoop alternatief is. Onderdelen vervangen wordt lastig, onderhoud wordt lastig.

De mensen die een 486 gebruiken gebruiken het vaak voor retro toepassingen, bepaalde specifieke programma's die alleen op die bepaalde onderdelen werkt.

Soms zijn er ook bedrijfspecifieke toepassingen die op een bepaalde architectuur werken. Ik meen dat teletext daar een voorbeeld van was. Ook melkmachines van boeren willen nog weleens werken op oude hardware.

Wanneer iets werkt, het zijn werk goed doet en vervangen soms lastig of duur is zie je nog wel eens van die oude apparaten staan.

[chocomellover]

Wanneer iets werkt, het zijn werk goed doet en vervangen soms lastig of duur is zie je nog wel eens van die oude apparaten staan.

Alleen dat soort apparaten dat krijgt ook niet spontaan een nieuwe linux-kernel erop gezet omdat die veiliger zou zijn etc.
Zoals je zelf al zegt, die werken zolang ze werken en feitelijk durft bijna niemand ze meer aan te raken uit angst om ze te breken, oftewel een huidige (of vorige) LTS-versie volstaat simpelweg voor de komende 10 jaar.

[x280]

Inderdaad melkrobots kost meer dan 100.000 euro en draait op minstens al 10 jaar niet verkrijgbare microcontrollers/microprocessor/cpu/fpga...

[Verwijderd]

Welke hardware is dan nieuw uitgebracht welke nog i486 gebruikt? Moet wel (zeer) specialistisch zijn of anders iets wat gemaakt en gebruikt wordt in landen zoals Noord-Korea welke compleet in isolatie zijn.

Daarnaast, i486 is de voorloper van Pentium - productie is stopgezet door Intel in 2007.

En als er oudere hardware is die nog op i486 draait, zullen de kernel updates van vandaag de dag mogelijk niet geïnstalleerd worden om instabiliteit te voorkomen.

[Wolfos]

https://www.jetwaycomputer.com/MI97.html

Long-Life Embedded Class with Planned Lifecycle Through Q1’2029

Deze bordjes bijvoorbeeld.
EDIT: Zie dat ik daar een Celeron heb gepakt. Het is me niet duidelijk of het ook daarvoor geld of alleen de Atoms van die generatie want die laatste verkopen ze inderdaad niet meer.

[Reactie gewijzigd door Wolfos op 2 augustus 2024 07:53]

[bwerg]

Als Jetway support wil bieden voor linux tot 2029 mogen ze natuurlijk prima de kernel forken en zelf i486-ondersteuning gaan beheren.

Als ik zo naar hun OS support list kijk zie ik trouwens vrolijk versies uit 2014 als laatste versie staan, maar aan de andere kant ook windows 10 (waar ik niks van geloof). Überhaupt een onrealistisch lange lijst van diverse OS'en voor zo'n legacysysteem. Leuk beloofd, maar ik geloof d'r weinig van.

Als je echt lange support op antieke hardware belooft zul je echt zelf het beheer over de ondersteunde software op je moeten nemen.

[Reactie gewijzigd door bwerg op 2 augustus 2024 07:53]

[Wolfos]

Uit ervaring werkt Windows 10 wel degelijk op deze bordjes. Zo oud is deze hardware ook niet. Maar goed, als ze in 2023 de laatste major release doen met i486 support dan zit je al in 2029 voordat de LTS periode voorbij is.

[Reactie gewijzigd door Wolfos op 2 augustus 2024 07:53]

[vrilly]

In de hele lineup is er geen enkele bordje met een oude i486 CPU?
Ik zie alleen maar relatief moderne hardware daar, vanaf 2012. Dat valt eerder onder i686 of amd64

[IrBaboon79]

Embedded spul kan nog het eea aan boord hebben… die oude chips zijn enorm krachtig voor heel veel toepassingen en kosten bijna niets meer. Maar goed, dat spul hoeft dan ook geen bleeding edge kernels dus een final release met een 6.x LTS branche doen en klaar.

[Falcon10]

*kuch* niemand gezien dat we over 468 ipv 486 hebben ?
Oh modje, vermoed dat het artikel ene kleine verbetering nodig heeft.

[Verwijderd]

forum: Geachte redactie

[Sando]

Dat zijn 17 stappen, daar heeft natuurlijk niemand zin in.

[2green]

Aanvullend krijg je ook nooit een reactie, totaal niet motiverend om eraan te beginnen of af te ronden. Even als response 'fixed' is toch geen moeite?

[Strangler1985]

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

Perfect omschreven, toch?

[ro8in]

De 486 is mijn nemesis. Ik had een 386(leuk voor Wolfenstein), maar wilde heel graag een 486 voor Doom, die is er nooit gekomen, uiteindelijk waren mijn ouders van de 386 over naar een Pentium. Maarja toen was Doom al oud nieuws.

Ooooit zal ik die 486 nog in mijn handen krijgen en Doom spelen op de hardware waarvoor hij ontwikkeld was!

Sorry verder totaal offtopic enzo, maar 486 brengt altijd wat jeugd emoties omhoog haha

Verder lijkt het mij wel logisch om 486 support te stoppen. Als dit het ontwikkelproces alleen maar tegenhoudt is het de moeite niet meer waard.

[Reactie gewijzigd door ro8in op 2 augustus 2024 07:53]

[boxlessness]

Ik herinner me uit een ver verleden dat met VxWorks (Real time OS) je de instructieset/interrupt mapping/IO mapping/drivers/etc zelf kon maken voor je hardware. De kernel functionaliteit zelf (e.g. scheduling, memory management, etc) was cross-platform en architectuur-agnostisch.

Nu weet ik (veel) te weinig van moderne OSen om te weten of dit model van een "glue-layer" tussen kernel functionaliteit en hardware een mogelijkheid is van de Linux kernel, maar het lostrekken van de kernel functionaliteit met de hardware mapping lijkt me een goede practice. Dan hoeft 486-support niet in de algemene kernel distributie te zitten, maar kan het een patch zijn op de kernel.

[Slaiter]

Microsoft stopte al met i486 support na NT4, dus afhankelijk van het service contract tussen 2003 en 2006. Linux support dus actief deze groep nog met diverse kernel upgrades, terwijl microsoft anno 2006 al geheel de plug had getrokken.
Overigens kunnen bedrijven die afhankelijk zijn van oude hardware deze dus gebruiken alleen krijgen ze geen actieve update/grades meer als het aan Linus ligt (ik ik snap dat zeker)

[Jerie]

Iemand die het nodig heeft (industriële toepassingen?) kan mooi een oude versie forken en de boel backporten.