Keresés: - Ubuntu Linux - PROHARDVER! Hozzászólások

Hirdetés

Legfrissebb anyagok

PROHARDVER! témák

Mobilarena témák

IT café témák

GAMEPOD témák

LOGOUT témák

Keresés

Téma összefoglaló

Utoljára frissítve: 2023-12-13 05:03

PROHARDVER!

Ubuntu Linux Összefoglaló

Hivatalos Ubuntu dokumentáció

Amennyiben kérdésed lenne, kérünk, add meg a szükséges adatokat a hiba minél pontosabb leírása mellett:

-számítógép típusa, hardverek pontos megnevezése (különösképp videókártya, vagy hálózati egységek)
-a használt rendszer pontos neve, verziója, a grafikus felület
-mikor és hogyan jelentkezett hiba, mi váltotta ki (program telepítés, frissítés, ...)
-eddigi próbálkozások a megoldásra (ha voltak ilyenek)

A hardverinformációkat legegyszerűbben úgy gyűjtheted össze, ha megnyitod a Terminál nevű programot a menüben. Ide írd be a következő parancsokat (mindkettő után nyomj Enter-t):

lspci
lsusb

Új hozzászólás Aktív témák

#41276 urandom0 senior tag hcl #41274

Új Válasz 2023-02-24 11:16:59 #41276
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

urandom0

senior tag

válasz hcl #41274 üzenetére

Viszont ha http-n megnézed a repószervert, ott van az összes régi verzió.
Persze, az archive-ban benne van, csak hát azzal mire megyünk.
Magam részéről még mindig OS szinten néztem; másrészt amennyire tudom, a C egyszerűbb dolog; tehát nem a headerben mondod meg, hogy mi lesz a függőség, hanem attól függ, milyen kódot írsz. Nem csinál meg helyetted semmit.
CMake-kel biztos megoldható lenne, hogy tetszőleges verziójú GTK headerket húzzon be. De mit kezdesz mondjuk Ubuntu 22.04-en egy 16.04-re fordított GTK programmal? Nézegetheted a terminálban a hibaüzenetet, hogy "cannot find shared library...".
Visszafele kompatibilitást én mindig úgy tudtam, hogy a régebbi dolgok mennek az újabb OS, HW, stb. verzióval is.
Igen, ez így van.
BTW szerintem Androidon sem a SDK régebbi verzióját használja, egyszerűen csak régebbi verzióhoz fordítja, ha azt mondod, hogy az az app menjen 7.x-en.
Ahogy @lionhearted mondja.
Hogy most konkrétan Androidnál hogy van megoldva, azt nem tudom. De pl. a WinAPI-nál úgy néz ki, hogy volt pl. a MapVirtualKey függvény, amikor a Windows csak ANSI karakterkészletet tudott kezelni. Aztán bejött az Unicode, és csináltak egy MapVirtualKeyA függvényt az ANSI karakterekhez, és egy MapVirtualKeyW függvényt az Unicode karakterekhez, a MapVirtualKey pedig csak egy makró lett, ami a kettő közül hívta meg valamelyik függvényt, attól függően, hogy definiáltad-e a program elején a #define UNICODE (https://learn.microsoft.com/en-us/windows/win32/intl/unicode-in-the-windows-api). És ez egy teljesen jó megoldás, mert így ha új programot írsz amihez Unicode támogatás kell, azzal is működik, illetve ha új rendszeren fordítod a régi programot, az is működik.
Ott kezdődik, hogy ilyen szinten nem kéne össze-vissza változnia mindennek.
De változik, és ez szerintem valahol érthető is. Tegyük fel, valaki 1996-ban kitalálta, hogy legyen egy GtkKiskutya függvény, ami egy kiskutyát rajzol a képernyőre. Te, mint GTK fejlesztő, akarod ezt a függvényt maintainelni 2023-ban? Nyilván nem, mert ha minden őskori szir-szart maintainelni akarunk, akkor a világ összes erőforrása is kevés lenne hozzá. Márpedig maintainelni, javítgatni időnként kell, mert közben volt három architektúraváltás, a régi Gnome1 már sehol sincs, stb.
Az biztos, hogy valaki szívni fog, a kérdés csak az, hogy ki
#41275 lionhearted őstag hcl #41274

Új Válasz 2023-02-24 11:00:52 #41275
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

lionhearted

őstag

válasz hcl #41274 üzenetére

Mert más a forráskód kompatibilitás és más a bytekód. JDK-nak meg lehet adni, hogy egy akármilyen verziós (nyilván nem újabbat, mint saját maga) forráskódot fordítson akármelyik általa ismert JVM-re. Ilyen módon a JDK (Java mint nyelv) előre kompatibilis. A JVM pedig visszafelé.