"Losse processor" is misledend. Dat ding zit ingebakken in de chipset, en is dus niet te verwijderen. En vaak ook niet eens echt uit te schakelen. Het heeft ook nog eens toegang tot het netwerk op zo'n manier dat het het verkeer ziet vóórdat de CPU het ziet, en daarmee vanalles kan uitvreten en jij als gebruiker hebt geen idee.

De iME en AMDs equivalent, de PSP, zijn feitelijk achterdeurtjes in je computer die sinds respectievelijk 2009 en 2011 eigenlijk altijd aanwezig zijn en langzaamaan steeds moeilijker te omzeilen dan wel uit te schakelen geworden.

Leuk dat deze winkel de gevonden kennis ook toepast maar het blijft behelpen. Je bent beter af met een processor plus chipset in je laptop waar al dat gedoe gewoon niet eens inzit. Tenminste, als de toeverlaatbaarheid van jouw laptop je belangrijk is.

Ben benieuwd hoe robuust deze oplossing is. Ongetwijfeld is het weer in te schakelen. Ergo je koopt een laptop met een uitgeschakelde ME. Vervolgens zet malware deze weer aan en je hebt een vals gevoel van veiligheid.

Of mis ik iets ?

https://www.security.nl/posting/529179/Intel+Management+Engine+via+nieuwe+methode+uit+te+schakelen

Marktplaats biedt al jaren een ruime keus aan iME probleem vrije computers.

Het is wel prettig als de computer wel voldoende performance heeft voor een up to date browser .

Je wilt een gevoel van veiligheid op een computer waar malware op draait ?

De redactie schreef 'aparte processor' .
Wat is er misleidend aan de term "aparte processor" voor een processor die volledig zelfstandig is t.o.v. de main processor ?
Maakt het dan uit of het een aparte die is , of een aparte package ?

Het is zelfs een volledig andere architectuur (ARM) - nog aparter ga je een processor niet makkelijk krijgen.

Hij deelt een behuizing, en misschien een stukje silicium substraat met de 'CPU' - maar is minimaal zo apart als een CPU core .

Na dit bericht gelezen te hebben vroeg ik me af. Zit er in bijvoorbeeld een raspberry pi 3 (arm) ook een soort IME of variant daarvan?

Dat is niet wat er stond om 14:53.

Niet dat we weten. Maar dat zegt niet zoveel.

Ik ben even kwijt welke CPU het was, wellicht een sparc of een powerpc, maar er is er iig een die een 68000 aan boord heeft om de rest op te starten. Waar je dus verder niet bij kan, maar hij is er wel. Als je kijkt hoeveel transistors dat kost op het totaal is het niet eens zo'n raar idee. Nieuw is het ook niet: Er zijn hele oude SGI machines waar de computer een hele kast (~42u rack) groot is, en de grafische kaart nog zoiets. Als je daar in gaat knutselen dan blijkt de grafische kaart een eigen CPU met OS erop te hebben, en als je weet waar de consoleaansluiting zit kan je er zelfs bij.

Er zijn ook genoeg insteekkaarten die general purpose CPUs aan boord hebben. Soms uit compatabiliteit zoals de pc-kaart die je voor sparc workstations kon krijgen, maar niet altijd. Een ISA 2400 baud modem met een 80186 erop, een PCI DSL kaart met een controller met linux erop, een netwerkkaart met een of zelfs twee R4000 cores erop, noem maar op. Die laatste kon je zelfs een SDK voor krijgen om je eigen off-loading firmware voor te knutselen.

Maar bijvoorbeeld ook je smartphone heeft niet alleen een CPU met wellicht meerdere cores waarvan er sommige gereserveerd voor achtergrondtaken, er zit nog een compleet systeem naast: De air interface heeft een eigen controller met OS, en die kun je ook aanvallen. Die zijn zelfs notoir lek.

Een CPU hoeft ook niet heel erg veel transistors te kosten, en met een beetje flash of EPROM en wat RAM kom je al een heel eind. Als ontwerper kan je ze dus vrij makkelijk gewoon erbijproppen en niemand die het door hoeft te hebben.

Het is wel dat de combinatie van versleutelde firmware, niet uit kunnen schakelen, de plek, en de toegang, die de iME en PSP bijzonder gevaarlijk maken. Wat min of meer ook geldt voor Lights Out Management-oplossingen van andere fabrikanten.

Wat op zijn beurt weer wijst op het aloude adagium dat je security niet er maar gewoon op kan plakken. Het idee van LOM, en dus ook de iME en PSP, is een bolt-on om het probleem te omzeilen van de onderliggende aanname dat een peecee altijd een operator voor de machine heeft zitten. Echte servers kun je via alleen een seriële poort bedienen, terminal zelf meenemen. Hang je rack met servertjes aan een seriële poortserver en je hebt je beheer op afstand geregeld. Maarja, dat is voor peeceetjes niet genoeg, en dan krijg je dit soort ellende.

Voor zover ik weet is de architectuur van de ARM processoren RISC architectuur en heeft zo'n dergelijke ME niet. Verbeter me mocht ik ontbreken aan mijn kennis.

De architectuur van de CPU zegt niets over het al of niet hebben van een losse management CPU binnen dezelfde behuizing, of op dezelfde plak silicium .

Inderdaad kun je zeggen dat ARM CPU's 'risc' zijn (let op - cisc/risc discussie is nogal betekenisloos tegenwoordig ) .

En inderdaad, ook bij mijn weten hebben de huidige ARMs nog geen management CPU'tje binnen de behuizing.

Overigens is het primaire doel van z'on management CPU het (out of band) kunnen managen van het systeem onafhankelijk van de hoofd CPU en het OS - vooral bedoeld dus voor CPUs die je in servers gaat gebruiken .

Dat Intel 'm fysiek wel meelevert met CPUs voor andere marktsegmenten is niet vreemd - Het maken en valideren van masker sets voor CPUs is heel erg duur. Economisch gezien wil Intel zoveel mogelijk dezelfde plakken silicium maken, en onderscheidende features enablen/disablen op basis van fuses die al of niet doorgebrand worden bij het inpakken . Of zelfs nog later, alleen maar door wat het BIOS aanzet of in microcode upload.

Veel van de 'server' features van een bepaalde CPU familie zijn aanwezig qua transistoren, alleen niet actief/bereikbaar in desktop modellen .

Je kunt dus ook verwachten dat als er ARM families voor 'datacenter servers' komen er ook gedacht wordt over het integreren van een aparte core voor 'management' .

Een ARM die spotgoedkoop moet zijn (licentie en silicium oppervlak) , en ultra low power zit niet in het segment waar de overhead/oppervlakte/stroom gebruik van nog een arm core als management engine verwaarloosbaar is.
Om die reden kun je 'm niet verwachten in de Pi CPU.

Het is geen fundamentele wet of noodzaak dat het niet past of niet kan bij 'ARM' of dat de fabrikanten van ARM cpu's meer of minder ethisch of security aware zijn dan Intel en AMD , alleen dat ze nu in een marktsegment zitten waar geen ruimte en geen behoefte is aan een on-board management core .

De IME was ook niet zo geheim, alleen niet zo opgemerkt als risico door de security crowd.
Hij zat en zit er als out of band management unit, en ik nogal zeker dat de feature op allerlei product announcements genoemd zal zijn .


Binnen een CPU zou het me toch verbazen. De vroege Sparcs en Power CPUs hadden ook echt niet het transistor budget waarin een M68K verwaarloosbaar is. Of ze het dan voor een latere serie CPUs wel zouden bouwen zou me toch iets verbazen.

Maar een auxiliary bootstrap processor in een groter _systeem_ (Sparc of Power gebaseerd) zou heel normaal zijn .
De Cray 1 had een Data General minicomputer daarvoor, en veel andere systemen hadden iets vergelijkbaars (vaak een PDP variant ) .
Ik zou me heel goed kunnen voorstellen dat het makkelijker is om met een enkele CPU een systeem met veel CPUs gecontroleerd op te laten starten, en de 68K is er een heel logische keuze voor.


Ook dat is vrijwel zo oud als 'de computer' - Channel processoren in IBM mainframes zijn fors krachtig.
En nu de GPUs in PC's - veel grafische reken units, maar ook een ARM core als controller .
Haast hetzelfde als de SGI reality engines van enkele decennia eerder .


Notoir lek zou ik het niet noemen - de iPhone unlocks die iets met de 'baseband' willen zijn beduidend zeldzamer dan slechts de OS hacks


Dat is wat anders - een grote CPU heeft de transistor ruimte, maar is geen eenmansproject . En het valideren van het ontwerp is een heel significant deel van het werk .
Daar prop je als ontwerper niet eventjes 20K transistoren bij (die ook nog diep inkoppelen aan allerlei bussen) zonder dat de rest van het team het ziet .
Het toevoegen van een IME door Intel en AMD is gewoon een beslissing met een markt-reden , en niet zo geheim.


