macbook 13" viheto ingyen (jotekony celra preferalt)

Adás - vétel - csere

Tipus: A1502   https://support.apple.com/kb/sp715

2014-ben vasarolt, retina

serial: C02NM3RNG3QH

 

A toltoje kicsit valogatosan toltott, megtort kabel miatt (magsafe2 tipushiba); javitottam folyekony gumival, de eleg rondan, bocs. A kijelzoje neha villodzik, valszeg a kabele a zsaneroknal "bekopott".

Akinek van ideje picit foglalkozni vele, prima kis gepet tud belole faragni.

Alapvetoen jotekony celra adnam szivesen, mittomen, iskola, nonprofit, arvahaz, ilyesmi. Ilyen jelentkezo hianyaban mehet barkinek.

Lokacio: pest megye.

  • 1003 megtekintés

( TCH | 2023. 09. 23., szo – 23:47 )

Helló, kösz a felajánlást, élnék vele, mert így tudok x86-os macOS-re is, meg PPC-s OSX-re is forgatni Lazarussal. :) (A mostani Lazarusok már nem mennek fel a régi PPC-s gépekre, de cross-compile-t tudnak.) Szóval, ha a YTFE Mac-es verziója jótékony célnak minősül, akkor vinném. :) Küldtem PM-et.
Oldschool Computer - http://oscomp.hu

( TCH | 2023. 09. 28., cs – 22:59 )

Jelentem, öcsémmel megpucoltuk a töltőcsonkot és a lukat is (neki vannak nagyon durva vegyszerei) és megy a gép gond nélkül, be is élesítettük rajta az El Capitant. :) (A kijelző nem gáz, úgyis HDMI + external monitor, meg external USB(-re konvertált PS/2-es) keyboard/mouse lesz ráaggatva.) Még szereznem kell hozzá egy TL-UE300-at (azt írták, ez megy 10.10-zel) és akkor még netem is lesz rajta. (WiFi-m nincs.) Úgyhogy a YTFE-nek, a PNG2ILBM-nek és a Wav28SVX-nek nemsokára lesznek macOS/OSX verziói is (hogy mikor, az még kérdéses), az opensource szoftvereimet/scriptjeimet meg innentől tudom tesztelni macOS/OSX-en is, mielőtt kiadom. Még egyszer nagyon szépen köszönöm a nagylelkű felajánlást, nagyon rendes volt tőled!
Oldschool Computer - http://oscomp.hu

( TCH | 2023. 10. 10., k – 22:35 )

Viszont, közbejött némi probléma: ez a micsoda valahogy lefrissítette magát El Capitan-ról Big Sur-ra. Van lehetőségem downgrade-re, legalább High Sierra-ig? Vagy wipe és reinstall?
Oldschool Computer - http://oscomp.hu

A fejlesztesed szempontjabol az a jo hir, hogy 15+ eve nincs olyan Mac, amin ne futna x64 binaris.

Az egyetlen fejfajas a no 32 bit miatt nekem a wine volt.

Talan ez a wine tutorial elmagyaraz par reszt veletlen: https://www.youtube.com/watch?v=mSIrhdofiQI

(Catalina elott vissza lehetett kapcsolni recovery mode-ban a 32 bitet, azt hittem azzal indit a video)

De egyrészt nekem forgatni is kellene 32-bitre és tegnap ez a Big Sur-on meghiúsult és nem értettem miért, mert azt hittem, hogy El Capitan. Másrészt meg a Catalina-tól kezdve az Apple teljesen kinyírta a 32-bites binárisok támogatását: futtatni sem lehet őket sajnos.
Oldschool Computer - http://oscomp.hu

Mi vagy te, NetBSD? ;)

A macOS i386-ot nincs ertelme tamogatnod. Senki nem fogja hianyolni. De ha annyira akarod VM - regi OS X mukodo, de nem egy agyondokumentalt ut. Szerintem messze nem er annyit se az i386 port. A tobbi ut, beleertve a downgrade-et ennel is rogosebb, foleg, hogy Big Sur idejere OS szintu fajlrendszer vedelem olyan feature-oket kapott, amit szopas korabbi macOS-en tesztelni. Pl. "FaszomSzoftver wants to access Documents" es tarsai. QTransmission es Deluge is evekig nem tudtak megugrani, hogy ne kezzel kelljen nekik full disk access-t adni System Preferences-bol, amikor ezek a fajlrendszervedelmi feature-ok bejottek.

Az x86_64-et jol es hatekonyan emulalja a Rosetta2 ARM64-rol. De amint eled kerul hasonlo modon egy M1-es Mac (a legregebbi is 2020-as), erdemes nativ verziot csinalni. Addig nem tudsz.

ppc es ppc64 - hat az max qemu-bol eselyes, gyors ugy se lesz.

Nem, de ebben speciel egyetértek velük. Ilyenkor kéne, hogy fontos legyen a diverzitás, amikor a választás lehetőségéről van szó, hogy legyen is miből választani. Eddig csak régi Mac-jeim voltak; PowerPC-sek, meg egy 2006-os Mac Mini, így csak azokat a régi OSX-eket ismerem (úgy-ahogy). A Tiger nekem speciel nagyon tetszik (bár sok helyen tőlem idegen), a Snow Leopard is egész jó...aztán most szembe jött a Big Sur és sikítottam, hogy mi ez a szar; hát ennyi hülyeség a windótízben sincs... És ezt akkor is leírom, hogy a Big Sur egy Big Szar, ha az Apple-pártiak megköveznek érte. Gránáttal. És a lassúság volt a legkisebb baja annak a rendszernek, csak, hogy tisztázzuk. Aztán a factory reset után megint egy egész kezelhető/használható rendszert ismertem meg a Maverickben. Az El Capitan se rossz, remélem a High Sierra se lesz az, mert úgy néz ki, hogy a Lazarusnak kelleni fog. Manapság mindent is szétkúrnak. Rommábutítják, egyre kevesebbet tud, de azt egyre nyakatekertebben és használhatatlanabbul és egyre több erőforrásért. Lehet hajbazerezni, de én ebbéli nézeteit 100%-ig osztom. Lehet, hogy néha túltolja a biciklit, lehet, hogy vannak tárgyi tévedései, de a nagy képet szerintem jól látja. Legalábbis én ugyanígy látom a nagy képet. Hogy egyre kevesebbet kapunk, egyre többért. Miért, a Solarist van értelme támogatnom? Használja azt valaki desktopként még? Pláne jútúbozik rajta? A jelek szerint igen. Szerintem van innen a hupról kemény egy (vagy kettő, ki tudja...) solarisos userem, bár lövésem nincs ki lehet az. De miért basszak ki vele? Ha megtehetem, hogy támogatok valamit, akkor miért ne támogassam, ha akár csak egy ember is a hasznát veszi? A build/upload úgyis automatizálva van, miből áll még egy verziót forgatni és feltölteni, ha működik? (Ha működik.) Hát, ha lesz ARM-os Mac-em, akkor nyilván azon fogok ARM-os binárist forgatni, addig marad a teszteletlen cross-compile. Igazából a Lazarus/FreePascal ökoszisztémában erre van lehetőség, bár reszelősnek tűnik a dolog... A QEmu itt viszont értelmetlen, két okból is. Egy: van igazi PowerMac-em. G4-es is, G5-ös is. Kettő, nem azért akarok crossplatform forgatni, mert a platform hiánya a probléma, hanem azért, mert a YTFE-hez szükséges Lazarus nem megy már fel a régi PowerPC-s Mac-eken futó OSX-ekre. (Értelemszerűen tök mindegy, hogy az a régi OSX real vagy virtuális vason fut.) Az 1.2.4 az utolsó, ami még működik ott, a YTFE-nek meg asszem 1.6.0, vagy 1.8.0 kell, nem tudom, hogy pontosan melyik.
Oldschool Computer - http://oscomp.hu

