Názory k článku
Nová verze systemd 258 odstraňuje cgroup v1, vyžaduje jádro Linux 5.4

Ale systemd je jednoduchy, kdyz se s tim naucite. Kdyz se podivate na to, jak to funguje uvnitr, je tam cela rada drobnych nastroju, co sice navenek utvari nejaky celek - ale soucasne plati, ze nemusite pouzivat zdaleka vsechny ty komponenty.

Rozhodne se nebavime o nejake nafouknute jedne binarce, co by delala vsechno mozne.

SystemD možná byl jednoduchý, ale dneska je i man systemctl tak dlouhý, že se tam těžko něco hledá. Hlavní program pro ovládání systemd má být co nejjednodušší a rozhodně bych neměl potřebovat manuál.

A to píšu jako člověk, který má systemd od počátku a napsal návod na systemd-networkd abych nemusel používat RedHat network scripts pro 30 IP adres.

A tak spousta utilit ma man pomerne kratky... jen v nich nenajdete v podstate skoro zadnou informaci a pokud chcete zjistit, jak konkretni vec doopravdy funguje, muzete zacit studovat zdrojak - protoze holt vyvojari pisou dokumentaci casto velmi neradi. V lepsim pripade v tom manu mate "jen" odkaz nekam na web. Zrovna vycitat delku manualu (dokumentace) je... kardinalni blbost, tim "slozitost" merit fakt nejde :-)

Udrzovane distribuce s tim problem mit fakt nebudou. Vase obavy jsou naprosto zbytecne. V distribucich s long-term podporou se drzi starsi verze a v tech aktualnich je neprekvapive vcelku aktualni kernel.

Já osobně za jednu z výhod Linuxu považuji právě to, že mohu mít dost starý kernel na dost nové distribuci. A on funguje. Když ten kernel potřebuji. Jakože jsem to, jak jsem psal, občas potřeboval. Že to nejsou Windows, kde přijde nová verze a mohu měnit celý počítač. To je to. Zrovna u jádra 5.4 je to už asi jedno ale vzdávat se jedné z jeho výhod fakt není fajn.

Produktově je to taky trochu dementizace. Asi jako když se třeba IKEA vzdala kompatibility mezi svými jednotlivými produkty. Protože to zřejmě víc nese a může být levnější takže ještě dostupnější masám. Že její velká hodnota byla právě v tom, že když si člověk koupil v roce X skříň, mohl se spolehnout na to, že do ní v roce X+10 přikoupil krabice a ony přesně pasovaly -- že nikdy nebyla drahá ale ani nejlevnější ale byla vysoce udržitelná. Dementizace produktu jak vyšitá. Vlastně je zrovna tohle celkově podobné víc, než by člověk čekal. Komponenty jako komponenty.

Ono to reseni se sirokou kompabilitou ale neskaluje donekonecna, resp. pak to vyzaduje enormni mnozstvi zdroju. Vzdyt se muzete chopit iniciativy a ten stary kus kodu nadale udrzovat, i to je jedna z vyhod Linuxu :-) Ale chtit to po jinych.... ne, to neni komunismus, vyvojaru neni neomezene mnozstvi. Znaky demence vykazuje spise touha chtit po druhych, aby uspokojovali vase okrajove potreby. Aneb, mate-li pocit, ze nekde je "dira", nic vam nebrani ji zacelit.

Přijde mi, že někteří diskutující (ne nutně zrovna/jen vy) tu zastává názor, který lze vyjádřit následným absurdně znějícím způsobem: So the people providing software for free should support things indefinitely because the people you've paid money for those things won't? (zdroj) Někdo si koupil HW na kterém pořádně nefunguje normální Linux, výrobce shrábl peníze a na další podporu se vykašlal, a teď bude po ostatních (vývojářích, ale i třeba uživatelích - kteří pak naráží na problémy způsobené legacy kódem) chtít, aby mu podporovali staleté kernely?

18. 9. 2025, 21:07 editováno autorem komentáře

Takže když budu mít staré železo, ale na něj půjde novej kernel, tak proč ho tam nedat?

Velká výhoda Linuxu je v tom, že vám tam nenutí novou verzi, která má násobně větší požadavky na železo protože prachy.

Zrovna IKEA nahrazuje zařízení se zigbee protokolem thread/matter. Elektronika a SW mají holt jiný životní cyklus než nábytek; je to jiné odvětví.

S tímto mylným názorem bojujeme my, v průmyslově-automatizační branži, už dobrých 20 let. Opravdu není reálné v nějaké technologii každých 5 let kompletně vyměňovat IT infrastrukturu jen proto, že se někomu něco po 5 letech už nechce podporovat.

A proto se v průmyslově-automatizační branži staví ostrovní systémy kde ty 20 let starý mašiny ovádá 20 let starý PC/PLC ...

Nikdo neinovuje sw pro 20 let starou mašinu tak, aby běhala na nejnovějším PC/PLC ...

Jediné místo které se inovuje je bridge který propojuje ostrovní systém s ostatní sítí (ovládání, vstup/výstup, monitoring ...) a to jen v případě kdy nejste schopen ten bridge tak ořezat aby nebyl nebezpečný té staré ani nové síti.

Ano, ale pak tu máte pojem kritická infrastruktura a zákon o kybernetické bezpečnosti, který to vidí poněkud jinak...

Opravdu?

Kde se tam píše, že musíte všude mít Win11 nebo kernel 6.8 ?

Já čtu, že musíte doložit, že jste infrastrukturu ochránil tak, abyste snížil vznik kybernetického incidentu na minimum.

Air-gap a příčetná access polici je pro většinu případů - kde není možno být "up to date" - považovaná za dostačující opatření.

A pak máte ještě prováděcí vyhlášku...
Ano, souhlasím, jenže na druhou stranu jste nucen logovat kde co a ty logy někde shromažďovat a průběžně analyzovat. Nehledě na to, že bývá zvykem mít prostupy pro servis. Navíc nemáte tak úplně pravdu - tím, že dáte technologii za nějaký firewall, tu technologii za ním nevyvážete z působnosti toho zákona (a vyhlášky). Dokonce ani v případě 100% air-gap.

On nejde o vyvázání z působnosti. Jede o splnění podmínek.

Klidně můžete mít zastaralý SW i HW a klidně i se známou chybou. Musíte to ale zdokumentovat, prokázat a přesvědčit bezpečnostního managera, že je obtížné - technologicky, finančně - zař. vyměnit/nahradit a zároveň jste udělal vše pro to, aby se to nedalo zneužít - proti funkci toho zařízení, nebo proti ostatní infrastruktuře. Váží se náklady a dopady.

Air-gap není v žádném případě dostačující, musí k tomu být access-policy jak co se týče výměny dat, tak fyzického přístupu, monitoring interní pokud to nějaké "logy" vytváří, nebo externí - čidly nebo sondami, a ten monitoring se musí vyhodnocovat. Spousta práce ... proto se hodnotí náklady a dopady.

Nehledě na to, že čas od času nějaká ta 20 let stará mašina odejde, tak tam musíte dát novější, na níž nepojede ten starší SW, a novější zase nepodporuje ten starší HW, který je k ní připojen. To se stává, pokud je k tomu nějaký racionální důvod. Ale pokud víte, že to nejde jen proto, protože někdo usoudil, že je to něco starého, tak to vyhodil, aniž by to reálně něčemu vadilo, je to docela frustrující.

Jenže vy asi ten racionální důvod jen nevidíte. Racionální důvod je že podpora každé starší technologie stojí nějaké peníze. Na návrhu HW, na návrhu SW.
Racionální důvod je že jste za to nezaplatil. Pokud potřebujete aby nový SW podporoval starý HW můžete si to zcela jistě domluvit s výrobcem ... A vývoj takové kompatibility si zaplatit (stejně jako někdo zaplatil extended support W10 (nebo to byly W7?))
To samé se systemd. Pokud chce někdo aby systemd podporovalo cgroups v1 nadále, není nic jednoduššího než si zaplatit full-time programátory kteří se o to budou starat.
Přispěvovatelé do OS nejsou placení, tudíž programují věci které je baví. Myslím prostě že spoustu lidí nebaví držet při životě zastaralý kód který používá pár procent uživatelů... A ti co jsou placení se starají o majoritní potřeby svých zákazníků.
(a imho v komerční sféře se uvažuje dost podobně. My jsme třeba měli 95/5... Pokud něco funguje 95% uživatelů, těch 5% se holt musí nějak přizpůsobit ... protože na těch 5% bysme spálili čas který by se nám nikdy nevrátil (a nezaplatil))

19. 9. 2025, 10:54 editováno autorem komentáře

To je to, o čem se snaží marketéři přesvědčovat obchodní partnery. Ale já celý život dělám ve vývoji SW/HW a vím, že tomu tak většinou není. Stojí to peníze, pokud musíte aktivně něco dělat. Technické racionální opodstatnění to většinou nemá, jen finanční - zaplať znovu za něco, za co jsi už jednou zaplatil.

A jedna ze zásad inženýrského vývoje SW bývala použij nejstarší možné verze knihoven, které ještě k řešení problému stačí, a pozor na věštění budoucnosti a řešení neexistujících problémů. Dnes se to všechno staví na hlavu, než něco odladíte, už se dočítáte, že daná věc je deprecated, verzují se i jazyky... Právě tady je původ problémů a to je to, co v důsledku stojí peníze - překotnost, zbrklost, nestabilita.

No, pak se bavime o nespravne nastavenem modelu financovani, ktery proste nepocita s nejakym zivotnim cyklem. Prave to "zaplat znovu, co uz jsi jednou zaplatil"... ne, takhle to fungovat nemuze a nebude. A pokud nekdo vyviji neco na v dane dobe uz zastaralych knihovnach, protoze mu to prijde jako skvely napad (no spis je za tim projev lenosti se naucit neco noveho, ktery si nejak ospravedlnujte), tak by si mel najit jinou praci. I v zemedelstvi se postupy meni a vyviji, proc by to melo byt u programatoru jinak?

> No, pak se bavime o nespravne nastavenem modelu financovani, ktery proste nepocita s nejakym zivotnim cyklem.
Ono počítá, s životním cyklem po dobu záruky. Pokud to chcete jinak, musíte si zaplatit (extended záruku, portaci nového software na starý HW, ...). Třeba v oblasti SOHO -- proč si myslíte že je všechno levné? Protože výrobce za produkt ručí 2 roky. Pokud by měl ručit více, bude to samozřejmně dražší. A ve finále to není úplně výhodný deal. Starý hadware těžko naučíte novým kouskům.

Danny, takze navrhujes dat treba do aut nebo lekarskych pristroju nejnovejsi technologii (idealne necertifikovanou) s nejnovejsimi knihovnami (samozrejme neodladenymi)? Nic ve zlym, ale rozumis tomu stejne jako duchodkyne Pohlova internetum… treba do aut se davaji komponenty ktere jsou odzkousene a ve spouste pripadu prosli nejakou certifikaci, tudiz nejsou nejnovejsi, tudiz k nim budou starsi knihovny… podobne to funguje u vyroby leku, nuklearni vyrobe,… libi se mi jak si lidi kteri tomu rozumi maji najit jinou praci zatimco clovek ktery evidentne dane problematic nerozumi se bude k tomu vyjadrovat stejne horlive jako neziskovka prosazujici prava specifickych mensin.

No zrovna automotive se sbirkou prikladu deravosti co se (be)bezpecnosti tyce jen hemzi zeano. Dost casto prave proto, ze nekdo vezme tu starou (kdysi davno i certifikovanou) vec a moc se netrapi nejakou inovaci... a par spitalu na to dojelo uz taky. Problem tehlech segmentu je prave to, ze to jednou nekdo certifikuje a.... dal nic. V podstate zadnej zivotni cyklus software, maximalne se flikuji prusvihy, kdyz se na ne ne opravdu tyce.

Ano, pak se taky dějou věci ... Auta vám otevře základoškolák (https://www.usenix.org/system/files/sec15_supplement.pdf), přes děravý bluetooth zapnete třeba brzdy (https://thehackernews.com/2025/07/perfektblue-bluetooth-vulnerabilities.html) a přes děravý XPčka na CTčku hackeři shodí celou nemocnici (https://en.wikipedia.org/wiki/WannaCry_ransomware_attack) ... Nicméně je důležité že to je celé certifikované a používá to staré dobré odladěné knihovny. I ty díry tam jsou evidentně dost odladěné a za ta léta i řádně otestované ;-)

Ano, musíte třeba aktivně navrhnout cesty na DPS. Musíte aktivně přidat např. další konektor, šváb etc. Musíte aktivně řešit že před 10 lety byly součástky jiné velikosti než dnes. A co se týče SW, tak aktivně naportovat starý kód na nový kód. Zvětšit si code-base, zvětšit si počet hodin testování, napsat nové testy. Navíc riskovat že kvůli těm pár součástkám a jednomu švábu navíc neprojdete EMI etc.
Takže pokud se zabýváte HW a SW, tak zcela jistě víte že to není copy&paste. (osobně se zabývám SW, HW mám jako koníčka, takže je možný že píšu blbosti)

> A jedna ze zásad inženýrského vývoje SW bývala použij nejstarší možné verze knihoven, které ještě k řešení problému stačí

To bývala a je zcela špatná. Platila dřív než se rozmnožili takový ti pánové co Vám přes díru v knihovně hacknou celý systém.
Dneska bych řekl že je spíš rozumné postavit nové řešení na bleeding-edge verzích, protože než Vaše řešení dopíšete, bude to stable...

To bývala a je zcela špatná. Platila dřív než se rozmnožili takový ti pánové co Vám přes díru v knihovně hacknou celý systém.

Říká se tomu inženýrský konzervatismus. Neříkal jsem děravé knihovny. Děravý nerovná se vyhovující. Ale jak chcete vychytat maximum děr v nějaké verzi nějaké knihovny, když za chvíli máte další verzi s dalšími hyper cool featurami (které ve skutečnosti ani nejsou tak důležité), s předělaným API, protože pro nějakou věc se to zdá být výhodnější (a pro jinou zase ne, na což se přijde v další verzi), přičemž starší verze se označí jako zastaralá a ukončí se podpora... A samozřejmě ty nové serepetičky a změny s sebou nesou další nové chyby.

A jak se posuzuje (ne)dulezitost? :-) Ze neco nepotrebujete vy prece neimplikuje, ze to je nedulezite. Mluvite abstraktne a systemem, ze nejlepsi podle vas by asi bylo vsecko zakonzervovat. Takove to sroubovaci pojistky prece bohate stacily, tak proc osazovat zasuvkove okruhy proudovym chranicem.

Tady je hezky vidět, že nemáte tušení, o čem Biktop píše. Protože v té analogii s pojistkami pojistky naprosto stačí pro ten účel, pro který byly navrženy (ochrana proti nadproudu), dnes stejně jako před sto lety. Proudový chránič je ta nová featura, která pro spousty účelů může být vnímána jako nadbytečná a nedůležitá (ochrana proti dotyku například u transformátoru nebo topné spirály nedává moc smysl) a není kvůli ní potřeba předělávat pojistkové skříně a leckdy i nové rozvody.

Ano, těžko se dá na této úrovni mluvit konkrétněji. Samozřejmě, co mně připadá zbytečné, může být pro někoho jiného něčím, bez čeho od teď nemůže žít. Snažím se na to dívat inženýrským pohledem. A ten se stal v SW vzácností.

Když něco nefunguje, oprav to. Když to funguje, nehrab do toho. Vyhovující řešení nahrazuj jiným jen tehdy, můžeš-li doložit prokazatelné výhody z toho plynoucí. Novější nerovná se lepší. Méně je často více. Hlídač hladiny na WC a v nádrži s louhem by mohly v zásadě fungovat úplně stejně, ale selže-li ten na WC, nebývá to takový malér jako u toho louhu. Známá chyba je menší problém než chyba, o níž nevíš. Každá nová technologie má neznámé chyby. Oprava chyby může mít za následek vznik nové neznámé chyby. Co se může pokazit, to se pokazí. Co se nemůže pokazit, to se taky pokazí. Jediný aparát, který nikdy neselže, je ten, který neexistuje (platí i o LOC). KISS.

Tavné pojistky se stále používají - tam, kde to má opodstatnění. Nikdo jejich podporu neukončil a nenutí mě nákladně předělávat starší rozvaděče, zvlášť když se tam pojistka mění jednou za uherský rok. Navíc jejich princip je jednoduchý a přímočarý, jsou spolehlivé, nejsou choulostivé na vnější vlivy. Proto na řadě míst máte tavné pojistky předepsané i v nových technologiích. Proudový chránič je po pár letech zralý na výměnu, protože degradoval a svou funkci přestal plnit, o čemž se většina uživatelů ani nedoví. Tím neříkám, že by se neměly instalovat.

Kdybych se držet těch analogií co tu padly, tak bych byl nucen předělávat DPS jen kvůli tomu, že trubičková pojistka někomu připadá jako překonaná nepoužívaná technologie (o čemž svědčí i to, že její design nikdo už desítky let nevylepšoval), její výroba je údajně drahá a nevyplácí se, proto se vše, kde se k všeobecné spokojenosti používá, musí vyměnit nebo nahradit za jistič. S tím, že s tímto "pokrokem" si musím dát pozor na silná magnetická pole, krytí, pravidelnou kontrolu funkčnosti a celé to stojí o řád víc peněz.

> A jedna ze zásad inženýrského vývoje SW bývala použij nejstarší možné verze knihoven, které ještě k řešení problému stačí, a pozor na věštění budoucnosti a řešení neexistujících problémů.

Jinými slovy už v době návrhu a výroby uděláte systém zastaralým, a pak smutníte na Rootu, že vám to nechtějí podporovat?

Mně to přijde absurdní. Já to dělám přesně naopak - snažím se používat to rozumně nejnovější. Ušetřím si tím právě problémy s podporou, alespoň první pár let (nebo 10 pokud jde třeba o LTS Ubuntu). Navíc to má problémy i s použitelností - si představte, že dotaženo ad absurdum by jistě na spoustu věcí "stačil" nějaký 20 let starý linuxový systém - ale jaký to asi bude mít uživatelský i vývojářský komfort (tehdejší GCC, Python 2, debuggery, IDE…), a jaké náklady přidá, když pak někdo bude potřebovat takový systém propojit s něčím současným…

A pak během vývoje narazíte na bugy které jsou už v upstreamu dlouho opraveny; nebo pokud opraveny nejsou, tak je opravíte, ale opravil jste si je jen vy sám a zbytek světa - včetně té vaší požadované podpory - jejich opravu mít nebude, protože koho by zajímala oprava v nějaké staleté knihovně. A to je další důvod proč pak nebudete moci upgradovat a mít podporu.

20. 9. 2025, 18:37 editováno autorem komentáře

Většinou bývá jednodušší dostat na novější systém starší knihovnu než naopak, ale hlavně: slušný software (programovací jazyky, API, datové formáty, síťové protokoly) poskytuje zpětnou kompatibilitu. Takže když se jako autor programu např. dobrovolně omezíš na starší verzí C, C++ nebo třeba Javy, tak tvůj program půjde přeložit a spustit jak na nejnovějších systémech a kompilátorech, tak třeba i na dvacet let starých. Stejně tak když budeš generovat třeba PDF ve starší verzi a dáš si záležet na jeho kompatibilitě a čitelnosti. Ano, podporovat cíleně dvacetileté rozpětí je asi už trochu extrém, ale uvádím to jako příklad. Naopak když použiješ vlastnosti z nejnovější verze jazyka (formátu, protokolu atd.), která se sotva teprve objevuje v distribucích, tak si sice ušetříš nějakou práci, připadáš si, že to děláš moderně, ale zároveň zkomplikuješ život dost lidem, kteří ten tvůj software mají používat a z nějakého důvodu nemohou upgradovat.