Je bent blijkbaar old skool opgegroeid met Sun en HP enzo ?

Die mooie console poort, waarop je break stuurt en dan in de Forth prom debugger landt, waar je kernel en process memory kunt editen om je shell sessie root te geven ?
(of Stop-A op het toetsenbord ).
En omdat je niet altijd 7x24 mannetjes on site hebt, sloot je al die echte servers aan op een console server met een analoog modem . Met terugbel faciliteit als je voldoende paranoide was.

Een Out Of Band / iLo/ Drac of serieële console zijn er allemaal om dezelfde reden - soms moet je je systeem recoveren wanneer het OS hangt, geinstalleerd moet worden of wegens een config fout in-band niet meer bereikbaar is.


Het was niet _vaak_ maar ik heb wel eens een echte server met een echt OS (tm) zodanig zien hangen dat de console poort er niks meer mee kon.
Dan kun je natuurlijk ook nog een remote power switch aan je console server hangen , maar de 'reset knop op afstand' van een ilo/drac kaart is nuttig.

Hij zit ook niet in de CPU zelf, maar in de chipset. Overigens waren zulke OoBMUs al opgemerkt als securityprobleem, aangezien er gaten in verschillende vendor-specific varianten gevonden waren, met de opmerking dat het patch management daar vaak te wensen overlaat. Niet kunnen verwijderen en niet kunnen patchen en niet uit kunnen schakelen is nog een stapje interessanter.

En er zitten wel degelijk "features" in die sterk gericht zijn op "security", meer dan de minder diep geïntegreerde alternatieven. Het is ook niet toevallig dat de AMD versie die vrij vergelijkbaar is, "Platform Security Processor" heet.

Dat was binnen een CPU, en niet een vroege. Het ding is maar 40k transistoren ofzo, dus valt redelijk in het niet bij de honderden miljoenen transistors die op een moderne multi-core CPU te vinden zijn. Maargoed, die zie je als eindgebruiker of zelfs programmeur dus ook nooit. Maar hij is er wel.

Nouja, wat we vroeger in meerdere chipjes deden doen we steeds meer met minder individuele chipjes, maar wel met veel meer onderdelen op een enkel chipje gepropt. Steeds kleiner ook. Een 68k in een recent proces is een stukje kleiner dan eentje in het originele proces.

Je kijkt teveel met popi oogjes van de verkeerde kant.

En toch hebben de meeste mensen nog steeds niet door wat de gevolgen van dat "feature" zijn. Overigens heb ik nergens gezegd dat het geheim was, dat maak je er zelf van.

En wat dan nog?

Precies de reden dat bijvoorbeeld routers een auxiliary console poort hebben: Eentje voor de management als je er bent, eentje voor het modem om in te bellen. Ondertussen steek je eerder een 3G stick in je routertje dan dat je een telefoonlijn bestelt en een extern modem aansluit, maar toch.

Het probleem met alles behalve de seriële console voor management is dat ze nodeloze complexiteit introduceren, waar ook nog eens onbedoelde zwakheden in blijken te zitten die moeilijk op te lossen zijn.

Terwijl BSODs als gewoon en acceptabel gezien worden.

Werd een keertje erbij geroepen want $ontwerpster had een tablet met kennelijk nogal slonzige drivers geinstalleerd. "Help, wat is dit?!?"
'Dat is nou wat je ziet als een mac crasht.'
"oh, nooit eerder gezien."

Die kaart heeft dan een "resetknop" ingebouwd, en natuurlijk kan dat. Laat je de serial afhandelen door een minimale FEP die de FORTH draait dan kan je die aan de resetpin laten trekken. Dat hoeft helemaal niet veel transistortjes te kosten. Overigens waren er ook wel Echte Servers waar de PSU een eigen seriële aansluiting hadden. Je kan ook een lijntje trekken van je seriële server waar alle servertjes toch al aan hangen naar de remote power switch die alle servertjes bedient. Die dingen zijn nog steeds in gebruik dus kennelijk is de ingebouwde remote resetknop in je remote management kaart toch niet altijd voldoende.

Ook leuk is als zo'n remote management kaart een externe power source nodig heeft, zodat'ie nog wat kan doen als je multiple redundant PSUs echt helemaal uit staan (waarmee zelfs "helemaal uit" alweer toch net niet echt "helemaal uit" meer is) dus dan moet er nog een extra wall wart ergens bijgeplugd worden.

Wat je kwijt bent als je serieel kan werken is de toetsenbord-en-schermemulatie en de noodzaak plaatjes te transporteren en te laten zien, en dus om te moeten OCRen wil je je management automatiseren, waar je dat anders met een tool als "expect" kan doen. Het alternatief is meer code toevoegen aan het ding dat je wil managen. Je kan door een simpelere inslag dus grote bergen complexiteit wegsnijden, en daarmee een meer robuust en betrouwbaar geheel creëren. En je krijgt er nog meer mogelijkheden mee ook, omdat alleen tekst zoveel simpeler is en dus makkelijker te manipuleren.

Geen wonder dat enterprise routertjes en switches nog steeds met zo'n console en plain text single file configuraties werken. Die kun je namelijk wel, ik noem een dwarsstraat, regelmatig geautomatiseerd om een kopietje van de config vragen en die dan in een CMS opbergen. Als backup, maar ook als historie. Dat is toch lastiger als er een muiscursor om de hoek komt kijken.

Het scheelt bijvoorbeeld ook het moeten hebben van een recente browser met java (niet javascript!) erin, zodat je die console remote geprojecteerd kan krijgen. En dus ook alweer enige tientallen miljoenen lijnen code waar je afhankelijk van bent voor het remote kunnen managen van je servertjes. Dat java vereisen is ook wel eens in switches geprobeerd maar dat was toch geen succes. Wat gek nu.

Een verschil met de Enterprise benadering. Remote management was in de jaren 70 al vrij normaal. Kon de support engineer op je stoep staan omdat de machine een signaal had afgegeven dat er iets fout dreigde te gaan. (300 bps).
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_intro2.html

Eigen mannetjes met voldoende kennis zijn te duur voor het echte werk. Outsourcen en/of downsizen voor goedkoper spul.
Probeer maar eens zo'n machine plat te krijgen. Het lukt als je de configuratie fout doet (80% belasting mag, meer dan 100% niet) of low level core routines zonder memory acces controles. Het zijn maar een paar van de mechanismes die je nu langzaam aan elders terug ziet komen.

Doel data center: geen eigen mensen, licht uit en laten draaien. Na 4 jaar een keer laten vervangen door de leverancier.

Ah, ik dacht dat de nieuwere versies al in de CPU package zaten , samen met alle andere functies die in de loop van de tijd van de chipset naar de CPU verhuisd zijn.
De IME zit (bij Intel) nog in de 'Platform Controller Hub'
https://en.wikipedia.org/wiki/Platform_Controller_Hub
Nu de resterende southbridge functies ook richting CPU gaan zal de IME moeten volgen denk ik.

Patchen/security van dit soort dingen is inderdaad vaak een ondergeschoven kindje.

[..]

Het was sterker geweest als je je bewering ondersteund had met een serie bewijzen .

Het feit dat een redelijke groep gemotiveerde en slimme mensen die hard zoeken (de unlockers) vrij weinig baseband bugs vindt maakt een statement 'notoir lek' wat mij betreft onjuist.


Je post ademde nogal de samenzweringsgedachten van geheime feature die 'een designer ongemerkt kan toevoegen'.



Je mag wel een beetje bijblijven. Die wereld was ook niet perfect noch het hoogtepunt dat sindsdien niet meer overtroffen is.

In die tijd waren Sun , HP's e.d. heel veel beter geschikt als server dan x86 systemen , mede omdat ze met de console poort een goed bruikbare out of band beheer mogelijkheid boden.

Dat die console poort de primaire CPU gebruikte en niet separaat de hardware kon resetten was een beperking.
De volledige systeem controle die je er vrijwel altijd mee kon krijgen was evenzeer een risico als een ongepatchte ilo nu is.


Uh, ook omdat de (cisco) console poort niet de handshake lijnen heeft die een modem verwacht . De magische recovery opties zitten weer alleen op die console poort.
Overigens zijn de router oob modules ook naar een aparte CPU met ethernet aansluiting gegaan .


Het punt was dat een console die de main CPU gebruikt (soms) niet genoeg is om een systeem echt te resetten.
Een echt zelfstandige ilo kaart kan dat wel.
En dan moest je alsnog een mannetje sturen om op de reset knop te drukken. (en hopen dat het aanduiding van zaal, rij , rack en positie klopt voor _welke_ server gepowercycled moet worden).

[..]


Tekst gebaseerd is prima.
Ik hoef geen oob omdat ik zo nodig met de muis een GUI scherm wil zien om BIOS settings aan te kunnen passen.
Dat mag prima met een VT100 of wat voor interface dan ook.

Ik wil _wel_ een out of band die een hard hangend systeem kan resetten. En het is ook wel erg prettig als de interface voldoende bandbreedte heeft om een basic systeem of recovery image naar een server te kunnen brengen.
En ethernet is wel heel veel makkelijker te verlengen door een datacenter dan RS232.

En ja, ilo kaarten die een dikke java client vereisen zuigen ook heel erg.

[..]

Daar had ik even geen zin in. Die baseband interface wordt niet eens zozeer naar een standaard alswel naar de paar merken torenapparaat geknutseld; het zit dus vol met quirks. Daarnaast wordt het puur voor functie en niet voor security gebouwd, en dat gaat goed zolang de boze buitenwereld niet boos genoeg is. Zie begindagen internet. Er zijn dus af en toe wel securityneuskes die een gat of twee in zo'n baseband processor vinden. Daarmee zitten ze niet op de applicatieprocessor maar hebben er vaak wel ongelimiteerd toegang toe. Natuurlijk moet je de telco zijn (of een neptoren neerzetten) om daarmee te kunnen rommelen, maar als je kijkt naar het veld dan is daar nog heel veel te onderzoeken en te verbeteren. Op zijn minst is het een grote onzekere factor, dus veiligheidshalve ga je ervanuit dat die basebandprocessor gewoon lek is. Wat af en toe ook wel doorschemert uit de realiteit. Maar het is geen groot ding dus een paniekfestijn als heartbleed zal niet snel gebeuren. En patchen ook niet.

Volgens mij doen die wat anders.

Dat lees je er zelf in.

Mijn denken werkt een tikje anders. Er zijn wel redenen om aluhoedjes op te zetten, bijvoorbeeld zijn er indicaties dat mainboards uit China met andere iME firmware aankomen dan de manufacturer samples direct van intel, maar als je de gedeelten waar je bij kan dumpt dan krijg je het origineel toch weer terug, dus wat daar precies aan de hand is? Dat is wel "ab werk", en dan krijg je dus een firmwareversie van "on trusting trust" voor je kiezen. Er zijn dus wel indicaties dat er aan gerommeld is of tenminste zou kunnen zijn. Maar daar had ik het nog helemaal niet over gehad.

Dat hoeft ook niet, want zelfs zonder dat, een CPU met eigen OS in je southbridge die zijn eigen ethernetaansluiting heeft en dus berichten van buitenaf kan ontvangen zonder dat de CPU waar het OS van jouw keuze op draait, zelfs als dat precies is als ontworpen, is voor jou een veiligheidsprobleem. Je weet niet wat het doet en het zit in een positie om jou een loer te draaien waar je heel weinig aan kan doen. Dat is uit veiligheidsoogpunt, zelfs als je intel met je leven vertrouwt, gewoon niet heel slim.

Die eerste beperking kan je opheffen met een FEP, wat in verbazend weinig transistoren zou kunnen. Ik denk dan aan bijvoorbeeld de J1 FORTH CPU, wier open source verilog source wel 200 lijnen is. Mischien dat je een hele FEP wel in 1000 lijnen kan, compleet met resetlijntjes, meer geavanceerde point-to-point serial van een paar megabits mischien, en wat dies meer zij. Maak het zuinig genoeg dat'ie van de stroom van de serial kan leven en je hoeft ook die extra wall-wart niet aan te sluiten.

Het punt is veel meer dat een iLO/DRAC/LOM/... veel complexer is dan'ie zou moeten zijn en dat dat een domino-effect heeft. Serial kan je wel bovenop automatiseren, IPKVM veel minder. Het is (alweer) die aanname van een operator aan de machine die zo diep in de peecee is ingebouwd die al die ellende veroorzaakt.

Maak een simpelere interface en het interfacen met die interface wordt ook simpeler. Plus dat als je je netwerkmanagement (en dus dier complexiteit) van die inbouwkaart naar een serial port server verplaatst, je toegangsbeheer op de console (en dus de macht) ineens ook een stuk simpeler wordt.

Die zit dan in de fysieke toegang (toch al "game over" hoe je het ook bekijkt) of in je goed gemanagde "bastion host" in de vorm van je netwerktoegankelijke serial console server waar de toegang tot zeg een heel rack tegelijk en per poort geregeld kan worden.

Ik zie dat wel omdat ik niet in "alle computers hebben scherm, muis, en toetsenbord" geloof, maar dat wil niet zeggen dat ik ook de klok wil terugdraaien. Veel meer, het hele peecee-gebeuren heeft nogal wat fouten gemaakt, vaak op kostengronden, die vaak neerkomen op goedkoop bleek duurkoop. Daar hoeven we natuurlijk niet mee door te gaan als we de noodzaak daartoe wegnemen.

Zelfs redmond heeft ondertussen toegegeven, schoorvoetend en zonder bronvermelding, maar wel toegegeven, dat de GUI ook niet uniform zaligmakend is en dat de CLI soms best makkelijk is, in de vorm van posershell.

Dan doe je dat toch niet. Dan plak je er een Font-End Processor voor. Wat ik ook noemde.

Die dat doet tegen een hele hoge prijs. Ik zeg, een nodeloos hoge prijs. We kunnen het ook wel op een andere manier. Die IPKVM-in-elke-server-inbouwen-aanpak heeft daar echt het monopolie niet op. En uit veiligheids- en betrouwbaarheidsoogpunt is complexiteit zoveel mogelijk te vermijden. Dus dat feature op een minder complexe manier inbouwen is toch een beter idee.

Je leert vanzelf hoe slim die "smart hands"-diensten zijn. Dat weet ik inderdaad uit ervaring.

Mee eens, maar kijk uit wat je "out of band" noemt. Als het in je southbridge ingebouwd zit, hoe "out of band" is het dan nog?

Dat hoeft niet per se over je commandokanaal als je een bios hebt dat je gewoon kan vertellen zijn volgende image zelf over het netwerk op te halen, zoals openboot dat kan. Alweer een dingetje dat peecees nooit konden en dus moest het er tegen hoge kosten achteraf alsnog tegenaangeplakt worden. Door floppies en CDROMs te faken bijvoorbeeld. Overigens bestaan er wel open source projecten die vergelijkbare functionaliteit toch weer toevoegen, maar dan via de netwerkkaart. Compleet met zelf flashbare custom scripts en zo verder.

Maargoed, als je niet bolt-on hoeft te faken, dan kun je met relatief weinig moeite meer bereiken dan al dat glimmend moois dat de OoBMUs met veel kunst en vliegwerk aan je peeceetje plakken.

Je bedoelt dat je even een switch kan neerplempen en het is wel goed? Voor je het weet hangt er iemand je netwerkje aan het internet en iedereen kan jouw servertjes managen. Uit veiligheidsoverwegingen is het beter de lijntjes simpel te houden. Maargoed, in plaats van switches pak je dan serial console servers, die dan als bastionhost dienst doen en dan dus wel aan een netwerkje hangen. Zoals gezegd, door dit handig aan te pakken elimineer je complexiteit en verplaats je de complexiteit die je overhoudt naar daar waar hij minder in de weg zit, of gewoon beter in de hand te houden is.

Want als je een machine uit de sloot wil trekken dan wil je simpele dingen die werken, niet obstakel na obstakel van andere dingen die je éérst moet doen.

Maargoed, het hoeft niet per se precies RS232 te zijn. Hoewel dat waarschijnlijk best voldoende kan zijn, zelfs op 9600 baud. Ik heb wel wat alternatieve encodings op het oog waarmee er meer bits per seconde over minder draadjes te sturen zijn, ook op redelijke afstanden. Het idee is altijd wel strikt point-to-point zodat je altijd met "de andere kant van deze draad" praat, en dat er niet eerst even uitgezocht moet worden welke van de tien of twintig of honderd aangesloten kandidaten je hebben wil. Die selectie doen we ergens anders, namelijk bij de poort.

Je kan ook de dotnet client pakken natuurlijk. Want iedereen gebruikt windows.

Net zoiets als roepen dat je teraterm moet pakken om je servertje te beheren, maar daar heb je wel de keuze om beter te weten en iets anders te pakken, en bij zo'n IPKVM toch wat minder. Zelfs "maar java is toch platformonafhankelijk!?!" blijkt niet altijd even waar. Ik weet niet hoe ze het doen maar ik weet wel dat er af en toe java opduikt die het domweg vertikt te werken op JVMs op andere dan voorziene platforms. Je kan gissen dat de ontwikkelaars puur op functie ontwikkeld hebben op een hele beperkte testbasis. Wat dat voor het ontwikkelen voor veiligheid lijkt dan op voorhand al nog minder rooskleurig.

Maargoed, het punt is, in abstracto, dat simpliciteit een beter idee is dan complexiteit. Het kost toch best veel ingewikkelde woorden om dat punt een beetje te maken.