-
Fototrend
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
válasz
Anakin007
#96444
üzenetére
Azt jól értelmezem, hogy pl. kép megnyitáshoz alapból az image.sh -t hívja meg és ez a szkript dönti el, mit mivel nyisson meg?
Igen.
Pl. találtam bejegyzést az image.sh-ban, miszerint xcf-t gimp-el, svg-t inkscape -el nyisson meg.
Ezek igazából csak alapértelmezéseket nyújtanak olyan esetekre, amikor nincs beállítva semmi sem az adott fájltípus megnyitásához.
Ha megnézed, a script elején van egy ilyen sor:
[ -n "${MC_XDG_OPEN}" ] || MC_XDG_OPEN="xdg-open"A végén pedig egy ilyen:
case "${action}" in
view)
do_view_action "${filetype}"
;;
open)
("${MC_XDG_OPEN}" "${MC_EXT_FILENAME}" >/dev/null 2>&1) || \
do_open_action "${filetype}"
;;
*)
;;
esacEz azt eredményezi, hogy ha az MC_XDG_OPEN értéke be van állítva, akkor a fájlon az XDG_OPEN műveletet hajtja végre, az XDG_OPEN művelet pedig az adott fájltípushoz rendszerszinten (tehát nem az mc-ben) beállított alapértelmezett műveletet hívja meg (https://portland.freedesktop.org/doc/xdg-open.html). És mivel nálad a Gvenview az alapértelmezett művelet, ezért azzal nyitja meg a képeket. Szóval igen, úgy van ahogy mondod, egy környezeti változót kérdez le, és az alapján dönti el, hogy mivel nyissa meg a fájlt.
-
válasz
Anakin007
#96440
üzenetére
Pedig jó helyen keresgéltél. Az Include=image azt jelenti, hogy az összes ilyen típusú fájlt "image" típusúként kezeljen.
Ha letekersz az edit extension file végére, ott találsz ilyet, hogyinclude/image
Open=/usr/lib/mc/ext.d/image.sh open ALL_FORMATS
View=%view{ascii} /usr/lib/mc/ext.d/image.sh view ALL_FORMATSEz a két sor mondja meg, hogy mit kezdjen az image típusú fájllal. A View az F3, ha lenne Edit, az lenne az F4, az Open sor pedig az Enter és a duplaklikk.
Annyit kell tenned, hogy az Open sor elé teszel egy #-t, ez innentől megjegyzésnek fog számítani, majd a következő sorba beírod azt, hogyOpen=display %fTehát ez legyen a végeredmény:
include/image
#Open=/usr/lib/mc/ext.d/image.sh open ALL_FORMATS
Open=display %f
View=%view{ascii} /usr/lib/mc/ext.d/image.sh view ALL_FORMATSMert ugye a display nevű programocska az ImageMagick megjelenítője (legalábbis nálam, OpenSuse alatt, elképzelhető, hogy nálad más lesz). Az %f pedig a kijelölt fájl teljes elérési útja.
És innentől fogva az mc a ImageMagickkel nyitja meg a képeket.
Ha valamikor a jövőben szeretnéd visszaállítania a társítást, akkor a most beírt sort törlöd, az eredeti Open= sor elől pedig kiveszed a #-t. -
#96419
urandom0
őstag
tordaitibi
#96418
válasz
tordaitibi
#96418
üzenetére
A /home csak egy elérési út, semmi más. Lehet az egy könyvtár egy, a rendszerrel azonos partíción. Lehet egy könyvtár egy másik partíción. Lehet egy logikai LVM kötet egy RAID tömb fölött. Lehet egy BTRFS kötet. Lehet egy távoli NFS/SFTP/SMB....
-
#96402
urandom0
őstag
tordaitibi
#96395
válasz
tordaitibi
#96395
üzenetére
Igaza van Rimuru kollégának, az ilyesmit a /etc/polkit-1/rules.d/ mappába kellene raknod, mert ha jön egy frissítés, simán felülírhatja/lecserélheti a fájlodat, és akkor írhatod meg újra.
-
A root a mindenható, neki alanyi jogon járó, elidegeníthetetlen jogosultsága van mindenhez.
Ha viszont sudo-val szerzel jogokat, akkor csak az történik, hogy van egy átlag user, aki (ideiglenesen) root jogosultságokat kap.Akkor ez még mindig nem teszi a dolgot biztonságosabbá, hiszen, ha megtudják a sudo user jelszavát, akkor ugyanúgy lehet randalírozni a rendszeren.
Többfelhasználós rendszerben gondolkodj. Ha egy rendszerhez van hozzáférése a rootnak, Józsikának, Petikének, Ancsikának, és azt szeretnéd, hogy Petike is root legyen, akkor vagy megadod neki a root account jelszavát (ezzel gyakorlatilag kiadod a kezedből az egész rendszert, nesze itt van csinálj vele amit akarsz), vagy beírod az /etc/sudoers-be, és onnantól fogva a saját jelszavával, a saját fiókja alatt tevékenykedhez root jogokkal. Tehát így nem kell kiadni a root jelszót.
Másrészt, a sudoers-ben meg lehet adni, hogy ne mindenhez legyen valakinek sudo joga, csak mondjuk egy-egy programhoz.
Pl. ha ezt írod be:user ALL=(root) /bin/mount,/bin/umountAkkor usernak csak a mount és umount parancsokhoz lesz root joga.
Illetve ha nem mindig vagy root, hanem csak akkor, amikor kell, akkor kisebb eséllyel csinálsz hülyeséget. És ez nem csak rád vonatkozik, hanem a programokra is. Gondolj bele, ha rootként jelentkeznél be a rendszeredbe GUI-n keresztül, akkor az X-en keresztül a böngészőn át minden egyes program rootként futna. Ha valamelyik programba van akár csak egy véletlen hiba, korlátozás nélkül boríthatja meg a rendszered.
Sok disztrón eleve le is van tiltva a root account, hogy senki ne is akarjon rootként dolgozni. SSH-n és gyárilag tiltva van a root.
Valamint az sem mindegy, hogy a logokban is másként jelenik meg, ha rootként csinálsz valamit, vagy ha sudozott felhasználóként.
-
Igen, Suse-nak főleg céges ügyfelei vannak, olyan kis "garázscégek", mint a BMW, a Lenovo, a SONY...
Otthoni felhasználók körében tényleg nem túl jelentős, Distrowatchon is csak a 9-10. helyen áll. -
Igen, ezt rebesgették, aztán a SUSE kiadott egy közleményt: Clear Course is Set for openSUSE Leap
A lényeg:
There are no plans to drop the classical (non-immutable) option for Leap; both non-immutable or immutable installation variants are available for Leap 15 and are planned for Leap 16. This is set to remain the preferred way for people to deploy Leap.
Leap will continue to follow the openSUSE factory development model.
Azaz lesz immutable és mutable verzió is a Leap-ből, és a mutable verzió lesz a preferált telepítési mód, tehát marad minden, ahogy van, csak lesz immutable verzió is.
-
Én hétfőn telepítettem OpenSuse Leap-et KDE-vel két gépre is, és el kell mondanom, hogy parádésan működik!
Itt még olyasmik is működnek, amik más disztrók alatt nem szoktak, pl. az SFTP megosztásokat fish:// protokollal szoktam megnyitni Dolphinban, mert sftp://-vel vagy nem is megy, vagy csak akadozva, de itt úgy is működik. Csodálatos!
Igaz, nem friss verzió, tavaly októberi, de jó ez nekem. -
#96311
urandom0
őstag
PCProfessor
#96309
válasz
PCProfessor
#96309
üzenetére
Nem értem mit teszel, hogy ezek a hibák előjönnek nálad.
Buguntut használ, azt teszi
Én 20.04 körül használtam utoljára Xubuntut, akkor nem tapasztaltam ezeket a hibákat, de hát azóta már sok víz lefolyt mindenhol.
Érdemes lenne megpróbálni a gépein egy OpenSuse Leap-et, hogy azalatt is előjönnek-e a hibák. Gyanítom, hogy nem. -
Pont ott írja a Debian wikiben, hogyan lehet beállítani, azt nem próbáltad?
https://wiki.debian.org/ZRam#sysvinit -
#96283
urandom0
őstag
tordaitibi
#96276
válasz
tordaitibi
#96276
üzenetére
Meg kéne próbálni a Spectacle-t úgy, hogy ez a robbanás animáció ki van kapcsolva.
-
#96273
urandom0
őstag
tordaitibi
#96243
válasz
tordaitibi
#96243
üzenetére
Spectacle meg van hülyülve, képernyőképnél beleveszi saját magát is
Ez egyébként akkor van, ha egynél többször egymás után nyomod meg a PrtScrt. Elsőre megjelenik a Spectacle ablaka, benne a képernyőképpel, másodikra viszont már nem jelenik meg új ablak, hanem csak csinál egy újabb képernyőképet, és azt rakja be a már megnyitott Spectacle ablakba.
Ahányszor lenyomod a PrtScr-t, annyiszor lesz benne a Spectacle ablaka -> [kép] -
#96271
urandom0
őstag
tordaitibi
#96270
válasz
tordaitibi
#96270
üzenetére
Én csinálnék azon a gépen memóriatesztet...
-
válasz
sh4d0w
#96235
üzenetére
Én most lecseréltem a Slackware-t Suse-ra, mert az open build service-t nyúzom, azzal meg voltak problémák Slacki alatt. De végső soron a Suse a Slackware-ből evolválódott ki, és ez meg is látszik rajta, mert eddig két olyan disztróval találkoztam, ahol van
/etc/profile.d/lang.sh, Slackware és Suse -
Azért írtam Slackware-t, MX-et és Antixot, mert azok systemd mentesek, és egy ilyen régi gépnél szerintem számít, hogy a systemd ne egye az erőforrásokat.
Egyébként Slackware-hez van függőségeket kezelő csomagkezelő, a slapt-get, és ott az sbo, ami forrásból fordít SlackBuilds alapján.
-
Csak úgy eszembe jutott erről az időeltolódásos dologról, hogy valamelyik setupban láttam olyan opciót, hogy meg lehet adni, UTC-ben vagy helyi időre van-e beállítva az óra. És igen, ma az egyik telepítettem Suse-t, és ott meg lehet --> kép.
Arra is emlékszem, hogy Slackware-ben is meg lehet adni, mert azt meg kb. 3 hete telepítettem -> kép.
Jó lenne, ha lenne ilyen opció Buntuk telepítőjében is. -
válasz
ubyegon2
#96225
üzenetére
Megfogadtam a tanácsom, várt
5leteseN
Nem próbáltad egy teljesen tiszta Firefox telepítéssel? Én megpróbálnám, lementeném a profilom, és kitörölném, illetve újratelepíteném a Firefoxot is, megnézni, hogy úgy is előjön-e a hiba.
Én most kipróbáltam Debian, Mint, OpenSuse és Fedora alatt, terminálból indítottam a Firefoxot, de nem sikerült elővarázsolnom ezt a warningot.
-
válasz
CPT.Pirk
#96212
üzenetére
kézi telepítésűre állítva
Ez csak annyit jelent, hogy az a konkrét csomag a te utasításodra települt, nem pedig más csomag függőségeként. Ennek akkor van jelentősége, ha eltávolítasz egy olyan csomagot, aminek ez az adott csomag a függősége, mert ha az kézire van állítva, akkor nem fog törlődni.
Pl. a plasma-desktop csomagnak a függősége akactivitymanagerd. Ha telepíted aplasma-desktopot, akkor felmegy vele akactivitymanagerdis, ha eltávolítod aplasma-desktopot, akkor törlődik akactivitymanagerdis. Kivéve, ha kézi telepítésűre van állítva a kactivitymanagerd, mert akkor nem fog törlődni.apt-mark showmanualparancs megmutatja a kézi telepítésűre állított csomagokat,apt-mark manualbeállít egy adott csomagot kézi telepítésűre,apt-mark autopedig auto telepítésűre állítja. -
válasz
ubyegon2
#96200
üzenetére
Te használsz Windowst azon a gépen?
Az óraidő gond akkor van, amikor dualboot felállás van. A Windows feltételezi, hogy az idő, amit az RTC mutat, helyi idő, a Linux viszont feltételezi, hogy az UTC idő, ezért hozzáad +2 órát (ugye mivel Europe/Budapest időzóna az GMT+2), ezért van az eltolódás. A legegyszerűbb megoldás, amit írtam, meg kell mondani a Linuxnak, hogy az RTC bizony a helyi időt mutatja, és akkor nem fogja korrigálni azt az időzona eltolással.
Egyébként ha NTP-ről kapja az időt a Windows és a Linux is, akkor elméletileg nem lehetne probléma.Ezt a Linux Mintes könyvet ki kéne tűzni az összefoglalóba.
-
-
válasz
CirrMee
#96193
üzenetére
1.
timedatectlparancs mit ad vissza?
A local time-nak kell mutatnia a jelenlegi valós időt, a universal time és az RTC time-nak két órával kevesebbet, a timezone pedig "Europe/Budapest" kell, hogy legyen.
Egyébként a különbség abból adódik, hogy a Windows a lokális időhöz állítja be a gép óráját, a Linux viszont nem állítgatja, hanem hozzáadja az időeltolódást. Vagy a Windows-nál állítod be, hogy ő is így viselkedjen, vagy a Linuxnál állítod át, hogy is úgy viselkedjen, mint a Windows.
Windowsnál csak registryből lehet állítani, Linux esetén parancssorból:timedatectl set-local-rtc 1 --adjust-system-clockHa ezután megint kiadod a
timedatectlparancsot, és aRTC in local TZsorban yes van, akkor jól állítottad át.2. Az adott meghajtókat fel kell csatolni. Erre a legegyszerűbb a Gnome "Lemezek" nevű programja, a csomag neve gnome-disks, gnome-disk-tool vagy gnome-disk-utility, attól függ, milyen rendszert és abból milyen kiadást használsz. A programban a két fogaskereket megkeresed, az alatt a "csatolási beállítások szerkesztését", és ott be tudod állítani, hogy induláskor automatikusan csatolja a rendszer (lsd. a képet).
3. Ez nem hiba, csak annyit, hogy a Firefox nem fogja használni a belső frissítő mechanizmusát, hanem a Linux saját csomagkezelője fogja majd frissíteni. Nem minden verziónál jön elő ez az üzenet, illetve nem is minden disztrón, én pl. Suse-n láttam a minap, sehol máshol (bár én Ubuntu alapú disztrókat nem használok, csak teszt célra).
-
Én az elmúlt pár évben Firefoxot használtam mindenhol, mobilon, Windows-on, Linuxon. Mostanában tértem át mobilon Vivaldi-ra, mert a Firefox elkezdte azt, hogy nagyon sokáig várakozik az oldalak betöltésénél. Nem tudom, miért van ez, lehet hogy csak törölni kéne a helyben tárolt adatait, vagy újratelepíteni az appot.
Egyébként tökéletesen szinkronizál ide-oda mindent. -
válasz
CPT.Pirk
#96121
üzenetére
Amúgy miért tesznek be olyan csomagot egy Debian jellegű disztróba, ami röviddel később használhatatlanná válik?
Én pl. githubról forrásból fordítom az OneDrive csomagot Lubuntun, pont ebből az okból.
A yt-dlp csomagja is így készül, sőt manapság a csomagok többsége így készül (Debiannal külön program van arra, hogy ha közvetlenül gitről, SVN-ről vagy ha Mercuryról szeretnél csomagot készíteni).
Csak hát te rendszeresen megcsinálod magadnak, a csomagfejlesztő pedig nem. Pedig szerintem annak sem lenne elméleti akadálya, hogy folyamatosan a friss csomag legyen a repóban. -
#96114
urandom0
őstag
tordaitibi
#96111
válasz
tordaitibi
#96111
üzenetére
Komolyan, hihetetlen, mit össze szenvedsz a programjaiddal.
Legfrisebb verzió, van deb csomag, 4 Ubuntu és 2 Debian verzióig visszamenőleg, van rpm csomag Fedorához és Suse-hoz, van snap, van flatpak, van appimage...
Van Ubuntura, van Fedorára, van appimage.
Van deb csomag.
Arch, Debian, Elementary, Fedora, Mint, OpenSuse, Ubuntu, és ha rákattintasz az "All downloads" linkre, ott még CentOS, RHEL, és Raspbian verzió is van.
Megbeszéltük már, ott a natív bináris (yt-dlp_linux), le lehet tölteni curllel, wgettel, pippel, van PPA. Flatpak csak azért nincs belőle, mert flatpakbe nem tudsz parancssoros alkalmazást csomagolni.
-
válasz
Warton
#96083
üzenetére
A Debian backports egy olyan Debian tároló, amiben vannak frissebb csomagok, mint a Debian stabil kiadásában. Azért hívják backportsnak, mert a Debian tesztelés alatt lévő verziójából (testing) portolnak vissza szoftvereket, hogy használhatók legyenek a stabil kiadásban.
A használata nagyon egyszerű, az /etc/apt/sources.list fájlba kell felvenni a tárolót:
deb http://deb.debian.org/debian bookworm-backports main contrib non-freeMajd ezután kiadod az
apt updateparancsot, és ha a backportsból szeretnél telepíteni valamit parancssoron keresztül, akkor odaírod a parancs mögé, hogy/bookworm-backports.
Pl. a yt-dlp-t nem úgy telepíted, hogyapt install yt-dlp, hanem úgy, hogyapt install yt-dlp/bookworm-backports.Ha mondjuk Synapticból telepítesz, akkor pedig kiválasztod a csomagot, és a csomag menü -> verzió kényszerítése... pontban tudod kiválasztani, hogy melyik verziót telepítse fel.
Hogy ha régebbi Debiant használsz, akkor a bookworm helyett az általad használt kiadás kódnevét (buster, bullseye, stb.) írod.
-
#96081
urandom0
őstag
tordaitibi
#96078
válasz
tordaitibi
#96078
üzenetére
Valamint lehet meg is próbálom. Ez a Mint megy a levesbe, egy szűzet felpakolok a helyére és megnézem mi a helyzet Flatpak vonalon.
Ha rám hallgatsz, akkor ne hallgass senkire, tedd azt, amit jónak látsz
Egyébként más is írta már neked ezt a megközelítést.Snap és Flatpak.
Azokkal lehet ötvözni az öreguras stabilitást és a friss támogatott naprakész szoftverparkot.Igen. Akármennyire nem szeretjük ezeket a konténerformátumokat...
-
válasz
ubyegon2
#96049
üzenetére
Én az Ubuntus bpo verziót próbáltam, az is felmegy, majdnem ugyanaz a verzió, mint a PPA-s.
Öööö, vagy én néztem el valamit, vagy te, de a gyári Mint-es verzió 2022.04.08-1, a bpo-s pedig 2024.04.09-1~bpo22.04.1. A gyári 2022-es kiadás, a bpo-s idén áprilisi
De lényegtelen... -
válasz
ubyegon2
#96044
üzenetére
Az ilyen kötőszavakat, mint az "amúgy" és az "egyébként" csak azért használom, hogy írásban elválasszam egymástól a gondolataimat
Abban teljesen igaza van Tibinek, hogy ez a csomagkezeléses dolog problémás, és nem csak az elavult csomagok miatt. Most tényleg, jön a kezdő, feltelepíti a Mintet, és azt látja, hogy több éves szoftverek vannak benne... azért na.
Már eleve az is problémás, hogy nincsenek elkülönítve a rendszercsomagok a felhasználói alkalmazásoktól, így ha az egyiket frissíteni akarod, akkor kénytelen vagy a másikat is frissíteni.
És pont erre jöttek rá a nagy Linuxos cégek is az elmúlt években, és ezért kezdtek el gőzerővel ráállni az immutable OS-re, mert akármennyi hátránya is van, jelen pillanatban senki sem tud jobb megoldást. -
Hát, én nem gondolnám, hogy ettől lenne Linux a Linux. Vállalati szinten az elmúlt években kezdett el terjedni az immutable OS + konténerizált appok. Ha ez a felállás átcsorog egyszer otthoni felhasználói szintre és az átlagoszerverekre, akkor is Linux marad a Linux.
Szemét gyűlik a Linux fájlrendszerében is. A saját config fájlaid, a log fájlok, stb.
Az egyediség meg tök jó dolog, én is szeretem, de azt be kell látni, hogy műszaki szempontból az egységesség sok szempontból előnyösebb.
-
#96031
urandom0
őstag
tordaitibi
#96028
válasz
tordaitibi
#96028
üzenetére
nem,. nem az Ubuntu vonal csomagkezelésével van a baj,az tökéletes hanem magukkal az elhanyagolt, elárvult magára hagyott programokkal. Semmi nem változott.
De, azzal is elég nagy baj van, mert sokszor pont azért nem lehet frissíteni egy csomagot, mert a függőségei elavultak. Az összes ilyen függőségkezelésre építő szoftverterjesztés rossz. Windows-on nincs ilyen, MacOS-en nincs ilyen, Androidon nincs ilyen, csak Linuxon van ilyen, és elég nagy szívás.
Amúgy teljesen igazad van szerintem mindenben.Ez egy KEZDŐ Linux topik!!!!! Nem a forráskódforgatásról és a menet közbeni kernelcseréről stb. kéne itt hoszas eszmecseréket meg példákat leírogatni az esetleg idetévedő színhülyéknek.
-
válasz
ubyegon2
#96019
üzenetére
Ez úgy működik, legalábbis Debiannál, hogy ha valaki nem akarja karbantartani tovább a csomagját, akkor ír egy e-mailt a maintainer levlistára, amiben bejelenti, hogy nem kíván tovább foglalkozni a csomaggal. Ezután a csomag felkerül a WNPP (Work-Needing and Prospective Packages) listára, (itt vannak egyébként összegyűjtve az árva csomagok, az unmaintained csomagok, a segítséget igénylő csomagok, a jövőbeni csomagok), és onnan valaki más „adoptálhatja”, ha úgy gondolja, hogy tud vele foglalkozni.
De egyébként feleslegesen okoskodok itt, nem ez lesz a gond, mert ahogy nézem, Ubuntu 22.04.04-ben (ugye ez a legfrisebb Mint alapja) valóban csak a 2022.08.04-én kiadott yt-dlg van (lásd changelog), DE jammy-backportsban már a 2024.04.09-én kiadott yt-dlg van (lásd changelog), és ugyanúgy Unit 193 a karbantartója. Tehát a karbantartó itt szépen végzi a dolgát, a probléma annyi, hogy Mint-nél ugye nincs backports repó, ahonnan az új csomag bekerülhetne.
Amúgy nem próbálta valaki lehúzni Debian backportsból a yt-dlp-t, és azt feldobni Mintre?
wget http://de.archive.ubuntu.com/ubuntu/pool/universe/y/yt-dlp/yt-dlp_2024.04.09-1~bpo22.04.1_all.deb
sudo apt install ./yt-dlp_2024.04.09-1~bpo22.04.1_all.debÉn kipróbáltam, feltelepül.
-
válasz
ubyegon2
#96016
üzenetére
a Mint-nek semmi köze ahhoz a csomaghoz
Hát, szerintem meg van. A maintainer felelőssége lenne az, hogy frissen tartsa a csomagját.
Az megint más kérdés, hogy elképzelhető olyan eset, hogy a maintainer nem tudja frissen tartani a csomagot. Miért? Mert pl. az frisebb verziójú yt-dlg olyan Python igényel, ami nincs a Mint repóiban.
-
válasz
CPT.Pirk
#96015
üzenetére
Itt a többség nem olvas. Vagy nem tud, vagy nem is akar, nem tudom, de hogy nem olvassák el azt, amit írunk, az biztos.
Én is írtam már, és mások írták, hogy van PPA a yt-dl-hez. Azt is írtam, hogy van letölthető bináris, aminek csak x jogot kell adni, és fut. Illetve én is ajánlottam két alternatívát (és írtam a Pythonos pip3-as verziót, ami viszont többeknek nem működött).
Egyébként szerintem is abszolút jogos Tibi felvetése, a világon semmi értelme annak, hogy egy 2022-as verzió van a repóban.
-
válasz
I02S3F
#95981
üzenetére
Persze, hogy az, mert te értesz hozzá. Hirtelen minden nagyon egyszerűvé válik, ha az embert ért hozzá.
Én pl. Slackware alatt simán megcsinálom, hogy törlöm a futó kernel csomagját, letöltök egy másik verziót, legenerálom hozzá az initrd-t, bemásolom a helyére, átírom az elilo.conf-ot ha kell, és kész a kernelfrissítés.
A minap pedig úgy jártam, hogy elkezdtem törölgetni a KDE csomagjait. kaddressbook, kio, kmod, kizé... következő bootnál volt meglepetés, szinte semmi nem indult el, csak egy alap prompt-om volt, meg egy csomó modulhibám. Próbálgattam kézzel betöltögetni a modulokat, de a modprobe-ra, az insmod-ra és az összes többire azt mondta, hogy "not found". Kiderült, hogy a kmod csomag nem a KDE-hez tartozik, hanem a kernel modulok kezeléséhez szükséges parancsok vannak benne, enélkül még egy pendrive-ot sem tudsz beolvasni. Én meg simán letöröltem
Bebootoltam a telepítő pendrive-ról, shellből visszamásoltam ezeket a programokat, utána már be tudtam bootolni normálisan. Utána töröltem, amiket kézzel másoltam be, és visszatelepítettem a kmod csomagot, azóta is működik.
Úgy könnyű, ha az ember ért hozzá, de aki nem, az nem fog ilyen problémákkal küzdeni, letörli és újratelepíti az egész rendszert, vagy visszamegy Windowsra. -
válasz
sh4d0w
#95951
üzenetére
Szerintem osszuk kategóriákra, kicsit stabil, közepesen stabil, nagyon stabil...
A Slackware, Debian, RHEL, Alma, Rocky, Suse Leap, MX, Antix a nagyon stabil kategória.
A *ubuntu, a Mint, az Elementary, a Fedora, a Zorin, Nobara, a Slowroll a közepesen stabil kategória.
Az Arch, Manjaro, Garuda, Endeavour, Garuda a kicsit stabil kategória.Már ha azt vesszük alapul, hogy melyik mennyire régi (=tesztelt). Ha más alapján kategórizáljuk, akkor más eredmény is jöhet ki.
-
válasz
sh4d0w
#95970
üzenetére
Aki még sosem csinált ilyet, annak persze, hogy bonyolult. Aki Windowsról jön, az nem ahhoz van szokva, hogy parancssorozni kell. A Windows-os megközelítéshez az áll a legközelebb, hogy böngészővel letöltöd a yt-dl_linux-ot, és futtatod (miután adtál neki x jogot). Mondjuk aki Windowsról jön, én annak nem a parancssoros változatát ajánlanám, hanem ezt vagy ezt a GUI-t.
-
válasz
urandom0
#95960
üzenetére
Bocsi, most látom, hogy Debiant használsz.
Most kipróbáltam én is, és Debian alatt ugyanezt írja ki, mint nálad. Slackware, Fedora és Rocky Linux alatt megy, Debian alatt problémázik.Utánanéztem, azt találtam, hogy van ez a PEP 668, ami kb. arról szól, hogy azért, hogy a Pythonos csomagok és a disztró saját csomagjai ne keveredjenek, a Python nem hajlandó a globális környezetbe csomagot telepíteni, hanem egy virtuális környezetet kell neki csinálni, és oda telepíteni... szerintem ez felejtős így.
Itt írtam, hogy ha leszeded a yt-dlp_linux fájlt, és adsz neki futtatási jogot, azt rögtön futtathatod is. Az is jó megoldás, amit BoB írt:
curl -L https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp -o /ahova_akarodCsak itt ugye a végén fájlnevet kell megadni, nem mappát:
curl -L https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp -o yt-dlpAdsz neki x jogot:
chmod +x yt-dlpÉs futtahatod.
-
válasz
Warton
#95955
üzenetére
Na jó, igazad van, előtte telepíteni kell a python3-pip csomagot.
-
-
válasz
Warton
#95941
üzenetére
Nagyon unatkozol?
yt-dlp telepítése Linuxon:
pip3 install yt-dlpAz apt-add-repository egyébként tényleg egy Ubuntus szokás, Debian alatt nem szokás használni.
szerk: egyébként a yt-dlp github oldalán, a Releases a
yt-dlp_linuxnevű fájlt. Ezt letöltöd, adsz neki +x jogot, és már futtathatod is. -
a yt-dlp -U nem pont ezt a frissítést végzi el?
És működik? Én tegnap kipróbáltam két különböző disztrón, nekem szépen visszaírta mindkettő, hogy mivel csomagkezelőből telepítettem a yt-dlp-t, ezért legyek szíves a csomagkezelőből frissíteni. Emiatt szerkesztettem én is a hozzászólásom tegnap, miután kipróbáltam, áthúztam azt a mondatot.
-
válasz
Warton
#95918
üzenetére
Akkor mi a francért nem lehet 2 év után befrissíteni a yt-dlp-t.
Mert bután van megcsinálva. Nem az egész yt-dlp-t kellene becsomagolni, hanem kellene egy script a csomagba, ami telepítésnél és frissítésnél lehúzza a legfrissebb yt-dlp-t.
Hasonlóan, mint a torbrowser-launcher csomag, abba sincs becsomagolva a Tor böngésző, ami telepíti (és utána frissül magától). -
#95913
urandom0
őstag
tordaitibi
#95908
válasz
tordaitibi
#95908
üzenetére
Ez az egész usrmerge történet arról szól, hogy okos emberek rájöttek, hogy a hagyományos Linuxos könyvtárszerkezet, ahol van /bin és /usr/bin, /sbin és /usr/sbin, /lib és /usr/lib, /lib64 és /usr/lib64, nem túl jó megoldás. Egyrészt nincs túl sok értelme különválogatni a /bin-t és az /usr/bin-t meg a többi, hasonló könyvtárat, mert minek (ez egy régi maradvány, manapság hasztalan). Másrészt kevésbé kompatibilis a UNIXOS könyvtárhierarchiával.
Úgyhogy elkészítették az usrmerge csomagot, ami annyit csinál, hogy a /bin, /sbin, /lib és /lib64 mappákból átmozgatja a fájlokat a /usr-beli megfelelőjükbe, és ezekre egy symlinket csinál. Tehát a /bin innentől egy symlink lesz az /usr/bin-re, az /sbin az /usr/sbin-re, és így tovább.
Elméletileg újonnan telepített disztrókon ez a váltás már tényleg megtörtént, úgyhogy igazából nem értem, mit akar tőled ez a hibajelentő. De nézd meg magad, ha nálad is ilyen -> nyilacskákkal jelöli a symlinkelést a mappáknál, akkor nálad is lefutott már az usrmerge:
Elméletileg el is távolíthatod, te a váltásból így sem - úgy sem veszel észre semmit. De ha már megtörtént a váltás, és eltávolítod a csomagot, a mappaszerkezet természetesen nem fog visszaállni a régi formára, marad ez a symlinkes megoldás.
-
#95895
urandom0
őstag
tordaitibi
#95888
válasz
tordaitibi
#95888
üzenetére
Ayt-dlp -Unem próbáltad kiadni? Elméletileg ez lefrissíti a programot.Egyébként itt egy saját ppa-t ír, te abból telepítetted, vagy a Mint gyári repójából?
szerk: én most Slackware alatt így telepítettem fel:
pip3 install yt-dlp
És a legújabb verzió van fent:$ yt-dlp --version
2024.04.09 -
#95880
urandom0
őstag
tordaitibi
#95877
válasz
tordaitibi
#95877
üzenetére
Szerintem nálad az lesz a probléma, hogy nincs felkészítve a guefi arra, hogy egy gépen több EFI partíció lehet. Nálad megtalálja a második EFI partíciót, megkeresi a csatolási pontját, de mivel nem az van felcsatolva, hanem a másik, ezért problémázik. Explicit módon nem lehet megadni neki az EFI partíciót, úgyhogy igazából az lenne a megoldás, hogy azt a lemezt, amin a nem szükséges EFI partíció van, ideiglenesen le kellene húzni.
-
#95875
urandom0
őstag
tordaitibi
#95872
válasz
tordaitibi
#95872
üzenetére
Megnéztem a guefi forráskódját, hogy honnan ismeri fel az EFI partíciót.
Azt csinálja, hogy kiadja az
lsblk -p -l -t -o name,parttype,maj:min,uuid,pkname,pttype,typeparancsot, és a visszadott táblázatban megkeresi azt a sort, amelyikben szerepel a '0xef' VAGY a 'c12a7328-f81f-11d2-ba4b-00a0c93ec93b' string.
Ha én adom ki ezt a parancsot, akkor szépen látszik is, melyik az EFI partícióm:# lsblk -p -l -t -o name,parttype,maj:min,uuid,pkname,pttype,type
NAME PARTTYPE MAJ:MIN UUID PKNAME PTTYPE TYPE
/dev/sda 8:0 gpt disk
/dev/sda1 c12a7328-f81f-11d2-ba4b-00a0c93ec93b 8:1 BF6A-7861 /dev/sda gpt part
/dev/sda2 0fc63daf-8483-4772-8e79-3d69d8477de4 8:2 db76fb61-88dd-44c8-8150-1db5090cd9c7 /dev/sda gpt part
/dev/sda3 0fc63daf-8483-4772-8e79-3d69d8477de4 8:3 04575784-05e9-4530-b313-e18704accbe5 /dev/sda gpt part
/dev/sdb 8:16 dos disk
/dev/sdb1 0x83 8:17 58e52e0e-013d-4190-830f-a91a8fbeb02b /dev/sdb dos part
/dev/sr0 11:0 rom
/dev/zram0 252:0 diskHa a másik gépemen adom ki, ott is látszik:
# lsblk -p -l -t -o name,parttype,maj:min,uuid,pkname,pttype,type
NAME PARTTYPE MAJ:MIN UUID PKNAME PTTYPE TYPE
/dev/sda 8:0 gpt disk
/dev/sda1 c12a7328-f81f-11d2-ba4b-00a0c93ec93b 8:1 7388-EE19 /dev/sda gpt part
/dev/sda2 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f 8:2 b98d5ee4-d376-4603-8fb6-7210c2b27fb7 /dev/sda gpt part
/dev/sda3 0fc63daf-8483-4772-8e79-3d69d8477de4 8:3 66260278-35c3-4c1e-80a0-6e66f566f7f7 /dev/sda gpt partEzután a guefi kiadja a
findmntparancsot, és megkeresi a már megtalált EFI partíció csatolási pontját.Tibi, ha te rooként kiadod ezt a parancsot, akkor mi a válasz?
lsblk -p -l -t -o name,parttype,maj:min,uuid,pkname,pttype,type,mountpoint -
#95874
urandom0
őstag
tordaitibi
#95872
válasz
tordaitibi
#95872
üzenetére
sudo guefi? -
válasz
ubyegon2
#95868
üzenetére
Csakhogy ezzel nem tudja átnevezni az EFI bejegyzéseket. Írtam én is, hogy van ez a program, de aztán meglestem alaposabban, és én nem találtam átnevezés opciót.
Maga a paranccsoros efibootmgr sem tud átnevezést, ami mindkettőnek az alapja. Ott is csak olyan lehetőség van, hogy új bejegyzést hozol létre, annak adsz egy címkét, és átmásolod egy már létező bejegyzés adatait. -
#95866
urandom0
őstag
tordaitibi
#95865
válasz
tordaitibi
#95865
üzenetére
De ezzek sikerült feltelepíteni, nem? Ahogy látom, az /usr/sbin/guefi ott van a helyén, csak a .desktop fájl miatt panaszkodik (talán hiányzik az intltool csomag?). Tehát paranccsorból el kell tudnod indítani.
Egyébként nálam így néz ki a folyamat:
$ make
for i in `ls po/*.po`; do \
msgfmt $i -o `echo $i | sed "s/\.po//"`.mo; \
done
intltool-merge po/ -d -u \
guefi.desktop.in guefi.desktop
Merging translations into guefi.desktop.
intltool-merge po/ -d -u \
guefi-kde.desktop.in guefi-kde.desktop
Merging translations into guefi-kde.desktop.$ sudo make install
Jelszó:
install -d -m 755 //usr/share/icons/hicolor/scalable/apps/
install -m 644 icons/guefi.svg \
//usr/share/icons/hicolor/scalable/apps/
for i in 48 32 24 22 16; do \
install -d -m 755 \
//usr/share/icons/hicolor/${i}x${i}/apps/ \
2> /dev/null; \
install -m 644 icons/guefi-$i.png \
//usr/share/icons/hicolor/${i}x${i}/apps/guefi.png; \
done
for i in `ls po/*.po|sed "s/po\/\(.*\)\.po/\1/"`; do \
install -d -m 755 //usr/share/locale/$i/LC_MESSAGES; \
install -m 644 po/$i.mo //usr/share/locale/$i/LC_MESSAGES/guefi.mo; \
done
install -d -m 755 //usr/sbin
install -d -m 755 //usr/share/applications
install -d -m 755 //usr/share/guefi
install -d -m 755 //etc
install -m 755 src/guefi //usr/sbin/
install -m 644 src/guefi.ui //usr/share/guefi/
install -m 644 guefi.desktop //usr/share/applications/
install -m 644 guefi-kde.desktop //usr/share/applications/ -
#95864
urandom0
őstag
tordaitibi
#95863
válasz
tordaitibi
#95863
üzenetére
Mint alatt nincs guefi?
Ez most meglepett...Innen letöltöd: https://github.com/gapan/guefi
Nem kell a release alatt keresni, rányomsz a Code-ra és ott a Download zip.
Kicsomagolod, belépsz a mappájába, majdmake, éssudo make install. Kipróbáltam, nálam működik.Nálad nincs telepítve a
git?
Ha telepíted, akkor ez az egy sor letölti, kibontja és fel is telepíti neked (csak ugye a sudo-nál kérni fogja a jelszót):git clone https://github.com/gapan/guefi.git && cd guefi-master && make && sudo make install -
#95861
urandom0
őstag
tordaitibi
#95860
válasz
tordaitibi
#95860
üzenetére
-
#95857
urandom0
őstag
tordaitibi
#95854
válasz
tordaitibi
#95854
üzenetére
Én abszolút hiszek neked, és nem is engem kell meggyőznöd, hanem a Mint telepítőjét
Te tudod, hogy hogyan szervezed a partícióidat. Mondjuk nem csodálom, hogy a Mint képességeit meghaladta, azért nem hétköznapi dolog az, hogy valakinek 3 lemeze és 4 EFI partíciója legyen. -
-
#95837
urandom0
őstag
tordaitibi
#95835
válasz
tordaitibi
#95835
üzenetére
Van egy efibootmgr nevű program, ezzel tudod az EFI bejegyzéseket szerkeszteni. Van hozzá GUI is, guefi néven és efiboots néven, kb. mindkettő ugyanazt tudja.
szerk: a guefi jobb, azt telepítsd fel.
-
#95836
urandom0
őstag
tordaitibi
#95824
válasz
tordaitibi
#95824
üzenetére
Na, ezért használnak part UUID-t manapság a busz-alapú megnevezések helyett, mert az állandó és örök, mint a nyomorúság. A busz-alapú megnevezéseknek van egy olyan jó tulajdonságuk, hogy adott esetben elcsúszkálhatnak, szóval hiába tudod te azt, hogy a /dev/sdc7 az EFI partíció, a telepítő lehet, hogy másként látja.
Illetve az sem kizárt, hogy BIOS/CSM módban bootoltál be, és ilyenkor a telepítő azt hiheti, hogy nem UEFI-s a géped. Ilyenkor hozzá sem nyúl az EFI partícióhoz, hanem simán /-ra rátolja a Grubot, feltételezvén, hogy te majd onnan fogsz bootolni.
-
#95775
urandom0
őstag
tordaitibi
#95773
válasz
tordaitibi
#95773
üzenetére
iwlwifi-t próbáltad? -
#95743
urandom0
őstag
tordaitibi
#95742
válasz
tordaitibi
#95742
üzenetére
Van egypár fájl a /boot/efi alatt, ami adott esetben frissülhet. Pl. a grub.cfg, grubx64.efi, grubia32.efi, ezek a Grub fájlai. Lehetnek ott firmware fájlok is (fwupdate vagy fwupx64.efi), amik szintén frissülhetnek, vagy létrejöhetnek, ha olyan új eszközt raksz a gépbe, aminek kell a firmware a boot alatt. Meg ott vannak a Shim fájlai is, a secure boothoz, ez is frissülhet időnként.
-
válasz
daninet
#95708
üzenetére
A Java egy tök nyelv, az egyik kedvencem, és a JDK is nagyon jó, csak szegény Java kb. 15 évvel van lemaradva bármelyik ma divatos nyelvtől, másrészt '95 óta nem sikerült elérni, hogy egy Java-s Hello World ne akkora legyen a startup time-ja, mint egy C++-os ERP-nek
A GraalVM is kb. 10 évet késett. -
válasz
sh4d0w
#95691
üzenetére
De használják, nem? Hát akkor meg? Kit érdekel, hogy lassú, szar, bugos, ha egyszer használják?
A trend most meg az, hogy Teams appokat írnak, mert a cégnek kell, és olyanokat írnak meg, amiket az ERP-t 25 évvel ezelőtt is tudnak. ERP-t csinálnak a Teamsből, olyan funkciókkal rakják tele, amiket egy Lotus Notes a 90 években már simán hozott. Csak ugye egy ilyen webes szar, mint a Teams, ezt 20x akkora erőforrásokkal csinálja meg, 30x lassabban...
-
válasz
CPT.Pirk
#95689
üzenetére
Az eredeti írást olvastam el. Sajnos abszolút meg is értem a fejlesztőt, ezek tényleg olyan problémák, amikkel szinte mindenki szembesül, ha Linuxra akar portolni valamit. Az külön gáz, hogy 2024-ben ott tartunk, hogy plusz libet kell használni, ha dekorációkat is szeretnél az ablakodra.
Én csak egy tized ekkora kis grafikus jelszókezelőt írtam Linuxra, Vala nyelven, GTK-val. Már az elején gondoltam, hogy ha Windowsra akarom portolni, akkor meggyűlik a bajom azzal, hogy valószínűleg Windows-on nincs libsecret, márpedig erre építettem az egészet. Igazam is lett, valóban nincs, úgyhogy áttértem a fájlban történő tárolásra (AES256-tal titkosítva, base64-gyel kódolva).
Ha valaki cross platform alkalmazást fejleszt, jó előre utána kell járni, hogy melyik platformon milyen lehetőségek vannak, mert utólag ezzel rengeteg plusz munkát spórolhat meg az ember.Amúgy én utálok mindent, ami Javascript, meg az összes Electronos cuccot, de azt el kell ismerni, hogy ilyen technológiákra építve nagyon könnyen lehet cross platform alkalmazást fejleszteni, és ezzel sok-sok munkaórát, és az ezzel együtt járó szívást lehet megspórolni.
-
válasz
I02S3F
#95609
üzenetére
Én azután kezdtem el használni a Rustdesket, hogy a Teamviewer 5 percenként eldobta a sessiont. Amúgy tényleg jó, nyílt forráskódú, nagyrészt Rustban és Dartban írták, és alapvető felhasználásra ingyenes.
Ha van közvetlen IP kapcsolat a gépek között, akkor az NX NoMachine is nagyon jó. Én a cégen belül ezt használom, Windowstól kezdve a Fedorán át, még az oldschool Slackware-en is fut, képes zárolni a gépet, ha valaki csatlakozik rá, és dinamikus állítja a képminőséget a hálózat sebességéhez képest, így nagyon gyors tud lenni a képátvitel.
-
#95554
urandom0
őstag
PCProfessor
#95552
válasz
PCProfessor
#95552
üzenetére
Linux to the rescue.
-
válasz
RaZroX
#95540
üzenetére
Egy hónapja ott tartottak, hogy éppen tesztelték a Qt 6-os portot, szóval ebből mostanában még nem nagyon lesz semmi sem.
Mondjuk nem is kapkodták el a fejlesztést, március 5-én jutottak el odáig, hogy na akkor át kéne portolni Qt 6-ra... -
Biztos nem sok embert érdekel, de összeszámoltam, Slackware alatt 1500-1600 csomag van (nem számolva a Slackbuild-et), Devuan alatt pedig olyan 45000 körül. Viszont Slackware-ben nincsenek elkülönítve a -dev és hasonló csomagok, ezért az 1500-1600 valójában több ennél.
De még így is elég dicséretes munkát végez a Salix kicsiny csapata, hiszen nálunk 9270 csomag érhető el (32 és 62 bites formában egyaránt) gyárilag, és ezenfelül lehet telepíteni a rendszerre a Slackware csomagjait és a Slackbuilds-es csomagokat is. -
Ha bent van a disztró repójában az adott kiegészítő, akkor onnan kell telepíteni. Fedorában pl. bent a Dash to dock, ha kijön a Fedora 40 a Gnome 46-tal, a Dash to dock is kompatibilis lesz már vele. Gondolom, a Solus is.
Amúgy a Gnome-nak pont az a titka, hogy nem szabad telerakni mindennel
Vagy ha az ember telepakolja, akkor olyasmikkel pakolja csak tele, amik a használatot nem változtatják meg jelentősen, hanem tényleg csak kiegészítik azt. Én pl. csak a GSConnectet, az Appindicatort, a Steal my focust és egy clipboard managert használok, de mindegyik nélkül el tudok lenni.Én kb. 10 éve nem használok asztali ikonokat semmilyen rendszerem sem, szerintem nagyon meg tudja törni a workflowt az, hogy ha el akarsz érni valamit az asztalon, akkor minimalizálnod kell az ablakokat, utána meg visszanyitogatni. Ráadásul az ember (és a programok is) hajlamos teleszemetelni az asztalt mindenfélével.
Szerintem start menü se kell, egy programindító kell csak, az meg van. Nyomsz egy Windows billentyűt, megjelenik a dash, oda kirakod a gyakran használt programjaidat, a többit meg eléred az alkalmazásrácsból.Gnome alatt nincs értelme az asztalra bootolni, mert nincs ott semmi. Az alkalmazásokat a dashról vagy az app rácsról indítod, és mivel a gyakran használt appokat a dashra rakod, ezért olyan nézetbe érdemes bebootolni, ahol rögtön a dasht látod.
-
Ismerem a Budgie-t, és őszintén szólva nem vagyok oda érte. Az ilyen felturbózott Gnome-ok, mint a Budgie, meg a POP Shell, gyakorlatilag 98%-ban Gnome-ok, csak beleheggesztenek egy-két kiegészítőt vagy segédprogramot, meg ráhúznak valami ronda témát, és elnevezik máshogy. Én ebben nem látom a hozzáadott értéket.
Azért is használok Fedorát, mert ebben szinte teljesen gyári Gnome-van. Nem alakítgatják át, nem patchelgetik agyon... fel tudom én is telepíteni azt a 2-3 kiegészítőt, amit használok, de ha akarom, ki is kapcsolgathatom őket, és akkor tényleg vanilla Gnome-ot kapok. -
Köszi a választ!
Eddig nem ismertem a Solust, de ezután majd ajánlani fogom, ha valaki rolling disztrót keres.
Kipróbáltam közben, futottam a Gnome verzióval egy kört live-ban. Gyorsnak tűnik, alaphangon 800-900MB RAM-ot használ a live, és ez az eopkg is jónak tűnik. Sebességre kb. a zypper és az apt szintjén van. Lehet, hogy feldobom valamelyik gépemre, és használgatom pár hétig.
Terminálban 11279 elérhető csomagot számoltam össze.
---Mentem egy kört Salix live-val is. Ez ugye egy Slackware fixed ágára (tehát nem a -currentre) épülő, nagyon tradícionális filozófiájú disztró. Sysvinit-stílusú init rendszert használ, a hivatalos és ajánlott csomagkezelője a slapt-get, ami a Slackware slackel csomagkezelőjére épül, azt bővíti ki apt-szerű függőségkezeléssel és funkciókkal. A jelenlegi verzió 2022 szeptemberében jelent meg (5.x kernel van benne), az eggyel korábbi 2017-ben.
Terminálban 9270 csomagot számoltam össze, de a Flatpak gyárilag telepítve van (legalább is a live-ban, de gondolom a telepített verzióban is).
Itt van két kép róla: 1 2 -
Milyen ez a Solus egyébként? Azt látom, hogy rolling, de mennyire frissek a csomagjai? Gyári Gnome van benne, vagy valami mókolt? Csomagkezelője milyen?
Nekem a Salix volt sokáig a szívem csücske disztró, nem sokat használtam, de amíg használtam, addig nagyon autentikus Linux élményt nyújtott. Amúgy meggyőződésem, hogy a Slackware-t is sokkan többen használnák, ha gyárilag lenne benne függőségkezelés, és sok-sok csomag hozzá.
-
válasz
urandom0
#95385
üzenetére
Más. Megjelent az LXQt 2.0.0: Release LXQt 2.0.0
Nem tudom, hogy hányan használják, amikor próbálgattam, nem találkoztam benne buggal.
-
válasz
I02S3F
#95377
üzenetére
Szerintem a contributorok számát érdemes inkább nézni a Github oldalukon, ott 315-öt ír.
Ú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
- Teszt Már csak két hónap van hátra a Windows 10 nyugdíjazásáig, ideje előrelépni
- Teszt [Linux] Vanilla OS, egy Debian alapú immutable operációs rendszer
- Teszt [Linux] Aeon Desktop, egy immutable operációs rendszer az OpenSUSE-tól
- Teszt [Linux] A Flatpak
- Bejegyzés MS Office365 Linuxon
- Bejegyzés [Linux] Futtassunk bármely disztrót a terminálunkban
- Bejegyzés Alpine Linux telepítés mindenféle low-end dologra
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- GYÖNYÖRŰ iPhone 12 Mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3852, 100% Akksi
- Lenovo P500 - 1650-2690 v3 akár 12 mag/24 szál, 32GB DDR4 RAM, 490W 80+gold táp, számla, 6 hó gar
- LG 27GR93U-B - 27" IPS - UHD 4K - 144Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDR 400
- HIBÁTLAN iPhone 13 128GB Red -1 ÉV GARANCIA - Kártyafüggetlen, MS3760, 100% Akkumulátor
- Apple iPhone 15 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: ATW Internet Kft.
Város: Budapest