-
GAMEPOD.hu
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
-
-
válasz urandom0 #41248 üzenetére
"Jó, persze, túl könnyű lenne az úgy élet, ha minden kompatibilis lenne visszafelé "
De kéne neki.
Pont ez a lényege az egésznek. csomag ugrik .1 -et, a régebbit kereső cuccoknak mennie kéne vele. Akkor nem megy, ha valaki idiótán írta be a függőségeket, de az egyre ritkább."nem beszélve mondjuk egy Xorg -> Wayland átállásnál"
Azt még sehol nem láttam normálisan megcsinálva. Felteszek egy OS-t, update, hülyén működik. Mi a franc.
Utána tűnt fel másból, hogy Wayland-re váltott. Semelyik nem bírta kinyögni az update (vagy sysupdate) folyamat közben, hogy ja, ez már Wayland lesz (KDE Neon, Kubuntu, Debian+KDE).
Pedig tök jó a Wayland, rakás feature van, csak borzalmas RAM zabálás is, és nem minden gépemben van elég.
Viszont : azért egy komplett grafikus alrendszer váltás persze, hogy nem zökkenőmentes. (Ahhoz képest a fentieken minden működött, szóval hibák nem nagyon voltak, csak a váltás ténye volt nem jól kommunikálva.)
Gnome-on meg X-Wayland váltás nélkül is rendszeresen estek ki kiegészítők egy-egy Gnome verzió ugrás után, mert a készítőnek követnie kellett a változásokat Pedig előző melóhelyen egész jól elvoltam a Gnome-os OS-en. A RAM fogyasztása is tök alacsony tudott lenni.Mutogatni való hater díszpinty
-
Pár napja kérdeztem, elhasal az Smplayer ha kiküldöm rá a Youtube streamot.
A yt-dlp verzió Windowson és Kubuntun is ugyanaz, 2023.02.17
Winen megy a stream Kubuntun nem.
Utánajártam, megvan a baja de ettől méginkább bután bámulok.
Lekérdeztem terminálba mi a baja a yt-dlp-nek, ez anyűgje:Exception: You are using an unsupported version of Python. Only Python versions 3.7 and above are supported by yt-dlp
Vagyis nem jó már neki a régi python.
Synaptic-kal feltettem a 3.7-es pythont, eredmény semmi.
Lekérdeztem a píthon verziókat, és megpróbáltam terminálból is telepíteni a 3.7-est.
Eedmény:tibi@TibiXubuntu:~$ sudo apt install python3.7
Csomaglisták olvasása... Kész
Függőségi fa építése
Állapotinformációk olvasása... Kész
python3.7 már a legújabb verzió (3.7.5-2ubuntu1~18.04.2).
tibi@TibiXubuntu:~$ python3 --version
Python 3.6.9
tibi@TibiXubuntu:
tibi@TibiXubuntu:~$ apt-cache policy python3
python3:
Telepítve: 3.6.7-1~18.04
Jelölt: 3.6.7-1~18.04
Verziótáblázat:
*** 3.6.7-1~18.04 500
500 http://hu.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
100 /var/lib/dpkg/status
3.6.5-3 500
500 http://hu.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
Valaki segítene ezeket értelmezni, mot akkor a python 3.5 vagy 3.6.7 vagy 3.7 mert én elvesztem...
A yt-dlp változatlanul nem műküdik.[ Szerkesztve ]
-
nagyúr
válasz tordaitibi #41251 üzenetére
Tudod hogy nálad is jobban hanyatlik sajnos a szellemi szintem.
Az már önmagában is komoly teljesítmény lenne! No de lehet tévedek, mivel én már nem is számítok Linuxosnak, tekintve, hogy csak használom pár éve a Mint Cinnamonos gépeket, néha feldobok egyet-egyet, megoldandó kérdés nulla, így aztán...
A gyari tarolok meg, arch es aur kivetelevel finoman fogalmazva tetulassan kovetik a nagyvilagot.
Szóval ott bicsaklik a dolog, hogy az Arch tároló csomagjai frissek, ez OK, de korántsem elégséges mennyiségűek, ha nem így lenne, nem kéne az AUR ugye..."Arch User Repository", szóval kb az Ubuntus PPA-nak felel meg, így aztán nem elég gyári.
-
-
válasz tordaitibi #41253 üzenetére
Kipurgálod, és nulláról? Már ha ki lehet purge-olni a Python-t, vagy esetleg force-olod a 3.7 telepítését...
Meg which python ? És megnézni, hogy van-e ott 3.7-es könyvtár is?
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
nagyúr
válasz tordaitibi #41255 üzenetére
abban igazat kell adnotok hogy míg arch alatt 1 kattintással bejelölhető maga a szoftveres kánaán
Egy kattintással 100 programot felraksz AUR-ból? Érdekes elmélet...azért én arra is emlékszem, hogy egyetlen csomag nevét beírtam az AUR-ba és feldobott egy tucat fura elnevezésű verziót a programból, no most mire abból a laikus kiválasztja, melyiket kellene neki felraknia, addig én békésen bemásolom azt a pár megszokott PPA-s sort a sources.list-be, frissítek és egy sorban terminalból felrakom a programokat. Igaz nem vagyok egy Archer, lehet azért megy ez nekem ilyen bonyodalmasan! Mondjuk az alapján, amiket írsz, Te sem vagy nagy Archer!
-
Van 3.7
tibi@TibiXubuntu:~$ which python
/usr/bin/python
tibi@TibiXubuntu:~$ cd /usr/bin
tibi@TibiXubuntu:/usr/bin$ ls -f *python*
dh_python2 python2 python3.6-config python3.7m x86_64-linux-gnu-python3.6-config
dh_python3 python2.7 python3.6m python3-config x86_64-linux-gnu-python3.6m-config
pybabel-python2 python3 python3.6m-config python3m x86_64-linux-gnu-python3-config
python python3.6 python3.7 python3m-config x86_64-linux-gnu-python3m-config
tibi@TibiXubuntu:/usr/bin$
-
-
válasz arcoskönyv #41260 üzenetére
elértetted--->félreértetted így jó lesz?
Nagy nyelvtanbubus vagyok és nem is gondoltam hogy rosszul használom, mentségemre hogy sztem. kismillióan így használják a szót.
Valahol olvastam hogy sok ilyen, a köznyelvbe tévesen elterjedt kifejezés létezik és annyira sokan használják hogy elfogadott lett.
Nyelvújítás -
válasz tordaitibi #41258 üzenetére
Akkor a "python" parancs hív meg rosszat. Path-on mi van...?
Meg akkor az /usr/bin/python mire mutat?Mutogatni való hater díszpinty
-
urandom0
aktív tag
válasz tordaitibi #41250 üzenetére
Saját laikus felhasználói véleményem hogy a Win, és az Android messze túlteljesíti a Linuxokat szoftverezhetőség, és visszafelé kompatibilitás tekintetében.
Ez így van, a Linux híresen rossz a visszamenőleges kompatibilitást tekintve.
A Windowsban sokkal jobban figyelnek erre, Androidon meg pláne. Ott nem az van, hogy van a GTK, aztán arra a verzióra fejlesztesz, ami van a disztróban, hanem eldöntöd, hogy melyik Android verziót támogatod (mondjuk 6-tól felfelé), és akkor tudod, hogy az API level 23-at vagy annál frissebbet fogsz használni, és akkor eleve úgy írod meg az appot.
Linuxban ilyet nem csinálhatsz meg, mert ha az Ubuntu 22.04-ben mondjuk GTK 3.24-van, akkor te hiába írod meg a programod GTK 4-re, nem fog az elindulni.Ugyanakkor ott van az oldalon külön 4 vagy 5 féle Linux telepítő, Ubuntura külön, Fedora meg még másokra.
Akkor most melyik az egyszerűbb..? A fejlesztő részéről?Felhasználói részről abszolút igazad van, fejlesztői részről is, de ez nem annyira visszamenőleges kompatibilitás kérdése, hanem a disztrók fregmentáltsága miatt van, hogy van Debian csomag, van Ubuntu csomag, van Arch csomag, Fedora csomag...
Na ezért is terjedtek el az appimage, flatpak és snap csomagok. Fejlesztői részről szerintem ez a legegyszerűbb.Stabilitás, bugmentesség szempontjából az a nem mindegy, hogy te támogatsz egy rendszert, vagy csak elfut rajta a programod.
De az én, a sima felhasználó számára a Linuxos megoldások sokkalta antifelhasználóbarátok mint a másik 2 rendszeré.
Oké, de te elég sajátosan csinálod a dolgokat
Úgy látom, te sok programot a weboldaláról töltesz le, nem az áruházból. -
urandom0
aktív tag
Pont ez a lényege az egésznek. csomag ugrik .1 -et, a régebbit kereső cuccoknak mennie kéne vele. Akkor nem megy, ha valaki idiótán írta be a függőségeket, de az egyre ritkább.
Ez kb. a lehetetlen szint
Szerintem egyszerűbb lenne, ha a repókban ott lennének a régebbi verziók is, és a program arra dependel, amelyikre akar.A Gnome más tészta, az egy külön állatfaj. Ők félévente megtörik a kompatibilitást, de ez náluk így van kitalálva. Ahogy mondani szokták, ez náluk nem bug, hanem feature
Egyébként így lehet a legjobban leszoktatni a népet arról, hogy custom témákat gyártsanak, mert mindenki megunja, hogy félévente összerottyanik a kis témája, aztán napokat-heteket kell szüttyögnie, mire újra gatyába rázza. Aztán 6 hónap múlva megint kezdődik előről... -
válasz urandom0 #41265 üzenetére
"Szerintem egyszerűbb lenne, ha a repókban ott lennének a régebbi verziók is, és a program arra dependel, amelyikre akar."
Ott is vannak. De alapvetően az egész csomaglogika az, hogy ami a korábbival ment, az az újabbal menni fog. Nagyjából az összes csomag alapú *nix így kéne működjön.
Amúgy a visszafele kompatibilitás az sehol nem az, hogy az újabb verzióra fejlesztesz, és menni fog a régivel Tehát a GTK korábbi verziójára kell fejlesztened, ha azt akarod, hogy azokon és az újabbakon is menjen.
Hogy mire dependel, azt úgy szokás megadni, hogy csomag>xx.xx , ha újabb van, akkor az OK. ...nak kéne lennie."Linuxban ilyet nem csinálhatsz meg, mert ha az Ubuntu 22.04-ben mondjuk GTK 3.24-van, akkor te hiába írod meg a programod GTK 4-re, nem fog az elindulni."
Mondjuk ez máshol sem lesz, ha egy .net 4. -re írsz, akkor 3.5-ön nem indul el
Fordítva viszont mennie kéne, a régebbi keretrendszeren írt cuccoknak mennie kéne az újabbon."A Gnome más tészta, az egy külön állatfaj. Ők félévente megtörik a kompatibilitást, de ez náluk így van kitalálva."
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
urandom0
aktív tag
válasz tordaitibi #41258 üzenetére
A /usr/bin/python egy symlink, valószínűleg a python3.6-ra mutat. Csinálj egy symlinket a 3.7-re: sudo ln -fs /usr/bin/python3.7 /usr/bin/python
-
nagyúr
válasz tordaitibi #41259 üzenetére
Aham, valóban L és félre... De már értelek, mondjuk nem is volt előttem egy archklón képe, hogy könnyebben megértselek. De ahogy nézem, a mostani Mint 21.1-ben még PPA sincs felvéve, egész jól elvagyok a natur felrakott rendszerrel is.
-
urandom0
aktív tag
Ott is vannak.
Nincsenek. Az Ubuntu 22.04-ben nincsenek ott az Ubuntu 16.04 csomagjai, pedig akár ott is lehetnének, vagy legalább egy részük.
Amúgy a visszafele kompatibilitás az sehol nem az, hogy az újabb verzióra fejlesztesz, és menni fog a régivel
De, normál esetben pont ezt jelenti. Pontosabban ez úgy nézne ki, hogy fent vannak mondjuk a GTK 43 devel libjei, és te behúzod a GTK 3.24-es headerjeit, és akkor arra fog dependelni a programod. Mint ahogy Androidnál megadod a minSdkVersion-t.
Hogy mire dependel, azt úgy szokás megadni, hogy csomag>xx.xx , ha újabb van, akkor az OK. ...nak kéne lennie.
Persze, egy olyan rendszeren, mint mondjuk az Android, ahol eleve biztosított, hogy elérhető az SDK több verzióban is. De Linuxon pl. ez így néz ki C-ben:
#include <gtk/gtk.h>
Vala-ban pedig így:
using Gtk;
A forráskódban semmilyen verziószámra nem tudsz dependelni, ez a fogalom ilyen szinten nem is létezik ezeknél a klasszikus Linuxos fejlesztőeszközöknél.
A csomagban persze megadhatod, max nem fog feltelepülni régebbi disztrókra.Mondjuk ez máshol sem lesz, ha egy .net 4. -re írsz, akkor 3.5-ön nem indul el
Oké, ez igaz, de a Windows ilyenkor feldob egy ablakot, és felajánlja, hogy letöltheted a korábbi .net-et, két katt és fent is van, és megy egymás mellett a .net 2 meg a .net 4. Egyébként a WinSxs mappában ott van egy rakat régebbi .net assembly (össze-vissza hardlinkelve egymásra).
Fordítva viszont mennie kéne, a régebbi keretrendszeren írt cuccoknak mennie kéne az újabbon.
Hát kéne, ja
De ha a kedves framework fejlesztő azt mondja, hogy mától nincs GtkButtonBox, GtkBox van helyette, használd azt, akkor mit csinálsz?
Fogod, átírod a programod GtkBox-ra, vagy a hagyod a francba az egészet. -
urandom0
aktív tag
válasz arcoskönyv #41268 üzenetére
Szerintem nem fog menni a pythonnal az update-alternatives, másrészt lényegében az is csak symlinket cserél, harmadrészt pedig oké, hogy más eltörik, de most meg az SMPlayer van eltörve, ez sem jó helyzet.
De egyébként jogos a felvetésed.tordaitibi, töltsd le az SMPlayer flathubos verzióját, abban tuti jó Python van
[ Szerkesztve ]
-
őstag
-
urandom0
aktív tag
válasz lionhearted #41272 üzenetére
Nem, sőt nagy valószínűséggel nem fog futni a régi szoftveres környezetben az új kód. De mondom, ez már tényleg a lehetetlen szint, hogy a régi környezetben működjön az új.
Fordítva megoldható, az nem akkora kihívás, de így nem. Abszolút jogos, hogy egy Ubuntu 22.04-re írt szoftvert nem tudsz futtatni 16.04-en, ezt nagyjából semmilyen oprendszeren nem tudod megcsinálni.[ Szerkesztve ]
-
válasz urandom0 #41270 üzenetére
Annyira régiekkel mondjuk ne sokat akarj kezdeni (ha feltelepíted, akkor valószínű összedől csomó minden). Viszont ha http-n megnézed a repószervert, ott van az összes régi verzió.
"De, normál esetben pont ezt jelenti. Pontosabban ez úgy nézne ki, hogy fent vannak mondjuk a GTK 43 devel libjei, és te behúzod a GTK 3.24-es headerjeit, és akkor arra fog dependelni a programod. "
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.
Ha egy régebbi cuccal akarsz kompatibilis lenni, akkor annak a hívásait kell használni.
Visszafele kompatibilitást én mindig úgy tudtam, hogy a régebbi dolgok mennek az újabb OS, HW, stb. verzióval is. HW szinten még OK is, hogy az újabbak régiekkel, de szoftver szinten nekem ez sosem volt meg így kőbe vésve, hogy adott library használata mellett régebbi verziókkal is kell működni a programnak.
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."De ha a kedves framework fejlesztő azt mondja, hogy mától nincs GtkButtonBox, GtkBox van helyette, használd azt, akkor mit csinálsz?"
Ott kezdődik, hogy ilyen szinten nem kéne össze-vissza változnia mindennek. A "hogy hívják ezen a héten a print parancsot" időszak már vagy 40 éve elmúlt Unix alapú dolgoknál(BTW néztem egyszer egy ilyet, hogy a Unix v1 kernelt előtúrta valaki, és elindította egy PDP emulátoron. Ugyanazok a ls, find, cat, stb parancsok, mint amik most Unix/Linuxon...)
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
őstag
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é.
[ Szerkesztve ]
Tegnap még működött...
-
urandom0
aktív tag
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
[ Szerkesztve ]
-
válasz lionhearted #41275 üzenetére
Nyilván
@urandom0 : "Persze, az archive-ban benne van, csak hát azzal mire megyünk."
Ha kell, leszeded" Nézegetheted a terminálban a hibaüzenetet, hogy "cannot find shared library..."."
Nem ilyenkor van az, hogy az újabb library-nek is kéne mennie vele? Meg hát erre van a csomagkészítés."De változik, és ez szerintem valahol érthető is."
Valahol nem. Az egész arról szólt, hogy azért egy tradicionálisabb Unix elég rendesen át volt gondolva, és az a mai napig alapvetően használatos dolgokból áll. Ha új cucc kerül be, akkor az onnantól értelmezett, de ami korábban megvolt, annak a működése nem kéne, hogy változzon.
A VMS meg a Z/OS pl. élő példák erre, a Z ugye alapvetően úgy van kitalálva, hogy amit egyszer arra a S/360 mainframe-re megírtak, annak az össze skésőbbi OS és HW verzión mennie kéne. (Kell mókolni, azt mondják, de alapvetően igaz.)OK, nem ördögtől való, hogy valami deprecated lesz, de nem mindegy, hogy valami olyan framework, ami minden alá dolgozik, vagy valami olyan, amit egyszerűbb kiváltani. Szerintem ez nagyon a fejlesztői oldalon múlik, hogy hogyan tartja karban a saját kódját.
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
válasz urandom0 #41267 üzenetére
Ha jól fordíttattam Guglival itt pont valami ilyet alkotott az emberke hogy csereberélni tudja a python verziókat.
Komment szekcióba jelezték hogy ezután valakinek annyira megborult a rendszer hogy be se bootolt, vagyis nem vaszélytelen.
[link]
Lehet lassan tényleg át kell állnom frissebb Ubira. -
User_2
tag
nálam még nem volt ilyen...
ubuntu egy pillanat alatt 22Gb -ra növelte a var/log/syslog file-t,
telerakta ezzel:
Feb 24 13:03:21 ***myname*** org.gnome.Nautilus[12801]: [00007f38dc6db800] vdpau_chroma filter error: video mixer rendering failure: An invalid handle value was provided.
nemigazán értek hozzá, törölhetem?
mondjuk az egész file-t is? vagy csak a tartalmát? -
-
User_2
tag
válasz User_2 #41280 üzenetére
a file-ban az első record ma reggeli, uh töröltem az egészet ezzel:
sudo truncate -s 0 /var/log/syslog
majd csinál másikat ubuntu ha akar
VLC okozta, google azt írjabug a valamelyik video akármiben, VLC okozza, ha megnyitott videót pause-olom, majd suspend-del "lekapcsolom" a gépet, újrindításkor egyből telenyomja a syslog-ot
köszönöm, hogy válaszoltál
var folderben még életembe nem jártam, pedig vagy 20 éve fut a valamilyen linux[ Szerkesztve ]
-
User_2
tag
válasz User_2 #41282 üzenetére
és akkor már töröltem a journal-t is, majd 3Gb volt
sudo journalctl --vacuum-size=100M
]var/lib/snapd/snaps/ takarításához viszont kell a segítság tényleg
ez nem működ:
sudo sh -c 'rm -rf /var/lib/snapd/cache/*'a snaps folder 15Gb, fogalmam sincs mi ez, de totál régi file-ok, rég nem haszált prgramokhoz.
[ Szerkesztve ]
-
-
growler
őstag
válasz tordaitibi #41279 üzenetére
[link] ?
-
urandom0
aktív tag
válasz tordaitibi #41279 üzenetére
Szerintem csináld meg azt a symlinket, amit írtam, és bízz benne, hogy minden működni fog. Én biztos, hogy ezt csinálnám, aztán ha omlik a rendszer, akkor su módban bebootolva, a fájlrendszert rw-ben felcsatolva vissza lehet állítani.
Honnan van amúgy az SMPlayer? PPA? -
urandom0
aktív tag
Ha kell, leszeded
Igen, meg annak a függőségeit, meg annak a függőségeit, meg azoknak a függőségeit is...
Jó móka leszNem ilyenkor van az, hogy az újabb library-nek is kéne mennie vele?
Nem, ha a (lefordított) programod a /lib64/libgtk-4.so.1-ra dependel, de neked csak /lib64/libgtk-3.so.1 vagy fent, akkor nem fog elindulni, és ez fordítva is igaz. Azt megteheted, hogy /lib64/libgtk-4.so.1-ra csinálsz egy symlinket /lib64/libgtk-3.so.1 néven, ez sok esetben működik, van amikor nem (főverziók között szinte biztos, hogy nem fog működni).
Az egész arról szólt, hogy azért egy tradicionálisabb Unix elég rendesen át volt gondolva, és az a mai napig alapvetően használatos dolgokból áll. Ha új cucc kerül be, akkor az onnantól értelmezett, de ami korábban megvolt, annak a működése nem kéne, hogy változzon.
De itt nem csak arról van szó, hogy bejön az új cucc, hanem arról is, hogy idővel MINDEN változik, és ha azt akarod, hogy a változásokhoz alkalmazkodjon a szoftvered, akkor karban kell tartanod. Ehhez pedig energia kell, idővel egyre több.
És persze, sok múlik a fejlesztőkön is, de most gondolj, hogy ha a KDE levlistán hetente 3x megkérdezik, hogy mikor lesz Wayland támogatás, akkor a projektvezetőnek nem az lesz a fontos, hogy a KDE 4 libjeit karbantartsák, hanem az, hogy mielőbb legyen Wayland támogatás, és akkor oda lesznek átirányítva a fejlesztők. És szerintem ez is érthető, mert KDE 4 userből van mondjuk 1000 fő az egész világon, KDE 5 userből pedig ötvenmillió.A VMS és a Z/OS (főleg ez utóbbi) azért speciális igényeket elégítenek ki. A mainframek területén az elmúlt ~50 évben sokkal kisebb mértékű változások voltak, mint a PC piacon. A S/360 pont jó példa, mert ott nincs natív visszafelé menő kompatibilitás, hanem először egy emulációs programot kell betöltenie a kezelőnek, és azt tudja lefuttatni a korábbi gépre írt programokat. Az olcsóbb modellekben nincs ilyen emulációs réteg, azokon nem is indulnak el a régebbi programok.
-
válasz urandom0 #41287 üzenetére
"Ha kell, leszeded
Igen, meg annak a függőségeit, meg annak a függőségeit, meg azoknak a függőségeit is...
Jó móka lesz "
Hát, ezért kellene, hogy az újabb csomagok mindenben kompatibilisek legyenek a régiekkel." hanem először egy emulációs programot kell betöltenie a kezelőnek,"
Arra gondolsz, hogy egy virtuális gépen lefuttatják a régebbi Z/OS-t?"idővel MINDEN változik, és ha azt akarod, hogy a változásokhoz alkalmazkodjon a szoftvered, akkor karban kell tartanod. "
Nehéz kenyér, na"Azt megteheted, hogy /lib64/libgtk-4.so.1-ra csinálsz egy symlinket /lib64/libgtk-3.so.1 néven, ez sok esetben működik, van amikor nem (főverziók között szinte biztos, hogy nem fog működni)."
Erre viszont valami egyéb megoldás kéne, nem az a jó, hogy elkezdjük szórni a helyet snap-re meg flatpakre.Mutogatni való hater díszpinty
-
urandom0
aktív tag
Arra gondolsz, hogy egy virtuális gépen lefuttatják a régebbi Z/OS-t?
Nem tudom pontosan, hogyan zajlik a dolog. Csak sejtem, hogy valami olyan emuláció lehet, ami a processzort emulálja, tulajdonképpen hasonlóképpen, mint egy virtuális gép.
Erre viszont valami egyéb megoldás kéne, nem az a jó, hogy elkezdjük szórni a helyet snap-re meg flatpakre.
Tudod, mit szoktak erre írni külföldi fórumokon? Hogy a tárhely olcsó, $0.5/GB...
Tárhelyfelhasználás szempontjából biztos, hogy nem a legoptimálisabb megoldás a flatpak meg a snap, de egyrészt könnyebben szabályozhatok a jogosultságok (akár grafikus felületről is), másrészt egy normálisan összerakott flatpak vagy snap csomagnál nem fordulnak elő olyan függőségi problémák, mint amivel tordaitibi is küzd, harmadrészt a rendszertől elkülönülve futnak. Ez egyrészt jó biztonsági szempontból is, másrészt azért, mert használhatsz több éves kernelt is úgy, hogy közben az appjaid frissek maradhatnak.
Ha most tordaitibi átállítja a Pythont 3.7-re, azzal veszélyezteti a rendszere stabilitását. Bár kicsi az esély rá, hogy nem fog elindulni a rendszere vagy valami hiba lesz, mert csak minor verziót ugrana, de akkor is van valamekkora veszélye.
De ha nem állítja át, akkor nem működik nála az SMPlayer.
Van még más alternatíva, pl. letölti a SMPlayer forrását, átírja benne a Python elérési útvonalát, és lefordítja magának, de ez megint csak elég macerás, és a frissítéseket is manuálisan kellene kezelnie. Esetleg megpróbálkozhat valami cgroups/firejail okossággal, de azzal ugyan csak nagyon problémás lenne.
Én ilyen esetben simán feldobnám a flatpakos SMPlayert és problem solved. -
válasz urandom0 #41289 üzenetére
Ja, mert a S/360-on kezdődött az egész prociemuláció, virtuálgép móka
"Tudod, mit szoktak erre írni külföldi fórumokon? Hogy a tárhely olcsó, $0.5/GB..."
Sejtem, de attól még na. Favágó megoldás." Ez egyrészt jó biztonsági szempontból is, másrészt azért,"
Igen, vannak előnyei, de hogy megéri-e adott helyzetben, az más kérdés.Amúgy ez a baj az egész Buguntuval, hogy elég kényelmes, de ilyen bosszantó dolgok vannak. Előző melóhelyen kereskedelmi kiadású Linuxokat adminoltunk, és ott több száz gépes környezetek mentek úgy, hogy kb. tesztelni se kellett az updateket.
10-15 éve még hatalmas selling point volt Linuxon, hogy betonstabil, és ilyen elkefélések nem nagyon voltak.Viszont @tordaitinbinek az a baja, hogy eléggé régi az Ubi, 18-as. Gondolom oda lassabban megy ki már az aktuális Python.
Van az update-alternatives segít neki, vagy pl. ha fejlesztés, akkor van virtualenv, és hasonló verzióváltogató okosságok.Mutogatni való hater díszpinty
-
válasz urandom0 #41286 üzenetére
Smplayer nem ppa hanem a legfrissebb verzió, tegnapelőtt töltöttem telepítettema oldalukról a Ubuntusat.
De itt most nemia a playerrel van a gond hanem a yt-dlp-vel! Annak kéne a 3.7 python, és bár ott van de ő nem tudja használni.
A symlinket hogyan, légyszi szájbarágósan. -
urandom0
aktív tag
Viszont @tordaitinbinek az a baja, hogy eléggé régi az Ubi, 18-as. Gondolom oda lassabban megy ki már az aktuális Python.
Elméletileg ez nem lehet gond, mert a bionic-updates-ben van a 3.7.5, és ha megnézed, nála is ezt írja:
python3.7 már a legújabb verzió (3.7.5-2ubuntu1~18.04.2).
Az, hogy a
python3 --version
3.6.9-et ad vissza, azért van, mert arra a verzióra mutat a symlink. Azapt-cache policy python3
pedig a tárolók prioritásait és a pinnelt csomagokat mutatja, igazából ez nem mérvadó. -
urandom0
aktív tag
válasz tordaitibi #41291 üzenetére
Smplayer nem ppa hanem a legfrissebb verzió, tegnapelőtt töltöttem telepítettema oldalukról a Ubuntusat.
Igen, közben rájöttem én is.
A symlinket hogyan, légyszi szájbarágósan.
sudo ln -fs /usr/bin/python3.7 /usr/bin/python
Szerintem így jó lesz, mert a yt-dlp a /usr/bin/python-ra hivatkozik, amit ha átsymlinkelsz a /usr/bin/python3.7-re, akkor elméletileg mennie kell.
Ha így nem megy, akkor próbáld ezt:
sudo ln -fs /usr/bin/python3.7 /usr/bin/python3Az én Xubuntumon (22.10) az /usr/bin/python és az /usr/bin/python3 is az /usr/bin/python3.10-re mutat.
-
-
-
-
válasz tordaitibi #41296 üzenetére
Nem jött be.
Ez az Onboard hibaüzenete:tibi@TibiXubuntu:~$ onboard
Traceback (most recent call last):
File "/usr/bin/onboard", line 32, in <module>
from Onboard.Exceptions import chain_handler
File "/usr/lib/python3/dist-packages/Onboard/__init__.py", line 23, in <module>
from Onboard.utils import Translation
File "/usr/lib/python3/dist-packages/Onboard/utils.py", line 38, in <module>
from gi.repository import GLib
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 42, in <module>
from . import _gi
ImportError: cannot import name '_gi' from 'gi' (/usr/lib/python3/dist-packages/gi/__init__.py)
Ennek most mi kellene, a sima python...? Vagy elment üdülni az egész pythonos szekció. -
válasz tordaitibi #41297 üzenetére
Az az __init__.py mi? Rakd a helyére.
Bár ha az egész át van symlinkelve, akkor kéne működnie.Mutogatni való hater díszpinty
-
Új hozzászólás Aktív témák
A topik célja: Segítségnyújtás az Ubuntut és variánsait használók és az ezekkel még csak ismerkedők számára
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Bemutató Linux a mindennapokban
- Bemutató Ubuntu 16.04 LTS kezdőknek, gyakorlatiasan, objektíven
- Hír Megjelent az Ubuntu 16.04 LTS
- Windows 10/11 Home/Pro , Office OEM/Retail kulcsok
- Adobe Creative Cloud - 2024. 04. 05 - 2025. 04. 05-ig
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Eladó Steam kulcsok kedvező áron!
- Steam, Windows, Origin kulcsok, előfizetések közvetlenül a kiadótól, a LEGJOBB ÁRON!