- iPhone topik
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Google Pixel topik
- Poco M3 - felújított állomás
- Térerő gondok, tapasztalatok
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Milyen okostelefont vegyek?
- Honor Magic6 Pro - kör közepén számok
- One mobilszolgáltatások
-
Mobilarena
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
anorche1
őstag
válasz
anorche1
#67398
üzenetére
Bocsi a duplaert.
/etc/default/grub -ban a GRUB_CMDLINE_LINUX_DEFAULT= reszbol toroltem a quiet -et, majd update-grub, restart, es mar irta, hogy epp mit csinal.
De igy sem lett okosabb, nem szamol vissza sehol, mindenhol zold OK.
Az utolso sor a Started TLP system startup/shutdown, de mellette ott a zold OK, tehat sikeresen elindult.
Es itt var, 1perc + par masodpercet. De mire? Utana mar nem ir ki uj dolgot, csak bejon bejelentkezo kepernyo.4.19 -es kernellel es 5.0 -as ck patches kernellel is csinalja.
A gepben nincs dedikalt gpu.
-
anorche1
őstag
Anya gepere vegre felkerul egy manjaro kde, egyelore csak a win10 melle, hogy baratkozzon vele.
A gep egy x220, i5-2520M cpu, 4GB ram egy 120ssd tarsasagaban.
Minden remekul mukodik, csak a boot nem.
1 perc 20 masodperc kell neki, hogy bekapcsoljon. A 7. mp -ben jelenik meg a grub, es az 1 perc 15. mp -ben a kde bejelentkezo kepernyoje.A manjaro egy ideje bekapcsolaskor nem irja ki a systemd uzenetetit, hogy epp mit csinal, csak uefi boot kepernyot (az e6440 -em eseteben dell logo, x220 eseten semmit, tok fekete a kepernyo), igy nem latom, hogy min tokol ennyit. Valoszinuleg var valamire, es vissza szamol egy lepesnel, csak nem tudom, hogy minel.
systemd-analyze parancsra ezt kapom:Startup finished in 2.471s (kernel) + 2.880s (userspace) = 5.352s
graphical.target reached after 2.501s in userspaceVagy arra lenne szuksegem, hogy be tudjam kapcsolni, hogy boot kozben irja, hogy epp mit csinal, vagy mas egyeb paranccsal megnezni, hogy mi az, ami miatt ennyit tokol.
-
-
Frawly
veterán
válasz
scream
#67392
üzenetére
Nincs felcserélődve. Az deafult magyar kiosztásban vannak jó helyen az í és a 0, és a rágott alma használ ANSI kiosztást az ISO világszabvány helyett. Az a megoldás jó rá, amit írtak.
De ezért érdemes megtanulni vakon gépírni. Többé nem lesz érdekes mi van a billentyűkre írva, nem kell matricázgatni a billentyűzeteket, ha külföldi. Én pl. brit ISO billentyűzetet használok, és egyáltalán nem zavar, hogy máshol van az z/y, 0/ö, stb., mivel nem nézek le. Bekapcsolom szoftveresen szabványos „hu” kiosztást és az UTF-8 kódolást, és jó idő. Nincs baj sem az ékezetes billentyűkkel, sem az ékezetes karakterekkel.
Egyébként az ANSI kiosztással sem lenne baj, de az amerikai billentyűzetre való, ahol nem használnak ékezeteket. Nemzeti, lokalizált kiosztásoknál csak a gond van vele. Nem véletlen a nemzeti gépírásszabványok is az ISO kiosztáson alapulnak.
Egyébként Amerikában is csak azért maradt népszerű az ANSI kiosztás, mert abban egy soros hosszú Enter van, amit könnyebb jobb kisujjal elérni gépíráskor, nem kell annyira messzire kinyújtóztatni, mint a fejjel lefelé fordított L alakú ISO Enternél, de ezért az egyetlen előnyért más téren kell árat fizetni.
-
scream
veterán
Hali!
Nemrég készültem el az új triple-boot rendszeremmel (Win10, macOS, Manjaro), viszont ezidáig inkább ubuntus disztrókkal volt dolgom, ha Linuxról van szó,
A problémám az volna, hogy a default magyar kbd kiosztásban az 'í' és a '0' fel van cserélődve (Apple Wired Keyboard), hogy tudnám szerintetek a leghatékonyabban megoldani, hogy visszakerüljenek a rendes helyükre?
-
#67390
ubyegon2
félisten
LantosBerry8
#67388
válasz
LantosBerry8
#67388
üzenetére
Nálam nincs alapértelmezetten fenn egyik vdpau csomag sem (de ugye nem is nVidiás gépek), de nálad is meg kell nézned a Synapticban a képen kizöldellő csomagokat, ha nincsenek fenn, akkor rakd fel mindet (lehet talán, hogy az egyik felesleges, mert benne van minden egy másikban, de ezzel ne foglalkozz). Kereső részbe írd be a vdpau szót Synapticról van szó....esetünkben ez egyszerűbb, mint terminalba bepötyögni.
Ha ezek a csomagok mégis fenn lennének, akkor vdpauinfo terminal kimenet fog kelleni!
Lehet, hogy azok a lejátszók múködnek, amiket Kapitány javasol, de nekem gyanús, ha nincs fenn vdpau......(szóval ne az alapértelmezett playert használd)
A hang viszont jó lett a VGA drivertől.....na ez is valami!
![;]](//cdn.rios.hu/dl/s/v1.gif)
A terminal kimenetet inkább szöveges ki/bemásolással rakd be ide és ezt a szöveget kijelölve nyomj rá a PH szövegablak alatti
Programkódgombra! -
#67389
CPT.Pirk
Jómunkásember
LantosBerry8
#67388
CPT.Pirk
Jómunkásember
válasz
LantosBerry8
#67388
üzenetére
Mivel játszod le? VLC és SMPlayer komolyabb lejátszók, amik tudnak használni hw gyorsítást.
-
válasz
Rimuru
#67386
üzenetére
Ez nem rocket science, csak erto olvasas kell hozza. Ugy latszik mar te sem olvasol eleg figyelmesen.
Minek, ha egyszer "mindent jobban tudok másoknál"!
Egyébként meg ez a jelszófelugrós valami inkább csak KDE-nél bosszantott anno, mert ott a networkmanager-hez ugrált fel mindig, Chrome-ot sose használok.
Ettől függetlenül nem egyértelmű a megoldása, hiába sugallod azt. (ne feledjük, kezdő home user szint) -- a linkjeimben is az érhető tetten!
-
Rimuru
veterán
válasz
ubyegon2
#67385
üzenetére
De pont errol szol, minden informacio megvan benne ami kell.
Csak neked, mind a ketto esetben nem kell vele foglalkozni tobbet: (például adjon meg üres jelszót, ez egyenlő a kikapcsolással) vagy lehetőség van arra, hogy a rendszerünk automatikuson feloldja az adatokat, abban az esetben ha ez a mesterjelszó azonos a felhasználónk bejelentkezési jelszavával.
Ez nem rocket science, csak erto olvasas kell hozza. Ugy latszik mar te sem olvasol eleg figyelmesen. -
válasz
savior
#67381
üzenetére
Valamelyik biztosan segít, bár gyakorlatilag ugyanaz a lényeg, de a jelszókezelőnél sohasem tudni biztosan.
**************************************************
Linux: kulcstartó nélkül ----
Ebből szerintem nem fogod tudni megoldani, nem pont erről szól.....
(ha már mindent jobban tudok....)
-
#67384
ubyegon2
félisten
LantosBerry8
#67380
válasz
LantosBerry8
#67380
üzenetére
Bocs, az F betű meg az alatta lévő rész csak magyarázatul szolgált a Manual-ból idézve.
Arra a kártyára a zárt 340-es drivert javasolják, először azt tedd fel a Rendszerbeállításokban benne kell lennie,
magasabb verziót ne rakj fel egyelőre. Ne máshonnan, ne a nVidia weboldaláról! Ha ezután is fen áll a gond, akkor célszerű továbbmenni.... (nincs Nvidia VGA-m, de ezt attól nyugodtan merem írni javaslatként)
-
#67379
ubyegon2
félisten
LantosBerry8
#67378
válasz
LantosBerry8
#67378
üzenetére
nem belevauzás, de.....
F
-f, --flags All CPU flags. Triggers -C. Not shown with -F to avoid
spamming.
-F, --full Full output. Includes all Upper Case line letters except -W,
plus -s and -n. Does not show extra verbose options such as -d
-f -i -l -m -o -p -r -t -u -x, unless specified.inxi -Fxxxés nem
inxi -fxxx -
#67377
CPT.Pirk
Jómunkásember
LantosBerry8
#67376
CPT.Pirk
Jómunkásember
válasz
LantosBerry8
#67376
üzenetére
Elég sok verziója van az N500-nak. De jól látom, hogy mindegyikben Intel GMA 4500M van? Az az inxi kimenet sokat segítene.
-
#67375
CPT.Pirk
Jómunkásember
LantosBerry8
#67373
CPT.Pirk
Jómunkásember
válasz
LantosBerry8
#67373
üzenetére
A Mint-ben van egy olyan, hogy zárt driverek, a beállítások között. Ott bekapcsoltál valamit? Tehetnél fel egy képet róla.
Terminálban egy
inxi -Fxxxparancs kimenete is érdekes lehet. Lehet, hogy nincs alapból telepítve az inxi, megtalálod a csomagkezelőben. -
#67374
Frawly
veterán
LantosBerry8
#67373
Frawly
veterán
válasz
LantosBerry8
#67373
üzenetére
GPU driver nincs rendben. Milyen gép is ez pontosan? Főleg a GPU lenne érdekes.
-
#67373
LantosBerry8
senior tag
LantosBerry8
senior tag
Sziasztok!
Ma telepítettem a linux mint 19.1 -et windows 10 mellé.
Fut mindkét rendszer, viszont észrevettem, hogy ami filmek/videók windows alatt zökkenőmentesen futnak, linuxon erősen szaggatnak...
Illetve a hdmi hangkimenet helyett a saját hangszóróját használja a laptop, ami windows alatt szintén probléma mentesen megy....Mi lehet a gond? - hogyan tudnám orvosolni?
-
CPT.Pirk
Jómunkásember
válasz
Lanash
#67371
üzenetére
Amelyik eszközödön szeretnéd, hozz létre egy legalább 20GB-os partíciót, de inkább több legyen mint kevesebb. A telepítőben ezt a partíciót add meg "/" root fájlrendszernek. Az ubi telepítőjét már régen láttam, de általában a telepítés végén meg szokták kérdezni, hogy melyik háttértár boot szektorába kerüljön a grub rendszertöltő.
Ha az SSD-t adod itt meg, akkor lecseréli a W10 indítóját a dualbootos grubra, ha a hdd-t, akkor oda fog kerülni a grub (érintetlen marad a w10 sajátja), de ekkor át kell állítanod a booteszközt a bioszban a hdd-re.Ha még nem telepítettél Linuxot, akkor javaslom próbáld ki egy ingyenes Virtualbox alatt, továbbá fusd át itt a téma összefoglalót, sok infót fogsz benne találni (pl. secure boot és w10 gyors rendszerindítás kapcsán is, amiket célszerű kikapcsolni).
-
CPT.Pirk
Jómunkásember
válasz
saiyajin
#67368
üzenetére
Én pár napja másoltam tele egy 16GB-os pent amit előtte Fat32-re kellett formáznom, mert az idióta Lenovo tabletem csak azt a fájlrendszert ismeri... Dolphin alól csináltam USB3 slotban USB3 penre, de pont úgy átment minden, mint máskor.
cigam: meg az akarom vagy nem akarom támogatni kérdése. Nyilván Windowson nincs ott a közösség aki megcsinálja nekik, így nem akarnak költeni a supportra az elégségesnél többet.
-
saiyajin
senior tag
válasz
leviske
#67347
üzenetére
Tegnap futottam bele én is. Már korábban is feltűnt, hogy egy usb3-as pendrive-ra (usb3-as porton természetesen) lassabban másol a Dolphin fájlkezelő Manjaro KDE-n, mint windowson, de annyira nem volt vészes.
Tegnap viszont egy régebbi 8GB-os, 2.0-s pendrivera (szintén fat32-es) akartam három videófájlt másolni, kb 4GB-nyi összesen, és három negyedóra alatt nem ért át. Rákeresve, több helyen is említik a problémát, de érdemi megoldást nem találtam. Pl.: [link]
A más fájlrendszerre való formázás segíthet, de az nem mindig elfogadható. Ha ad valaki egy telepakolt pendrive-ot, hogy huzzám már rá a hétvégi kirándulós videót, nem akarom formatálgatni a pendrive-ját. És windowson semmi gond pendrive-val, szóval nem a végét járja. -
CPT.Pirk
Jómunkásember
A blender egyik fejlesztője posztolt egy érdekeset, hogy a régi hardverek (amik ugyan már kevesek a blenderhez, de ettől még megy rajtuk) driverei Linux alatt karban vannak tartva, míg Windows alatt már több éve egyik se kapott driveres javítást. https://www.phoronix.com/scan.php?page=news_item&px=Blender-2.80-GPU-Requirements
-
válasz
CPT.Pirk
#67364
üzenetére
Nem ennyire egyszerű, de nem is annyira bonyolult, igaz ez attól is függ ismeri-e a user azt a 2-3 parancsot, ami segíthet ilyenkor. Akár az Összefoglalóból is könnyen puskázhat bárki.
De ha csak ennyi előnye van ezeknek a csodáknak, az nem túl sok szerintem. A függőség azzal nem sok vizet zavar, ha fenn marad és párszáz kb felesleg áll szemben 2 GB felesleggel, ha az említett példát nézzük.Megnéztem több csomagra is anno a különbséget, csak nem akartam túl sokat linkelgetni.....bár már tökmindegy, úgyis
mindent jobban tudok másoknál! by DavePersze az is lehet, hogy csak nekem nem volt még az 5+ év alatt gondom eltávolított csomagok függőségeivel, ezt nem tudom.
-
válasz
Frawly
#67362
üzenetére
Nem emlékszem mi volt az a csomag, ami itt a Haladóban szóba került, de telepítve 2,5GB hely is elég már neki.
Lehet, hogy ez a Telegram telepítés volt az, amiről itt próbáltam leírni mennyi más módon lehetne telepíteni, mielőtt még ezekhez a csoda univerzális snap, flatpak, appimage akármikre fanyalodnánk!
-
Frawly
veterán
Igen, normális. Az Android Studio egy nagy megabloat Qt-s alkalmazás. A flatpack csomagok meg nagyok, mert az összes .so modult is hozzácsomagolják az alkalmazáshoz, azokat is, amik már fent vannak a rendszereden meg fent vannak a disztród tárolójában, mert a flatpack csomag kiadója nem lehet biztos, hogy az az adott függőség a te gépeden, a disztród tárolójában elérhető lesz, vagy ha elérhető is, akkor nem lesz elavult verzió. De flatpack nélkül ezt csinálja régóta a Steam is.
A flatpack mindenképp bloat, akármit csinálsz. Ha csak egy mód van rá, ne használj ilyeneket, tedd fel az adott szoftvert a disztró tárolójából, vagy valami megbízható külső tárolóból.
(#67359) ubyegon2: így van, ebbe most nagyon beletrafáltál. Viccen kívül, van olyan flatpack csomag, ami tényleg egy giga fölötti mennyiséget hány fel a gépre. Sokkal rosszabb, mintha 400 MB-nyi KDE függőség jönne le a csomagkezelővel. Ha csak egy mód van rá, akkor az ilyen Flatpack, Snap, Appimage univerzális csomagok használatát kerülni kell. Ezeknél még sokszor az is jobb, ha inkább forráskódból forgat valaki. Tényleg csak a vészesetben érdemes hozzájuk folyamodni.
-
Frawly
veterán
válasz
Apollyon
#67352
üzenetére
Nekem még nem ment tönkre. Igazából az umount nélküli lehuzigálás nem a pendrive-nak árt fizikailag, hanem a fel nem írt adatok vesznek el, meg inkonzisztens lesz logikailag a fájlrendszer. Valóban nem javasolt lehuzigálni, akinek nincs türelme, másoljon hálózaton vagy neten keresztül.
-
-
Mert ez a flatpak lényege. Anélkül, hogy bármit módosítanál a rendszereden, futtathatsz (kipróbálhatsz) olyan programokat, amiknek a függőségeit nem kell telepítened. Pl. Gnome alatt anélkül tudod futtatni a kdenlive-ot, hogy a rendszeredre akará csak 1 KDE függőség feltelepülne, nemhogy a komplett ablakkezelő. Vagy fordítva, KDE alól futtathatsz Gnome-ot igénylő programokat anélkül, hogy bármelyik Gnome komponenst feltelepítené. Persze olyan eset is lehetséges, hogy egy program működéséhez olyan programkönyvtár szükséges, amit a rendszered aktuális verziója még/már nem tartalmaz. Nem kell kibogarászni, hogy milyen csomagok kellenek hozzá, hiszen alapból benne vannak (még akkor is ha az adott csomagot nem is tartalmazza a disztribúciód). Nem módosít semmit a rendszereden, egyszerűen csak fut egy virtualizált környezetben. És ez az "burokban" futás előnye/hátránya is.
-
válasz
sh4d0w
#67356
üzenetére
Nekem ez nagyon nem fér össze a linhxos világgal.
A kipróbált csomagok közül mindegyiket használtam már Mate környezetben is, és kisebb gnome csomagokat leszámítva nem kellett nekik semmi. Szó sem volt akkor gnome sdk-ról, meg KDE Platformról.
Ha repóból tud futni ezek nélkül, akkor flatpak-osítva miért kell neki?
Biztos van rá logikus magyarázat. -
CPT.Pirk
Jómunkásember
válasz
leviske
#67349
üzenetére
Csináld amit growler írt. A bizt. eltávolítást mindig kellene használnod. Mikor penre másolok, a folyamatjelző szerint már kész a feladat, de ettől még akár 1 perccel később is szöszöl a pennel (villog rajta a hozzáférést jelző led is), még ír rá dolgokat. A biztonságos eltávolítás ilyenkor megvéd az adatvesztéstől.
-
leviske
veterán
válasz
CPT.Pirk
#67348
üzenetére
Volt már, hogy használtam (olyankor előfordult, hogy kifagyott). Konkrétan az átmásolásban nem segített.
A formázás jellegét illetően volt Windows-on gyors formázott fat32-es pednrive is, meg még a gyári (Adata) fat32-vel érkezett is.
Érdemes volna terminálból formáznom valamire?
-
leviske
veterán
Találkozott már valaki olyan jelenséggel, hogy fat32-re formázott pendrive-ra a rendszer nem képes hibamentesen fájlokat másolni?
Jelenleg kénytelen vagyok a noti és az asztali gép közt megosztott mappát használni, mert pendrive-on csak a kis txt fájlok másolódnak tényleg át. Hibát meg nem szokott jelezni a másolás befejeztével.
MÁS: Uppoltam a játékos témát, így a kifejezetten lutris, dxvk, proton és úgy általánosságban Linuxon történő játék futtatás kérdéseket érdemes lehet ott átbeszélni. Bár azt hiszem ilyen jellegű kérdésekkel eddig így is csak én voltam itt.
-
válasz
Frawly
#67343
üzenetére
felesleges egy gépre 3 disztró. Vagy ha van is, akkor úgy nem ér semmit, hogy az idő 99%-ban Mint fut, és csak 1%-ban próbálgatod a többit.
A HP-n elvan bármennyi, a Mint is elfér, a desktopon használok Mint-et, mivel ezen melózom, ezen nem is fut már más, elég sok PPA-s program is van a melós gépen, mivel ez van tele HDD-vel is, így más ezen amiatt nem lesz, mert eléggé készségszinten dolgozom/filmeket készítek fel megnézésre.....
A 8570p-n inkább a klónokat szoktam felváltva használni, ha unok már a desktopnál ülni.
Egyébként meg ha egy disztró rendesen be van állítva, akkor a mindennapi használat során nem sok különbséget kéne érezzel és egy kiadás alapú és egy rolling disztró között.
Gyakorlatilag semmi különbség nincs, ahogy mondod, Mivel minden bosszantó hibát el tudtam hárítani az elején Manjaronál, így szerintem ennél több tapasztalat nem is kell nekem sem kiadás alapú sem (half)rolling disztróknál.
Sajnos sokan félreértik, mikor a kérdezőnek kénytelen vagyok leírni, Manjaronál érhetik meglepetések, mert ez tény. Egyből támadásnak veszik a rollingosok, de akkor sem írhatom, hogy rakd fel nyugodtan, mivel nálam mindig előjönnek gondok, de én tudom kezelni, egy totál kezdőnek meg azt mondom, rakjon fel Mint Cinnamont.
Ettől még mindhárom rendszer tetszik nekem. Mások meg azt használnak, meg attól hisztiznek, amitől akarnak.
Ezzel nem tudok mit kezdeni, hogy egy x tip. rendszerről egyszerűen nem lehet leírni, amit tapasztalok 10. alkalommal is. Értem a pszichológiai hátterét, de nem érdekel. -
Frawly
veterán
válasz
zoltanz
#67336
üzenetére
Valószínű, hogy neked nem is kell más, ha a Debian kielégíti az igényeidet, megy, és nem érzed úgy, hogy valamiben is korlátozna, vagy a régebbi csomagverziók gondot okoznának. Úgy valóban nem érdemes disztróhoppolni, hacsak nem tanulási, szakmai fejlődési célzattal.
Még a grafikus felület, DE/WM váltása sem ok disztróhoppolásra, Debian minimum netinstallra bármit feltehetsz igény szerint és feltémázhatsz.
-
Frawly
veterán
Igen, ezt valóban rosszul írtam. Azóta én is rájöttem, de nem tudtam már szerkeszteni. Kicsit csodálkozok, mert évekkel ezelőtt olvastam, hogy az Ubuntu dobni fogja a speciális architektúrákat és csak az x86-ra és x86_64-re koncentrál, mivel asztali disztró akar lenni. Azóta meg dobták az x86-ot is.
Azt tudtam, hogy van arm-fork is, de külön projektként futtatva.
-
Frawly
veterán
válasz
anorche1
#67332
üzenetére
Ja, hogy ez volt a baj. Ezek szerint csak nem frissült a keyring csomag. Máskor bármit telepítesz, ne pacman -S csomagnév formában tegyed, hanem pacman -Syu csomagnév kiadásával. Sok szívástól kíméled meg magad. Ez még Debian/Ubuntu-alapú disztrókon is így van, ahol ajánlják, hogy a apt upgrade && apt update előzzön meg minden mást.
@ubyegon: felesleges egy gépre 3 disztró. Vagy ha van is, akkor úgy nem ér semmit, hogy az idő 99%-ban Mint fut, és csak 1%-ban próbálgatod a többit. Úgy lenne értelme, hogy elszánod magad, és akkor mondjuk 3-4 hétig csak Manjaro-t nyomatsz. Vagy Chackrát, gondolom az a half rolling, ami még fent van. Úgy nem lesz egy rendszerrel tapasztalatod, ha csak néha napján megjáratod és lefrissíted. Egyébként meg ha egy disztró rendesen be van állítva, akkor a mindennapi használat során nem sok különbséget kéne érezzel és egy kiadás alapú és egy rolling disztró között. Az csak akkor jön elő, ha mondjuk forráskódból forgatva teszel fel dolgokat, vagy valami olyan új feature kell, amit csak az új verziós csomag tartalmaz.
-
#67335
Cirbolya_sen
aktív tag
Cifu
#67334
Cirbolya_sen
aktív tag
Az Ubuntu especiel pont igen, persze az egy Debian-lecsatlakozás.
Van x86_64, x86, arm64, armhf (arm 32bit / arm v7) és van külön Rpi féle kiadás, ppc64el és s390x.Pont ezt akartam beleírni én is, mert sokan /köztük én is/ az Pi vonalról vagy NAS-ok felől, esetleg router szoftverek felől /EdgeMax, OpenWrt/ érkeznek a linux világba, ha meg ez az irány úgy is adott, akkor legkevésbé számít a gördül, vagy nem gördül kérdés
Aztán, hogy később mi lesz a kedves és használt linux, az sok mindentől függ majd.
Csak hogy, egy újrakezdő is hozzászóljon az topikhoz
-
válasz
Frawly
#67320
üzenetére
A Debian ezt készen nyújtja. Ugyanezt egy Arch, Fedora, Ubuntu nem tudja nyújtani, azok már csak jellemzően x86_64-re vannak és kifújt, se x86, se semmi (jó, van Arch32 és Arch Arm is, de az külön disztró).
Az Ubuntu especiel pont igen, persze az egy Debian-lecsatlakozás.
Van x86_64, x86, arm64, armhf (arm 32bit / arm v7) és van külön Rpi féle kiadás, ppc64el és s390x. Oké, motorolla, MIPS és SPARC nincs...3) nagy szervezet áll mögötte, sok fejlesztő, sok csomagfenntartó, nincs az, hogy ha valaki kiesik, annyi a projektnek, meg holnaptól egyszer csak megszűnik. Persze már egy Arch-ot sem fenyeget ez a veszély, elég széles tábora van, már jelen van 17 éve, elég sok disztró épül már rá, nagyon nem úgy tűnik, hogy a közeljövőben hanyatlásnak indulna.
Az Ubuntu és Ubuntu-flavored eléggé népes tábor azért, lássuk be. Plusz ugye többé-kevésbé ami megy Debianon, az megy Ubuntun is...
-
CPT.Pirk
Jómunkásember
válasz
ubyegon2
#67331
üzenetére
Nem olvasom el az összes hozzászólást a topicban, délután se nagyon voltam itt de ha figyeltél a 'TG' dolgaira, akkor tudhatnád, hogy nem ugrom az első szurkálásra... Ha úgy érzed, hogy ilyen problémával találkozol ami TG beavatkozást igényelne, akkor tudod hol érsz el engem, vagy valakit a staff részéről. Erről a témáról ennyit.
-
válasz
ubyegon2
#67330
üzenetére
Most olvasgatom újra a délután keletkezett hsz-eket, azért érdekes, hogy jönnek finom szurkálódások a nem rolling disztrókkal kapcsolatosan is, ilyen esetekben még soha nem hallottam, hogy egyből örjöngés, felháborodás lenne vagy a Tg is felszólítaná a népeket az Off-ba áthúzásra.....pici elfogultság talán van itt....
kár.....persze érthető.
-
válasz
Frawly
#67328
üzenetére
Manjaro már január 10. óta fenn van pedig, az elején ez az iwlwifi bug volt, de azt valahogy megoldottam saját favágó módszeres ötletemmel, mert amúgy arra nem találtam még akkor semmi megoldást. Szóval épp eleget foglalkoztam vele, hogy szóba hozzam akár, de úgy látom többeknek ez nem tetszik.
Teljesen jól múködik, a kernel panicokat leszámítva, de ott is csak átírom az épp kernel frissülés utáni Mint boot.cfg-t és a következőig semmi gond nincs.
Szóval van egy kiadás alapú disztróm, egy rolling és egy half-rolling is régóta a HP 8570p-n együgyű Mint userként elvagyok velük. Persze mindenki csak elküld a fenébe, feltételezve, hogy sosem láttam még rolling disztrót élőben.
Írhattam volna, hogy az küldjön el a fenébe, akinek egyszerre van a gépén rolling, half-rolling és apt-os rendszer és időnként akár összehasonlításokat is tud rajta végezni, de már bizonyos nívó alatti beszólásokra nem reagálok.
Cinmanó csak a Mint-en van, Manjaro az KDE, Chakra meg ugye nem sok DE-t ismer!
Ezt a 5.0 kernel Mint-re hegesztést csak viccnek szántad? Mert akkor kacajgok rajta.......
A délutáni glibc 2.29-es Manjaro-s probléma megvolt? Nem piszkálódtam, pedig ugye mi a rolling előnye.....? No de úgy látom azóta is rolling-nem rolling téma van, ami nem gond, csak ha én is belevauzok.
-
Dave™
nagyúr
válasz
MineFox54
#67325
üzenetére
Mindig a kernel jön fel első érvnek, de nem szabad megfeledkezni a szoftverekről sem. KDE esetén pl. elég gyakran (néhány hetente) frissülnek a szoftverek, és kifejezetten hasznos újítások jelennek meg vagy éppen valami bugot javítanak. A rolling modellnek köszönhetően megjelenés után 1-3 héttel (a Manjaro stable ágának van ennyi késleltetése) már meg is kapom őket, nem kell rá egy évet várni.
-
Frawly
veterán
válasz
Rimuru
#67317
üzenetére
Mivel nem írtad, hogy mivel nem értesz egyet, így úgy veszem mindennel egyetértesz.
ubyegon2: most nézem, mi ez a Manjaro telepítés ott fönt a gépeden? A Mintesek vagy a HP megtudja, hogy rollingozol, és neked annyi. Örök kezdőknek nem szabad ilyet felrakni. Instabil, meg eltörik és a Wi-Fi-od sem látja. Nagyon remélem, hogy legalább Cinmanóval van feltéve
(#67324) Bici: nem csak hogy a legtöbb nem rolling disztrón, de lényegében egyiken sem megy. Most az Ubi 19.04-es az első, ami az 5.0-ás kernellel tudja. Vagy ha Debian alatt SID-et használsz vagy Fedora, ami félrolling, ilyesmi. De pl. ha valaki Proton-ozik, annak is nagyon melegen ajánlottak a minél frissebb csomagok, akkor is, ha a hardver, amin fut, nem túl új.
De arra hála istennek nem kell majd sokat várni, hogy a Mint is támogassa az ilyen Raven Ridge és egyéb újdonságokat. Röpke 1 évet (20.04-es Ubuntuig)
Bár valami kernel utility ott is van biztosan, amivel hamarabb fel lehet hegeszteni egy 5.0-ás kernelt. -
Frawly
veterán
Ezt nem is tudtam, hogy a Cannonical is foglalkozik már ilyennel.
Az egész linuxos világ arról szól, hogy teszter vagy meg a saját időddel fizetsz. Nem csak Red Hatnál meg a SUSE-nél van így. Már a Win10 is erről szól, ha nem LTBS ágat használsz, akkor bizony kapod arcba rendesen a ki nem tesztelt frissítéseket, telemetriával meg kaszálják be a teszteredményeket, de legalább fizetsz is érte, hogy tesztelhess. Mac-nél meg a túlárazott hardverrel fizeted ki a szoftveres ökoszisztémát.
A CentOS meg hiába közösségi, ugyanazt a kódbázist kapod, ugyanazokat a csomagokat, ugyanazt a Red Hat patches kernelt, stb..
Bár én ezt valahol hátránynak tartom. Az ilyen spéci disztrókon gond lehet, hogy valami spéci kernelpatch vagy fordítási beállítás miatt nem megy egy lefordított csomag. Míg pl. Archon minden csomag vanilla állapotban van, nincs semmi disztróspecifikus hack bennük, ami bezavarhatna akárminek is.
-
Frawly
veterán
válasz
MineFox54
#67323
üzenetére
Nem is mondtam, hogy az Arch rossz. Nem véletlenül használom én is évek óta. Nyilván, ha szükséged van ilyen spéci i3wm-es dolgokra, meg az Arch Wikire, akkor azt kell használni. Akkor felesleges is pedzegetni, hogy esetleg nem-e Debian legyen helyette, adva lesz, hogy mit használj.
Egyébként biztos vagyok, hogy Debianra is elérhető i3gaps és egyéb, csak valami külső tárolót kell hozzá felvenni, vagy weboldalról .deb csomagot összevadászni.
Bár igazából az i3wm-es cuccok kódbázisa és függőségfája nem nagy, ilyen i3gaps, meg i3lock-color hipp-hopp leforgatható egy git clone https://blabla && ./configure && make && make install után.
-
MineFox54
őstag
Core2Duo+NV 9600GT-n, illetve Ivy Bridge-en működök, úgyhogy ilyen irányú tapasztalataim nincsenek
Frawly:
Nyilvánvalóan csak viccből mondtam, leforgattam Debianon, nem is volt gond
Csak vicces hogy az ilyen vackok elférnek AUR-ban. Ha egy mód van rá, megpróbálok Debianon maradni, nem jöhet össze a szentháromság. -
válasz
MineFox54
#67316
üzenetére
Egy gyakorlati példa: AMD Raven Ridge APU-hoz a 4.19-es kernel óta van stabil grafikus driver.
Ez azt jelenti, hogy a legtöbb nem-rolling disztrón a mai napig nem megy normálisan ez a hardver.
Persze, pl. a Fedora kivétel, mert ott majdnem olyan gyorsan pörögnek az események, mint egy rolling esetén. -
MineFox54
őstag
válasz
Frawly
#67320
üzenetére
"Véleményen szerint a Debiannak nem a hosszú csomagélettartam az előnye"
Hát nem is előnyként mondtam. Persze, desktop felhasználás esetén. Hál' istennek a gamingből kimaradtam, egyedül a Doom 1 amire szükségem van."Archon pl. ezzel szemben kb. 10 ezer csomag van mindössze, zusammen, tehát hivatalos tárolók + AUR"
Bezzeg i3lock-color meg i3gaps az már nem jutott Debian tárolókba"Debianhoz előbb találsz segítséget, többen ismerik, több tutorial, blogpost, stb. van róla, ha problémába ütközöl, előbb találsz hozzá megoldást a neten, mint Archhoz. Archhoz ott a Wiki meg a fórum és kifújt"
Ez mondjuk elég vicces, mert kb. 95%-ban az ArchWikiben találok megfejtést a Debianon fennálló problémáimra. (persze nem rendszerszintű dolgok esetében, csak "felhasználói szoftverek"-nél).Jön a héten egy második Thinkpad, felcsapok rá egy Archot. Megnézzük, mire jutok
-
Dave™
nagyúr
válasz
Frawly
#67321
üzenetére
Nem kell félteni a Canonicalt, ők is szolgáltatnak
A Fedorát és az OpenSUSE-t kár idekeverni, ha nem tévedek azok nyújtják a tesztbázist a fizetős megoldások számára, ami így elég nagy hozzáadott érték, a felhasználó meg örül, hogy ingyen kapta, pedig valójában ő ezért cserébe teszter is egyben. A CentOS meg közösségi projekt, szóval megint más. -
Frawly
veterán
válasz
kovaax
#67319
üzenetére
A Red Hat meg a SUSE nem a Linuxból gazdagszik, hanem abból, hogy megoldásokat épít rá, meg supportot árul hozzá cégeknek. Maga a linuxuk nem kerül pénzbe, bármikor feltehetsz ingyen is egy Fedorát, CentOS-t vagy OpenSUSE-t, ugyanazt kapod, mínusz a support.
Azt viszont sose tudtam, hogy a Canonical miből él. Szerintem csak azért marad fent, mert Mark Shuttleworth milliomosként pénzeli. De ha megunja, hogy csak a pénzt viszi, cseszhetik.
-
Frawly
veterán
válasz
MineFox54
#67316
üzenetére
Ezt neked kell tudni, hogy mennyire van szükséged új verziós csomagokra. Jellemzően akkor van szükséged ezekre, ha nagyon új hardvered van, vagy játszol (Wine, Lutris, Stream, Proton, DXVK, stb.), vagy streames, multimédiás dolgokkal foglalkozol.
Az extrém hosszú élettartamú csomagokkal meg az a baj, hogy egy idő után elavulnak, és nem tudják kielégíteni az újabb alkalmazások függőségeit.
Véleményen szerint a Debiannak nem a hosszú csomagélettartam az előnye, hanem
1) ez a disztró támogatja a legtöbb architektúrát (arm, arm64, sh, powerpc, m68k, mips, sparc). Ez persze egy Gentoo-n is megoldható, de azon neked kell mindent fordítgatni, meg kínlódni vele. A Debian ezt készen nyújtja. Ugyanezt egy Arch, Fedora, Ubuntu nem tudja nyújtani, azok már csak jellemzően x86_64-re vannak és kifújt, se x86, se semmi (jó, van Arch32 és Arch Arm is, de az külön disztró). Ezzel szemben egy Debian elindul elvileg egy 486-oson is (386-oson is ment, amíg a 3.8-as kernelből ki nem szedték a támogatását), igaz köszönet nem lesz benne, csak a boot tart percekig, míg a modern disztrók már dobták a 686-os támogatást is lassan.
2) ehhez van a legtöbb csomag. Valami jóval 40 ezer fölött van, és még erre jön rá egy csomó PPA, meg egyéb weboldalakon fellelhető .deb csomag. Ehhez képest egy Ubuntu-n már kevesebb csomag elérhető, de még mindig szép szám, meg jók hozzá a .deb csomagok. Archon pl. ezzel szemben kb. 10 ezer csomag van mindössze, zusammen, tehát hivatalos tárolók + AUR. Persze, forráskódból forgatás is játszik, de akkor megint nem vagyunk előrébb egy Gentoo-hoz képest, a Debian meg ezt nélkülözhetővé teszi
3) nagy szervezet áll mögötte, sok fejlesztő, sok csomagfenntartó, nincs az, hogy ha valaki kiesik, annyi a projektnek, meg holnaptól egyszer csak megszűnik. Persze már egy Arch-ot sem fenyeget ez a veszély, elég széles tábora van, már jelen van 17 éve, elég sok disztró épül már rá, nagyon nem úgy tűnik, hogy a közeljövőben hanyatlásnak indulna.
4) Debianhoz előbb találsz segítséget, többen ismerik, több tutorial, blogpost, stb. van róla, ha problémába ütközöl, előbb találsz hozzá megoldást a neten, mint Archhoz. Archhoz ott a Wiki meg a fórum és kifújt.De ha rollingot akarsz, de nem akarsz Debianról váltani, akkor válts át SID tárolókra. Azzal is kvázi rollingot kapsz.
-
kovaax
őstag
-
Dave™
nagyúr
válasz
MineFox54
#67316
üzenetére
Két előnye van, az egyiket meg is válaszoltad: nem kell régi verziókat használni vagy külső tárolókkal trükközni a'la Ubuntu, ha valamiből újabbat szeretnél használni (mert abban már kijavítottak valami meglévő bugot, vagy újabb szolgáltatások jelentek meg). A másik, hogy nem disztribúciót frissítesz ami mindig elég nagy kockázat, hanem folyamatosan frissülnek a csomagok kisebb léptékben, ráadásul sok felhasználónál fut le kb. ugyanúgy, ahol a hibák a testing/unstable ágon valószínűleg kijönnek, a stabilon meg pici késéssel megkapod a biztonságot meg a viszonylag friss csomagokat is. A Debian a fentiek szöges ellentéte, de az Ubuntu is közelebb van ahhoz, mint amit egy tetszőleges rolling/half rolling rendszer nyújt.
A Debian híresen stabil egyébként, csak az sokszor kimarad, hogy ez elsősorban a baromi régi csomagoknak köszönhető, amiben persze már rengeteg dolgot javítottak az idők folyamán, csak közben azért történtek fejlesztések is.
#67315: ez tényleg erősre sikeredett, de sebaj, ez is egy vélemény
-
MineFox54
őstag
válasz
Frawly
#67315
üzenetére
Bármiféle negatív felhang nélkül kérdezem, pusztán kíváncsiságból, sosem volt még Virtualboxon kívül rolling disztróm:
Milyen valódi előnye van egy rolling rendszernek pl. egy Debian ellen? Mondjuk Debianon pont extrém hosszú a csomagok élete. Ami felcseszett a múltkor az a 2017 novemberi LibreOffice a stretch tárolóban... Azóta egy főverziót lépett a szoftver.
-
Frawly
veterán
válasz
kovaax
#67314
üzenetére
Nyilván, ha valakinek fizetős Oracle kell, meg Red Hat kernel alá, az így járt, maradjon csak vendor lock-in-ben. A Linuxnak az lenne a lényege, hogy nyílt forráskód, bárhol lefordítható, beüzemelhető, disztrótól, gyártótól függetlenül.
A rollingokhoz support nem jár. Azt magadnak supportálod. Ha nem bírod, használsz helyette Windowst, vagy megbízol vele külső céget.
Azt meg nem látom, hogy ha a Linux világa a pénzről szól, hol van benne a pénz. Az én meglátásom szerint nem a pénz miatt fejlesztik, hanem a nagy cégek akarnak olyan platformot, amit az egész iparág használhat, nem kell egy gyártótól függeni. Ellenkező esetben, ha nem lenne a Linux, a MS-nak még nagyobb hatalma lenne, aztán várhatnánk arra, hogy valami új architektúrát vagy technológiát támogassanak. Kicsit érdekes is lenne nagy szerverfarmokon meg szuperszámítógépeken, ha nem lenne Linux. Na, azokra próbálj Oracle-szart meg Windows felrakni, minimum érdekes lesz. De ez a valóságban nem probléma, mert akinek ilyen komoly eszközparkja van, az supportál magának bármit, ők általában saját disztrót szoktak hegeszteni és supportálni maguknak. Olyan nagyokról beszélek, mint a Google és társai. Nincsenek rászorulva egy cégre meg semmilyen LTS-re sem.
Meg az egész vita onnan indult ki, hogy volt egy szerver valahol, ami annyira nem volt fontos, hogy évekig hozzá sem nyúlt senki, nem tartotta karban. Na, azon aztán tényleg baromi fontos az Oracle, az audit, meg support, és tényleg nem mehetett volna rá rolling.
Félre ne értsd, nem a rollingot akarom éltetni mindenáron, mert nem való mindenhova, csak azt mondtam, hogy nem igaz az ellenkező mantra sem, hogy a rolling ne lenne alkalmas bármire. Itt volt kolléga, aki kijelentette, hogy szerverre nem szabad rakni, mert instabi, meg jön a szerverrendőrség, rád rúgják az ajtót, és ha meglátják, hogy ilyen Arch vagy Gentoo van fent, legumibotoznak.
-
kovaax
őstag
válasz
Frawly
#67297
üzenetére
Múltkor nem volt időm leírni, hogy miért beszélsz hülyeséget, de most van, hát így jártál...
A linux felhasználók nagy része nem disztróvaccsol, hanem azt nézi, hogy a neki szükséges szoftvereket hol támogatja a gyártója. Például OL-RHEL-SLES, és akárhogyan nézem, nem látok egy rolling rendszert sem köztük. Vajon miért lehet???
A linux felhasználók jó részének pedig meg kell felelni mindenféle törvényi előírásoknak, ahol sokszor követelmény, hogy legyen a használt szoftvereknek támogatása, ha másért nem, azért, mert az auditot végző cégek csak a nagy fizetős disztrókat ismerik, mert nem tudnak annyi szakembert fenntartani, ahány disztró van.
Ráadásul a linux felhasználók nagy részének ügyfelei vannak, szolgáltalásokat nyújtanak, úgyhogy gáz esetén kell legyen valaki, aki segít (ami a gyakorlatban sokszor azt jelenti, hogy kár esetén el lehessen kenni a felelősséget, de ez már más lapra tartozik).
"A Linux világa eleve a sokszínűségről szól." Ez valamikor régen talán még igaz is volt, de már jó régen a linux világa az üzletről és a pénzről szól. A kernel és egyéb szoftverek fejlesztői jó része már nem hobbiból vagy szórakozásból dolgozik a linuxon, hanem pénzért. Az otthoni felhasználók száma elenyésző az ipari felhasználókhoz képest.
-
-
Frawly
veterán
A keyfile-ozást nem ajánlom. Több okból is: bekészíted vele a kulcsot a lábtörlő alá, így a titkosítás komolytalanná válhat. Másrészt meg rizikós is, véletlenül olvashatatlanná válik a kulcsfájl, buktad a titkosított adatokat, ha nincsenek meg titkosítatlan mentésben. Persze lehet biztonsági másolatot tartani a keyfile-ról, de akkor meg még több kulcsot készítettél be a lábtörlő alá.
Azt kell érteni, hogy a kényelem és a biztonság ellentétes fogalmak. A jelszót beírni kényelmetlen minden bootkor meg meghajtófelcsatoláskor, főleg ha kellően erős és hosszú, de cserébe a legbiztonságosabb módszer. Én minden bootkor beverek egy 20+ karakteres ATA jelszót (korábban én is LUKS dmcrypt-et használtam épp ilyen jelszóval), majd felhasználói nevet, és egy 10+ karakteres felhasználói jelszót. De csak 1-2 másodpercig tart. Már annyira rááll a kezem, hogy fel sem tűnik, nem esik nehezemre.
-
Sziasztok!
Egy particiot szeretnek dm-crypt segitsegeven titkositani.
Az lenne jo, ha nem kellene mindig jelszot beirni, amikor hozza akarok ferni, hanem egy kulcs file lenne a hozzaferes feltetele.
Ezt hogy tudom elerni?Olvasgatom eppen az Arch wikit, de meg to kezdo vagyok titkositas temaban, siman lehet, hogy az elottem levo megoldast nem veszem eszre.
Kossz!
-
válasz
anorche1
#67306
üzenetére
Igen, gondoltam, hogy a core-ban le van maradva a Manjaro, de mire sikerült az én stabil Manjaro-mat elindítani.......van ám humorérzék itt, kiírja nekem, hogy RIP
....szóval az AUR-ból viszont felrakhatod a friss glibc-git 2.29.r102.g462e83a4a0-1, glibc-git néven keress rá az Octopiban.
-----------------------------------------------------------------------------------------
OK tudom mitől van Manjaro-nál a kernel panic, meg is tudtam oldani és persze csak együgyű Mint userként járok így mindig.....(valóban a Mint miatt van, de az is fenn van, persze a Manjaro utálja is)
-
Frawly
veterán
válasz
anorche1
#67302
üzenetére
Próbáld meg újratelepíteni a keyring csomagot. Majd kiadni a pacman-key --init parancsot. Ellenőrizd, hogy jó-e a gépen a dátum. Itt részletesen írnak a teendőkről.
Ha semmi más nem segít, a /etc/pacman.conf-ban mindjárt az elején az [options] részben a SigLevel-es változóknál a Required és Optional helyére írd be a TrustAll értéket, és úgy futtasd újra a pacmant. Csak ideiglenesen, míg felrakod a csomagot. Néha van, hogy a csomagkészítő kulcsa lejár, és elfelejt újat generálni. Jelezni kéne a Manjaro fórumán.
-
anorche1
őstag
válasz
Rimuru
#67304
üzenetére
Igen, ezzel is probalkoztam mar, csak nem akartam meg 1 hozzaszolast irni, szerkesztesi idobol meg kifutottam.
Igy felment rendesen az aktualis csomag, de ugyanugy nem indul el, mint mikor kezzel raktam fel,keyserver-options auto-key-retrieve(#67305) ubyegon2
Manjarot hasznalok, itt a csomagok frissessege csuszasban van az arch hoz kepest.
Probaltam a letoltott tar.xz -t telepiteni, ekkor ezt kapom:loading packages...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing glibc (2.29-1) breaks dependency 'glibc=2.28' required by lib32-glibc
Press any key to continue...Probaltam a lib32-glibc -bol is a frisset felrakni, akkor pedig ezt:
loading packages...
resolving dependencies...
warning: cannot resolve "glibc=2.29", a dependency of "lib32-glibc"
:: The following package cannot be upgraded due to unresolvable dependencies:
lib32-glibc
:: Do you want to skip the above package for this upgrade? [y/N] n
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'glibc=2.29' required by lib32-glibc
Press any key to continue...De ha jol sejtem ezt sem igy kene csinalni
Szerk.: Ja latom, nem csak a signatures hibara irnak javasolatot, hanem a glibc -re is.
De mar az elso lepest sem tudom megtenni (Downgrade to the previous release of this package that worked), hisz mikor egy korabbi verziot raktam fel, akkor sem indult el. -
válasz
anorche1
#67303
üzenetére
A második linkedben görgess lejjebb, ott írnak megoldásokat, de akár a glibc 2.29-1-et is leszedheted innen.
viszont 2.28-5 a legfrissebb -- ez a fenti link ismeretében fura......
+előzött blufi (de mint kiderült, én úgyis 'mindent jobban tudok másoknál')
-bocs az értelmetlenségéért, de idéztem az utsó 4 szót. -
anorche1
őstag
válasz
anorche1
#67302
üzenetére
Felraktam egy regebbi, chromium-vaapi-73.0.3683.103-1-x86_64 verziot, hatha ennek jo a regebbi glibc is. Valoban jo, ennek mar mas baja van inditaskor:
/usr/lib/chromium/chromium: error while loading shared libraries: libicui18n.so.63: cannot open shared object file: No such file or directory[link] Ezt a fajtlt az icu csomag tartalmazza, ami fent is van. Illetve vegigneztem a chromium fuggosegeit, minden fent van.
5let?
-
anorche1
őstag
Manjaro, kde, es aurbol szeretnem a chromium-vaapi-bin -t felakni, de a kovetkezo hibat kapom:
...
==> Verifying source file signatures with gpg...
chromium-vaapi-74.0.3729.108-1-x86_64.pkg.tar.xz ... FAILED (unknown public key 011FDC52DA839335)
==> ERROR: One or more PGP signatures could not be verified!
:: Unable to build chromium-vaapi-bin - makepkg exited with code: 1Probaltam a letoltott chromium-vaapi-74.0.3729.108-1-x86_64.pkg.tar.xz -t kezzel telepiteni, fel is ment, de nem indul el, ha terminalbol probalom inditani, akkor a kovetkezo uzenetet kapom:
/usr/lib/chromium/chromium: /usr/lib/libm.so.6: version `GLIBC_2.29' not found (required by /usr/lib/chromium/chromium)Gondolom hianyzik neki egy fuggoseg, de pontosan mi?
Szerk.: Ja gien, a glibc nevu csomag fent van, viszont 2.28-5 a legfrissebb. Ez lenne a gond?
).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Vélemény Linux Mint Debian Edition 4
- Tudástár MX-Linux 19
- Bemutató Linux a mindennapokban: Manjaro KDE
- Bemutató Linux a mindennapokban
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Hír A Steam Play hozza el a Windowsra írt játékokat Linuxra
- Hír Hova jut a világ? Linuxot kínál a Windows Store!
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- Bomba ár! Lenovo X1 Yoga 2nd - i7-7G I 8GB I 256SSD I 14" WQHD Sérült I W11 I CAM I Garancia!
- BESZÁMÍTÁS! ASRock B550M R7 5700X 32GB DDR4 512GB SSD RTX 3070 OC 8GB NZXT H400 fekete Enermax 750W
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RTX 4070Ti Super GAMER PC termékbeszámítással
- Eladó Új Motorola G31 4/64GB szürke / 12 hónap jótállással!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest