Hirdetés
- Megjött a Cherry legfrissebb, taktilis karakterisztikájú kapcsolója
- 8 bővítőhelyes Jonsbo "akvárium", akár kábeleket rejtő alaplapokhoz is
- 4K felbontású, 240 Hz-es OLED monitorokkal köszönti az őszt a Lenovo
- Ismét egy teljesen friss egérrel gyarapította kínálatát a Pulsar
- Legalább 20 éves lemaradásban vannak a kínai litográfiai cégek?
- Milyen videókártyát?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Soundbar, soundplate, hangprojektor
- Ismét egy teljesen friss egérrel gyarapította kínálatát a Pulsar
- Megjött a Cherry legfrissebb, taktilis karakterisztikájú kapcsolója
- Most Kína tiltotta ki a nemrég exportengedélyt kapott AI gyorsítókat?
- Milyen billentyűzetet vegyek?
- Mini PC
- ASUS ROG Ally
- Xiaomi Mi Box androidos médialejátszó 4K és HDR támogatással
-
PROHARDVER!
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
-
PROHARDVER!
(rögzített hozzászólás)
Legyetek szívesek az offtopik témákat ne ebben a topikban tárgyaljátok ki. A topikgazda is jelezte, most törölni kellett jópár hozzászólást, most már maradjatok a (szakmai) topik keretei között.
Új hozzászólás Aktív témák
-
urandom0
senior tag
válasz
Petya XT
#99976
üzenetére
Semennyire. Illetve pontosan annyira, mint bármely másik program, amit letöltesz a netről, és mindenhez van hozzáférése, amihez neked is. Szvsz az appimage az a formátum, amit legutoljára választanék, ha valamilyen programról lenne szó.
Az appimage-nek gyakorlatilag nincs biztonsági modellje, nem tudod szabályozni, hogy mihez férjen hozzá, ellentétben a flatpakkal és a snappel.
Ráadásul a flatpakhoz és a snaphez elég jól kiépített infrastruktúra van szinte az összes disztróban. Feltelepíted a flatpak csomagot, és tudsz vele letölteni, frissíteni, repókat kezelni, jogosultságokat kezelni... appimage-hez pl. csak külső féltől származó frissítőprogram van.
Flatpak és snap programoknál a rendszer csinál neked .desktop fájlt is, appimage-nél nem. Illetve flatpakhoz több eszközük van a fejlesztőknek, hogy a megjelenése jobban illeszkedjen a rendszertémához. -
urandom0
senior tag
válasz
Remus389
#99935
üzenetére
- Ha hívnak, már előre jelzi értesítésben, mielőtt meghallanád a csörgést, és ha épp fut valami média, azt megállítja
- Megkapod a gépen a telefon értesítéseit, és fordítva
- A gépen futó lejátszót tudod vezérelni telefonról
- Van olyan üzenetküldő app, aminél ha üzenetet kapsz, a gépről tudsz válaszolni
- Egérpadként tudod használni a telefont
- Tudsz beállítani parancsokat a gépnek, és a telefonról kiadni őket...Nagyon jó program....
-
urandom0
senior tag
válasz
Necronom
#99912
üzenetére
Én is a friss telepítést javaslom, az a legtisztább. De ha nagyon akarod, megpróbálkozhatsz azzal, hogy frissíted 20.04-re, aztán 22.04-re, majd 24.04-re (már ha egyáltalán LTS Lubuntud van, nem non-LTS). Nagyjából ugyanezek a lépések, mint ahogy itt le van írva: https://askubuntu.com/questions/1454762/18-04-22-04-upgrade
Annyi, hogy neked még egy köztes lépésed lesz, amikor 20.04-ről 22.04-re frissítesz, majd onnan do-relese-upgrade-del 24.04-re.
De ennél tényleg egyszerűbb a tiszta telepítés. Az meg úgy megy, hogy lementesz mindent, ami kell (jelszavaid is, minden legyen meg), letöltöd a legfrissebb Lubuntut, kiírod pendrive-ra, bebootolsz róla és feltelepíted, ennyi. Ne hagyd meg a /home-ot sem, én nem ajánlom.
-
#99893
urandom0
senior tag
Freeman007
#99891
urandom0
senior tag
válasz
Freeman007
#99891
üzenetére
KDE Wayland alatt van egy minimális támogatás a plusz egérgombokhoz, az egérbeállítások között nézz körül, lehet, hogy az is elég.
-
#99883
urandom0
senior tag
CsengődiGeri
#99877
urandom0
senior tag
válasz
CsengődiGeri
#99877
üzenetére
Elég nagy különbségek vannak az asztali környezetek között.
Az Xfce-ben (nem Xface) például nincs kompozitor, így a video tearinget magadnak kell megoldani valahogy (több módszer is van rá), bár elméletileg hamarosan áttér az Xfce is Waylandre.
Az asztali környezethez tartozó programok terén is vannak nagy különbségek, az Xfce képnézegetője, a Ristretto elég butácska, képmegjelenítésen kívül gyakorlatilag nem tud mást, a KDE-féle Gwenview-ban viszont vannak szerkesztési lehetőségek (átméretezés, forgatás, stb.).
A fájlkezelőjük is más, Xfce-ben a Thunar az alapértelmezett, KDE-ben a Dolphin, Gnome-ban a Nautilus. A Thunar egyszerű, mint a százas szög, de használható. A Dolphin elég jól bővíthető, gyárilag vannak benne olyasmik, amik Thunarban nincsenek. A Nautilus kb. a kettő között áll. KDE-ben és Gnome-ban van például rendszerszintű fájlindexelő-kereső, Xfce alatt nincs.
Kifejezetten Xfce-hez tervezett levelezőprogram például nincs, KDE-hez ott a KMail, Gnome-hoz az Evolution vagy a Geary. De a KMail és az Evolution is egy programcsomag része, amik amolyan komplett személyes adatkezelők, van bennünk naptár, todos, notes, stb.
Gnome-hoz és KDE-hez is van saját szoftveráruház, Xfce-hez és Mate-hez nincs.Én a Mate-ről nem nagyon tudok nyilatkozni, nem sokat használtam, de tudásban nagyjából egy szinten van az Xfce-vel (az Xfce talán valamivel többet tud).
Kifejezetten Xfce-hez tartozó appokból ennyi van: https://www.xfce.org/projects
Gnome-hoz tervezettből ennyi: https://apps.gnome.org/hu/
KDE-hez tervezettből ennyi: https://apps.kde.org/hu/
KDE-nek vannak a legösszetettebb programjai, a Gnome appjai egyszerűbbek, Xfce-hez pedig csak néhány alapvető alkalmazás van.Sebességben, memóriahasználatban is vannak különbségek. Mate és Xfce nagyon alacsony erőforrásigényű, a KDE már nagyobb, és a Gnome a legnagyobb, de mindegyik teljesen jól megy régebbi vason is.
-
#99847
urandom0
senior tag
peterattila
#99846
urandom0
senior tag
válasz
peterattila
#99846
üzenetére
Logokat tudsz ilyenkor nézegetni. dmesg, journalctl, ha legközelebb fagy, jegyezd meg az időpontot, és nézd vissza journal-ban, mi történik olyankor. A driverek biztos, hogy lementek, nem maradt fel semmi? Lehet, hogy érdemes lenni blacklistelni az nvidia driverét.
-
#99837
urandom0
senior tag
gyuri860213
#99833
urandom0
senior tag
válasz
gyuri860213
#99833
üzenetére
Én nem a megszólított vagyok, de azt el tudom mondani, hogy évek óta nincs már MySQL a Linuxokban, mind átálltak MariaDB-re, licenszelési okokból. Nyugodtan használd ezt, a MySQL-t csak külső forrásból tudod telepíteni.
-
urandom0
senior tag
Van egy külső ADATA SSD-m, egy terrás, kb. négy éve használom, semmi baja. Vannak WD SSD-im is, három gépben is, azok is teljesen jók. Iitthon van egy Samsung EVO, és a cégnél kb. 120, azok is teljesen jól mennek.
Előző munkahelyemen volt egy Silicon Power külső SSD-t, ez lőttem lévő rendszergazda is használta már pár éve, én is használtam pár évig, azzal sem volt gond. -
urandom0
senior tag
válasz
ubyegon2
#99696
üzenetére
Hát ha a user rákattint a fájlkezelőben a meghajtóra, és nem történik semmi, akkor is tudni fogja, hogy megnyekkent a cucc...
![;]](//cdn.rios.hu/dl/s/v1.gif)
De amúgy igen, táphibás eszköznél azt ír be az fstabba, amit akar, annak mindegy az. Egyébként systemddel is lehet fix mount pointot beállítani, fstab nélkül, valahogy így:[Unit]Description=Mount external drive to /mnt/external_driveAfter=network.target[Mount]What=UUID=<meghajtó_UUID>Where=/mnt/external_driveType=auto[Install]WantedBy=multi-user.targetÉs utána engedélyezni kell:
sudo systemctl enable mnt-external_drive.mountDe ha nincs kihuzigálva a meghajtó, és fixként üzemel, akkor teljesen jó megoldás az fstab is. De ilyen táphibás, bizonytalan működésű cuccokkal én nem is kísérleteznék.
-
urandom0
senior tag
válasz
ubyegon2
#99692
üzenetére
A
nofailcsak azt ignorálja, hogy külső vagy belső FSTAB-ba csatolt eszköz eltávolításakor ne álljon le a boot folyamat 90 sec-re (vagy amennyire be van állítva).Igen, és neki pont ez kell (vagyis hát nem kell, csak érdemes). Én is ezt írtam, hogy azért érdemes beírni a nofail-t, hogy ne akassza meg a bootot.
A rendszer szempontjából persze mindegy, hogy külső vagy belső lemez, ő ilyen különbséget nem tesz. -
urandom0
senior tag
Na, az asztali ikonok az, ami nekem abszolút nem hiányzik
Windowsos gépen is csak a sajátgép és a lomtár van kint, de azokat sem onnan nyitom meg.A te képeden nem látszik, az enyémen igen, hogy ha 32 vagy 24 pixelre van állítva a dash magassága, akkor az ikonok kicsit elmosódnak.
Céges OpenSuse-ra feldobtam a Gnome-ot, dash to dockkal és dash to panellel is jól néz ki:
[kép]
[kép] -
urandom0
senior tag
válasz
daninet
#99633
üzenetére
Én nem bánom, ha kicsit látszódik a háttér, legalább megtöri a monotonítást. Gnome-nál úgyis az van, hogy ha elindítasz egy programot és kirakod teljes képernyőre, akkor sehol egy átlátszó felület, csak a monoton szürkeség, fehérség, és max az ikonok színesek.
Ugye ilyen az alap: [kép]
Ha dash to dockkal "tálcásítod", akkor ilyen: [kép]
Ha ezt összehúzod, kicsit hülyén néz ki, mert nincs lekerekítve a panel és nincsenek távolságok: [kép]
Dash to dockkal viszont így néz ki: [kép]
Ez utóbbinál az ablak és dock között nincs távolság, mert shrinkelve van a dash, mivel alacsony felbontású laptopon néztem.
De szerintem az első és az utolsó néz ki a legjobban, de az elsőnél én szoktam beállítani áttetszőséget, hogy ne csak egy ilyen matt fekete gyászkeret legyen.Amúgy ezt a gyászkeret kérdést az Elementary OS, oldotta meg jól. Alapból a top bar teljesen átlátszó: [link]
Ha viszont egy ablak a top bar mellé kerül, vagy teljes méretűre van állítva, akkor fekete hátteret kap a top bar: [link]
Egy ilyen beállítás bekerülhetne a Gnome-ba is... -
urandom0
senior tag
válasz
moleculez
#99631
üzenetére
Hát ha dash to dockot használsz, akkor az már nem az a mód, ahogy a Gnome fejlesztők megálmodták. Ők úgy gondolták, hogy Windows billentyűvel hívod elő a tevékenységek nézetet, és ott váltasz alkalmazást. Én így használtam, mindenféle dash to dock és egyebek nélkül, és szerintem EZ a megoldás nem produktív.
Az egy fokkal jobb, mikor alul van a dock, és ha leviszed az egeret, akkor megjelenik, ha nincs rajta az egér, akkor eltűnik.
Én ezt a megoldást sem annyira szeretem, vannak vele problémák.
Az viszont, hogy alul folyamatosan látszódjon a dock, felül pedig a "top bar", az pedig nem kevés plusz helyet elfoglal a képernyőből, főleg úgy, hogy a top baron alig van hasznos dolog. MacOS-en ez azért működik jól, mert ott az ablakok menüje beépül a top barba, így hasznosul az a terület, de Gnome-on nem.
Akárhogy is nézem, szerintem a legjobb a klasszikus megoldás, hogy van egy darab paneled (most az mindegy, hogy alul vagy felül van), és azon van minden.Ráadásul az összes asztali környezet úgy van kitalálva, hogy ha teljes képernyős az ablak, akkor ha a jobb felső sarokba feltolod az egeret és klikkelsz, akkor pont bezárod az aktív ablakot, mert a bezárógomb úgy van kialakítva, hogy nagyobb az érzékelési területe, mint amekkora maga a grafika, és így érzékel még a legfelső, jobb szélső pixelen is. Gnome-nál nem így van, mert ott ugye eleve más az alapkoncepció, tehát így ezt a funkciót is elveszted.
Sőt, régebben, ha alulra raktad a panelt valamilyen kiegészítővel, akkor az ablakok néha elcsúsztak felfelé pont egy panelnyi méretet. Vagy ha elküldted alvó állapotba a gépet, akkor ébresztés után az összes megnyitott ablak fel volt csúcszva. Ezt lehet, hogy javítottak azóta, nem tudom. -
urandom0
senior tag
válasz
moleculez
#99629
üzenetére
Én is úgy használtam, amikor még használtam, de ha megint Gnomeoznék, akkor szerintem dash to panellel csinálnám. Szerintem nincs igazán értelme elrejteni a dokkot/dasht/panelt/tálcát (ki hogy hívja), mert tök jól hangzik, hogy "distraction free" és hasonlók, de szerintem semmilyen kognitív terhelést nem okoz az, hogy látod a futó programokat. A tevékenység nézetes alkalmazásváltás, meg hogy folyton nyomkodni kell a Windows billentyűt, az megterhelőbb.
-
urandom0
senior tag
Hidd el, én is tudom, hogy a Gnome projekt elég sokat adott a közösségnek. Nincs is igazán problémám a Gnome-mal, sőt, amikor 9 ember azt hangoztatta, hogy a Gnome 3 szar, akkor én voltam a 10., aki azt mondta, hogy nem szar az, csak más hozzáállást igényel. Sőt, nekem az is nagyon tetszik, hogy nagyon sok közreműködő, nagyon sok kisebb-nagyobb programot tol bele a projektbe, sokkal jobban látszik a dolog közösségi jellege, mint más asztali disztróknál. Régebben gondolkodtam azon, hogy ezekről én is írok, mert vannak köztük nagyon érdekes projektek.
Csak vannak ezek a hibák, amiket évek óta elfelejtenek javítani, és ez kicsit zavaró, főleg, ha munkára is használja az ember a rendszerét. Illetve vannak dolgok, amiket jó lenne, ha megoldanának végre, de ezek sem nagyon akarnak sikerülni nekik. -
#99624
urandom0
senior tag
tordaitibi
#99622
urandom0
senior tag
válasz
tordaitibi
#99622
üzenetére
Én az Elementary OS ikonjait szerettem: https://docs.elementary.io/hig/reference/iconography
Egy időszakban Play Store-ból is le lehetett tölteni, még mobilon is ezt használtam, Elementary-s háttérel. -
urandom0
senior tag
Most Fedorás a gond, de egyébként olyat szokott csinálni a Gnome szoftver, hogy pl. görgetek lefelé, és újratölti az egész szoftverlistát. Vagy ha egyszerre több telepítést indítottam el, sokszor megakadt, és se előre, se hátra. Mondjuk Debianon nem igen használgattam, ott lehet, hogy jobban működik. De Fedorán, Manjarón és Ubuntun használgattam, ezeken mindig volt vele valami probléma.
-
urandom0
senior tag
A Gnome Szoftver sose volt a helyzet magaslatán, akárhányszor próbáltam használni, mindig volt vele valami gond, úgyhogy szépen lassan le is szoktam a használatáról.
A másik ilyen program a Gnome Weather volt. Ezt a 40-es verziónál tették tönkre, mert korábbi verziókban bármilyen települést be lehetett állítani, onnantól felfelé viszont csak azokat, amik szerepelnek az adatbázisában, és az nem túl sok. Én egy ~60 ezres városban élek, és ez pl. nincs benne, így nekem gyakorlatilag használhatatlan.Amúgy azon szoktam gondolkodni, hogy a weboldalán a képeken csak azért szerepel Budapest, mert érzékeli, hogy MO-ról vagyok, vagy mindenki ezt mutatja-e?
-
urandom0
senior tag
-
urandom0
senior tag
válasz
moleculez
#99589
üzenetére
Most olvasom, hogy Notably for command-line users, we’ve changed the default terminal to Ptyxis.
Kíváncsi vagy, hányszor fogom elgépelni (sehányszor, mert első dolgom lesz feldobni helyette a Gnome terminált).Az új dnf mennyivel gyorsabb, mint a 4-es? RPMFusion frissült már?
-
urandom0
senior tag
válasz
Rimuru
#99033
üzenetére
A csomagkezelő oda rakja a binárist, ahova a készítője akarja. Megcsinálhatná a Firefox is azt, hogy a csomag nem a végleges helyére rakja a binárist, hanem másik mappába, vagy ugyanabba a mappába, csak másik névvel, és amikor indítod a Firefoxot, akkor egy script kicseréli a régi binárist a régire.
Nem csak engem zavar ez a dolog,, és látom a kommentek közt más is írta már ugyanazt a megoldást, amire én gondolok. -
-
-
urandom0
senior tag
válasz
Petya XT
#98778
üzenetére
Én is próbáltam már erre rákeresni, túl konkrét dolgokat nem találtam. De szerintem "fertőzött" kifejezés nem olyan jó, inkább "szennyezettnek" kellene fordítani, bár az sem fedi le teljesen a dolog jelentését.
Hogy miért lehet "fertőzött" egy kernel, több oka lehet:
- pl. valamilyen nem GPL-es, hanem propitetary licencű betöltött modul (pl. NVidia vagy AMD GPU driver)
- live patchelt kernel
- valamilyen hiba vagy bug folytán korábban leálló kernel
- force-olva betöltött kernel modul, ilyenek...Szóval úgy kb. azt jelenti, hogy nem a gyári eredeti kernel fut, hanem lett betöltve valami, vagy egy bug vagy valamilyen hiba folytán esetleg módosulhatott. Ez igazából egy ilyen utalás arra, hogy ha hibát keresne az ember, elképzelhető, hogy a kernelben van hiba.
https://docs.kernel.org/admin-guide/tainted-kernels.html
https://support.hpe.com/hpesc/public/docDisplay?docId=c02905321&docLocale=en_US
https://unix.stackexchange.com/questions/118116/what-is-a-tainted-linux-kernel
-
urandom0
senior tag
Ha megcsinálod a méretvonalakat úgy, ahogy leírtam, akkor ugyanúgy a rajz részei lesznek, mint bármilyen más objektum, úgyhogy elméletileg ugyanúgy ki is kell nyomtatódniuk. Ha máshogy nem megy, akkor mentsd el először PDF-be, és nyomtasd ki azt.
Ha erősen műszaki jellegű rajzot szeretnél készíteni, akkor viszont Inkscape helyett valami CAD programmal lenne célszerű csinálnod, pl. FreeCAD-ben.
-
#98706
urandom0
senior tag
tordaitibi
#98702
urandom0
senior tag
válasz
tordaitibi
#98702
üzenetére
Hú, igazad van, bocsi, összekevertem a hibernálást a hybrid sleeppel
-
-
urandom0
senior tag
Amúgy a powercfg /H off parancs a hibernalást kapcsolja ki (ezért nem lesz fast startup sem).
Igen, mert a kettő gyakorlatilag ugyanazt a technológiát használja a háttérben. Nem tudod egyiket kikapcsolni a másik nélkül.
Ubynak ezt kell kikapcsolni, mert ez zárolja a meghajtó, nem a BIOS-os fast boot. A BIOS-os fast boot az olyan, hogy nem végez annyi hardverellenőrzést, ilyesmik.
-
-
#98581
urandom0
senior tag
tordaitibi
#98577
urandom0
senior tag
válasz
tordaitibi
#98577
üzenetére
Újabban EasyEffects néven fut: [link]
Disztrótól függően vagy ilyen, vagy olyan néven lehet megtalálni a repóban. De ez a Pipewire-hez igazított verzió, szóval ha Pipewire van a disztróban, akkor ezt érdemes feltenni, a PulseEffects-s pedig hanyagolni (mert az a PulseAudio-hoz készült, régebbi változat). -
urandom0
senior tag
válasz
RaZroX
#98504
üzenetére
A flatpak, a snap és az appimage is nagyon hasonlít a Mac-féle app bundle-re, a legnagyobb különbség ezek között, hogy a flatpak és a snap csomagok között függőségek definiálhatók, tehát pl. egy flatpak csomag függhet egy másik csomagtól. Ha pl. két flatpak csomagnak kell a Gnome 44 runtime, akkor elég egyszer feltelepíteni, mindkét csomag tudja használni.
Illetve a flatpakhoz és a snaphoz beépített támogatás van majdnem minden disztróban (legfeljebb alapértelmezetten nem települ fel), de az appimage-hez nincs ilyesmi. A flatpak/snap csomagok nagyon könnyen telepíthetők, frissíthetők, törölhetők parancssorból vagy grafikus programból, appimage-hez nincs ilyen jellegű támogatás (harmadik féltől származó program van rá). -
#98507
urandom0
senior tag
tordaitibi
#98500
urandom0
senior tag
válasz
tordaitibi
#98500
üzenetére
Az a baj, hogy egy disztró karbantartása sokkal nagyobb feladat, mint amennyire elsőre annak tűnik, és ezt sokan nem látják az elején. Mert nem csak arról szól, hogy fogok egy alap disztrót, hozzácsapom a saját csomagjaimat és kész. Minden apró hülyeséggel foglalkozni kell, ami nagyon el tudja vinni az időt.
Én a múltkor a Guefihez deb és rpm csomagokat. Ez egy pici, egyszerű program, ráadásul még ritkán is frissül, de mivel alapból Slackware-hez készült, így meg kellett patchelnem, hogy más rendszerek alatt is menjen (és még egy patchet csináltam hozzá, hogy a parancsikonok is rendben legyenek).
Ha most lenne 3-4 olyan csomagom, amihez mondjuk hetente-kéthetente jönnek frissítések, és folyamatosan karban szeretném tartani őket, már az heti több óra elfoglaltságot jelentene nekem, és azt kéne beillesztenem a napi dolgaim közé... -
-
urandom0
senior tag
válasz
moleculez
#98462
üzenetére
Ezek addig működnek jól amíg az egyes (szubkúltúrák) szakterületek a saját kis ökoszisztémájukat karbantartják, és/vagy találnak hozzá szponzort mert elég fontos (vagy annak eladható).
Hát igen, amikor pénzérdek van a dolgok mögött, akkor működnek, hobby fejlesztésnél viszont sokszor sajnos nem. Megunja a fejleszti, elveszti a motivációt, vagy történik valami, aztán úgy járunk, mint a left-padnál. Kihúznak egy téglát, aztán dől össze a kártyavár.
Én mostanában Javazok, és itt hatalmas nagy előny, hogy fixen ott van a JRE, amiben az alapvető függvények és azon kívül sok-sok hasznos függvény ott van. De ha komolyabb dolgot akar az ember, akkor ahhoz is kénytelen lehúzni a netről a függőségeket.
-
urandom0
senior tag
válasz
RaZroX
#98471
üzenetére
Mi történik ha nem váltok azonnal amikor kijön az új, hanem várok pár hónapot amíg az is stabil lesz?
Fedoránál ez úgy van, hogy évente két főverziót adnak ki, általában áprilisban és októberben egy-egyet, és minden főverzió körülbelül 13 hónapig van támogatva. Ez azt jelenti, hogy amikor kijön az új verzió, az eggyel korábbi verzió akkor van kb. az életciklusa közepén, azaz onnantól még fél évig támogatott, az azelőtti verziónak pedig hamarosan, pár héten belül lejár a támogatása.
Itt egy kép, ha jobbra görgetsz, ott vannak a jelenlegi kiadások:
https://en.wikipedia.org/wiki/Template
edora_Linux_release_timelineItt látszik, hogy a 40-es verzió megjelenésekor a 39-es verziónak még kb. fél éve volt hátra a támogatás megszűnéséig, ez hamarosan lejár. A 38-as verzió támogatása pedig kb. egy hónappal a 40-es verzió megjelenése után járt le.
Konkrétan így néz ki a dolog: https://endoflife.date/fedora
Szóval akár két verzióval is lemaradhatsz, vagy ha egy verzióval vagy lemaradva, akkor van fél éved az átállásra. Én sem szoktam elkapkodni egyébként, mindig kivárok pár hónapot.
-
urandom0
senior tag
válasz
#63718632
#98467
üzenetére
A Fedora telepítőbe be van "drótozva", hogy kell egy /boot partíció 1GB méretben és ext4 fájlrendszerrel.
Nincs bedrótozva, csak alapértelmezett felállás az, hogy készít magának boot partíciót. Azért a Fedora telepítője nem akkora rakétatudomány, mint ahogy itt egyesek beállítják.
Haladó módban bárhogy lehet partícionálgatni. Az "über expert" mód a Blivet GUI, de átlagos otthoni felhasználásnál soha nincs rá szükség, én is csak egyetlen egyszer használtam, mert kíváncsi voltam rá.Fel kell rakni párhuzamosan egy "susét" és egy "fedórát" és megnézni a különbségeket. Vagy nagyon mélyen doksikat olvasni.
Itt egy Suse telepítés:
[root@Fujitsu-Suse /home/balazs]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 119,2G 0 disk
├─sda1 8:1 0 487M 0 part /boot/efi
├─sda2 8:2 0 114,9G 0 part /var
│ /usr/local
│ /tmp
│ /srv
│ /opt
│ /root
│ /boot/grub2/x86_64-efi
│ /home
│ /boot/grub2/i386-pc
│ /.snapshots
│ /
└─sda3 8:3 0 2G 0 part [SWAP]
sdb 8:16 0 931,5G 0 disk
└─sdb1 8:17 0 931,5G 0 part /mnt/sdb1
sr0 11:0 1 1024M 0 romVan még két másik Suse-s gépem, mindkettőnél van egy ~500 MB-os EFI boot partíció, ez nyilván az UEFI boot miatt kell.
---
Kicsit szerintem túl van lihegve ez a partícionálósdi. A disztrók által felkínált default partíciós sémák az otthoni felhasználók 99%-nak teljesen jók.
A BTRFS pedig teljesen jó, teljesen használható, kb. 5 éve csak azt használok, semmi gond nincs vele. -
urandom0
senior tag
Félig-meddig elolvastam a levelet, meg a szálat is, ami vicces, hogy épp a Pythont hozzák fel példának. Én is úgy vagyok, mint az egyik hozzászóló, hogy ha valami úgy kezdődik, hogy pip install..., akkor hagyom a francba, mert tudom, hogy jó eséllyel úgysem fog működni.
Semmit nem ér, hogy lehet egymás mellé telepíteni eltérő verziójú Pythonokat, ha egyszer szinte minden Pythonos cucc a netről szedi a függőségeit - olyan függőségeket, amiket ezer éve nem tart karban a kutya sem, sok közülük nem is létezik már.És ez a történet valóban nem a Rustról szól, nagyjából minden nyelv és környezet ilyen manapság. NodeJS-ből is addig jó a 16-os, amíg nem akarsz olyan projektet fordítani, amihez legalább 18-as kell, és akkor nincs mit tenni, ha mondjuk Debianban csak 16-os van, akkor be kell szerezned valahonnan frissebbet. De mondhatnám a Go-t is, ugyanez a szitu. Vagy XY random nyelvet/frameworköt, az is ugyanez. Nem véletlenül mentek rá manapság annyira a snap/flatpak/appimage/docker cuccokra, mert azok az oprendszertől függetlenül tudnak frissülni (vagy épp verziót lockolni).
Egyszerűen el kell fogadni, hogy manapság a világ kurva gyorsan változik, és ami egy éve még friss volt, az ma már elavultnak számít, és sok esetben lehetetlen fenntartani a függőségi rendszert. Már én rászoktam a dockerre, pedig az elején utáltam.
Amikor elkezdtem Java fejlesztéssel foglalkozni, akkor is úgy voltam vele, hogy jó lesz nekem a Java 8 is, amíg támogatott, aztán majd átállok 11-re. Aztán már én is Java 21-nél tartok, mert a 8-as verzióval egy rakat cucc nem megy, a 11-es nincs normális GraalVM támogatás, és így tovább...A Rusttal kapcsolatban meg el kell fogadni, hogy egy új dolog, és sok minden messze nem eléggé kiforrott még körülötte. De amit írnak vele kapcsolatban, hogy a borrow checker nem ér semmit, az egy orbitális baromság. Lehet persze körkörös referenciákkal memleaket csinálni Rustban is, de a mostani toolok többsége az ilyet kiszűri, és egyébként meg oda kell figyelni.
-
#98455
urandom0
senior tag
tordaitibi
#98449
urandom0
senior tag
válasz
tordaitibi
#98449
üzenetére
Ez nem Linuxos probléma, ez egy általános tendencia, hogy a fejlesztő cégek vagy kirakják a félkész szoftvert nyílt forráskódba, hogy a többit majd tegye hozzá a közösség, és onnantól fogva a fejlesztő cég csak annyi felelősséget vállal, hogy befogad-e egy adott commitot vagy sem. És bumm, így születnek a szar szoftverek.
Ez persze baromi jó a cégnek, mert nagyon alacsony erőforrásokkal tudja fejleszteni és tesztelni a szoftverét, mert ezt meg teszi helyette a közösség. Csak hát amíg a munkahelyen kivágnak, ha nem dolgozol, addig egy nyílt forráskódú fejlesztőt semmilyen retorzió nem ér, ha hetekre vagy hónapokra eltűnik.
Én írtam mobilappot Fluterrel és Darttal, ott ugyanez ment. Nincs semmilyen csomag a bluetooth kezelésére? Majd a közösség megoldja... meg hát, csak ha az egyik fejlesztő elmegy nyaralni 2 hétre, és bug van a csomagban, te meg nem tudod lefordítani az appod, az nagyon jó érzés.
-
urandom0
senior tag
válasz
moleculez
#98392
üzenetére
A .desktop fájloknak alapvetően nem kell x jogosultság, mert nem futtatható fájlok, hanem inkább konfigurációs fájlok, amik az asztali környezetnek szólnak. Gyakorlatilag viszont korábban volt már olyan, hogy az x nélküli .desktop fájlokat nem jelenítette meg a rendszer.
Olyanba is belefutottam már, hogy ha nem a $PATH-ban lévő könyvtárba települt a program indítófájlja, akkor a .desktop fájlban meg kellett adni azt az útvonalat, ahova települt, másként nem volt hajlandó megjelenni az indítóban. -
urandom0
senior tag
válasz
totron
#98323
üzenetére
Nem zavar, mert én nem a Windowsra készült tízbillió szoftvert akarom használni, hanem azt a tucatnyit, amire szükségem van, és az mind elérhető Linuxra is.
A kis Raspberry-met napi szinten használom, ezen van a webszerverem, ezt használom fájlszervernek, elég fura lenne mondjuk ezen Windowst futtatni, már csak azért is, mert Windowsra nincs tmux (és semmilyen terminal multiplexer). És ez engem sokkal jobban zavar(na, ha használnék Windowst).
Minden egyéb platformon nagyobb a kínálat.
Amennyiben egyéb alatt a Windowst és a MacOS-t értjük, akkor igen.
-
urandom0
senior tag
válasz
moleculez
#98278
üzenetére
Egyes Windowsokon a SysMain (régebbi nevén Prefetch) szolgáltatás memóriaszivárgást okoz. Én eddig két gépen találkoztam ezzel, egy asztali gépen és egy laptopon, ami egyébként azért is érdekes, mert van 4-5 ugyanolyan laptopunk, és azok közül egyiken sem jött elő...
Nade ez a dolog úgy néz ki, hogy bekapcsolod a géped, a memória kb. 30%-a foglalt. Aztán ahogy telik az idő, egyre feljebb megy, végül megáll olyan 99%-os memóriahasználatnál, és kegyetlenül belassul tőle a gép, és nem tudsz vele mit csinálni. Le kell tiltani a szolgáltatást, és onnantól oké a dolog.
Nem lehet, hogy ebbe futottál bele te is?Én meg úgy jártam a minap Windows 11-gyel, hogy egy nem engedte lefrissíteni a Windows 10-et egy i7-7700-as gépet, ami nem is annyira meglepő, mert a Windows 11 CPU kompatibilitási listájában nincs benn ez a proci.
Viszont letöltöttem az ISO-t egy pendrive-ra MCT-vel, és onnan meg szó nélkül felment
Szóval vannak vicces dolgai ennek a Windowsnak. -
urandom0
senior tag
válasz
szbalogh
#98259
üzenetére
Szia.
Szerintem ez nem nagyon fog menni máshogy, mint forrásból fordítással.
Esetleg megpróbálhatod hozzáadni az elrepót:
https://elrepo.org/wiki/doku.php?id=startEzen belül van három repó, az elrepo-extras, elrepo-testing és elrepo-kernel. Ez utóbbiban van a kernel-lt, ami long term, azaz hosszú támogatású jelent, és a kernel-ml, ami pedig a mainline-t jelenti. Megpróbálhatod lecserélni a jelenlegi kerneled, mert a mostani elég régi, viszont a 6-os verzióban már alapból bent van a 8188eu driver, ami kell a TP-Linkhez.
Vagy marad a forrásból fordítás innen: https://github.com/lwfinger/rtl8188eu
Végső esetben megpróbálhatod innen lekapni az rpm-et (kmod-8188eu-*), de nagyon meglepődnék, ha ez jól működne.
De én elsősorban a rendszerfrissítést javasolnám, próbálj meg áttérni 9-re. Én Rocky 9.4-et használok egy RPi-n, ebben 6.1.31-es kernel van, a TP-Link szerintem ezzel a verzióval már megy.
-
urandom0
senior tag
válasz
vizcsap
#98250
üzenetére
Feltételezem ha belső meghajtóra telepíteném a rendszert, akkor nem lenne ilyen probléma
Igen. Valószínűleg a külső házad nem inicializálja a lemezt időben, ezért a rendszer nem találta meg magát. Külső házas történeteknél ilyenek előfordulnak.
@mindenkinek
A Fedora és a Fedora alapú rendszerek alapértelmezetten btrfs-t használnak. A /var, /var/home stb. mappákat külön subvolume-ok alá csatolják fel. A subvolume-ok olyanok, mint egy "fájlrendszer a fájlrendszeren belül", saját gyökérrel, saját inode táblázattal, stb.
Az a partíciófelosztás, a vizcsap ezen screenshotján van, teljesen normális, fizikailag egy partíción vannak azok a mappák, csak más subvolume alá vannak felcsatolva. -
-
urandom0
senior tag
válasz
ubyegon2
#98206
üzenetére
*ez szerintem nem is Linuxos appimage
$ file viber.AppImage
viber.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=30e06184968532b6a9aa36f44ada39e4af0bda56, for GNU/Linux 2.6.32, strippedDe az!
Én vagy két hete próbálgattam végig a deb-es, az rpm-es, az appimage-es és a flathub-os Vibert. Az ikonjukon kívül nem észleltem köztük különbséget.
-
urandom0
senior tag
válasz
szuszinho
#98181
üzenetére
Akkor viszont meg kéne nézni, hogy cron alatt a $PATH-ban benne van-e a zip, a find, a date, esetleg a teljes env-et is kiírathatod.
És valami ilyesmű jellegű logolást tehetnél a scriptbe:
#!/bin/bash
d=$(date +%Y_%m_%d)
echo "date: $(date +%Y_%m_%d), d: $d" >> log.txt
zip -r /ide/file_$d.zip /ezt >> log.txt 2>&1
echo "/ide/file_$d.zip" >> log.txt
find /ide -type f -mtime +15 >> log.txt
find /ide -type f -mtime +15 -exec rm {} \; >> log.txt 2>&1Nem próbáltam ki, lehet, hogy van benne hiba. De a lényeg, hogy logolj el mindent, hátha csak valami banális hiba van.
-
urandom0
senior tag
Hát kérlek szépen, ez egy segmentation fault, vagy más néven access violation. A Gnome Commander olyan memóterületet akart elérni, ami nem hozzá tartozik, valószínűleg egy lefoglalatlan memóriaterületre akart írni, vagy el van indexelve benne egy tömb, stb.
Ezzel nem tudsz mit kezdeni, a fejlesztőnek kell kijavítania.
Ha terminálból indítod, lehet, hogy ír még mást is. -
urandom0
senior tag
válasz
paolinho
#98147
üzenetére
Az mit jelent (vagyis honnan tudhatom), hogy sima szkriptfájl a fájl?
Általában a script fájloknak .sh kiterjesztésük van. De ettől még nem lesz futtatható, Linux alatt csak akkor válik valami futtathatóvá, ha futtatási jogot adsz neki. Erre való a
chmod +xparancs (vagy ha a fájlkezelődben van rá lehetőség, akkor ott).Illetve a felső kép a kicsomagolt rom maga. Akkor ott nyitok egy Terminál-t és írom be konkrétan a ./linux_fastboot_update_rom.sh parancsot?
Szerintem azon a képen az látszik, ahogy a tömörítő programban megnyitottad, hiszen ott van a "Kibontás" menüpont.
Ha ki van bontva, akkor nyitsz egy terminált abban a mappában, ahova kibontottad, és kiadod a ./linux_fastboot_update_rom.sh parancsot.Ha az sh-ra rákattintok, akkor kapom a második képet.
Akkor viszont olyan fájlkezelőd van, ami duplaklikkre nem lefuttatja, hanem megnyitja a fájlt. Ennek biztonsági okai vannak, hogy ne tudj véletlenül elindítani egy scriptet.
Ilyen jobbklikkelj a fájlra, és biztos van ott valami futtatás menüpont. -
urandom0
senior tag
válasz
paolinho
#98143
üzenetére
Az sh sima szkriptfájl. Futtatási jogot kell neki adni, vagy terminálból úgy, hogy
chmod +x fájlneve.sh, futtatni pedig úgy lehet, hogy./fájlneve.sh, vagy fájlkezelőben a tulajdonságainál, és utána vagy duplaklikkel indul, vagy jobb klikkes menüben van futtatás parancs.
Csak először csomagold ki valahova. -
urandom0
senior tag
lsusb -t nálam ezt adja az eszközömre:
Port 5: Dev 11, If 0, Class=Mass Storage, Driver=usb-storage, 480Mdmesg -w és udevadm monitor parancsok mit adnak vissza, miközben kihúzod és visszadugod? A dmesg usb-storage-ként kell, hogy mutassa, az udevadm pedig scsi block eszközként.
Egyébként ha rákeresek a modulok között, nálam is mutatja az uas-t:
# lsmod | grep -i uas
uas 36864 0 -
urandom0
senior tag
Nem hiszem, hogy ehhez bármilyen driver kellene. Nekem van 3 külső házam, az egyik Axagon (nem pont ez a típus, ami neked van), és egyikhez sem kellett soha semmilyen driver. Az egyik jelenleg egy RPi-re dugva üzemel, még úgy is tökéletes. Ott valami más gond lesz szerintem. Ha tudod, próbáld ki másik HDD-vel.
-
urandom0
senior tag
válasz
tvamos
#98120
üzenetére
Bocs, de ez a Grubos hozzáállásod hülyeség. Milyen installer okoskodik bele és milyen beállításaidba? Ha azt tapasztalod, hogy a Grub elront valamilyen beállításod, akkor valószínűleg olyan config fájlokat módosítottál, amiket nem kellett volna, mert azok a Grubhoz tartoznak, és a Grub a következő frissítésnél felül fogja írni őket.
A legjobb megoldás, hogy hagyod frissülni a Grubot. De ha valami nyomós indokod van rá, hogy ne frissüljön, akkor az apt-mark hold csomag parancssal meg tudod akadályozni, hogy frissüljön az adott csomag.
-
urandom0
senior tag
válasz
totron
#98037
üzenetére
Az X a maga idejében egy nagyon fejlett cucc volt, csak azóta megváltoztak az elvárások és a lehetőségek is, és az X, ahogy van, nagyon elavultnak számít már.
A multiplatformmal mi a gond? Most azon kívül, hogy nyilván minden supportált platformon le kell tesztelni, adott esetben itt-ott kicsit alakítani kell rajta...
moleculeznek is:
Üzemeltetői szempontból nyilván egyszerűbb az élet az ilyen böngészős cuccokkal, de én fejlesztői szempontból azt látom, hogy olyan problémákkal küzdenek, amiket egy normális multiplatform nyelv/keretrendszer már rég maga mögött hagyott. Gondolok pl. az erőforrásproblémákra, amikkel szinte minden komolyabb böngészős szoftver küzd. A mai gépeken persze nem annyira látványos, hogy egy DOM művelet mondjuk 0,002s helyett 0,2s alatt megy végbe. De ha azt vesszük, hogy egy asztali GUI framework ugyanazt a műveletet 20 évvel ezelőtt meg tudta csinálni 0,002s idő alatt, akkor azért na.
Meg gondolok arra, hogy a böngésző (vagy ha szerveroldalról beszélünk, akkor NodeJS), mint framework, jócskán elmarad mondjuk egy JRE vagy .NET mögött. A böngészők az elmúlt években kezdtek el olyan osztályokat nyújtani a fejlesztő számára, amik JRE-ben 20 éve ott vannak. A class mint kulcsszó, a WeakMap, WeakSet, vagy pl. a temporal, stb. Az összes olyan nyelv, ami valamikor scriptnyelvként indult, az elmúlt években elkezdett elmenni ilyen Java-s/.NET-es irányba. A JavaScript is azóta lett használható nyelv, mióta TypeScriptnek hívják
De a PHP is ezen az úton halad, szigorúbb típusosság, interface-ek, type hinting, stb.Most én is fejlesztek egy programot, egy elég egyszerű kis adatmegjelenítőt. Az egyik egyetemen fog futni, Neptunból exportált órarendi adatokat, eseménynaptárból exportált rendezvényeket, és rövidebb infókat fog megjeleníteni. Az elején vacilláltam rajta, hogy hogyan csináljam meg, legyen böngészős app, legyen Electronos, vagy natív, ha igen, akkor milyen nyelven... a Java mellett döntöttem, mert a JRE-vel egyben egy olyan frameworköt kapok, amiben rengeteg hasznos metódus van, és nem nekem kell minden egyes apróságot megírni nulláról. És mert a Java egy jó programozási nyelv, a JavaScript meg egy ócska tákolmány
-
urandom0
senior tag
Igen, manapság ebbe az irányba haladunk, és szerintem jó ez az irány. Régen, a '70-es/'80-as években a nagyobb intézményeknél már működött az, hogy volt egy vagy több központi szerver clusterben, futott rajta valamilyen rendszer (általában UNIX), a dolgozóknál pedig volt egy terminál gép, és a szerverre belépve dolgoztak. Ehhez képest hatalmas visszalépés az, hogy minden dolgozónál van egy teljes értékű munkaállomás, és helyben fut. És ez a DOS ill. a Windows 9x sara, mert azok csak minimális mértékben voltak felkészítve a hálózati működésre.
A másik megoldás, hogy a programot valamilyen multiplatform nyelven írják, helyben fut, de az adatokat a szerverről veszi. Csak ez megint problémásabb olyan szempontból, hogy a fejlesztőre hárul a többféle operációs rendszer supportálása (tesztelés a különféle rendszereken, stb.), míg webes cuccnál nem. És a webes cuccot könnyebb deployolni, mert pl. frissítésnél csak élesíteni kell a szerveren a friss verziót és kész, míg helyileg futó programnál ki kell tolni a user gépére a friss binárist.
-
#98020
urandom0
senior tag
tordaitibi
#97996
urandom0
senior tag
válasz
tordaitibi
#97996
üzenetére
Fogadom nagy összegbe hogy a 3%-ról megugrana a részesedése. Bár.. megint mindjárt megkapom hogy nem, dehogyis kell a szélesebb felhasználói tábor, neeem, ááá, szenvedjen meg érte aki akarja használni, és egyáltalán, dehogy is kell elterjednie, a hülyék maradjanak Winen.
Mintha féltenék. Mitől...?Nem félelemről van szó, de szerintem a Linux elterjedtsége csak akkor fog növekedni, ha a Windowst annyira elszarják, hogy tényleg használhatatlan lesz. Jövőre, ha véget ér a Windows 10 támogatása, valamelyest növekedni fog a Linux elterjedtsége, már most is látszódik ez a trend (a bűvös 4%).
De egyébként az a folyamat épp a snap/flatpak csomagokkal indult el, amiről te beszélsz. Egységesítés, verzióváltás (vagy nem váltás) az operációs rendszer verziójától függetlenül.... a cégek már sok éve használják, az otthoni userekhez még nem annyira csorgott le.
Az Appimage írásaddal maximálisan egyetértek.
Az nem én voltam
-
#97991
urandom0
senior tag
tordaitibi
#97988
urandom0
senior tag
válasz
tordaitibi
#97988
üzenetére
Lényeg, felpakolsz valamit aminek kell a libakarmi1.1, az legyalulja a libakarmi1.0 -t, és a csomagkezelő legyalulja azt a 5-10 programodat aminek a ez a függősége. Ez így brilliáns.
Ez csak akkor igaz, ha a csomagkészítőnek szándékosan ez volt a célja. Minden további nélkül fent lehet egy csomag több különböző verziója, szépen megférnek egymás mellett. Ilyen pl. a python, amiből van 3.11, 3.12, stb., és mind telepítve lehet párhuzamosan. Vagy a GTK, amiből most nekem is telepítve van libgtk-2_0-0, a libgtk-3-0 és a libgtk-4-1.
Meg lehetne csinálni azt, hogy mondjuk az Ubuntu 24.04-ben bent legyen az összes addigi Ubuntu verzió összes csomagja. A probléma az, hogy nincs, aki a régi csomagokat karba tartsa.
A Windowsban is rengeteg régi kód van, ezért is tud a korábbi verziókkal kompatibilis maradni. De ott a Microsoft megoldja házon belül, nagyon ügyelnek a visszafelé kompatibilitásra. Linuxnál ezt így nem lehet eljátszani. -
urandom0
senior tag
Azt ne kapcsold ki, hanem tekerj lejjebb az ablakban, a jobb alsó sarokban ott a jelszókezelő elindítása gomb. Arra klikk rá, az ablakban lesz olyan, hogy jelszó megváltoztatása. Arra klikk, és itt van a trükk: nem szabad jelszót megadni, akkor sem, ha hápog, hogy túl gyenge a jelszó. Csak okézd le az üres ablakot.
-
urandom0
senior tag
válasz
galaxy55
#97724
üzenetére
Az apt tudtommal egy frontend a többihez, legalábbis úgy indult.
Igen, az, az apt-get-et, az apt-cache-t és az apt-rdepends-et tudja helyettesíteni. De igazából lényegtelen, ki kinek a kicsodája, csak megjegyeztem, hogy Fedora és Suse után szokatlan, hogy ezek mind külön kis programocskák. De nincs különösebb jelentősége.
A "leglowlevelebb" része a dolognak a dpkg, ez olyan, mint rpm alapú rendszereknél maga az rpm segédprogram.
-
urandom0
senior tag
válasz
galaxy55
#97717
üzenetére
Nem keverem. Az apt-get, az apt-cache és az apt három különböző program. Az igaz, hogy az apt tulajdonképpen az apt-get és az apt-cache összevonásából született meg, úgyhogy végső soron kiváltja mindkettőt (az más kérdés, hogy az apt-cache kimenete alapértelmezetten egész más, sokkal bővebb, és szerintem jobban használható).
De az apt-key, az apt-add-repository, az apt-changelog, stb., mind-mind kis apró programocskák. És néha még az ember használja a dpkg-t is.Az unattended-upgrades más, mint amiről beszélek. Annak a megfelelője a dnf-automatic, zyppernél tudtommal nincs rá kész megoldás.
A zypper és a dnf azt csinálja, hogy X időnként minden csomagművelet előtt frissíti a metadatokat. Ez olyan, mint ha te mondjuk minden második órában lefuttatnál egy apt update-et. -
urandom0
senior tag
válasz
#63718632
#97702
üzenetére
Hogy érted, hogy interaktívabb? Nekem az apt-ben egyetlen egy dolog nem tetszik, hogy szét van szabdalva ilyen-olyan frontendekre, mint pl. az apt-cache, apt-key, apt-add-repository... dnf-nél és zyppernél ezek mind egyben vannak. Mondjuk zyppernél még mindig nincs "autoremove".
szerk: én azt is szeretem, hogy a dnf és a zypper is automatikusan updateli a metaadatokat időnként, az apt ezt sem csinálja.
-
urandom0
senior tag
De te sosem panaszkodtál a dnf sebességére. Tele van a net olyanokkal, hogy Why is dnf so horribly slow?, Why is dnf so slow?, Extremely slow dnf, de te mindig azt mondtad, hogy szerinted nem lassú a dnf
Szerintem még az új verzió is lassú, gyors majd akkor lesz, ha átállnak dnf5-re, az meg majd csak a 41-ben lesz. -
urandom0
senior tag
válasz
ubyegon2
#97692
üzenetére
Fedorához pl. nincs normális grafikus csomagkezelő. Ha Gnome-ot használ az ember, annak van a saját szoftver áruháza, meg KDE-hez a Discover (tudtommal se a Muon, se az Apper nincs már bent a repóban), de olyan, mint Debian alapú rendszerekhez a Synaptic, csak a Dnfdragora van, de szerintem azt sem használja senki sem, olyan béna. Szóval Fedora alatt nagyjából elkerülhetetlen, hogy terminálozzon az ember, ha a csomagjait akarja menedzselni.
-
urandom0
senior tag
válasz
galaxy55
#97694
üzenetére
i3 az egyértelműen ablakkezelő szerintem. A desktop environment inkább az, ahol van panel, vannak minialkalmazások, esetleg widgetek, külön beállító ablak, kis segédprogramok, tehát így minden egyben. A wm pedig tényleg inkább csak egy ablakkezelő, esetleg néhány plusz segédprogram hozzá.
-
urandom0
senior tag
A legtöbb mai gép simán bebootol NTFS fájlrendszerű EFI partícióról is, csak akkor kell a FAT-hoz ragaszkodni, ha nem indul NTFS-sel.
Az az UEFI_NTFS partíció pedig FAT (konkrétan FAT12), oda van írva... csak a kötetcímke UEFI_NTFS. Ez a Rufus egyik sajátossága, az UEFI
TFS nevű bootloader. -
urandom0
senior tag
válasz
paolinho
#97663
üzenetére
Ha lenyitod az Area (Terület) mezőt, ott van olyan lehetőség, hogy Rectangular Region (Téglalap alakú terület), ha azt választod ki, és rányomsz a Take a new screenshot-ra, akkor új képernyőképet fog készíteni, de úgy, hogy te adod azt a területet, amiről készüljön a kép. De van ott olyan lehetőség is, hogy csak az aktív ablakról készüljön kép, vagy a kurzor alatti ablakról, így nem is kell vagdosni semmit.
A Gwenview-s megoldás inkább akkor jó, ha nagyon pontosan akarsz körbevágni valamit, mert ott ránagyítva is ki lehet jelölni a vágandó területet.
-
urandom0
senior tag
Nem szokat számít szerintem (ha csak nem Gnome). Most pl. erről a gépről vagyok:
OS: openSUSE Leap 15.6 x86_64
Host: ESPRIMO P400
Kernel: 6.4.0-150600.23.17-default
Uptime: 10 hours, 36 mins
Packages: 2932 (rpm), 8 (flatpak)
Shell: bash 4.4.23
Resolution: 1920x1080
DE: Plasma 5.27.11
WM: KWin
Theme: [Plasma], Breeze [GTK2/3]
Icons: [Plasma], breeze [GTK2/3]
Terminal: konsole
CPU: Intel i5-2320 (4) @ 3.300GHz
GPU: Intel 2nd Generation Core Processor Family
Memory: 1759MiB / 7829MiBAnnyi, hogy SSD van benne a gyári HDD helyett, és KDE-vel is gyors, mint a villám.
Egy hasonló gépet használok a cégnél is, az is valami tizenpár éves HP valami. A Gnome volt a leglassabb rajta, de KDE és Xfce között én már nem vettem észre igazából különbséget, max ilyen fél másodperceket. Kb. annyi különbség van, mint egy Systemd-es disztró és egy Slackware között, nagyon minimális. -
urandom0
senior tag
válasz
paolinho
#97648
üzenetére
Milyen ablak jön be, ha PrtScr-t nyomsz? Nincs rajta olyan gomb, amivel téglalap alakú területet lehet kivágni?
Ilyen
vagy ilyen ablakot kell, hogy kapj, amikor nyomsz PrtScr-t.
Attól függően, mennyire vagy régi a rendszeredben a KDE. Mindenesetre akármelyik ablakot is kapod, van benne Exportálás gomb. Ha ezt megnyomod, ki tudod választani a Gwenview nevű programot, ami a KDE képnézegetője, de van benne Levágás funkció, lásd itt. Ezzel méretre tudod vágni a képet, és utána csak el kell mentened.
-
#97520
urandom0
senior tag
tordaitibi
#97518
urandom0
senior tag
válasz
tordaitibi
#97518
üzenetére
Megmondom őszintén, sosem szerettem ezt az ablakváltó dobozt és a csodalámpa effektet. Nekem a Plasma alap ablakváltója teljesen jó.
-
#97516
urandom0
senior tag
tordaitibi
#97511
urandom0
senior tag
válasz
tordaitibi
#97511
üzenetére
Írták, hogy a Linux Mint + KDE nem annyira jó barátok, így nem is akartam ráerőltetni. Mondjuk én pont azt a megoldást nem szeretem, amit te használsz.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
edora_Linux_release_timeline
TFS nevű bootloader
Új hozzászólás Aktív témák
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!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- sziku69: Szólánc.
- Milyen videókártyát?
- Óvodások homokozója
- Elektromos autók - motorok
- A fociról könnyedén, egy baráti társaságban
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Soundbar, soundplate, hangprojektor
- sziku69: Fűzzük össze a szavakat :)
- Google Pixel 10 Pro XL – tíz kicsi Pixel
- További aktív témák...
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Game Pass Ultimate előfizetések 4 - 19 hónapig azonnali kézbesítéssel a LEGOLCSÓBBAN! AKCIÓ!
- Xiaomi Redmi Note 11 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 12 mini 128GB Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3327, 94% Akkumulátor
- Telefon felváráslás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Macbook Pro 2019 // i5 // 1TB // Számla+Garancia //
- Bomba ár! Dell Latitude 7390 - i5-8GEN I 8GB I 256GB SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest