Linux 6.10 To Drop Support For Very Old DEC Alpha Hardwarehttps://t.co/M2dPDsAV74
— Phoronix (@phoronix) May 6, 2024
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
ahogy nezem, power architektura atment a power.org hataskorebe, ami kb elhalt. ezt az osregi verziot en is dobtam volna a linux helyeben.
- A hozzászóláshoz be kell jelentkezni
https://openpowerfoundation.org/ és nem halott.
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Oké, javítanad a Wikipédiat? Köszönöm
- A hozzászóláshoz be kell jelentkezni
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Az egész Power az igazából IBM hatáskörben van, más nem gyárt Power ISA-val processzort, az egész alapítványosdi pont olyan, mint ahogy az Androidot hivatalosan az Open Handset Alliance csinálja (miközben a Google diktál).
- A hozzászóláshoz be kell jelentkezni
más nem gyárt Power ISA-val processzort
Dehogy nem, az NXP (az általuk megvett Freescale nyomán, ami meg a Motorola Semiconductors átnevezett/függetlenedett verziója volt). Mondjuk a többségét gondolom mihelyst lejárnak a hosszútávú support szerződések, dobják... De a 40x az amúgy egy embedded IBM mag volt, amit licencben még az AMCC gyártott, asszem. Nagyon low-end, no FPU és az MMU-ja is igen csak kezdetleges (ha egyáltalán volt) ami miatt elég sok külön codepath volt rá a kernelben, miközben sosem volt egy igazán népszerű mag, gondolom. Vagy nem olyasmi, amire manapság modern kernelt akarnak rakni (set-top-boxokat, hálókártyákat, ilyesmiket hajtott, rendszermanagement processzorként is használták, stb). Amúgy ehhez hasonlóan az ős-PowerPC 601-et is szintén a "specialitásai" miatt raktak ki pár éve.
Gondolom a 440-es sorozatra, ami a 400-asok "nagytesója", és van benne FPU meg rendes MMU az eltávolítás nem vonatkozik, de ezt nem néztem meg.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Van nekik (vagy volt?) rendes 64 bites power procijuk is. Lásd: https://www.nxp.com/products/processors-and-microcontrollers/power-arch…
- A hozzászóláshoz be kell jelentkezni
Én tudom. :) Asszem annyi a "probléma" mindössze, hogy ezek mind big-endian only chipek - ha jól tudom, legalábbis a hozzájuk adott ökoszisztéma/SDK pár éve még BE only volt, mostanában nem néztem -, és az NXP nem is ugrál hogy PPC64LE-t csináljon hozzájuk, amivel csak az a gixer, hogy egy rakás FOSS projektet meg az IBM tart karban akik meg erőből tolnak mindent a little endian felé... Az NXP amúgy is hajlamos "egy bizonyos" verziót, vagy custom tree-t szállítani bootloaderből, kernelből, driverekből a chipjeihez, aztán ez van, osszad be... Ha van elég igény, akkor előbb-utóbb lesz persze mainline support is, pl. az iMX ARM SoC chipekhez is lett lassan-lassan... De sok sikert hivatalos supportot kapni, ha nem az NXP-féle tree-t használod. Legalábbis 4-5 éve még így volt. Mostanában kimaradtam ezekből kicsit.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Régen fejlesztettem ilyenekre kernelt, de igen ez a big endian dolog okozott gondot. Elvileg támogat little endian módot, de mivel hálózati eszközben volt a big gyorsabb network byteorder miatt. Viszont cserébe nem ment a kexec normálisan.
- A hozzászóláshoz be kell jelentkezni
ez a ceg hogy van meg eletben? vannak osregi rendszerek akik vendorlockin-ben ragadtak es oket fejik?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Én szerettem ezeket a vasakat.
- A hozzászóláshoz be kell jelentkezni
Nekem nincs velük tapasztalatom, meg nem használok ilyeneket, így nem fog hiányozni, de elvi síkon nem támogatom, hogy funkciókat vegyenek ki, ezt ráadásul újabban feature-ként reklámozzák, harangozzák be a soydevek, akiknek újabban most ez a mániájuk, hogy miden legyen mesterségesen elavultatva, támogatása megvonva, nyírjuk ki, stb.. A Phoronix írta, hogy mindezzel csak kb. 4400 sornyi kódtól szabadulnak meg, hát az kb. semmi a Linux kernel 1 gigás méretéhez, 16 millió kódsorához képest, csepp a tengerben, akár benne is hagyhatnák. Értem, hogy ezek elég régi, legacy platformok, talán már nem is futtatják elfogadható teljesítménnyel a modern kerneleket, disztrókat, de én a helyükben benne hagynám, amíg nem jön elő javíthatatlan bug, amit fenntartó hiányában nem tudnak tovább patkolni.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Teszteletlen kódot nem érdemes megtartani. Bármikor eltörhet és a kernel esetében simán okozhat akár hardver hibát is. Teljesen irreális ilyen vasakon modern Linux kernelt futtatni.
- A hozzászóláshoz be kell jelentkezni
de én a helyükben benne hagynám, amíg nem jön elő javíthatatlan bug, amit fenntartó hiányában nem tudnak tovább patkolni.
Valahol olvastam, hogy az Alpha EV5 port már egy ideje broken, a port egyes részei tele vannak kóddal amik nem tudnak működni jelen formájukban azon a gépen, és minden jelenlegi disztró ami még támogat Alpha-t (pl. a Debiannak van portja rá), az ennél újabbat kér. Szóval vagy kivágják, vagy masszív bugfixeket igényelne... Amit senki nem akar beletenni.
A PPC portot meg jelentős részben az IBM és vidéke tartja karban és a corporate controlled open source keretében szeretnek belőle mindent kihajigálni, ami nekik már nem kell és "útban van". Gondolom a 40x-ekre is lejárt valami support szerződés, és mivel ezek a low-end PPC-k sok speciális kódot igényelnek, senki nem ugrál a karbatartásukért... Meg amúgy is, valszeg nem számítana az sem, ha valaki fellépne karbantartóként. A Go is így járt, abból az egész 32bites PPC-t meg a 64bit régebbi verzóinak supportját is kivágták pár éve, hiába jelentkeztek volna külsős karbantartók rá...
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Ja, ez így más. Ha tényleg el van törve az Alpha kód benne, és a PPC-t meg maga a kódfenntartó, az IBM nyírja ki, akkor azzal a Linux kernelesek valóban nem tudnak sok mindent kezdeni, csak kiszedni, bár én még ilyenkor sem feature-ként reklámoznám.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Oh ... nem az ellen vagyok, hogy kivegyék a kódjukat. Mindössze nosztalgiáztam egy pillanatra ...
- A hozzászóláshoz be kell jelentkezni
mindig akad valami minimal oprendszer, most is van? Mint 20 éve volt a linux, amíg nem lett 16 millió soros a kernel :)
- A hozzászóláshoz be kell jelentkezni
Persze! Az Android killer hogyishijjákaneve, ami a HUPkó Linux/Android Hater Group szerint már 5 éve megölte az Androidot és a Linuxot is! Mi is a neve ... Valami növény ... Fuchsia vagy mi ... Má' mingyá' lenyomja!
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A Fuchsia nem ellensége a Linuxnak vagy Androidnak. Nyílt forráskódú rendszer az is. Működőképes és számtalan előnyös képessége van a korábbi mikrokerneles rendszerekre jellemző teljesítményvesztés nélkül. Felépítéséből adódóan biztonságosabb és jobban skálázható rendszer. A Google-nél folyamatos a fejlesztése de nem tűnik úgy, hogy közeljövőben kezdenének vele valamit. Ezalatt Kínában az amerikai eredetű boszorkányüldözés miatt pályát módosított Huawei fejlesztett valami nagyon hasonlót mint a Fuchsia. Ez a Harmony Next. Sajnos a teljes rendszer nem nyílt forráskódú, csak a rendszer magja. A Fuchsiaval ellentétben ez már nem csak egy labor OS hanem hamarosan eszközök millióin működő rendszer. Okosórától mobiltelefonokon át szuperszámítógépekig jól skálázható. Akár okosóránál is gyengébb hardverű beágyazott eszközökön is elfut. A Linux kerneles android-variáns wearos ma is kínlódik okosórákon, itt már előnyben van a Harmony next. Egy másik előnye, hogy a jövőben lehetőséget teremt az Android és iPhone mobilokban is megtalálható második önálló SoC rendszer elhagyható legyen, amin networking és telephonyt biztosító önálló rendszer fut. Újra visszaköltözhet a fő rendszer processzorára ez a funkció, ami azóta már sok magos SoC chippé fejlődött minden mobilban. Valaha egyetlen arm magon megfért egymás mellett a mobil hálózat kezelése és a többi okostelefonos funkció. A Symbian ezt 70%-30% nem túl hatékony fix időosztással oldotta meg, de legalább stabilan. Openmokon állítólag Linux kerneldriver oldotta meg a mobil hálózat kezelését, erről csak olvastam nekem nem volt Openmokos mobilom.
Ennek a jelentősége abban áll, hogy pont az 5G technológiákat elsők között támogató Huaweihez kötődő HiSilicon Kirin chipek miatt kezdődött az amerikai boszorkányüldözés. Ha a ma szilíciumba öntött hálózatos kommunikáció teljesen szoftverré változik, akkor könnyebbé válik az arm gyártók közötti választás, persze ha Harmony Next a mobil rendszere. Nemzetközi jogi bohóckodással is nehezebb fogást találni rajta.
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
tl;dr
Én a HUPkó szakértők évekkel ezelőtt elhangzott vágyálmait figuráztam itt ki. Kb. leszarom mit tud a Fukszia, évek óta nem hallottam róla.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Á, közben néztem, nem is annyi már, 1 helyett 1,4 gigára rúg, és 25 674 430 kódsor már közben a Linux kernel (a legutóbbi 6.9-RC7), bár nyilván ebből nem fordul az egész, mert csak 1 architektúrára fordítod, meg nem minden drivert, API-t forgatsz bele, csak ami neked kell, de azért nem egy csöppség. A BSD-k kernele kisebb, bár nincs pontos adat, mert ott a komplett core utils meg minden bele van mérve, de a FreeBSD (~9 millió kódsor), OpenBSD kódbázisa (~3 millió) se kicsi, igaz ez nem mind kernel, így soványabb még, de folyton híznak azok is.
Ha most izgalmas, minimál, POSIX kompatibilis OS kell, akkor Plan9/Inferno, Haiku, Redox OS, amin van is fejlesztés érdemben, többen dolgoznak rajta, igaz a hardver, szoftvertámogatásuk még elég ergya.
Linuxnál nem csak a kernel aggasztó, már önmagában a systemd-ben is van 1,6 millió kódsor, gcc/llvm-ben még több, Rust 1,6 millió LOC, böngészők is ilyen kellemes 16 millió kódsor környékén vannak, amikor ez a sok bloat összeadódik, azért az nem olyan jelentéktelen kódméret egy komplett OS-nél. És akkor még ilyen LibreOffice, meg mást nem is számoltunk hozzá, meg Gtk4, Qt6 hegyeket, nagyobb DE-ket, Electron, Flatpak köztes rétegeket, amik még futnak. Brutál tud lenni.
Androiddal az a baj, hogy nem csak hogy szar, de a Google rajta tartja a kezét, a Fuchsia meg olyan, hogy van, de sose készül el. GNU Hurd esetleg, de hát az is kb. annyira használható, mint egy nyél nélküli wc-kefe, kb. semmin nem fut el normálisan.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
A Linux kernelt is eléggé le lehet slankítani, ha kidobálod belőle, ami nem kell. Pár éve csináltam egy saját Buildroot alapú rendszert, Amigára. A kernelt magát 5-6 mega köré ki lehet hozni, emlékeim szerint, ha elég erősem próbálod, meg nem kellenek ilyen úri murik bele, hogy USB... :D (5.valahanyas kernel, 5.10 talán?) 50Mhz-s 68060-n egész jól ketyegett, 128MB RAM-mal, volt hálózat, minden. A legnagyobb gáz az a disk I/O sebessége volt - max. 2MB/sec, PIO0 az alaplapi IDE port egy Amiga 1200-esen, szóval pár nagyobb szoftver használata türelemjáték volt. Még akkor is, ha egy SD kártyáról futott az egész - tehát nem arra vártunk hogy egy pörgő rozsdalemez felett kóvályogjon az olvasófej. De az akkori komplett céges embedded IoT stackünk végülis tök jól ment rajta. MQTT kommunikáció, Python 3.x, adatbázis, minden...
(Van róla unlisted YT videó is, de nem akarom linkelni, mert van benne pár céges logó, meg evetélt termékekre referencia, amit nem kéne mutogatni, azt mondták... Kár érte.)
Már régóta rajta van a listán hogy áttolom az egészet egy 33Mhz-re overclockolt 68040-es Mac Performa 475-re, aztán akkor az működhet mind dedikált 68k-s Linux tesztgépem. Főleg hogy azon van alaplapi SCSI verzérlő is, szóval TALÁN annyira nem fog fájni, még ha a proci jóval lassabb is lesz...
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
5-6 mega? Ne már.
Embedded cucchoz csináltam minimál kernelt, 1.5 mega körül belefértem. Van benne hálózat és diszk kezelés, oda ennyi kell.
- A hozzászóláshoz be kell jelentkezni
Egy eszköz specifikus monolit kernel még x86-ra is ki szokott jönni ilyen 20-30MB-ból. ARM-on olyan 5MB, ha nem optimalizál méretre.
- A hozzászóláshoz be kell jelentkezni
Most kezdek majd nemsokara RISC-V-re portolni ezt-azt, kivancsi vagyok mekkora lesz. Bar nagy kovetlemenyek elsore nem lesznek (valami SD kartyas hattertar, HyperRAM alapu memoria), es egy soros konzol. Az a lenyeg hogy ezutobbin keresztul majd az `mc`-t el lehessen inditani, mert akkor mar munkaeszkoz is lesz...
- A hozzászóláshoz be kell jelentkezni
Az már jó régen lehetett. Most körülnéztem a gépemen a Yocto-val épített cuccok között, és a legkisebb kernel 3MB körül van. Az övék: https://www.openbmc.org/
A 4.14-es i.MX7-es kernel is 7.5MB, az 5.15-ös pedig már 9.5MB. Pedig az csak egy 32-bites proci.
- A hozzászóláshoz be kell jelentkezni
A yocto egy bloatware ahhoz képest, amivel én szoktam dolgozni :)
1.37 MB, 6.2.5, ARM-ra fordítva.
Nyilván optimize for size, xz tömörítés, és semmi sallang, még modulok se. Egy busybox-ot futtat csak kb. Ez persze nem a "production" kernel, ez csak egy recovery módhoz kell. Ha kell, akár soros vonalon is le bírom küldeni, ez a lényege.
- A hozzászóláshoz be kell jelentkezni
Igen, de ha sovány kernelt akarsz, az kicsit művészet, fekete mágia. Nagyon kell érteni, hogy milyen feature-ök kellenek neked, mik nem, mint szedhetsz ki, hogy még működjön. Gentoo-n ezzel én nagyokat szívtam, vagy 100× kellett leforgatni a kernelt, mert mindig kimaradt valami a támogatásból, EFI stub boot, ThinkPad buttons, ACPI, stb.. Ész nélkül sem lehet szedegetni, mert akkor tényleg be sem bootol, nem működik. Szerteágazó terület, kell hozzá tapasztalat, kezdőnek nagyon frusztráló, ha nem tudja mit csinál.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Az óidőkben -- igaz, hogy NetBSD-hez -- volt egy olyan csomag, 'adjustkernel' néven, ami a 'dmesg' kimenete alapján ,,kigyomlálta'' a NetBSD kernel egyetlen konfigurációs állományából azokat az eszközöket (bejegyzéseket), amelyek ugyan benne voltak az alap 'GENERIC' kernelben, de a dmesg nem találta őket meg...
"Share what you know. Learn what you don't."
- A hozzászóláshoz be kell jelentkezni
Nem tudok róla, hogy Linuxnál lenne ilyen tool, bár nem tartom kizártnak. Nekem még nem jött szembe. Csalni azért lehet Linuxon is, egy fullos generic disztrót bebootolva megnézni, hogy milyen firmware-csomagok vannak fent, meg lsmod-dal listázni a használt kernelmodulokat, az valóban segíthet egy picit, meg a Gentoo Wiki is említ sok mindent, hogy milyen funkciókhoz mit kell engedélyezni a kernel config-ban.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Ilyen témák jöhetnének a HW/SW p0rn kategóriában! :-)
- A hozzászóláshoz be kell jelentkezni