Te itt engem tobb ponton felreertettel.

Csupan azert akartalak dolgokrol lebeszelni, mert "nulla userert nem eri meg". Leginkabb mert tudom, hogy recent macOS verziok sokkal jobban meg fognak teged szivatni. :( Es az arra forditott valtozatot tobben hasznalnak, jobb annak a hulyesegeit tesztelni inkabb - mert van neki boven.

A ppc/ppc64 szuksegesseget amugy nem vitattam. A fejfajas ellenere se. De tenyleg fogadnek egy talca sorben, hogy nem fog kelleni az OS X i386 port senkinek. A Solaris-osnak fixen tobb usere lesz.

Sorry, félreérthető volt. Köszi a figyelmeztetést, de IMHO pont az i386 port fogja a legkevesebb fejfájást okozni: csak egy kapcsoló a Lazarusban. Ez az, ami nem akart menni a Big Surban. Hát, én meg nem hinném, hogy tényleg senki nem fogja használni; a Solarisról előbb hittem volna ezt, de ott se jött be.
Oldschool Computer - http://oscomp.hu

csak egy kapcsoló a Lazarusban

Nem azzal van a baj, hanem azzal, hogy Mojave es Big Sur kozott volt par idegesito valtozas, ami eltort korabbi OS X-en jol futo programokat. Ezert erdemesebb Bug Suron (is) tesztelni a 64 bites buildet.

Es itt jottem azzal, hogy en a Bug Sur hulyesegeit priorizaltam volna a 32 bites port helyett.

Oh... Azt tudtam, hogy a Catalinában kihajították a 32-bites cuccokat, de azt nem, hogy még a rendszert is összetúrták. Hát, kösz, hogy szóltál. Ebből asszem dual boot lesz; hely van elég... Mondjuk a Lazarus (a FreePascal) tkp. mindent is belecsomagol a binárisba (azért olyan böszme nagy), így neki az OS verziók közti middleware lib-ek API változásai nem sokat jelentenek; persze, ha még a kernelt is összetúrták az más. A torta próbája az evés; először megpróbálom a High Sierra alatt fordított binárisokkal és ha nem megy Catalinától felfele, akkor dual boot. Még egyszer köszi a figyelmeztetést.
Oldschool Computer - http://oscomp.hu
Nagyon úgy néz ki, hogy igazad lesz: az i386 compile ugyan megoldódott, viszont cserébe az ARM64 kinyúvadt. Mondjuk letesztelni amúgy sem tudom ARM-os Mac híján, de a semminél csak jobb. Szóval kinéz a dual boot; lehetséges utólag is kettéosztani az SSD-t adatvesztés nélkül, hogy a másikra Big Sur mehessen? Vagy kezdhetem előről az egészet, csak ezúttal előre ketté kell vágni az SSD-t.
Oldschool Computer - http://oscomp.hu

> Mondjuk letesztelni amúgy sem tudom ARM-os Mac híján

tesztelesbe tudok segiteni M1-en, ha nem jo akkor tudok ra tavasztalt is adni ideiglenesen

> lehetséges utólag is kettéosztani az SSD-t adatvesztés nélkül

hat a BootCamp telepito valahogy megcsinalja, szoval biztos, kerdes mivel? diskutil esteleg? google? :)

https://support.apple.com/hu-hu/guide/disk-utility/dskutl14027/mac

Az elso lepes mindenkeppen Disk utility, raadasul mig Linuxnal megszoktad, hogy umount mielott resize-olsz egy particiot, hfs+/apfs meg pont ellenkezoleg: csak online futo macOS-bol tud mountolt particiot resize-olni:

https://hup.hu/node/145008

Viszont dual bootot lehet inkabb ugy probalnek, hogy masik kulso diskre rakom a masik macOS verziot es arra bootolok. A bootcamp nem csak Windows-ra jo btw?

Nem a RAM-igény miatt, hanem a platformtámogatás miatt; valamiért létezett a 32-bites x86, mint platform az OSX alá. PPC-s Mac-eket is használnak az emberek a mai napig. OSX-szel is. Lehet, hogy lesz, akinek pont az kell. Ha már csak egy ember akadt, akit így megszabadítottam a YT JS-hegyeitől, akkor már megérte. (Egyébként a Snow Leopard-ból még volt PPC-s verzió, bár csak a bétáig jutottak vele.)
Oldschool Computer - http://oscomp.hu
Hát ehhez Mavericks (10.9) volt eredetileg, most arra áll vissza épp. :D Sebaj, felupdatelem 10.13-ra. Kösz a helpet. Sz*rk: Mennyivel gyorsabb, intuitívebb a Maverick... Minden elsőre ott van, ahol kell és úgy megy, ahogy kell; nem kell külön layoutot letölteni ahhoz, hogy menjen a magyar kiosztás (kivéve az Í betűt, de Big Sur-ban egyáltalán nem ment), nem görög fordítva alapból az egér, stb.
Oldschool Computer - http://oscomp.hu

( TCH | 2023. 10. 10., k – 22:50 )

Aztán: van valakinek XCode 8.2.1 és Xcode 10.1 telepítője? Apple ID telefonszámot kér, máshogy meg nem bírom leszedni. Az xcode-select --install csak a command line tools-t telepítette.
Oldschool Computer - http://oscomp.hu
Én soha nem adom fel. :) Látod, hány évig kerestem egy relatíve új, manapság használható Mac-et és a végén csak lett. :) Lesz XCode is, csak nem tudom, honnan. Bár lehet megkérek családtagot/havert, hogy segítsen bereggelni, aztán letöltöm és elrakom az XCode telepítőket.
Oldschool Computer - http://oscomp.hu

> megkérek családtagot/havert, hogy segítsen bereggelni

miert, nincs mobilod se? :)

> aztán letöltöm és elrakom az XCode telepítőket

ezt majd meseld el hogy sikerult. nekem mar vagy 2 eve nem megy az xcode letoltes mert kiirja, hogy big sur mar nem tamogatott, frissitsek os-t elobb :)

Nu, Sanyi letöltötte nekem a 8.2.1-est és a 10.1-est (lehet, hogy High Sierra lesz a dologból, mert a Lazarus se akar már felmenni 10.11-re), megy fel a tárhelyére, reggelre fent van, én meg szedhetem le. Mondom, hogy nem szabad feladni sosem. :)
Oldschool Computer - http://oscomp.hu

( TCH | 2023. 10. 28., szo – 22:10 )

Update: Sikerült a dualbootot megcsinálni, most van egy High Sierra-m, meg egy Big Sur-om; előbbi i386-os, utóbbi aarch64-es binárisok előállításához; x86_64-et mind a kettő tud...viszont a PowerPC-s buildingek elszállnak -13-as hibával. Már megérdeklődtem, hogy mifáras. Stay tuned. De ha nem megy, akkor a PowerPC buildeket egyelőre elengedem. Akinek viszont van ARM64-es Mac-je, az kipróbálhatná, hogy ez a bináris fut-e, mert én csak lebuildelni tudom, de kipróbálni nem. (Csak egy üres form, amit be lehet zárni.)
Oldschool Computer - http://oscomp.hu

( TCH | 2023. 10. 30., h – 02:43 )

1.19.1 released: van Mac támogatás Core/Carbon, Core/Cocoa, Core 2/Cocoa és M1/Cocoa felállásokkal. PowerPC-k egyelőre elnapolva. Még egyszer köszi hory-nak a gépet, arpi_esp-nek az adaptert és mindenkinek, aki segített a helpet. Egyébként oscompon lett közben RSS is, szóval akit érdekelnek a program további verziói, az feliratkozhat rá.
Oldschool Computer - http://oscomp.hu
A Core az a CPU (Core Duo), a Carbon meg a GUI. Nem vagyok OSX expert, de legjobb tudomásom szerint a Carbont használta az első N db OSX és a Cocoa az csak később lett bevezetve. Idézet a wikiből:
Carbon was one of two primary C-based application programming interfaces (APIs) developed by Apple for the macOS (formerly Mac OS X and OS X) operating system. Carbon provided a good degree of backward compatibility for programs that ran on Mac OS 8 and 9. Developers could use the Carbon APIs to port (“carbonize”) their “classic” Mac applications and software to the Mac OS X platform with little effort, compared to porting the app to the entirely different Cocoa system, which originated in OPENSTEP.
In order to offer a real and well supported upgrade path for existing Mac OS code bases, Apple introduced the Carbon system. Carbon consists of many libraries and functions that offer a Mac-like API, but running on top of the underlying Unix-like OS, rather than a copy of the Mac OS running in emulation. The Carbon libraries are extensively cleaned up, modernized and better "protected". While the Mac OS was filled with APIs that shared memory to pass data, under Carbon all such access was re-implemented using accessor subroutines on opaque data types. This allowed Carbon to support true multitasking and memory protection, features Mac developers had been requesting for a decade. Other changes from the pre-existing API removed features which were conceptually incompatible with Mac OS X, or simply obsolete. For example, applications could no longer install interrupt handlers or device drivers.
A tévedés jogát fenntartom, nem vagyok OSX expert.
Oldschool Computer - http://oscomp.hu

A Carbon a C SDK neve, amivel olyan szoftvert keszithettel PowerPC archra, amit el lehet inditani Mac OS 8 es 9 rendszeren is, valamint fut Mac OS X verziokon is. Intel eseten nincs ertelme ilyen binarist kesziteni, hiszen itt boven a 2002-2003 elotti idokrol beszelunk. Ez a Mac OS - Mac OS X migracios utvonalra keszitett koztes API (az elso OS X 2001-es). Az OS X sajat SDK-ja a Cocoa, ami Objective C (ez jott a Next iranyabol, minden OS X verzio ismeri, mai napig NSTableView a tableview neve). A binaris, amit le tudok tolteni Carbon neven, az nem Carbon, mert hasznal Cocoat, viszont nem Cocoa, mert hasznal Carbon -t is. Ennek nincs ertelme :).

Szoval, nem tudom, hogy mi volt a cel, de a 32 bites Intel CPU-val szerelt Macek 10.4.4 es 10.6.8 kozotti verzioval vannak/lesznek ellatva (10.4.4-vel jelentek meg, es 10.6.8 az utolso, ami tamogatja), ezeket le tudod fedni 1 darab, Cocoa binarissal. Szerintem, elegnek kell lennie 3 verzionak, ARM64, i386 es x86-64, a Carbon-i386 az teljesen ertelmetlen a fentiek tukreben.

Ugy latom egyebkent, hogy a binarisaid Resource-ja kozos (1 darab ikon), ezeket igy akar egybe is csomagolhatod a 'lipo' command segitsegevel, igy eloallitva egy olyan binarist, ami egyszerre tartalmazza az ARM, az x86-64 es az i386 kododat, egyszerusitve a letoltest (ez az ajanlott utvonal is). Ha keszitessz PPC verziot, azt is bele lehet csomagolni :)

Ha valakit megkersz, akinek van fizetos Developer fiokja, akkor o ala fogja tudja neked irni a binrarist. Ha ugy van forditva, akkor a notarizacion is at lehet zavarni es akkor semmi warning/buborek nem lesz, akkor se, ha a legujabb rendszeren probalja valaki elinditani. (nekem van fiokom, ha gondolod:) )