Kdo chce skloubit kompatibilitu s novou funkčností, tak se bude snažit o tzv. progressive enhancement tzn. použije nové funkce, pokud jsou dostupné, a jinak si vystačí s tím, co má.

Na tohle není universální odpověď – chce to odhadnout vhodnou míru konservativismu pro daný obor, projekt, zákazníka…

Cpat na novy system starou knihovnu je stejna blbost, jako krecovite do stareho systemu roubovat knihovny nove. Kdyz vezmu jen ten vas priklad s Javou - tak pri stari dvaceti let jsme nekde na urovni 5u6 a to bude derave jak cednik - mj. dilem i proto, ze u novejsich zranitelnosti uz ani nikdo neztraci cas tim, ze by vubec zkoumal, jestli tam je ta dira taky. Neboli jinak receno - to, ze vam u novych chyb nekdo tu vasi muzejni verzi nezmini rozhodne nikterak negarantuje, ze tam ta dira neni taky. Provozovat neco takoveho a nedejboze to tlacit do novych deploymentu muze jen nezodpovedny blazen :-) A samozrejme se nemusime omezovat jen na Javu, to jde aplikovat na cokoliv... treba i OpenSSL z te doby pred 20 lety je uz deset let fakticky neudrzovane.

Konzervatismus je hezka vec, ale realne tenhle vas "genialni" pristup vede k tomu, ze se pak zbytecne resi prusvihy proto, ze provozovane slepence software stoji na nezaplatovanych knihovnach. Praxi, kdy si nejaky softwarovy produkt tahne sve (casto dost zastarale) verze knihoven je bohuzel velmi rozsirena. A pak se pak vsichni divi, ze veci v ramci nejakeho utoku popadaji... nezijeme v idealnim svete, kolem beha spousta tech co ma motiv skodit a podobne diry aktivne vyhledava.

Pricetne, neasi.

Já to dělám přesně naopak - snažím se používat to rozumně nejnovější.

To je spíš jen hra se slovy - jaký je rozdíl mezi rozumně nejnovější a rozumně nejstarší... Ale zásadní upgrade infrastruktury má být opodstatněn jen zásadními inovacemi technologií ji využívajících. I za cenu toho, že ta infrastruktura není ideální - to totiž nebude nikdy.

vývojářský komfort (tehdejší GCC, Python 2, debuggery, IDE…),

Tak jestli vývojář v podstatě nutí uživatele zásadně měnit HW/SW kvůli svému IDE, tak to už neříkám nic. Snad jen, že by se měl živit jinou profesí.

Tezi o hledani si jine prace jde uplatit i na tzv. "vyvojare", kteri se s podobnymi plky o tom "jak to staci" drzi starych a jiz neudrzovanych verzi knihoven a produktu, ktere jejich tvurce uz davno neudrzuje.

Ono to někdy je poměrně složité. Kupříkladu máte software, který dodavatel vyvinul a otestoval, zprovoznil u významných zákazníků. Ten vyberete ve výběrovém řízení (cca 6-12 měsíců) k implementaci ve firmě (3 měsíce PoC, 6 měsíců testovací prostředí, 6 měsíců produkční prostředí. Následuje zhruba půlroční baby-sitting období, kdy ladíte integrace s ostatními aplikacemi.
Když přijde aplikace do normálního provozu, je tedy minimálně dva až tři roky stará.
A, řekněme, že má v závislostech třebas takovou Javu, která udělá generační skok, novou LTS versi, která přináší určitou míru nekompatibility.
Následuje tanec mezi bezpečnostním oddělením, které trvá na dodržení EOL a upgradu Javy, a dodavatelem, který není tak rychle schopen to překlopit na podporovanou versi Javy... (Pozn.: ta Java je jen příklad - těch komponent v závislostech bude určitě mnohem více...)

Ale tady se nebavime o vecech, co by se tahly par mesicu... ale o tom, ze ten "produkt" je realne vystaveny na dvacet let starych knihovnach, co se uz davno neudrzuji. A spoleha se ciste jen na to, ze se v tom nikdo stourat nebude. Aneb hlavne ze to vypada hezky/moderne navenek (takze vyvoj probiha), ale ze je uvnitr hnuj se neresi...

Jenže ono to často bývá přesně naopak - kvůli faceliftu se požaduje nejnovější HW/SW, ale funkcionalita je v podstatě pořád stejná.

Jiste, a proto se auto po faceliftu ma problem pripojit k wifi AP, co ma WPA3.... :-) Srandovni byly i problemy s retrofity LTE, kdyz se vypinaly 3G site... kde se to vyresilo proste tak, ze zakaznik se poslal do mist, kde slunko nesviti.

V realitě se to řeší tak, že si udržujete náhradní díly nebo pak sháníte starší kusy na eBay ;-)

Ono spoléhat na to, že vám to bude někdo vyvíjet a upravovat dle nejnovějších trendů je ošidné. Zvlášť u mašin které jsou vyvinuté pro vás nebo vyrobené v několika málo kusech.

Máme tu několik stojů a přístrojů které dobře slouží, není důvod je vyměňovat ... a to přesto, že jejich výrobci před lety skončili, zkrachovali nebo je koupil někdo větší a zrušil jejich výrobní program... A co včil?

Vyhodíte spektrometr za mega jen proto, že jeho ovládací SW (tedy hlavně driver) jede jen na Win98? Ne, zabezpečíte aby ta stanice s Win98 nemohla na síť a síť nemohla k ní, nastavíte jednosměrný přenos dat ze spektometru na úrovni technologie Win98 (např. serial port) a můžete to provozovat dokud to bude výhodné.

V rychlosti jsem prolétl optional complexity, ...

> We can develop a reliable XML generator on few lines of code because we can implement only the subset of the standard that we need. Writing such code is much more sane than including some bulky library that has several orders of magnitude more lines of code than our program.

... tomuhle se musím jen smát. Pak přijde někdo že by chtěl do XML tohle. Pak někoho napadne že by tam chtěl "<" a někoho jiného napadne že by tam poslal UTF znak. A přesně takhle vznikají bugy v software (a vývojové tasky se prodlužují na extrémní čas) kterým lze zabránit úplně jednoduše. Použít knihovnu na které pracuje N vývojářů a tyhle dětské chyby už má dávno odladěné.
Schválně by mě zajímalo kdo racionální zaplatí čas programátorovi aby si nastudoval celou specifikaci XML dopodrobna a nenasekal tam při renderu jednu chybu.
Nedej bože že se přijde požadavek mít output formát variabilní a chudák programátor místo aby napsal nějakou abstrakci rovnou (protože "We should avoid unnecessary complexity") bude horko-těžko dostávat pryč XML generátor a abstrahovat to ;-)

Ale pravda, pro opravdu jednoduché tooly to možná dává smysl. Pro reálný softwarový vývoj pro klienty (kteří reálně ani nevědí co chtějí teď, natož co budou chtít zítra) už o dost méně...

Tak ono záleží na analýze. Něco jiného je, že klient neví, co chce, něco jiného je, že třeba děláte interface pro nějakou průmyslovou mašinu, tam opravdu není nejmenší důvod, aby pro (třeba) teplotu vrtáku nebo výšku hladiny emulze někdy v budoucnosti používal utf8 znak, takže printf() je naprosto dostatečný (naopak by Vás velmi rychle poslali do háje ostatní zákazníci, které celkem nezajímá, že i nový výstup je přesně podle specifikace jako to, že kvůli Vašemu updatu se jim zastavila fabrika, protože s utf8 pro změnu neumí pracovat jejich interface)

Už zase?!

Objektivne? :-) Predpokladam, ze sam nedisponujete informacemi, ktere jsou motivaci na strane tvurce - zato jste skalopevne presvedcen, ze to delaji blbe. Pro vas coby konzumenta produktu muze byt zmena neprijemna, ale bez dalsiho nelze dovodit ze tvurce dane veci na tom bude lip, kdyz zachova rozhrani, na ktere jste zvykly. Porad tam vidim predevsim soucty z pohledu vasi kapsy, aniz by nekde bylo objektivni hodnoceni dopadu na kapsu protistrany :-)