Portál AbcLinuxu, 2. května 2025 20:00
Pořád nějakej blbej komiksTen "blbej komix" je porad lepsi nez tvoje zvratky na diitu
aspoň víme komu z rootí redakce komix vadil a kuli komu se to teda jakože vyplo :D :/ :D :/
Desktop jsem dávno opustil a pro svoje domácí žvýkání používám 12 let starý ThinkPad W520, takže ještě Sandy Bridge. Na druhé straně grafický (ne)výkon, respektive nepodpora Vulkanu je trochu omezující, takže upgrade by si už zasloužil, ale za co, když W520 je poslední model s ještě použitelnou ThinkPad klávesnicí.
Btw. Hovorkův komix to tu drží nad vodou a dokonce ho tak v 95% případů i chápu.
11 let nemám potřebu nic měnit, protože stále stačí na vše co potřebuji. A pokud chcípne, mám v záloze ještě jeden identický repas. Ale už mám jeden typ vyhlédnutý.
Jo, jo, byl jsem to já. Nedávno se mi podařilo sehnat další knihu, kterou jsem roky nemohl získat, Helikonie: Léto od Briana Aldisse.
BTW. k tomu noťasu mám samozřejmě i dock, ale na ThinkPadu s jeho trackpointem jsem schopen hrát i střílečky, když na to příjde
[...] ale za co, když W520 je poslední model s ještě použitelnou ThinkPad klávesnicípouzival sem ze stejneho duvodu T420s (kde na rozdil od W (ci Non-S) rady neslo menit CPU, takze 2core),
Doma nemám novější/rychlejší stroj než Thinkpad T410 (i5-580M) z roku 2010. S mitigations=off
to (subjektivně) běží jako o polovinu mladší stroj v porovnání s výchozím nastavením prakticky všech dnešních distribucí. Problém je nicméně grafická karta (NVS 3100M), která je s nouveau nepoužitelná (má grafické artefakty a sem tam sestřelí kernel). Pro nvidia drivery sice ještě někdo udržuje patche, ale už né všechen SW běhá se starým OpenGL a udržovat to v chodu s aktuálním kernelem je peklo.
Poslední QtCreator navíc chlapci z Qt "vylepšili" tak, že se na tom stroji začal při psaní cukat kurzor, takže ač ten stroj umožňoval(vynucoval) psát podstatně kvalitnější SW, než "běžné Goldenfishovo 64-jádro", dojde asi v brzké době k jeho nahrazení. Co se dá dělat, pokrok nezastavíš...
Nutnost reverzního inženýrství tvorbu ovladačů pro Nvidie samozřejmě podstatně stěžuje, ale když je vůle, je i cesta, koneckonců lidé z nouveau taky začínali "na zelené louce". Bohužel na to ale člověk musí být extrémně inteligentní, do 35 let a nemít žádný jiný život (jak jsem si prakticky ověřil při reverse engineeringu Garminích map, což přede mnou taky byl 15 let nevyřešený problém) a tady už minimálně 2 ze tří požadavků nesplňuju...
V případě nestability nouveau driveru ale pravděpodobně nebude podstata problému v tom, že by dnes chyběly nějaké zásadní informace o tom HW, ale spíš v driveru samotném. Psát driver pro grafickou kartu není jako práce s buzolou děti... A z toho mála co o vývoji linux kernelu/driverů vím mi přijde jako sci-fi, že by zrovna tak podfinancovaný tým jako ten co dělá nouveau měl prostředky se nějak vážně zabývat problémy s 14 let starou kartou. Pro kterou mimochodem ty "otevřené" ovladače od Nvidie moc nových informací nepřináší, protože cílí pouze na karty od roku 2018, tedy o několik generací novější HW.
Takže abych to shrnul - ano, můžu začít trávit stovky hodin zkoumáním kódu ze subsystému kernelu o kterém vím úplné kulové nebo to zkusit "hodit" na někoho v mailing listu nouveau, ale reálně a pragmaticky pro opensource udělám mnohem větší službu tím, že si řeknu "fuck you Nvidia" a koupím si nový stroj s AMD...
a koupím si nový stroj s AMD...…s rozbitým EDID :) Tohle je bohužel jeden z těch problémů, které mě už párkrát potkaly - vidím problém, dokážu ho celkem jednoduše hotfixnout hnusnou editací kódu modulu, ale udělat z toho řešení, které mi přijmou do upstreamu (jak by tady mělo vypadat? nějaké kroutítko v /sys?), vypadá pro mě dost nedosažitelně… Jiný takový problém byl třeba „potřebuju aby šel otevřít sériák aniž by to sáhlo na RTS“ (protože různá Arduina používají RTS pro reset MCU, takže při otevření sériáku ho resetneš, a já bych se chtěl umět připojit k běžícímu programu). To nejde, protože se to vypíná pomocí ioctl, ale k tomu nejdřív musíš udělat ten open :). V modulu to jde snadno zakomentovat/změnit default, ale jak by mělo vypadat správné řešení pro upstream? Taky kroutítko v /sys? Přijmou mi ho, nebo řeknou „Arduino nesplňuje specifikaci sériáku (což je pravda, znásilňuje RTS ke špatnému účelu), tohle podporovat nebudeme“?
Ano, napsat patch/driver co "nějak" vyřeší tvůj problém a patch/driver co projde do upstreamu jsou dvě zcela odlišné věci...
sysfs je určitě dobré místo pro nestandardní API/parametry, ale dvakrát nadšení z toho maintaineři taky zrovna nebudou. Mně se nakonec povedlo je přesvědčit i o tom, že naše karta musí mít tu miliardu nestandardních nastavení co si přejí hardwareáři/manageři, včetně takových libůstek, že umožňujeme nastavit zkriplený pixel format mimo VESA rovnice, ale rozhodně to není něco, co bych komukoliv doporučoval dělat...
mkgmap generuje a qmapshack čte pouze původní IMG formát, co GARMIN už 15 let nepoužívá a má takové "prima" vlastnosti, jako že souřadnice jsou max 24b a tudíž ty mapy nemají jedinou pravoúhlou budovu...
GPXSee umí zobrazit i "nové" NT mapy, což je prakticky kompletně jiný (a mnohem složitější) formát.
pouzivat 13 let stary stroj je mimo realitu. Doba se trochu zmenila. Zkuste si zadat do GeekBench database ruzne procesory vcetne Vaseho a porovnat cenu.
Jak vidíš, jsou lidé co takové stroje běžně používají, takže mimo realitu je akorát tak tvoje představa, že to nejde, nebo to musí lidi nějak zásadně omezovat. Já ten systém používám jako "běžný desktop", ne na spouštění GeekBench benchmarku, takže mě zajímá jak se s ním pracuje jako s běžným desktopem a ne nějaká čísla v GeekBenchi. A s výjimkou kompilace C++, která by samozřejmě mohla být rychlejší, oproti "moderním" strojům (ano, pracuji i s takovými) nepozoruju nějaký zásadní rozdíl.
Planuju si nejaky HW cluster pro Apache Spark, nejake skalovani a je skvely, ze to jde vubec provozovat na beznym HW.
To stále "já o voze, ty o koze". Pokud budu chtít dělat "big data", "AI", nějakej korporátný SW v Javě nebo hipsterskej SW v Electronu, tak si na to (chtě nechtě) taky pořídím nějaký "dělo", protože tyhle věci prostě fungují na principu: ubijeme to výkonem HW. Ale tvá představa, že "každej přece píše korporátní SW v Javě" je prostě mylná.
Bohuzel ani nemate predstavu, kolik vlaken sezere GUI nebo IDE na 64 jadrovem stroji. Videl jste jak vypada load 128-900 na GUI aplikaci, kterou vyvojari spatne napisi, kdyz uz mluvime o tom 64-core ? A co by ta aplikace asi delala ? Eeeeee, vyvojar co dela na 64-core vyviji spatny SW, asi si nakrad, ...., krasny pribeh.
Tady bych asi taky chtěl nějaké věci rozporovat, ale bohužel tomu ani po desátém přečtení tak úplně nerozumím a přijde mi, že to ani není tak úplně napsáno česky...
Náhodou, to vypadá pěkně Já jsem aktuálně zprovozňoval a příležitostně provozuji následující kusy:
3D tištěné HTPC (stáří ~7 let)
Prehistorické SONY VAIO (stáří asi 13 let... až na baterku a vykvrdlaná USB fajn stroj )
a Fujitsu Lifebook AH512 (stáří také tak 12 let... jenom dostal víc paměti)
Na příležitostnou úředničinu a naučení pro děti ideální železo...
Já jsem původně nechtěl dát přes 15, potřeboval jsem ho ale hned a nechtěl jsem Intel, tenhle Ideapad tak bylo to jediný, co tam vůbec měli v rozumný konfiguraci s AMD...Ktery organ byl ten vecer generalem?
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.