Jahogy. Akkor rosszul tudtam, hogy a Cocoa a későbbi OSX-ek GUI API-ja volt. Köszönet a fejtágításért; én még csak most ismerkedek közelebbről az OSX-szel: a PowerMac-jeimen, meg a 2006-os MacMini-n nem sokat foglalkoztam vele, csak felraktam (a Linux, BSD-k, meg a MorphOS mellé), "hogy legyen". Azt, hogy a bináris mit használ, azt az LCL intézi, nekem csak annyi beleszólásom van, hogy megmondom neki, hogy mit használjon; ha ő hibridet csinál, azzal nem sokat tudok kezdeni. :/ A cél az volt, hogy lehetőleg mindent is támogassak, de ezek szerint a Carbonosnak tényleg semmi értelme, ha a 32-bites Cocoa-s ugyanúgy fog futni 10.4-ig visszamenőleg (illetve, ha egyszer életre leheltem a PowerPC-s buildinget, akkor 10.0-áig). :) Köszi a tippet az egybecsomagolással; csábító egy "univerzális" appot összerakni belőle, de az a buildchain elég jelentős módosítását jelentené (jelenleg egyetlen script intézi az egészet - amit csak meg kell hívni az adott valódi vagy virtuális gépen és intézi a forrás beszerzését, a konfigurációt, a buildet, a csomagolást és a feltöltést -, de az külön verziókat csinál), szóval még megfontolom. Ez az aláírás dolog, ez hogy üzemel? Minden release-nél alá kell írni (binárishoz köthető hash, stb.), vagy egyszer aláírtad, kaptam egy kulcsot és akkor azt használhatom mindegyiknél? Utóbbi esetben köszönöm és élnék nagylelkű felajánlásoddal. :)
Oldschool Computer - http://oscomp.hu

A Cocoa maganak az OSX SDK-nak a marketinges buzzword neve. 

A lipo-t belerakhatod 1 darab "scriptbe", mert az "csak" azt csinalja, hogy egybekombinalja a megadott binarisokat. Szoval, az nem egy bonyolult valami.

Minden ".app"-ot ala kell irni (a fejlesztoi fioknak van erre valo kulcsa, amivel Store-on kivuli terjeszteshez ala tudja irni a szoftvereit). Ezen kivul, van a "notarization" is, https://developer.apple.com/documentation/security/notarizing_macos_sof… amikor elkuldod a komplett binarist, ilyenkor a binarisod adatai bekerulnek abba az adatbazisba, amibol a programot hasznalok gepen levo GateKeeper dolgozik, igy ha el is lopjak a kulcsodat, ezt a folyamatot nem tudjak "kikerulni" (mert ehhez nem a kulcsodra lenne szukseg, hanem magara a developer accountodra). A multban (es gondolom, a jelenben is) surun elofordult, hogy 1-1 repoba bekerultek fejlesztoi kulcsok :D. Eddig egyebkent, barmit kuldtem a "notarization service"-nek, mindenre megkaptam az alairast. 

A developer oldalhoz lehet adni "al" hozzaferest valakinek, akar a jogait is korlatozni, viszont, a storeon kivuli terjeszteshez kello kulcsokbol mintha nem lehetne ezeknek a fiokoknak sajatja. Nekem "maganszemely"-re szolo fiokom van, ehhez nem tudok neked alfiokot kesziteni, igy csak az mukodhet, hogy ha elkeszitettel egy releaset, ideadod, en alariom es visszakuldom. Abban sem vagyok biztos, hogy nyugodtan aludnek, ha adnek neked fiokot, amivel korlatlan szoftvert alairhatnal, es be tudnal kergetni az apple notarization servicebe. 

A lipo-t belerakhatod 1 darab "scriptbe", mert az "csak" azt csinalja, hogy egybekombinalja a megadott binarisokat. Szoval, az nem egy bonyolult valami.
A jelenlegi chain-be belerakni bonyolult, mert mindenképpen kétszer - két rendszeren - kell futtatnom a scriptet: a High Sierra meg tudja csinálni a Core, ill. a Core 2 binárist, a Big Sur meg a Core 2 és az M1 binárist, úgyhogy az egyiken csak egy 32/64-bites x86-os hybrid appot tudnék összehozni, a másikon meg egy x86_64/aarch64 hybridet. Ha ezeket is kombinálni akarnám, akkor át kéne írni a buildscriptet és valahogy összehozni a két rendszert.
igy csak az mukodhet, hogy ha elkeszitettel egy releaset, ideadod, en alariom es visszakuldom.
Köszi, de ez így felejtős. Nekem, ha release-elnem kell, mert mondjuk fogtam egy ordas bugot, vagy a kugli megint variált és bedőlt valami, akkor azonnal kell reagálnom.
Abban sem vagyok biztos, hogy nyugodtan aludnek, ha adnek neked fiokot, amivel korlatlan szoftvert alairhatnal, es be tudnal kergetni az apple notarization servicebe.
Nem tudom mire gondolsz, de én nem gyártok malware-eket. Pláne nem más fiókjával aláírva.
Oldschool Computer - http://oscomp.hu
Ezt simán lehetne, csak a 32/64-bites x86 hibridnek mi értelme van az x86_64/arm64 mellett? Akkor simán van egy 32-bites, meg egy x86_64/arm64, nem? Mindenesetre még meggondolom ezt az egybegyúrás dolgot, meg előtte azért szeretném a PPC-s forgatást is életre lehelni.
Oldschool Computer - http://oscomp.hu
Nem tudott, az első inteles Mac-ek még sima Core Duo (Yonah) CPU-sak, azaz 32-bitesek voltak. A Tigerből mind a PPC-s, mint az inteles verzió 32-bites volt. A Leopardból már asszem volt 64-bites inteles (PPC-s tuti). Félig off: közben megcsináltam a PKG-s csomagokat, nem tudom a másik topicban olvastad-e.
Oldschool Computer - http://oscomp.hu

pedig szerintem is az universal binary (amikor egy "exeben" benne van 2-3 platform kodja) lenne a tuti... amugy ahogy fentebb is irtak, boven eleg az x64 es arm64 tamogatasa, folosleges a ppc es a 32bittel szivas, mar 2007 ota van x64 support, elotte meg ppc volt, azt is bele lehet rakni de az is folosleges mar igy 2023-ban szerintem :)

vagy buildelj egy ppc/i386 universal verziot a regi os-en carbonnal, es egy korszeru cocoas x64/arm64 universal verziot a big sur-on. aztan nezd meg a letoltesek szamat par honap mulva :)

amugy kivancsi lennek a nodejs vagy a youtube-dl hogy megy 20 eves ppc/i386 gepeken, mert ezexerint anelkul ugyse hasznalhato...

A PPC és a 32-bit nem fölösleges, mert vannak, akik még használják; nekem is itt van a két PowerMac, csak épp romokban a lakásom (meg az életem)... PPC-s build sajnos jelenleg egyáltalán nem megy: elszáll -13-as hibával (igen, mínusz), a Lazarus fórumon meg hallgatnak... Nem kell hozzá NodeJS, vagy youtube-dl. Egy bármilyen JS interpreter kell, ha internal link usage van, vagy egy YT letöltő, ha original link usage. A JS interpreter azonban nem csak a NodeJS lehet, hanem bármilyen JS interpreter; a program a node mellett a QuickJS és muJS interpretereket is megtalálja, de lehet más interpreterek is jók; én ezeket ismerem. (És a YT letöltő sem csak a youtube-dl lehet, hanem pl. a yt-dlp is.) skami fórumán téma a program és 20-30 éves gépeken használják, QuickJS-sel és nincsenek sebességbeli gondok vele.
Oldschool Computer - http://oscomp.hu