- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Ivqkzy-: 2. gépem
- Magga: PLEX: multimédia az egész lakásban
- Steven: Sokat utazó kávéfüggők ide!
- eBay-es kütyük kis pénzért
- droidic: EA GAMES – élő emberrel a supportban 2025 ben
- btz: Internet fejlesztés országosan!
-
LOGOUT
Debian GNU/Linux
Új hozzászólás Aktív témák
-
Friczy
senior tag
Pár éve visszaszoktam a Debianra desktopon
Korábban testinget használtam, mert a három éves programokat desktopon túl réginek tartottam, és amikor az Ubuntu először megjelent, megdöbbentő volt, hogy elsőre működik sok minden, amit Debianon külön reszelni kellett - több-kevesebb sikerrel.
Aztán az Ubuntu valahogy kezdett egyre gépigényesebb lenni, párhuzamosan pedig időnként meglepő bugokat produkált, és egyre inkább az volt az érzésem, hogy kevesebb a kontrollom a rendszer felett. Kerestem ismét mást, találtam is egy nagyon jót: Arch. Ez egy szép kitérő volt, aki szereti időnként low-level szinten konfigurálni a rendszerét, cserébe átlátható, annak nagyon jó, feltéve, ha hajlandó is rászánni az időt, mert ha mondjuk fél évig nem frissíted a rendszered, utána már nagyon nehéz dolgod lesz. De mindegy, arra jó volt, hogy megszeressem a rolling-release rendszert, viszont sok gépen egyszerre nem szeretnék Archot használni, túl sok időt venne el a karbantartás.
Így aztán jött a kompromisszum: vettem egy mély levegőt, és Debian unstable. Kicsit valóban észnél kell lenni, és ha pl. úgy látszik, hogy függőségi gondok vannak, akkor frissítés stop. apt-listbugs csomag életmentő, frissítéskor átnyálazza a bugokat, ha van nyitott bug a felrakandó verzióra, akkor szól, eldöntheted, hogy az egész frissítést megállítod, a hibás csomagot rögzíted (pin) a korábbi verzión, vagy a hiba ellenére mégis felteszed. Pinning esetén a cron napi futáskor átnézi, hogy még megvan-e a hiba, ha nincs, akkor leszedi a pinninget automatikusan, szerintem zseniális
További óvintézkedésként etckeeper minden frissítéskor egy újab git verziót készít az /etc könyvtárról, könnyű visszatérni korábbi konfigurációra - bár ezt a feature-t még nem kellett életmentésre használnom.
Jó egy-másfél éve használom így a desktopot, kellően friss, és ritkán futottam bele tényleg idegesítő problémába.
Flash - működik, bár a Flash maga helyből megérett a kidobásra oprendszertől és disztribúciótól függetlenül.
Iceweasel-Firefox: bár az Iceweasel elvileg minimálisan különbözik a Firefoxtól, én is tapasztaltam furcsa viselkedéseket, így inkább a bináris FF-et használtam, ugyanígy a Thunderbirdöt az Icedove helyett.
Viszont a Debian-Mozilla vita megegyezéssel zárult, ennek eredményeképpen eltűnt/eltűnik az Iceweasel, és ismét Firefox van a Debianban, és valamikor a közeljövőben a Thunderbird is visszatér. -
Friczy
senior tag
válasz
Lathronos
#7744
üzenetére
A PPA-t ne tekintsük az Ubuntu részének, ugyanis nem az. És az az érzésem, hogy a Debianban több csomag van, mnt az Ubuntuban, főleg, ha figyelembe vesszük, hogy az Ubuntu esetén a universe (és főleg a multiverse) már félig kilóg a repositoryból). Annak idején futottam bele Ubuntun olyan problémába, hogy egy csomagnak függőségi problémái voltak,rákerestem a bug leírására, a karbantartó el is ismerte, és lezárta azzal, hogy a universe-ben van, ahol nem feltétlenül kell kijavítani a hibákat
Tehát az Ubuntu 'nagyobb csomagválasztéka' kissé megtévesztő.
-
Friczy
senior tag
válasz
CPT.Pirk
#7716
üzenetére
Nem jól érzed
Van elég ember, de a stabil disztribúció Debianban azt jelenti, hogy kiadás után már csak security bugokat javítanak, verziót nem frissítenek. Akkor se, ha nem jól működik. Ennek van előnye is (pont a stabilitás, csak disztribúció-frissítéskor kell meglepetésekre számítani), és hátránya is (ha bugos volt az upstream, akkor bizony évekig az marad a kiadásban).Ha valakinek ez nem felel meg, nyugodtan választhat másik disztribúciót.
-
Friczy
senior tag
válasz
bambano
#7689
üzenetére
Nem tricky, sticky
De nem javaslom, az pont nem azt csinálja, ami itt az igény, hanem azt, hogy bár a könyvtáron 777 van, mégis mindenki csak a saját file-ját tudja módosítani (1777 érték a könyvtáron).Itt pedig pont az a cél, hogy az adott könyvtárban bárki tudja módosítani az ottani file-t. Samba oldalon acl-t célszerű használni (régen használtam Sambát komolyabban, tehát konfigot nem tudok mondani most), valamint a force user és force group opciók.
A Linux jogosultságon érdemes lehet a group-nak módosítási jogot adni (könyvtár szinten 775), valamint a setgid opció a könyvtáron. Ez az újonnan létrehozott file-okat mindenképpen abba a csoportba teszi, amely a könyvtár tulajdonosa (és amelynek beállítottad a törlési jogot, lásd 775 a könyvtáron).
Szerintem a samba force group és a setgid együtt már jó eséllyel megcsinálja, amit az eredeti kérdező szeretne.
-
Friczy
senior tag
A Debian levelezőlistán is cikkeztek erről, ismert bug, egyelőre a workaround annyi, hogy használj régebbi kernelt. A videokártya kernel részénél van a probléma, emiatt X alatt, és nem minden videokártyánál jelentkezik.
(szerencsére nálam unstable van Intel videokártyával, így nem érint
-
Friczy
senior tag
válasz
Apollyon
#7293
üzenetére
ffmpeg visszatért a Debianba
legalábbis a sidben már benne van (és ismét benne van az mplayer is).
Szóval a következő stabil kiadásban is várhatóan benne lesz, ahogy tudtommal a testingben is benne van már.Nem tudom, mennyire macerás a testingből vagy a sidből backportolni a stabilba mostanság, régen elég sokat csináltam ilyet. Inkább, mint külső repo.
-
-
Friczy
senior tag
válasz
#59070464
#7269
üzenetére
Gnome-ot használok, az Evolutionnal csak az a bajom, hogy nagy, nehézkes és ronda
A Thunderbird fejlesztése nem ért véget, rendszeresen jönnek ki új verziók. Miért is halott?A Claws se tetszik, egy időben használtam, tetszetős, de sok hibája volt. Lehet, hogy azóta megjavult, de pillanatnyilag nem érdekel. Én vígan elvagyok a Thunderbirddel.
-
Friczy
senior tag
válasz
#59070464
#7267
üzenetére
https://www.debian.org/Bugs/
https://bugs.debian.org/release-critical/Ha egy csomagban release critical bug van az adott release kiadásakor, akkor az nem kerül be a kiadásba. Ez viszonylag ritka dolog, mert a freeze időszak viszonylag hosszú, és elsősorban erre való. Általában a népszerűbb, fontosabbnak ítélt programok hibáira jobban koncentrálnak, tehát az általad említett Evolution nem valószínű, hogy erre a sorsra jutna egy ilyen esetben (más kérdés, hogy szerintem nem lenne kár érte
, de ez csak azért van, mert én nem szeretem)Az, hogy 'a tárolóból is kikerül' nehezen értelmezhető. A stabil kiadás tárolójába természetesen nem kerül bele, de attól még magát a programot nem dobják ki a Debianból, az unstable és testing tárolóban benne marad. Ahogy az oldstable-ben is, a stabil - értsd: már kiadott - release-ek tárolóiból nem kerülnek ki csomagok, és nem is kerülnek be újak.
-
Friczy
senior tag
válasz
#59070464
#7264
üzenetére
Tegyük fel, írok egy dev-nek, ha érdemlegesnek találja (nem tudom mi alapján dönti(k) el) és bekerül, akkor az onnantól számítva benne lesz a tárolóban?
Ha lesz egy maintainer, aki felvállalja, csinál belőle csomagot, akkor bekerül a fejlesztői (sid) tárolóba, onnan pedig a testingbe. És amikor a testingből stable lesz, és a befagyasztási időszak alatt nem tartalmaz release critical bugot, akkor a következő stabil kiadásban benne lesz.
-
Friczy
senior tag
válasz
bambano
#7201
üzenetére
Nehéz válasz. Szívem szerint mondtam volna a bash_profile-t, de ah valaki átállítja a shelljét másra, akkor ezt is buktad.
Az /etc/environment lehet a megoldás szerintem is (nekem legalábbis az szokott működni), ha valamiért nem működik, akkor nézd át a pam.d beállításokat, megvan-e a pam_env.so mindenhol, ahol kell.
A session beállításoknál kell, létezik egy common-session, amit szinte minden pam.d file beránt, érdemes oda betenni.
-
Friczy
senior tag
Úgy látom, erősen mozog a célpont .) Eddig nem volt feltétel, hogy alapértelmezett lehessen. Mellesleg pl. szerintem ez hátrány, ha egynél több felhasználónak van joga roottá válni, akkor a shared jelszó önmagában is felvet biztonsági problémákat, erről korábban írtam, így én nem örülnék annak, ha alapértelmezett lenne. De ha valakinek ez az aggálya sudoval szemben, van lehetősége megoldani.
-
Friczy
senior tag
Jelszó megszerzésről írtál, még véletlenül sem említve azt, hogy hogyan szerez jelszót valaki. Te most a jelszó megszerzési esetei közül önkényesen kiragadtad a jelszó lelesését. Nos, ugyanilyen hozzáállással simán tudok neked igennel válaszolni, csak a feltételeket kell megfelelően belőni.
Pl. az otthoni gépem esetén többnyire senki nincs a szobában, amikor a jelszót begépelem, így esélye sincs lelesni. Ha mégis megtenné, akkor a szóbajöhető személyek száma összesen kettő, a feleségem és a fiam. Egyik esetben sem félek attól, hogy akár a root jelszót, akár a saját jelszavamat megpróbálná lelesni, még kevésbé attól, hogy felhasználni. Szóval a válasz egyszerű igen, a jelszó lelesése rosszindulatú személy részére meglehetősen nehéz, annyira hogy nyugodtan mondhatom egyenlőnek az esélyt.
Mindenesetre arról volt szó eredetileg, hogy a su vagy a sudo a biztonságosabb, most pedig egyes jelszavak biztonságáról beszélünk, nem pedig egyik vagy másik technikai megoldás biztonságáról önmagában. Ebből az következik, hogy inkább a használati mód biztonságáról van értelme beszélni, azaz azt mondani, hogy 'a su biztonságosabb, használd azt a sudo helyett' egyszerűen egy túl sommás és így téves értékítélet.
(Mellesleg ajánlom figyelmedbe a sudoban a rootpw és runaspw opciókat, ha ezeket beállítod, akkor a saját jelszó helyett a root jelszót illetve azt a jelszót kell használni, amelyik user nevében akarsz valamit csinálni, így aztán a fenti félelmed - gyakran használt jelszó megszerzése - is kiküszöbölhető)
-
Friczy
senior tag
Ettől még nem lesz biztonságosabb. A jelszó megszerzésének lehetősége nem attól függ, hogy hányszor használja valaki, hanem attól, hogy az adott jelszót hogy tárolja, hány helyen használja, és mennyire biztonságos a jelszó továbbítása hálózati használat esetén.
A linkelt cikkedet természetesen olvastam, tulajdonképpen az ottani végkövetkeztetéseddel nem értek egyet, bár a cikk jó
-
Friczy
senior tag
5. Nekem meg a su tűnik biztonságosabbnak.
Attól függ, hogy használod. Ha a sudonál nem nyitod szélesre a kaput (nincs NOPASSWD opció, csak a megadott user/userek használhatják), vagyis csak az használhatja, akinek azt tényleg meg akarod engedni, akkor semmivel sem biztonságosabb a su, mint a sudo. Ha több embernek akarod biztosítani a rendszeren, hogy root lehessen, akkor pedig a sudo biztonságosabb, mert nem kell megosztott jelszót használni, és akkor vonod vissza a többletjogosultságot, amikor akarod.
-
Friczy
senior tag
válasz
spammer
#6928
üzenetére
Mert ha van valami sérülékenység a programban (és egy böngészőben sajnos elég nagy az esélye), akkor nem jó megadni a támadónak azt a lehetőséget, hogy át tudja írnia programot.
Annak idején a 'Linux alá nincs vírus' mítosz igazi apropója az volt, hogy a futtatható file-ok olyan helyen voltak, ahova a felhasználónak esélye sem volt írni, így a klasszikus vírusok akkor se tudtak volna terjedni Linuxon, ha lettek volna ilyenek
Szóval alapvető szabály: a futtató program lehetőleg az adott felhasználóval legyen átírhatatlan.
-
-
Friczy
senior tag
válasz
stopperos
#6512
üzenetére
Néhány dolgot rosszul tudsz, bár a végeredményben igazad van
A backports nem a következő kiadás, teljesen független tőle. Backportsba azok a csomagok kerülnek, amelyeknek újabb verziójára komoly igénye van valakinek (és akad valaki, aki felvállalja).
A SID (fejlesztői) kiadás általában folyamatosan 'mozog' a testingbe, azaz ha a sidben rendben van egy csomag és senki nem akasztja meg, akkor kb. két héten belül bekerül az aktuális testing repoba. Ez alól csak a freeze periódusok (ami most is van) kivételek, ilyenkor az automatikus 'csorgást' megállítják, és javítják a kiadásbeli hibákat. A SID közben is folyamatosan frissül, bár ilyenkor kicsit kisebb lépésekkel, mert a fejlesztői erőforrások a testing rendbetételére mennek. Aztán a Jessie megjelenése után ismét megnyitják az automatikus kapcsolatot, és akkor ismét elkezd frissülni a testing - amiből majd idővel a következő kiadás lesz.
-
Friczy
senior tag
Ne számíts rá.
A stabil verzión belül nem váltanak kernelverziót. Ez annyit jelent, hogy a 3.16 marad a Jessie-ben, annak teljes életciklusában. A biztonsági javítások kerülnek csak bele, de új verziót nem fognak beletenni.
Nagyon kevés olyan csomag van, ahol verzióváltás van a stabil kiadáson belül (többnyire a web-böngészők), a többinél csak hibajavítások vannak, a verzió megtartásával.
Ahogy mondták neked, ha a backports repoba bekerül az újabb kernel, akkor azt felrakhatod, és lesz új kerneled. Vagy fordíthatsz magadnak.
-
#6505
Friczy
senior tag
beloadjoker
#6504
Friczy
senior tag
válasz
beloadjoker
#6504
üzenetére
libnl-genl-3-dev csomag kellene neked.
-
Friczy
senior tag
válasz
konradl
#6487
üzenetére
Az 'egyszerre nem megy' kifejezést kissé pontosítani kéne, ha érdemi segítséget szeretnél. Semmi alapvető akadálya nincs annak, hogy ne menjen, de a hibakereséshez többet kéne tudni.
A második kérdésedre a válasz, hogy nem normális, de a bridge esetén sok buktató van, és abban én se vagyok otthon
-
Friczy
senior tag
válasz
CPT.Pirk
#6482
üzenetére
a man interfaces szerint:
Lines beginning with the word "auto" are used to identify the physical interfaces to be brought up when ifup is run with the -a option. (This option is used by the system boot scripts.) Physical interface names should follow the word "auto" on the same line. There can be multiple "auto" stanzas. ifup brings the named interfaces up in the order listed.
Lines beginning with "allow-" are used to identify interfaces that should be brought up automatically by various subsytems. This may be done using a command such as "ifup --allow=hotplug eth0 eth1", which will only bring
up eth0 or eth1 if it is listed in an "allow-hotplug" line. Note that "allow-auto" and "auto" are synonyms.Ez alapján az allow-hotplug is jó lehet neked, mert a 'brought up automatically by various subsystems' kifejezésbe a boot is beleérthető és beleértendő. Egy másik oldalon olvastam, hogy az allow-hotplug és az auto közt az az egyik különbség, hogy az auto mindenképpen feljön bootkor, az allow-hotplug pedig csak akkor, ha be van dugva, de akkor viszont igen - bootkor is
Ugyanakkor az /etc/init.d/networking restart esetén állítólag az allow-hotplug nem jön vissza, az auto igen. De ilyet ritkán használ az ember.
Szóval szerintem nyugodtan tegyél egy próbát az allow-hotpluggal, jó eséllyel ez fog kelleni neked.
-
Friczy
senior tag
válasz
ubyegon2
#6443
üzenetére
Valóban nem olyan gyors, mintha a teljes rendszer lenne SSD-n, de nem olyan nagy a különbség. Nálam az /usr mindig külön partíció volt, kézenfekvő volt, hogy ezt teszem SSD-re. Ami nem SSD-ről töltődik ilyenkor, az a boot, és a nem /usr alatti libek (ezek viszont többnyire egyszer töltődnek be, aztán a memóriában cache-elődnek, tehát olyan sokat itt nem lehet pluszban nyerni).
-
Friczy
senior tag
válasz
Apollyon
#6432
üzenetére
Nem kell akkora SSD.
Fillérekért lehet venni 40-60 GB-os SSD-ket, vagy akár 120-ast, ha a root partíicót az /usr-rel együtt arra teszed, a /home (és akár a /var) megmaradhat az olcsó, nagy HDD-n, és nem ment rá a gatyád, viszont lesz egy sokkal gyorsabb rendszered.
Nekem csak az /usr van ssd-n baromi sok minden fenn van, és így foglal 12 GB-ot, tehát egy 40 GB-os SSD-n is szellősen elférne a teljes root. És sokkal gyorsabb a rendszer, mintha a WD Greenről töltődnének be a programok.
-
#6409
Friczy
senior tag
feketegergo
#6406
Friczy
senior tag
válasz
feketegergo
#6406
üzenetére
Az, hogy fel van telepítve, csak a winchesteren foglal helyet, de az a mai méretek mellett egyáltalán nem számottevő. Nyugodtan feltehetsz többet is, nem fog instabilitást okozni.
Több memóriafogyasztásra akkor számíthatsz, ha 'rendszeridegen' alkalmazásokat indítasz el (itt arra gondolok, hogy mondjuk Gnome alatt KDE-s holmit, vagy KDE alatt GTK-ra épülő programot, mert ilyenkor a plusz libraryket be kell tölteni. Ez szempont lehet akkor, ha kevés a RAM, de 2-4 GB vagy afelett ez már nem annyira komoly dolog (na meg a Firefox - vagy akár a Chrome - képes egyedül is mindent megenni
-
Friczy
senior tag
válasz
Apollyon
#6400
üzenetére
A 3.18 sose fog bekerülni a Jessie-be, a Jessie kernele 3.16 lesz, és ahogy írtam: a stabil kiadáson belül már csak biztonsági patchek kerülnek be a repositoryba.
A teljes experimental használata tele lehet meglepetésekkel, tehát nem írtak hülyeséget. Önmagában a kernel kb. annyira (vagy talán egy kicsit kevésbé) problémás, mintha a kernel.orgról letöltött kernelekkel játszadoznál.
Szóval ha innen is akarsz használni bármit, az experimentalt sose vedd fel a sources.listbe, amit innen akarsz feltenni, azt töltsd le .deb file-ba, és tedd fel dpkg-val. És tarts készenlétben alternatív boot megoldást
-
Friczy
senior tag
válasz
Apollyon
#6391
üzenetére
A 3.18 - vagy bármely olyan kernel esetén, ami nincs a disztribúcióban - magadra vagy utalva. Nem kapsz se biztonsági frissítést se más egyebet, amit a Debian megcsinál. És itt nincs hibajavítás a kernelben, a hibajavítás új kernelverziót jelent (adott esetben újabb kompatiblitási problémákkal is).
-
Friczy
senior tag
válasz
Apollyon
#6385
üzenetére
Mivel a Debiannál úgy döntöttek, hogy ez a kernel kerül be a Jessie-be, ez a verzió sokáig fog élni. A Debian megszokott megoldása, hogy az esetlegesen megjelenő biztonsági javításokat (csak a biztonságit!) ráteszi a disztribúció kernelére, így a biztonságos kernel adott lesz, de verziót váltani nem szokott stabil kiadáson belül.
-
Friczy
senior tag
válasz
Apollyon
#6383
üzenetére
El kell keserítselek: az unstable-ban jelenleg 3.16-os kernel van.. Ha újabb kernel kell, azt jelenleg maximum a kernel.orgról tudod letölteni és fordítani.
A saját, kézzel fordított kernellel el lehet játszani, sokáig én is csináltam, de mostanában nincs semmi olyan plusz feature, ami annyira kellene, hogy kernelt fordítgassak. Ha ilyet akarsz csinálni (nem az unstable-ből, mert ott nincs 3.18), akkor ajánlom figyelmedbe a kernel-package nevű csomagot, ezzel kényelmesen tudsz a kernelforrásból fordítás után csomagot készíteni, amit utána már a csomagkezelő kezel. Kényelmesebb, mint a sima make install (bár az gyorsabb), de így a kernel felrakás, eltávolítás sokkal könnyebb.
-
Friczy
senior tag
válasz
Apollyon
#6381
üzenetére
Általában a kernel viszonylag problémamentesen cserélhető újabbra. De itt is problémát tud okozni a videokártya-driver, mert ezeknek általában van kernelbe beépülő része is. Nyílt forrású drivereknél (pl. az Intel) több esély van arra, hogy ez nem gond, mert a mainline kernel része a videokártya-meghajtó is, ellenben a zárt drivereknél (nVidia, AMD) biztos, hogy fordítani kell a kernelmodult.
A rendszer többi része általában vígan elvan a hivatalosnál újabb kernellel.
-
Friczy
senior tag
Érdekes kérdés ez, én különféle időszakokban más-más megoldást használtam.
Egy időben mindig stable kiadást, elvégre az a stabil. Desktopon is (sőt, kezdetben csak az volt). Aztán volt egy idő, hogy vagy két évig nem jött ki új stabil verzió (Woody, ha jól rémlik), a korábbi meg már nagyon elavult volt, kellettek az új funkciók, így szépen átálltam a testingre. Mivel probléma nélkül ment, használtam a testinget, aztán jött némi hűtlenség (Ubuntu, majd Arch), és mivel mindegyikben akadt olyan, ami nem tetszett (Ubuntunál a minőség, Archnál az, hogy a fejlesztés időnként nagyon cikkcakkos, a nagyobb programválasztékhoz sokszor kell forrásból fordítani, ezek upgrade-je meg fárasztó), visszatértem a Debianhoz, de mivel az Arch rolling release kicsit hozzászoktatott az új dolgokhoz, most unstable van fenn, és egyelőre ez is marad.
Nos, a háromféle tapasztalat:
Stable: ahogy írják. Agyonüthetetlen, ha egyszer belövöd, utána évekig jó lesz, nem kell hozzányúlni. Persze szép lassan minden nagyon régi lesz (kivéve most már a böngésző, mert az a stable alatt is frissül - régen nem így volt), és ez néha tényleg kellemetlen desktopon, de ha valakit ez nem zavar, akkor jól jár vele.Kivéve, ha a gépe túl új, mert akkor elképzelhető, hogy kell néhány frissebb dolog (kernel, videokártya-driver), és ez már izgalmasabbá teszi az életet, jöhet a backport.
Testing: Igazából a hosszabb testing használat alatt nem volt komolyabb problémám, rendszeresen (pár naponta) frissítettem a rendszert, néha persze nem jött össze, függőségi problémák gyakran adódtak, de általában nem kellett foglalkozni vele, magától megjavult (nem erőltettem semminek a frissítését). Persze néha nem, de egy kis gyakorlattal ki lehet találni, hogy mikor kell jobban belenyúlni.
Unstable: a legrizikósabb a háromból, de mióta fenn van, nem volt vele túl sok gondom, pedig időközben a systemd-re is átálltam. Ugyanakkor itt fel kell készülni arra, hogy valami egyszercsak egy upgrade után nem megy, akár olyan szintig, hogy be sem bootol a rendszer, rescue disk kell. Itt már óvatosabbnak kell lenni, nem árt, ha a legfrissebb csomag mellett a korábbi verzió is megtalálható a gépen, ha vissza kell állni, frissítéskor érdemes megnézni, hogy van-e olyan hiba, ami esetleg érinthet (apt-listbugs nagy segítség ebben), nekem még óvintézkedésként az etckeeper verziókezelőben menti az /etc/... tartalmát, és még gondolkozom azon, hogy az upgrade-elt csomagokat upgrade előtt dpkg-repackkal összecsomagolom és úgy rakom el a könnyebb visszaállás érdekében.
Tehát tulajdonképpen mindegyiknek van előnye, hátránya. Testingnél még érdemes végiggondolni, hogy a stable-vel ellentétben itt természetesen nincs security update, viszont egy esetleges hiba esetén az upstream változásai ide érkeznek meg legkésőbb, tehát bugok szempontjából a testing a legrosszabb. Tehát ha a biztonság fontos, akkor ezt is érdemes meggondolni.
Különben pedig mindenki döntse el maga. Nekem - most - desktopon unstable, serveren stable van, és ez így nekem megfelel. Másnak meg más
-
Friczy
senior tag
Na, kicsit kutakodtam, mert engem is érdekelt, hogyan lehet megtalálni azokat a csomagokat, amelyek fent vannak a rendszeren, de már nem léteznek a hivatalos repositoryban (itt hivatalos alatt azt értem, ami tényleg benne van az /etc/apt/sources.list file-ban)
És megint igaz, hogy Debianon baromi sok minden készen van, csak meg kell találni
aptitude search ~o
És ez még az olyanokat is megtalálta, ami sose volt része a Debiannak, csak innen-onnan felkerült, de csomagból (pl. viber).
-
-
-
Friczy
senior tag
válasz
bambano
#6303
üzenetére
Jogos észrevétel, de forrásnak nem feltétlenül, elég a headers csomagnak.
Az pedig a függőségek miatt felkerül, mert a v4l2loopback-dkms függ a dkms-től, ott meg a Recommends: közt ott vannak a linux-headers-xxx csomagok. A recommends pedig alapból felkerül apt-getnél.
Csak arra kell figyelni, hogy a megfelelő -headers csomag kerüljön fel a lehetséges háromból.
Persze ha saját kernelt forgattál, az más.
Szerk: pontosítottam a függőségeket.
-
Friczy
senior tag
Nem volt még szerencsém hozzá, de mivel benne van a Debianban, ne tölts le külön source-okat.
Telepítsd csomagból.
v4l2loopback-dkms
v4l2loopback-source
v4l2loopback-utilsEzeket a csomagokat rakd fel Lehet, hogy ez már meg is oldja a problémádat. Ha nem, akkor keress a v4l2loopback-dkms csomagban valami README jellegű file-t, abban biztos lesz leírás, hogy mit kell vele tenni
-
Friczy
senior tag
Maga a driver mindegyikhez ugyanaz, az elképzelhető, hogy újabb chipeket nem kezel megfelelően. MIndenesetre a teszt kedvéért megnéztem a notebookomon ugyanezt (az első generációs I5), ott is teljesen jól kezeli az eltérő beállításokat. (ezen Arch fut).
Érdekes volt a notebookomon egyébként a Kali linux (ez egy Debian alapú, pentestre kihegyezett disztribúció), ha azt bootolom a notebookon úgy, hogy rajta van a külső monitor is, akkor nem indul el az X
(failed to set mode: invalid argument)Ebben az xserver-xorg-video-intel verziója 2:2.19.0-6, ez megegyezik a wheezyben lévővel, az asztali gépemen 2:2.21.15-2+b2 (sid).
Ebből simán következhet az, hogy a stabil Debianban régi az xorg drivere, és ez okoz gondot.
A packages.debian.org szerint az xserver-xorg-video-intel újabb verziója elérhető a wheezy-backports részben,
[link]lehet, hogy érdemes kipróbálni.
-
#6285
Friczy
senior tag
feketegergo
#6284
Friczy
senior tag
válasz
feketegergo
#6284
üzenetére
Nem valószínű, az enyém is processzorba integrált video, I5 (sandy bridge).
-
#6283
Friczy
senior tag
feketegergo
#6282
Friczy
senior tag
válasz
feketegergo
#6282
üzenetére
Debian sidet használok, de volt korábban Ubuntu és Arch is, problémám egyikkel sem volt. A Gnome3 megjelenése óta (illetve már a Gnome2-vel is hasonló volt) nincs méretezési problémám.
Én úgy gondolom, inkább a videokártya drivere lehet a gond. Nálam intel van, az opensource driverrel.
A 2 xserver sem megoldhatatlan dolog, de mivel nekem teljesen jól működik a kiterjesztett desktop, és ezzel kevesebb beállításbeli gond van, arról nincs tapasztalatom.
-
#6281
Friczy
senior tag
feketegergo
#6280
Friczy
senior tag
válasz
feketegergo
#6280
üzenetére
A két teljesen eltérő felbontást gond nélkül kezeli a rendszer. Nekem 19" az egyik monitorom (5:4-es képaránnyal), a másik pedig egy széles 22", a felbontások teljesen eltérőek, és minden jól működik a kiterjesztett desktoppal. Az alkalmazások többnyire azon a képernyőn nyílnak meg, ahol az egér van (egy-két alkalmazás pedig megjegyzi, hogy hol zárták be legutóbb. Ráadásul a gnome3 munkaterület-váltása csak az elsődleges képernyőn működik, így pl. a TV-t ki tudom tenni a második monitorra fullscreenben, közben pedig dolgozom az elsőn, munkaterület-váltással, mindennel.
-
Friczy
senior tag
válasz
Jester01
#6265
üzenetére
Jól megválasztott és őrzött root jelszó az, amit nem tudnak egynél (max. kettőnél) többen.
Nagyrészt igazad van, az általános sudo joggal vigyázni kell, nem szabad fűnek-fának kiadni, ha egy gépen túl sok felhasználónak van sudo joga, akkor szerepköröket kell kialakítani annak megfelelően, hogy miért kell a root jog.
-
Friczy
senior tag
válasz
Apollyon
#6261
üzenetére
Biztos lehet, xfce-vel nem tudom, én Gnome-ot használok, ott a network manager simán elintézi (nem csak Debianon, Arch alatt is). Természetesen ilyenkor nem kell, illetve nem is szabad kitölteni az /etc/network/interfaces file-t, mert az ott bekonfigurált eszközöket a network manager kihagyja.
-
Friczy
senior tag
válasz
Apollyon
#6259
üzenetére
Nem tudom elképzelni, hogy bármi is másként menne, mint mondjuk Ubuntunál, ahol helyből ez a megoldás van. Én már régebben (még Ubuntu használat előtt) is használtam a sudo-t, Ubuntunál ez volt a default, és azóta is, Debianon, Archon is első dolgom telepítés után megcsinálni. Összesen egy programmal találkoztam eddig, ami nem szerette ezt a megoldást (már nem emlékszem, pontosan mi volt az), ez viszont nem függött a disztribúciótól, épp Ubuntu alatt jelentkezett). Ez utóbbi problémát egy sudo su paranccsal meg lehetett oldani.
Ha több év alatt egyszer jelentkezett ilyen probléma, akkor talán mégsem akkora gond. Egy otthoni, egyfelhasználós rendszernél nincs nagy jelentősége, azonban ha többen használják a gépet, akkor már nagyon nem jó, ha a root jelszót többen is ismerik.
-
Friczy
senior tag
válasz
Apollyon
#6246
üzenetére
A boot process viszont már nem látszik, csak 1-2 infót ír ki max. Ezt hogy lehet visszaállítani? Én mindent akarok látni.
Megkeresed az /etc/default/grub file-t. Megnyitod rootként a kedvenc editoroddal. A file-ban megkeresed ezt a sort:
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
Kitörlöd a quiet szót (ha van benne más, azokat hagyd meg, meg az idézőjeleket is).
Rootként kiadod az update-grub parancsot.
Reboot.Ha nem hozná azt, amit szeretnél (kétlem), akkor a quiet szó helyett noquiet legyen.
-
#6249
Friczy
senior tag
honda 1993
#6221
Friczy
senior tag
válasz
honda 1993
#6221
üzenetére
Semmi gáz nincs ebben, mások az elvárásaid, mint amit a rendszer ajánl. Ennyi. Innentől kezdve két választásod van: a) igazodsz a rendszer elvárásaihoz; b) keresel olyan rendszert, amely igazodik a te elvásásaidhoz.
-
#6248
Friczy
senior tag
honda 1993
#6200
Friczy
senior tag
válasz
honda 1993
#6200
üzenetére
https://wiki.debian.org/ATIProprietary
-
Friczy
senior tag
Számomra a Debian jobban kézreáll, mint az Arch (azzal együtt, hogy az Arch nagyon szimpatikus disztribúció).
Teljesen más a két rendszer alapfilozófiája, az Arch igyekszik minél kevesebbet változtatni egy-egy programon, míg a Debian sokkal többet alakít át rajta, valamint sok esetben az alapértelmezett konfiguráció is használhatóbb. Ebből a szempontból mindenképpen könnyebb a Debian használata. További előny, hogy a csomagválasztéka sokkal nagyobb. Nagyon sok minden, ami Archnál csak az AUR-ből érhető el (az ennek megfelelő minimális támogatással, és a rendszeres újraforgatásos upgrade-del együtt), a Debianban része a disztribúciónak, simán felrakod, bekonfigurálod, és készen is vagy.
Hátrány lehet (főleg az Archhoz szokott felhasználóknak), hogy a Debian nem rolling release, ha kijön egy stabil kiadás, abba a következő stabil kiadásig nem kerülnek bele új verziók (egy-két kivétel van - pl. Iceweasel, ami tulajdonképpen a Firefox - ez túl gyorsan változik ahhoz, hogy évekig ugyanaz a verzió maradjon). Tehát a Debian hamar elavul, ez inkább desktopon hátrány, serveren viszont előny a stabilitás.
A csomagok maintainerei átírják a kódot (pontosabbban patchet készítenek hozzá), a patcheket természetesen visszaküldik az upstream felé is, aztán azt vagy elfogadják, vagy nem.
Illetve mivel alapelv, hogy csomagverzió a stabil kiadáson belül nem változik, az időközben megjelent biztonsági hibákat visszaportolják a régebbi programokba (amennyiben azok érintettek a hiba szempontjából).
-
Friczy
senior tag
válasz
bambano
#6192
üzenetére
Nem egészen.
A Jessie befagyasztása azt jelenti, hogy ami eddig nem került bele, már nem is fog. Viszont ha van olyan csomag, ami release-critical hibát tartalmaz, és nem tudják kijavítani a kiadásig, akkor az a csomag még kikerülhet a Jessie-ből.
Lásd:
https://release.debian.org/jessie/freeze_policy.html
Removing packages from testing during the freeze
During the freeze, we will continue to automatically remove non-key packages with RC bugs in testing and their reverse dependencies. As usual, the auto-removal system will send a notice before this happens. Please note that it is not enough for the bug to be fixed in unstable. The fix (in unstable or testing-proposed-updates) must be done in such a way that the fixed package can be unblocked and allowed to migrate to testing, based on the rules listed above.
YES, this means that your package will be removed if it (Pre-)Depends or Build-Depends on an RC buggy non-key package. And, YES, this removal occurs even if your package has no RC bugs. In other words, please ensure that your packages and their (non-key package) dependencies are RC bug free. If you can remove the (Build-)Depends on an RC buggy package in a non-invasive way, you can ask for pre-approval to make this change to avoid auto-removal of your package.
-
Friczy
senior tag
Ha a testing disztribúciót a nevével (jessie) írod be a sources.listbe, akkor gyakorlatilag amint kijön a jessie stable disztribúcióként, neked is az lesz. Tehát az átmenet észrevehetetlen.
Ugyanakkor a Jessie jelenleg nincs olyan állapotban, hogy problémamentesen használható legyen, időről időre bele lehet futni kellemetlenségekbe. Ezek nem túl nagyok, ha értesz hozzá, de ha nem, és/vagy nem szeretsz sokat reszelni a rendszeren, akkor jelenleg nem javaslom a testinget.
A jelenleg testingben lévő csomagok nagy valószínűséggel bekerülnek a stabilba megjelenéskor, persze előfordul hogy valamit mégsem sikerül bevinni, de ennek a jelenlegi fázisban már kicsi az esélye.
-
Friczy
senior tag
válasz
csicsaaa
#6149
üzenetére
El kell döntened, hogy NATot vagy proxyt akarsz csinálni, illetve esetleg vegyesen. Proxy esetén nem kell NAT beállítás, cserébe csak néhány szolgáltatást tudsz használni a gép mögötti hálón (http, https, ftp - over http).
Proxy esetén tulajdonképpen nem kell NAT, mert ott két külön kapcsolat van: a klienstől a proxyig egy, és a proxytól a serverig a másik. Ez utóbbit már a proxy nyitja saját címével, tehát NAT nem kell.
Persze na nem csak azt a forgalmat akarod kiengedni a gatewayen, amit a proxy tud, akkor szükséged lesz NAT-ra is, viszont ez esetben ez a proxytól független.
Egy biztos, ha mind meg akarod csinálni, amit leírtál, az kezdőként nem lesz egyszerű.
-
Friczy
senior tag
5.0 már nem is fogja, ahhoz már új csomag, frissítés nem várható.
6.0-ra frissítés módja részletesen le van írva a Debian oldalán:
https://www.debian.org/releases/squeeze/releasenotesItt a megfelelő architektúrát kiválasztva keresd meg a '4. Upgrades from Debian 5.0 (lenny)' fejezetet.
-
-
Friczy
senior tag
válasz
Apollyon
#6060
üzenetére
Az egyértelmű, hogy a non-free-t nem lehet a free-be áttenni, mert a licence olyan. A Debian polcy szerint a main és contrib nem tartalmazhat olyan programot amely licence szerint nem teljesen szabad felhasználás. Ez pl. nagyon megkönnyíti azok életét, akik kereskedelmi célra használják a Debiant, ha nem kapcsolják be a non-free-t, biztos nem lesz gondjuk a licence-ekkel.
Na most megtehetné a Debian, hogy egyáltalán nem teszi be a rar-t a free részbe, ezzel kicseszve azokkal, akik nem akarják használni a non-free-t, szerintem ők többen vannak, mint akiknek hozzád hasonlóan problémát okoz, hogy két rar van.
Véleményem szerint ez a szigorú licence-kezelés - még ha időnként furcsa eredményeket is hoz - a Debian egyik roppant vonzó tulajdonsága. Az ember ragaszkodjon a (világosan lefektetett) elveihez.
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest