Hirdetés
- Nem kéri tovább a nekik fejlesztett csúcs-GeForce-ot Kína?
- Milyen egeret válasszak?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Fejhallgató erősítő és DAC topik
- HiFi műszaki szemmel - sztereó hangrendszerek
- Kezdő fotósok digitális fényképei
- Nem elégszik meg egy panellel a Philips világelső monitora
- Gaming notebook topik
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- SSD kibeszélő
Új hozzászólás Aktív témák
-
-
Véreshurka
senior tag
Mi volt a driver hiba? Virtuális gépben lehet, hogy az emulált chipset vagy hasonló nem része az alap kernel kofignak (pl. VirtualBoxban még mindig alap a PIIX3, de ICH9-az általában jobb választás).
Wiki szerint: "It is a common misconception that genkernel will "automatically" generate a custom kernel configuration. genkernel automates the kernel build process and assembles the initramfs, but does not generate a custom kernel configuration file. If a kernel configuration is not provided, genkernel will use a generic kernel configuration file which will produce a general purpose kernel suitable for daily usage (at the expense of a large modular kernel)."
A genkernel alapvetően automatizálja a kernel, initramfs fordítását és telepítését, de mindenképpen kell hozzá egy induló kernel konfig. Ezt vagy te magad készíted el vagy használhatod azt amit az adott kernel verzió ad neked mint alap.
Ha már van egy működő konfigod, akkor minden további kernel építésnél (pl. új verzió esetén) ezt már újrahasználhatod, pl. így:
genkernel --kernel-config="/etc/kernels/kernel-config-$(uname -r)"Qemu/KVM alatt próbálkoztam a telepítéssel, így a VIRTIO driverek hiányoztak. A
genkernel --virtio allparanccsal már minden rendben volt. Én voltam a hülye, mert amikor kerestem az okokat nem tettem hozzá a kereséskor, hogy Qemu/KVM, itt sem említettem, hogy mi alá szerettem volna telepíteni.Köszi a konfigra vonatkozó info-kat!
Hasznosak leszenk a későbbiekben. -
shina
tag
Driver hiba volt. Viszont lehet én értem félre, de a genkernelnek nem az lenne az egyik feladata, hogy úgy állítsa be a kernelt, hogy az mindent felismerjen? Azaz ha működik valami a live cd alatt akkor működnie kellene boot után is? Ebből nekem legalábbis ez jött le:
"genkernel works by configuring a kernel nearly identically to the way the installation CD kernel is configured. This means that when genkernel is used to build the kernel, the system will generally detect all hardware at boot-time, just like the installation CD does."
De lényeg, hogy meglett a hiba, és bootol is a rendszer. -
Véreshurka
senior tag
-
F34R
nagyúr
Driver hiba volt. Viszont lehet én értem félre, de a genkernelnek nem az lenne az egyik feladata, hogy úgy állítsa be a kernelt, hogy az mindent felismerjen? Azaz ha működik valami a live cd alatt akkor működnie kellene boot után is? Ebből nekem legalábbis ez jött le:
"genkernel works by configuring a kernel nearly identically to the way the installation CD kernel is configured. This means that when genkernel is used to build the kernel, the system will generally detect all hardware at boot-time, just like the installation CD does."
De lényeg, hogy meglett a hiba, és bootol is a rendszer. -
Véreshurka
senior tag
Distrotube csak a végső megoldás volt, hogy vizuálisan is lássam, hogy jól csináltam-e
. Alapvetően a handbook-ot követtem. GRUB-ot telepítettem, a sys-boot/grub:2-t.A forum-ot olvasgattam, de mindeenhol azt írják, hogy pl. a /boot mappában nézzem a grub.conf-ot. Te is azt írod, hogy az /etc/fstab-ban írjam át a csatolást. De hogyan tudom ezeket elérni? Mert amikor kiírja boot-kor, hogy nem ismeri fel a root fs-t, akkor 3 lehetőségem van:
1. entert nyomok és megpróbálja újra, de ugyanaz lesz az eredmény
2. beírom, hogy shell és átvisz a rescueshell-be,
3. "q"-t nyomok és uyganaz leszu az eredmény, mint ha entert nyomtam volna.Tudom, hogy talán nem nekem való a gentoo, mert nem vagyok még elég járatos a linux világában, de arra gondoltam, hogy talán pont egy gentoo telepítésével és használatának próbálgatásával egy virtuális környezetben ezen tudnék változtatni.
-
Véreshurka
senior tag
blkidparancsal kitudod a meghajtok UUID-jet listazni... majd /etc/fstab-ban megnezed egyezik-e.. ha nem, atirod. Grub-ot hasznalsz? Nem distrotube kell, hanem gentoo wiki, meg gentoo forum. Ott tudnak segiteni egeszen biztosan. a handbookot itt talalod. [link] atneznem meg, nem-e kimaradt valami.Distrotube csak a végső megoldás volt, hogy vizuálisan is lássam, hogy jól csináltam-e
. Alapvetően a handbook-ot követtem. GRUB-ot telepítettem, a sys-boot/grub:2-t.A forum-ot olvasgattam, de mindeenhol azt írják, hogy pl. a /boot mappában nézzem a grub.conf-ot. Te is azt írod, hogy az /etc/fstab-ban írjam át a csatolást. De hogyan tudom ezeket elérni? Mert amikor kiírja boot-kor, hogy nem ismeri fel a root fs-t, akkor 3 lehetőségem van:
1. entert nyomok és megpróbálja újra, de ugyanaz lesz az eredmény
2. beírom, hogy shell és átvisz a rescueshell-be,
3. "q"-t nyomok és uyganaz leszu az eredmény, mint ha entert nyomtam volna.Tudom, hogy talán nem nekem való a gentoo, mert nem vagyok még elég járatos a linux világában, de arra gondoltam, hogy talán pont egy gentoo telepítésével és használatának próbálgatásával egy virtuális környezetben ezen tudnék változtatni.
-
F34R
nagyúr
Sziasztok!
Próbálkoznék Viirtuális gépként telepíteni egy gentoo-t csak, hogy ismerrkedjek vele. Már másodszorra futottam neki, de újraindításnál eddig mindkétszer ez fogadott:
"!! Block Device UUID=xxx is not a valid root device...
!! Could not find the root block device in UUID=xxx.
Please specify another value or:..."Első nekifutásra magam konfiguráltam a kernelt, utána találtam egy fórumot ahol hasonló problémánál egy kimaradt driver okozta a hibát. Így másodszorra nekifutva már inkább a genkernel-t választottam, hogy az telepítse a kernelt, ne nekem kelljen. Viszont ezután is ugyanez a hiba fogadott.
MBR-es partíciós táblát használok, 2 db partícióval, a telepítési segédlettől annyiban térek még el, hogy a /boot partíciónak nem ext2-t, hanem ext4-et használok:
/dev/sda1 /boot
/dev/sda2 /Amikor a genkernel lefutott láttam egy olyan részt a végén, hogy a ROOT-ot nekem kell kézzel megadnom, bár nem volt világos a mikéntje, és a wiki sem írt erről, hogy bármi dolgom lenne kernel telepítés után, így a
genkernel allparancs után rátértem az fstab szerkesztésére. Illetve találtam egy fórumot ahol pont azt javasolták, hogy nem kell megadnom, hogy mi a root.Ezzel kapcsolatban lenne kérdésem:
1. Hogy tudom indulásra bírni a rendszert? Mit kellene még beállítanom telepítéskor, hogy ne ütközzek ebbe a hibába?
2. Ha nem szeretném újra telepíteni az egész rendszerrt, akkor hogyan tudoma már meglévő, de nem boot-oló rendszerben megváltoztatni a root partíciót? Chroot az egyetlen lehetőség ilyenkor, vagy a rescueshell-t is lehetne használni?
Ezután végignéztem a youtube-on Distro Tube jóvoltából egy telepítést ahol szintén genkernel-el lett telepítve a kernel, és kb. én is ugyanazokat a lépéseket követtem mint ő, ott sem lett megadvagenkernel allparancs után kézzel a root partíció, és míg nála elindult a rendszer, nálam megakadt.Ebben esetleg tudna segíteni valaki?
Előre is köszönöm! -
Véreshurka
senior tag
-
Sikerült Windows alól is elérni ssh-val (régi puttyot használtam, ez volt a gond).
Hangkártyát nem kell váltanom, mert ugyanaz a kártya. A master kézi módosításával lejátszás közben is változik a hangerő, ez a része működik. A rendszer grafikus felületén viszont akármit választok ki (analóg/digitális), az alsamixer alatt az SPDIF kimenet "00" szintű és nem tudom változtatni.
-
Igen arra, ami terminalbol mukodik... ott siman tudnod kellene kartyat valtani, F4 vagy hasonlo. asoundrc-ben kell mokolnod ha nem megfeleloek a beallitasaid.
Sikerült Windows alól is elérni ssh-val (régi puttyot használtam, ez volt a gond).
Hangkártyát nem kell váltanom, mert ugyanaz a kártya. A master kézi módosításával lejátszás közben is változik a hangerő, ez a része működik. A rendszer grafikus felületén viszont akármit választok ki (analóg/digitális), az alsamixer alatt az SPDIF kimenet "00" szintű és nem tudom változtatni. -
Üdv!
Használok egy zenelejátszásra kihegyezett Gentoo alapú disztribúciót, a neve Daphile.
A gondom az, hogy az egyik asztali gépemen nem jól kezeli az SPDIF kimenetet (az analóg kimenet az jó). Nincs hang egyáltalán, a DAC hangerő állításakor ad annyi életjelet, hogy pattog (próbáltam több DAC-ot is).
A hardveres hibát kizárom, mert Windows és Ubuntu alatt is működik az SPDIF. Arra gondoltam, hogy esetleg a drivert kellene importálni hozzá (találtam Linuxhoz, bár azt nem tudom, hogy Gentoo alatt is jó lehet-e).
Ebben tudtok segíteni? Köszönöm. -
Még a USE flagekkel sem lenne bajom, mert hasznosak, ha nem akarsz belefordítani a csomagokba valami bloat feature-t. Hanem ez az emerge nagyon minimalista, nem jelzi ki jól a függőségi fát, hogy egy adott csomagot a USE flag-ek vagy egy másik csomag függősége miatt húz-e be. Valahogy nem nagyon lehet szabályozni, hogy milyen csomagnak milyen USE flag-je legyen.
Azt viszont jó, hogy írod, hogy az Artix-ban libsystemd van, ezt nem tudtam. Elég kár. Mondom, nekem megfelelne a Gentoo, hajlandó vagyok beletenni a munkát, csak legyen átláthatóbb.
-
Persze a Haskell egy felesleges nagy boszme kornyezeti valtozo.. neked a virutal/opengl csomag kellett volna csak. esetleg USE-ba berakod hogy
-haskell
Van meg ilyen forgatos systemd mentes disztro... CRUX. bar nekem az vele a tapasztalatom, hogy nem mindig fordulnak le a csomagok. Rolling az is valamennyire. Es nem kell bajlodnod a USE flaggel."Ilyen Calculate Linuxnak számomra nincs értelme, mert ennyi erővel feltehetnék egy Artix-ot, ami Arch alapú, friss, valódi rolling, nem kell vele szenvedni és systemd sincs benne."
systemd nincs benne csak libsystemd.so
azert kell, hogy ne kelljen minden csomagot atforditani... igy az archos csomagokkal 100%-ban kompatibilis. -
Nem is az a baj, hogy dolgozni kell vele, meg fordítgatni kell forráskódból. Hanem nem látni, hogy milyen csomagnak milyen USE flag-je nem stimmel. Ilyen Calculate Linuxnak számomra nincs értelme, mert ennyi erővel feltehetnék egy Artix-ot, ami Arch alapú, friss, valódi rolling, nem kell vele szenvedni és systemd sincs benne.
Kicsit erőlködtem még Gentoo-val. Leszedtem pár csomagot, majd újra felraktam. Most már 2 órán keresztül fordítgatta a Haskell-t is, pedig a kutya nem kérte rá, félreazonosította az opengl csomagot, egy haskellesre. De lett előrelépés, most már a startx után csontrafagy. Ebből újratelepítés lesz, ha akkor is szórakozik is fütyiségekkel, akkor dobom. Kár érte, mert majdnem ott voltam, hogy működik minden, jó volt az OpenGL, lett ALSA hang, erre ment az egész a süllyesztőbe. Egy centin múlt, hogy végül nem laktam be.
Persze a Haskell egy felesleges nagy boszme kornyezeti valtozo.. neked a virutal/opengl csomag kellett volna csak. esetleg USE-ba berakod hogy
-haskell
Van meg ilyen forgatos systemd mentes disztro... CRUX. bar nekem az vele a tapasztalatom, hogy nem mindig fordulnak le a csomagok. Rolling az is valamennyire. Es nem kell bajlodnod a USE flaggel."Ilyen Calculate Linuxnak számomra nincs értelme, mert ennyi erővel feltehetnék egy Artix-ot, ami Arch alapú, friss, valódi rolling, nem kell vele szenvedni és systemd sincs benne."
systemd nincs benne csak libsystemd.so
azert kell, hogy ne kelljen minden csomagot atforditani... igy az archos csomagokkal 100%-ban kompatibilis. -
Nah megneztem mit tud ez a Calculate linux, Gentoo forumon olvasgatva talaltam ra, es arra is hogy vannak neki binaris csomagjai. Amelyek nincsenek a mirrorjukon fent, azt termeszetesen forrasbol probalja felrakin ebbol a szempontbol nem lesz jobb a Gentoo-nal.
A lista itt talalhato meg, ha valakit erdekel. [link]
-
Majdnem így, csak a --new-use-t használva. Most éjszaka adtam ki, elfordítgatott pár órát, 119 csomagot. De most se jó. Mit tudnék ezzel csinálni?
Nem az, hogy a picom nem jó, de a startx és a Firefox is túl lassan tölt be, tehát valami alapvető probléma van. Ami nem lenne baj, de fogalmam sincs, hogy hol keressem a megoldást, és a teljes újratelepítésen kívül mit tehetnék.
-
Ez egyre kínkeservesebb
Nagy nehezen csiholtam ALSA hangot, majdnem vért hugyoztam vele. Utána kicsit még kísérleteztem a Sway-jel, mert a másik fórumon linkeltek hozzá egy ilyen SUID bites trükköt, persze nem működött. De annyit mégis elértem vele, hogy addig telepítettem hozzá extra megoldásokat (pl. weston), amíg nem fordított újra az emerge pár dolgot wayland USE flaggel. Na, ez volt óriási hiba, mert most már megint nem megy a picom 
Persze próbáltam visszacsinálni, leszedtem az összes weston-os és sway-akármis csomagot, a zz-autounmask-ból kivettem a mesa-t az utána beírt wayland USE flag-gel együtt, próbáltam megint mindent opengl USE flag-gel fordítani, opengl mesa picom csomagokat, de hiába, nem tudja használni az OpenGL-t.
Az i915 kerneldriver rendben van, a glxinfo szerint megy a DRI hardveres gyorsítás is, a glxgears is pörög, de OpenGL nem akar menni. Hogy tudnám visszacsinálni ezt a wayland-es kárt, hogy újra menjen az egész? Érzem, hogy valamit még újra kéne fordítani az opengl USE flag-gel, de nem tudom micsodát, meg melyik paranccsal kéne az összes érintett csomagot újrafordítani.
-
Eddig nem is tudtam, hogy a Calclulate linux a portage binary csomagjait hasznalja
Igy mar a GCC es LLVM telepites is csak par masodperc
Szoval van lusta Gentoo = Calculate linux
Ez egyre kínkeservesebb
Nagy nehezen csiholtam ALSA hangot, majdnem vért hugyoztam vele. Utána kicsit még kísérleteztem a Sway-jel, mert a másik fórumon linkeltek hozzá egy ilyen SUID bites trükköt, persze nem működött. De annyit mégis elértem vele, hogy addig telepítettem hozzá extra megoldásokat (pl. weston), amíg nem fordított újra az emerge pár dolgot wayland USE flaggel. Na, ez volt óriási hiba, mert most már megint nem megy a picom Persze próbáltam visszacsinálni, leszedtem az összes weston-os és sway-akármis csomagot, a zz-autounmask-ból kivettem a mesa-t az utána beírt wayland USE flag-gel együtt, próbáltam megint mindent opengl USE flag-gel fordítani, opengl mesa picom csomagokat, de hiába, nem tudja használni az OpenGL-t.
Az i915 kerneldriver rendben van, a glxinfo szerint megy a DRI hardveres gyorsítás is, a glxgears is pörög, de OpenGL nem akar menni. Hogy tudnám visszacsinálni ezt a wayland-es kárt, hogy újra menjen az egész? Érzem, hogy valamit még újra kéne fordítani az opengl USE flag-gel, de nem tudom micsodát, meg melyik paranccsal kéne az összes érintett csomagot újrafordítani.
-
Na, úgy néz ki, hogy neked lett igazad. Az opengl kellett USE flagnek. Utána a picom újrafordításánál lehúzott pluszba egy opengl csomagot, és utána újrafordult a picom. Mindkét kód kicsi, nem volt 1 perc összesen. Utána egyből jó lett, van transzparencia meg vsync meg minden.
Viszont Waylandba szerintem nem tudok segiteni..
Hirtelen meg talan annyi, ha nem akarsz consolekitet meg elogind-t... hogy ezt vegrehalytod..sudo setcap cap_sys_tty_config=ep /usr/bin/swayesetleg ha a gpu-ddal van proglemaja akkor...
WLR_DRM_DEVICES=/dev/dri/card1 sway
(dev/dri/card itt azt add meg amelyiket hasznalni akarod... az integraltat, vagy a dedikaltat).bash_profile-ba.# If running from tty1 start sway if [ "$(tty)" = "/dev/tty1" ]; then exec sway fiEgyebet nem tudok mast elkepzelni meg...
-
Jó, de most mondom, hogy nem a környezeti változók a gond. Először én is azt hittem, de azóta pótoltam őket kézzel. Hanem a kezelt hardvereszközöket nem éri el a Sway elogind nélkül, tehát képernyő, billentyűzet, egér, egyéb eszközök. Terminálkimenetben nyühögi az ilyenforráskód.c error meg amolyanforráskód.c line 542 faxtudjami errorjait, hogy nem éri el az eszközöket. Gondolom jogosultság miatt, ha rootként futtattom, úgy meg sehogy nem hajlandó futni.
Egyébként ezért jó a Gentoo, már tanultam egy csomó hasznos dolgot, meg pár programról, amiről korábban azt hittem, hogy minimalisták, kiderült, hogy bloatok. Ez a Sway is, meg pl. a Termite terminál is. Utóbbi is csak hiába 2 mega, de van egy rakat Gtk-s, Gnome-os, harfbuzzos, ikontémás, lófügyis függősége, ami rohadt bloattá teszi sajnos. Már a fordítási időből látszik, hogy valami bloat, de ezt addig nem látod, amíg el nem kezded forráskódból forgatni, vagy nem Gentoo-t használsz. Aki most kezdi ezeket először, mint én is, annak egy ilyen durva első felismerés, szemfelnyitó pillanat.
Most a picom kompozitorral szopok, panaszkodik, hogy nincs belefordítva a glx támogatás, ami OpenGL-es. Nem tudom melyik USE flag-gel lehetne ezt pótolni. Semmi nem írja, megnéztem a forráskódját és a meson scriptjét, és onnan sem derül ki.
-
Hat OpenRC-n csak a consolekit-el vagy az elogind-vel megy...
Enable support for rootless session via elogindXorg is megy rootless elgind es consolekit nelkul Xwapper-el. itt viszont Sway-el erdekes a dolog... vagy a conf.d-bol kell egy scriptel a wm inditasa elott inditani a kornyezeti valtozot vagy nem tudom...
-
Nem, mindenképp kell neki elogind. A ck-launch-session csak annyit segítene rajta, hogy gondoskodna indulás előtt a környezeti változókról. Viszont ez mindhiába, mégse működik, mert mikor a Sway kezelne az eszközöket (kijelző, stb.), akkor dobálgatja a forráskód.c error-okat, nem éri el őket. Nálad azért meg ck-lauch után, mert eleve az elogind-t is feltetted.
-
Nem kell neki, csak hasznos lehet (ugy ahogy Gnome eseten is, technikailag hasznalhato systemd nelkul csak alap dolgok eltoresevel).
Ugy emlekszem elsonek consolekittel futtattam: exec ck-launch-session sway.
Most hasznalok elogind-t, a fenti hasznos dolgok miatt.
Egyebkent nem emlekszem semmi magiara, alap dolgokat felraktam (video driver, elogind, stb) beirtam hogy sway es kesz. -
Megint elakadtam a rendszer belakása közben. Felraktam a SwayWM-et, de nem működik. Az okát is tudom. Hiányzik neki néhány környezeti változó, XDG_RUNTIME_DIR, SWAYSOCK, stb.. Az a baj, hogy ezek egy részét hiába állítom be kézzel, a SWAYSOCK-ot nem lehet, mert az már csak a Sway indulása után létrejött fájlra építene.
Archon működik, de ott a systemd systemctl nevű toolja gondoskodik erről, hogy beállítja ezeket a szükséges környezeti változókat a /etc/sway/conf.d/10-systemd.conf fájlban lévő scripttel:
#!/bin/sh
#
# FS#63021
#
systemctl --user import-environment DISPLAY WAYLAND_DISPLAY SWAYSOCK XCURSOR_SIZE
if command -v dbus-update-activation-environment >/dev/null 2>&1; then
dbus-update-activation-environment DISPLAY WAYLAND_DISPLAY SWAYSOCK XCURSOR_SIZE
fiNa már most Gentoo alatt OpenRC initrendszert használok. Ott is lehet ilyen conf.d trükköt eljátszani, de gyanítom nem fog működni.
Tudom, hogy Kékluficet is Sway-t használ, ezért kérném a segítségét, hogy ő ezt hogy állította be.
Jelenleg fut ugyan a Sway, kézzel beállítgatott környezeti változókkal, de a grafikus alkalmazások nem indulnak, nem találják a displayt, meg a Sway socketet. Tehát fent van, működik a Sway, csak nettó használhatatlan.
Szerk.: a Sway oldalán lévő dokumentáció azt írja, hogy elogind kell neki, és ez alapján újra kell forgatni a wlroots-t. Ez tényleg működhet?
-
Egyik az GNU C library [link] a masik meg egy gnome library ami altalaban a c-ben irodott programoknak kell. [link]
Glibc-t csak Musl-al tudod valtani, de akkor felejtsd el a wine-t, steamet, es egyeb nepszeru programokat. Viszont azt mar nem tudod megtenni, mert eleve ahhoz masmilyen stage3-kell
[link]
Egyebkent minel nagyobb szalat adsz meg neki annal tobb memoriat fog emeszteni..
-j5 helyett progalkozz csak siman -j2 vel.. tovabb fog fordulni, de nem fog annyi RAM-ot fogyasztani. -
Még mindig virtuális gépen gyakorlom a telepítést, de nem akarom az OFF topikot offolni. Lett egy új kedvencem: glibc. Csak az 50 perc volt, mire lefordult, és közben szépen beszippantotta a virtuális gépnek adott 6 GB RAM-ot. Erre még 15-20 percig leállt malmozni mindenféle nyelvű lokalizációs fájl generálásával, 487 darabbal. Ez meg mi a ráknak, mikor nekem csak en_US UTF8 kell? Ehhez képest a kernel villámgyorsan fordul.
Egyébként már volt értelme gentoo-zni, pedig még nincs is fent a gépen, de már egy csomó csomagról látom, hogy milyen iszonyú bloatok.
A glibc nem lenne kiváltható sima glib-bel? Közben egy fenti hozzászólásommal ellentétben nem lesz már Chromium fordítás, dobtam ezt a böngészőt Archon is, mivel nem tud alternatív DNS-t kezelni, ami meg nekem fontos lett, mióta a lakástulaj által leszerződött netszolgáltató szűr pofátlanul egy csomó oldalt és emiatt 1.1.1.1-es Cloudfare-es DNS-t kell használjak
-
Amugy nem tudom hogy most milyen gepen csinalod (es mennyi erofforasst adtal a virtualis gepnek) es min akarod majd telepiteni, de a notimon (m3-7Y30) 2.5x gyorsabban megvannak a dolgok mint nalad. Kulonbseg lehet, hogy mindenfele USE flaget belosz.
Csak egy kis referencianak irom, hogy ne sirj azert mert fel nap a gcc, nem annyi. Azert te sem kavefozot hasznalsz. -
Kár. Amitől még félek, ha már a fő gépemre telepítem, hogy a Wine-vel szopás lesz. Ami ugyebár multilib, meg nem is kicsi, megőszülök mire önmagában lefordul, de aztán még fordítani fog hozzá függőségnek egy rakat 32 bites libet is, mivel a 64 bites rendszeren fent lévő 64 bites libeket a 32 bites Wine nem tudja használni. Dikcsák, nágyón sukór lesz, mo-re.
Amugy nem tudom hogy most milyen gepen csinalod (es mennyi erofforasst adtal a virtualis gepnek) es min akarod majd telepiteni, de a notimon (m3-7Y30) 2.5x gyorsabban megvannak a dolgok mint nalad. Kulonbseg lehet, hogy mindenfele USE flaget belosz.
Csak egy kis referencianak irom, hogy ne sirj azert mert fel nap a gcc, nem annyi. Azert te sem kavefozot hasznalsz. -
Még mindig virtuális gépen gyakorlom a telepítést, de nem akarom az OFF topikot offolni. Lett egy új kedvencem: glibc. Csak az 50 perc volt, mire lefordult, és közben szépen beszippantotta a virtuális gépnek adott 6 GB RAM-ot. Erre még 15-20 percig leállt malmozni mindenféle nyelvű lokalizációs fájl generálásával, 487 darabbal. Ez meg mi a ráknak, mikor nekem csak en_US UTF8 kell? Ehhez képest a kernel villámgyorsan fordul.
Egyébként már volt értelme gentoo-zni, pedig még nincs is fent a gépen, de már egy csomó csomagról látom, hogy milyen iszonyú bloatok.
A glibc nem lenne kiváltható sima glib-bel? Közben egy fenti hozzászólásommal ellentétben nem lesz már Chromium fordítás, dobtam ezt a böngészőt Archon is, mivel nem tud alternatív DNS-t kezelni, ami meg nekem fontos lett, mióta a lakástulaj által leszerződött netszolgáltató szűr pofátlanul egy csomó oldalt és emiatt 1.1.1.1-es Cloudfare-es DNS-t kell használjak
-
Frawly
veterán
Még mindig virtuális gépen gyakorlom a telepítést, de nem akarom az OFF topikot offolni. Lett egy új kedvencem: glibc. Csak az 50 perc volt, mire lefordult, és közben szépen beszippantotta a virtuális gépnek adott 6 GB RAM-ot. Erre még 15-20 percig leállt malmozni mindenféle nyelvű lokalizációs fájl generálásával, 487 darabbal. Ez meg mi a ráknak, mikor nekem csak en_US UTF8 kell? Ehhez képest a kernel villámgyorsan fordul.
Egyébként már volt értelme gentoo-zni, pedig még nincs is fent a gépen, de már egy csomó csomagról látom, hogy milyen iszonyú bloatok.
A glibc nem lenne kiváltható sima glib-bel? Közben egy fenti hozzászólásommal ellentétben nem lesz már Chromium fordítás, dobtam ezt a böngészőt Archon is, mivel nem tud alternatív DNS-t kezelni, ami meg nekem fontos lett, mióta a lakástulaj által leszerződött netszolgáltató szűr pofátlanul egy csomó oldalt és emiatt 1.1.1.1-es Cloudfare-es DNS-t kell használjak
-
Az i5-2520M most csak kényszerből van benne, mert kimúlt a régi alaplap, és a ThinkPad X szériánál a proci rá van forrasztva az alaplapra, így egy tartalék lap van benne ezzel a gyengébbik procival. Majd veszek bele másik alaplapot, amin i7-2620M vagy i7-2640M proci van, bár az sem sokkal gyorsabb, egész minimálisan, +1 MB cache, +200-300 MHz órajel, de épp úgy 2 mag 4 szál, 35W TDP, lepkefing erő. De idővel a laptop is le lesz cserélve valami combosabbra, min. 4 mag 8 szálas modernebb proci.
(#3516) F34R: a két emberes felállással az a baj, hogy kevesen vannak. Még ha lelkiismeretes is csinálják, akkor is túl nagy a veszélye, hogy magánéletbeli problémák miatt akadozik a fejlesztés, meg kiesik a fejlesztő és lehal a projekt. Meg a kisebb disztrók mögött is rengeteg csomag van, így kellenek az emberek mögé, ez a Linux meg opensource olyan mozgalom, hogy csak tömeggel megy, magányos farkasként elég nehezen.
Így nézegetve az LFS-t egyébként nem tűnik nagyobb számnak a Gentoo-nál, meg az Archnál sem nagyon. Épp úgy chroot-os telepítésre építenek, LFS-nél csak annyi a különbség, hogy mielőtt maga fordítja az ember a csomagot, be is kell szereznie innen-onnan az elszórt forráskódot, meg nincs függőségkezelés.
-
>GCC, Firefox, Chromium, ezeknél kibírom, ha hosszabban fordul, legfeljebb kicsit ritkábban frissítem, nem 1-2 naponta, hanem 1-2 hetente.
Meg szep hogy ezeket nem forditanad naponta, mert annyi ido alatt az a szegeny i5-2520M nem is tudna vegezni veluk
Gentoo-val nekem azert eri meg butykolnom (a minimalis mivoltat leszamitva), mert ellentetben a "bleeding edge" arch-csal es manjaroval, ez frissites utan nem halja szet magat. Itt valahogy nagyobb hangsulyt fektetnek arra, hogy a portage-ba bekerulo csomagok tesztelve legyenek, mintsem, hogy elobb elerhetok legyenek, mint a distrowatch-on eggyel mogottuk levo disztron...
-
Valószínű saját disztrót rakok inkább össze. Néztem az LFS-t is most, csak a kézikönyvét, meg 1-2 videót róla, de már nem tetszik:
1) nem a legújabbak a csomagok. Nem túl elavultak, relatíve frissek, de elmaradnak az Archtól
2) erőlteti a GRUB-ot, amit nem szeretnék feltenniInkább az LFS mintájára, de nem annak alapján, összerakok valami saját renszert, ami git masterből fordul.
Ez a 77MB-os memófogyasztás tetszik. Főleg, hogy a dwm is fut, az elég királyságos. De a 4.14-es kernel nálam már szörnyen réginek számít.
Pont valamelyik nap neztem a KISS Linux-t... nah az tenyleg mindenbol a legfrissebbet forgassa... Annyira viszont komolyan azt nem vennem mert ket darab ember csinalja...
(#3515) Domonkos
+1
Talan meg a Devuan Beowulf hasonloan stabil...
-
Abban viszont igazatok lehet, hogy nem éri meg bütykölni. De ezt mondták anno az Archra is, meg ti sem véletlenül Gentoo-t használtok. Szóval valahol mégis megéri, mert nem csinálnánk, mindenki Ubuntut, MX Linuxot vagy Manjaro-t használna.
LibreOffice-t nem használok, meg LLVM-et sem, csak GCC, Firefox, Chromium, ezeknél kibírom, ha hosszabban fordul, legfeljebb kicsit ritkábban frissítem, nem 1-2 naponta, hanem 1-2 hetente.
>GCC, Firefox, Chromium, ezeknél kibírom, ha hosszabban fordul, legfeljebb kicsit ritkábban frissítem, nem 1-2 naponta, hanem 1-2 hetente.
Meg szep hogy ezeket nem forditanad naponta, mert annyi ido alatt az a szegeny i5-2520M nem is tudna vegezni velukGentoo-val nekem azert eri meg butykolnom (a minimalis mivoltat leszamitva), mert ellentetben a "bleeding edge" arch-csal es manjaroval, ez frissites utan nem halja szet magat. Itt valahogy nagyobb hangsulyt fektetnek arra, hogy a portage-ba bekerulo csomagok tesztelve legyenek, mintsem, hogy elobb elerhetok legyenek, mint a distrowatch-on eggyel mogottuk levo disztron...
-
Valószínű saját disztrót rakok inkább össze. Néztem az LFS-t is most, csak a kézikönyvét, meg 1-2 videót róla, de már nem tetszik:
1) nem a legújabbak a csomagok. Nem túl elavultak, relatíve frissek, de elmaradnak az Archtól
2) erőlteti a GRUB-ot, amit nem szeretnék feltenniInkább az LFS mintájára, de nem annak alapján, összerakok valami saját renszert, ami git masterből fordul.
Ez a 77MB-os memófogyasztás tetszik. Főleg, hogy a dwm is fut, az elég királyságos. De a 4.14-es kernel nálam már szörnyen réginek számít.
-
Valószínű saját disztrót rakok inkább össze. Néztem az LFS-t is most, csak a kézikönyvét, meg 1-2 videót róla, de már nem tetszik:
1) nem a legújabbak a csomagok. Nem túl elavultak, relatíve frissek, de elmaradnak az Archtól
2) erőlteti a GRUB-ot, amit nem szeretnék feltenniInkább az LFS mintájára, de nem annak alapján, összerakok valami saját renszert, ami git masterből fordul.
Ez a 77MB-os memófogyasztás tetszik. Főleg, hogy a dwm is fut, az elég királyságos. De a 4.14-es kernel nálam már szörnyen réginek számít.
-
Hacsak nem konkretan ezzel szeretnel foglalkozni, akkor elobb vagy utobb ra fogsz jonni, hogy az OS-t butykolni idopazarlas; azt az ember csak kozvetetten hasznalja es akkor a legjobb, ha nincs az utadban. Persze egy Gentoo telepitessel eleg sokat meg lehet tudni a GNU+Linux-os rendszerekrol, de azert ezt valasztani, hogy idot sporolj, az onmagad atverese.
Viszont ha az a celod, hogy egy nagyon minimalis disztrot viszonylag keves raforditassal osszedobj, arra nagyon is alkalmas. Itt az enyem:
-
Kösz szépen a válaszokat. A kedvem eléggé elvettétek, nincs értelme akkor szívni vele
Egyébként hihetetlen, hogy az Archnál nincs frissebb, mikor ők sincsenek toppon belőle. Lehet az LFS-t kéne megpróbálnom, úgy, hogy mindent git masterből fordítok.
Hacsak nem konkretan ezzel szeretnel foglalkozni, akkor elobb vagy utobb ra fogsz jonni, hogy az OS-t butykolni idopazarlas; azt az ember csak kozvetetten hasznalja es akkor a legjobb, ha nincs az utadban. Persze egy Gentoo telepitessel eleg sokat meg lehet tudni a GNU+Linux-os rendszerekrol, de azert ezt valasztani, hogy idot sporolj, az onmagad atverese.
Viszont ha az a celod, hogy egy nagyon minimalis disztrot viszonylag keves raforditassal osszedobj, arra nagyon is alkalmas. Itt az enyem: -
Akkor maradok eleinte a stage3-nál.
Az O2 vs. O3 témában sokat olvastam, de nem meggyőzőek az érvek, egyik tábor ezt javasolja, a másik a másikat. Ezek az O2 és O3 paraméterek bekapcsolják linkeléskor az LTO-t? A fordítási időt és áramot nem akarom visszanyerni, max. éjszaka fordítom a csomagokat. A lényeg, hogy mikor használom a gépet, akkor a leggyorsabb binárisokkal legyen használva, nyerjek sebességügyileg egy Arch-hoz képest.
UEFI bootra az EFI stub bootot találtam, ahol a kernel bootol közvetlenül EFI partícióról, se GRUB, se systemd boot. Ilyen van Archon is, de ott sose sikerült működésre bírnom, ezért kicsit tartok tőle. systemd bootot nem csak a systemd miatt nem akarok, de initramfs-t sem szeretnék, nettó felesleges, ha nincs szoftveres titkosítás.
Verzióknál csak annyit ír a Gentoo Wiki, hogy a Portage-t lehet Testing-re állítani, ha az architektúra elé ~ jelet teszünk. De ez elvileg csak a Portage-re vonatkozik, és nem tudom, hogy az Archhoz képest mennyire lesz friss.
Négy célom van a Gentoo-val: 1) szakmailag fejlődjek, hogy ne akadjak el az Arch szintjén, 2) systemd mentes legyen, 3) gyorsabb legyen, 4) frissebb legyen, hogy megérje a vele való munkát.
Nehany csomagbol van 9999 ami megegyezik a github masterrol lehuzott verzioval...
2-3% elonyod van ahhoz kepest, mitha masok forditanak helyetted es a csomagkezelod rakna fel. Grub helyett ott van pl a Syslinux is... OpenRC-nel kapcsold be a parrallel run-t akkor nyersz par masodpercet... lenyegeben ennyi. Initramfs-t ugy tudod elkerulni ha kezzel forditot a kernelt nem pedig a genkernellel.
Nah jah, libreoffice-nal, vagy videoszerkesztonel, GCC-nel LLVM-nel hozhat tobb %-s elterest, de kis csomagoknal szinte semmit...
LO-t meg FF-t forditson a franc mikor van bin verzioja is portageben -
Akkor maradok eleinte a stage3-nál.
Az O2 vs. O3 témában sokat olvastam, de nem meggyőzőek az érvek, egyik tábor ezt javasolja, a másik a másikat. Ezek az O2 és O3 paraméterek bekapcsolják linkeléskor az LTO-t? A fordítási időt és áramot nem akarom visszanyerni, max. éjszaka fordítom a csomagokat. A lényeg, hogy mikor használom a gépet, akkor a leggyorsabb binárisokkal legyen használva, nyerjek sebességügyileg egy Arch-hoz képest.
UEFI bootra az EFI stub bootot találtam, ahol a kernel bootol közvetlenül EFI partícióról, se GRUB, se systemd boot. Ilyen van Archon is, de ott sose sikerült működésre bírnom, ezért kicsit tartok tőle. systemd bootot nem csak a systemd miatt nem akarok, de initramfs-t sem szeretnék, nettó felesleges, ha nincs szoftveres titkosítás.
Verzióknál csak annyit ír a Gentoo Wiki, hogy a Portage-t lehet Testing-re állítani, ha az architektúra elé ~ jelet teszünk. De ez elvileg csak a Portage-re vonatkozik, és nem tudom, hogy az Archhoz képest mennyire lesz friss.
Négy célom van a Gentoo-val: 1) szakmailag fejlődjek, hogy ne akadjak el az Arch szintjén, 2) systemd mentes legyen, 3) gyorsabb legyen, 4) frissebb legyen, hogy megérje a vele való munkát.
Jok a celjaid, de:
- En nem hiszem, hogy a systemd sebesseget meg lehetne openrc-vel kozeliteni. Par s diffi biztos lesz az elobbi javara
- Mivel sokkal kisebb a kozosseg, igy a csomagok is kesobb, kevesebbszer es lassabban kerulnek ki. Meg akkor is, ha az unstable (~) csomagokat is bevalogatsz.
- Semmi nem lesz erezhetoen gyorsabb ami IO-t igenyel; es ami nem, az sem jelentosen. Akik arch-ra csomagolnak azok is meg szoktak mindent tenni annak erdekeben, hogy adott korulmenyek kozt a legjobb legyen a kikerulo szoftver.Felreertes ne essek, en nem szeretnelek lebeszelni a gentoo-rol, de amit te szeretnel az a meme resze.
-
1: 3. Ezzel meglepoen keves szopas van - vagy ha van is, akkor kelloen hamar kiderul hogy ne kelljen mindent ujracsinalni. Hogy ezzel milyen "gyors" binarisokat forditasz az teljesen fuggetlen.
2: En gcc-t hasznalok, -O2-vel, mert anno voltak stabilitasbeli problemak -O3-mal. Meg nagyon udvozito, hogy mennyivel gyorsabban fordul vele szinte minden. Igazabol a poen az az, hogy akarmennyire is "gyorsra" sikerul forditanod a binarist, a forditasba beleolt idot es villanyt sosem fogod visszanyerni. Ilyen indokkal szerintem ez nem eri meg. Ha meg tenyleg csak a sebesseg szamit, akkor meg hagyd ki az OS-t a hardver es a szoftvered kozul
3: passz
4: layman-t erdemes atbongeszned; de ott sem lesznek mindig fent a legfrissebbek. Az arch ilyen szempontbol sokkal "blidingedzzsebb". Viszont semmi sem gatol abban meg, hogy a github-rol, egyeb helyekrol leclone-ozott csomagokat telepits kezzel.
5: Csak kernelfrissiteskor es aramszunetkor inditom ujra a gentoo-s gepem; passz -
Gentoo-sokhoz lenne pár kérdésem. Egyelőre virtuális gépre fogom telepíteni gyakorlásképp, a jövő hét vége felé, meg fizikai hardverre. Szóval a kérdések sorban:
1) hányas stage-ből érdemes kiindulni? A Gentoo Wiki a stage3-at ajánlja, de én szeretnék minden binárist a legoptimálisabbra fordítani.
2) fordításkor gcc-t vagy clang-ot érdemes használni, és milyen optimalizációs kapcsolókkal? A gépben lévő i5-2520M procihoz az összes utasításkészlet szerint hozzá szeretnék optimalizálni, beleértve a linker optimalizációit is (amit a Clear Linux használ). Villámgyors binárisokat akarok, akkor is, ha 3-4× annyi ideig tart a fordítás. Nem valami combos gép már ez a régi noti, szeretnék belőle minden extra teljesítményt kicsikarni.
3) az UEFI boot hogyan oldható meg GRUB és systemd boot nélkül? Valami egyszerű UEFI bootolási lehetőséget akarok, lehetőleg GRUB nélkül. Ilyet kínál is a systemd, de ha már Gentoo, akkor systemd-t sem akarok a gépre, pont ezért is teszem fel az Arch ellenében.
4) milyen tárolókat érdemes bekapcsolni, ha a legújabb verziókat akarom? A bleeding edge maximumára akarok rámenni, nem a stabilitásra. Már Archon is Testing tárolókat használok jó ideje, nincs is vele gond, de még így sem a legfrissebb néhány csomag, a kernel nem RC-s, a wget 1.99.2 helyett 1.20.3-as csak, a mesa 19.2 helyett csak 19.1.6, a gcc 10-es helyett csak 9.1-es, stb.. Öregszenek az Arch-osok is
5) az initnek OpenRC-re gondoltam, ebben mire kell figyelni, ha párhuzamosan induló szolgáltatásokat akarok a minél gyorsabb bootidő érdekében?1: 3. Ezzel meglepoen keves szopas van - vagy ha van is, akkor kelloen hamar kiderul hogy ne kelljen mindent ujracsinalni. Hogy ezzel milyen "gyors" binarisokat forditasz az teljesen fuggetlen.
2: En gcc-t hasznalok, -O2-vel, mert anno voltak stabilitasbeli problemak -O3-mal. Meg nagyon udvozito, hogy mennyivel gyorsabban fordul vele szinte minden. Igazabol a poen az az, hogy akarmennyire is "gyorsra" sikerul forditanod a binarist, a forditasba beleolt idot es villanyt sosem fogod visszanyerni. Ilyen indokkal szerintem ez nem eri meg. Ha meg tenyleg csak a sebesseg szamit, akkor meg hagyd ki az OS-t a hardver es a szoftvered kozul
3: passz
4: layman-t erdemes atbongeszned; de ott sem lesznek mindig fent a legfrissebbek. Az arch ilyen szempontbol sokkal "blidingedzzsebb". Viszont semmi sem gatol abban meg, hogy a github-rol, egyeb helyekrol leclone-ozott csomagokat telepits kezzel.
5: Csak kernelfrissiteskor es aramszunetkor inditom ujra a gentoo-s gepem; passz -
Frawly
veterán
Gentoo-sokhoz lenne pár kérdésem. Egyelőre virtuális gépre fogom telepíteni gyakorlásképp, a jövő hét vége felé, meg fizikai hardverre. Szóval a kérdések sorban:
1) hányas stage-ből érdemes kiindulni? A Gentoo Wiki a stage3-at ajánlja, de én szeretnék minden binárist a legoptimálisabbra fordítani.
2) fordításkor gcc-t vagy clang-ot érdemes használni, és milyen optimalizációs kapcsolókkal? A gépben lévő i5-2520M procihoz az összes utasításkészlet szerint hozzá szeretnék optimalizálni, beleértve a linker optimalizációit is (amit a Clear Linux használ). Villámgyors binárisokat akarok, akkor is, ha 3-4× annyi ideig tart a fordítás. Nem valami combos gép már ez a régi noti, szeretnék belőle minden extra teljesítményt kicsikarni.
3) az UEFI boot hogyan oldható meg GRUB és systemd boot nélkül? Valami egyszerű UEFI bootolási lehetőséget akarok, lehetőleg GRUB nélkül. Ilyet kínál is a systemd, de ha már Gentoo, akkor systemd-t sem akarok a gépre, pont ezért is teszem fel az Arch ellenében.
4) milyen tárolókat érdemes bekapcsolni, ha a legújabb verziókat akarom? A bleeding edge maximumára akarok rámenni, nem a stabilitásra. Már Archon is Testing tárolókat használok jó ideje, nincs is vele gond, de még így sem a legfrissebb néhány csomag, a kernel nem RC-s, a wget 1.99.2 helyett 1.20.3-as csak, a mesa 19.2 helyett csak 19.1.6, a gcc 10-es helyett csak 9.1-es, stb.. Öregszenek az Arch-osok is
5) az initnek OpenRC-re gondoltam, ebben mire kell figyelni, ha párhuzamosan induló szolgáltatásokat akarok a minél gyorsabb bootidő érdekében? -
Azt hogy a desktop profilokba mit miert raknak/nem raknak be nem tudom, egyszeruen azert mert nem erdekel, nem hasznalom oket. Amug ez nem csomag, csak USE flag kerdes. (egyebkent lehet csinalni sajat profilt is
)
Egyszerre tobb verzio is fent lehet a csomagokbol (gyarilag nincs olyan sok beloluk de), a python erre pont jo pelda, bovebben megtalalod Slot(ting) alatt (off: kicsit szomoru hogy 2008 ota meg mindig vannak olyan aktivan hasznalt libek amik nincsenek python3-ra portolva... legalabb a python2 tamogatasa hivatalosan is veget er 2020-ban, [link]). Nyugi fent lesz a python3 is.package.use - itt csomagonkent tudod allitani a flageket (make.confban globalisan + profilokban is vannak globalisak es per package flagek is).
use flag - lenyegeben funkcionalitast tudsz vele allitani, fuggosegekhez csak annyi koze van hogy ha olyat allitasz be ami behuz mast akkor azt a csomagot is fel kell raknod fuggosegkent.
vagyul pl a connman-t, ha nincs a gepedben(/nem akarod hasznalni/stb indok) bluetooth es wifi akkor ugy fogod fordiani hogy use flageknel -bluetooth es -wifi van igy nem fog felkerulni jo par fuggoseg (pl wpa_supplicant, bluez, stb), es connman se fogja tamogatni ezeket.
masik pelda: van olyan use flag hogy man (ahogy a neve is utal ra, man page telepiteset tudod vele allitani), ha kihagyod egy csomagnal (tehat -man-t adsz meg) az nem fog befolyaslni semmit se a fuggosegekben viszont ahhoz a csomaghoz nem lesz man.Azt irom neked hogy ugorj ki az ablakon, megteszed? Ugy kell particionalni ahogy szeretnel, ahany wiki/leiras/blog/ember/helyzet/stb mas lesz mondva, a neked megfelelo modon kell eljarni. Mondtam mar hogy nem vakon kell kovetni a leirasokat.
Köszi! Egyelőre a szavakat értem, de nem állnak össze egységes egésszé a fejemben. Mondhatni nézek mint az a bizonyos bornyú az új kapura... Majd még elolvasom párszor, hogy mi micsoda
Ugrás előtt elgondolkodnék rajta. Ugyanakkor kísérletezni, megtanulni, hogy mi merre hány méter, talán érdemes követni a leírást. Aztán ha világosság gyúlik, megcsinálom a particionálást is a saját szájízem szerint. Ki tudja hogy ennek a distro-nak mi a heppje particionálás szempontjából.
-
Köszi a tippet, hétvégén megint nekiszaladok... Bár ugye én egy előre elkészített profilt telepítek, miért nincs benne gyárilag ez(ek) a csomagok is, ha igény van rájuk. Plusz nem lehet hogy azért maradnak ki mert alapból már a Python 3-at teszi fel? Nem fognak így összekutyulódni a dolgok?
Az USE flag-ek ről sincs semmi fogalmam. Addig is próbálom megérteni a manuelben leírtakat.pl. Itt (/etc/portage/package.use/python) írja le, hogy melyik csomagok a függőségei, miket kell feltennie ahoz, hogy működjön?Nem a partícionáló program akarja, hanem ez van leírásban:
GPT
Partition Filesystem Size Description
/dev/sda1 (bootloader) 2M BIOS boot partition
/dev/sda2 ext2 (or fat32 if UEFI is being used) 128M Boot/EFI system partition
/dev/sda3 (swap) 512M or higher Swap partition
/dev/sda4 ext4 Rest of the disk Root partitionMBR
Partition Description
/dev/sda1 BIOS boot partition
/dev/sda2 Boot partition
/dev/sda3 Swap partition
/dev/sda4 Root partitionAzt hogy a desktop profilokba mit miert raknak/nem raknak be nem tudom, egyszeruen azert mert nem erdekel, nem hasznalom oket. Amug ez nem csomag, csak USE flag kerdes. (egyebkent lehet csinalni sajat profilt is
)
Egyszerre tobb verzio is fent lehet a csomagokbol (gyarilag nincs olyan sok beloluk de), a python erre pont jo pelda, bovebben megtalalod Slot(ting) alatt (off: kicsit szomoru hogy 2008 ota meg mindig vannak olyan aktivan hasznalt libek amik nincsenek python3-ra portolva... legalabb a python2 tamogatasa hivatalosan is veget er 2020-ban, [link]). Nyugi fent lesz a python3 is.package.use - itt csomagonkent tudod allitani a flageket (make.confban globalisan + profilokban is vannak globalisak es per package flagek is).
use flag - lenyegeben funkcionalitast tudsz vele allitani, fuggosegekhez csak annyi koze van hogy ha olyat allitasz be ami behuz mast akkor azt a csomagot is fel kell raknod fuggosegkent.
vagyul pl a connman-t, ha nincs a gepedben(/nem akarod hasznalni/stb indok) bluetooth es wifi akkor ugy fogod fordiani hogy use flageknel -bluetooth es -wifi van igy nem fog felkerulni jo par fuggoseg (pl wpa_supplicant, bluez, stb), es connman se fogja tamogatni ezeket.
masik pelda: van olyan use flag hogy man (ahogy a neve is utal ra, man page telepiteset tudod vele allitani), ha kihagyod egy csomagnal (tehat -man-t adsz meg) az nem fog befolyaslni semmit se a fuggosegekben viszont ahhoz a csomaghoz nem lesz man.Azt irom neked hogy ugorj ki az ablakon, megteszed? Ugy kell particionalni ahogy szeretnel, ahany wiki/leiras/blog/ember/helyzet/stb mas lesz mondva, a neked megfelelo modon kell eljarni. Mondtam mar hogy nem vakon kell kovetni a leirasokat.
-
Van 3 csomag aminek olyan pythonra van szuksege ami tamogatja az sqlite-ot, kb ezt jelenti amit ott latsz.
USE flagekkel tudod allitani a modulokat. Python eseteben az sqlite alapbol ki van kapcsolva, ezert szol a csomagkezelo hogy kellene.
1 lehetseges megoldas:
# echo '>=dev-lang/python-2.7.15:2.7 sqlite' >> /etc/portage/package.use/pythonMiért erölteti partícionáláskor a 2MB-os (BIOS boot) partíciót? - mindig fdisk(/gdisk)-et hasznalok, az nem eroltet ram semmit. Az hogy amit te hasznalsz program mit miert csinal neked kell tudni.
Hasznosak leszenk a későbbiekben.
. Alapvetően a handbook-ot követtem. GRUB-ot telepítettem, a sys-boot/grub:2-t.
azert kell, hogy ne kelljen minden csomagot atforditani... igy az archos csomagokkal 100%-ban kompatibilis.
Nagy nehezen csiholtam ALSA hangot, majdnem vért hugyoztam vele. Utána kicsit még kísérleteztem a Sway-jel, mert a másik fórumon linkeltek hozzá egy ilyen SUID bites trükköt, persze nem működött. De annyit mégis elértem vele, hogy addig telepítettem hozzá extra megoldásokat (pl. weston), amíg nem fordított újra az emerge pár dolgot wayland USE flaggel. Na, ez volt óriási hiba, mert most már megint nem megy a picom 
Új hozzászólás Aktív témák
- BESZÁMÍTÁS! GIGABYTE B650M R7 7700X 64GB DDR5 512GB SSD RX 6750XT 12GB Lian Li Vector V100 750W
- GAMING PC! Ryzen 9 3900X / RX 6700 XT / B450 / 16GB 4000MHz / 500GB NVMe / 750w Gold! BezsámítOK
- 27% - LG UltraGear 27GS93QE-B OLED Monitor! 2560x1440 / 240Hz / 0.03ms / G-SYNC / FreeSync
- iPhone 15 256GB 87% (1év Garancia)
- GAMER PC! i5-13500 / RTX 3070 Ti / 16GB DDR / 512GB NVMe / 650w!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest