- Apple iPhone 15 Pro Max - Attack on Titan
- Elnéztük a mai dátumot
- Vodafone mobilszolgáltatások
- Huawei P30 Pro - teletalálat
- MIUI / HyperOS topik
- Tényleg jobban fogyaszt a Peugeot, az Opel és a Citroen?
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Yettel topik
- Realme GT Master Edition - mestermunka
- Samsung Galaxy S22 Ultra - na, kinél van toll?
Hirdetés
-
Elnéztük a mai dátumot
ma Nem holnap, ma mutatkozik, pontosabban mutatkozott be a HTC U24 Pro, csak elnéztük (mármint én) egy nappal a dátumot.
-
Meggyőző arcjátékkal reagál a kínai humanoid robot
it A kínai Ex-Robots hiperrealisztikus humanoid robotjai meggyőző arckifejezésekkel dolgoznak, a pszichoterápiában és az egészségügyben is bevethetik ezeket.
-
Már elstartolt az AMD nyári játékpromóciója
ph Ezúttal a Navi 32 XL és XT GPU-val szerelt videokártyákhoz kaphatunk két, tavaly megjelent programot, amiket egy négyes listából válogathatunk ki.
-
Mobilarena
Debian GNU/Linux
Új hozzászólás Aktív témák
-
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.
-
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 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
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 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
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 honda 1993 #6200 üzenetére
https://wiki.debian.org/ATIProprietary
-
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.
-
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.
-
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 #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 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 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 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.
-
Friczy
senior tag
válasz feketegergo #6284 üzenetére
Nem valószínű, az enyém is processzorba integrált video, I5 (sandy bridge).
-
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.
-
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
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.
[ Szerkesztve ]
-
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
É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
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
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 #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 #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 #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 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 #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.
-
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 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 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 beloadjoker #6504 üzenetére
libnl-genl-3-dev csomag kellene neked.
-
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.
-
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
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.
Új hozzászólás Aktív témák
- NBA és kosárlabda topic
- Tenisz topic
- kraftxld: Diáklaptop - Dell Latitude 3140 - Királyunk ajándéka
- Apple iPhone 15 Pro Max - Attack on Titan
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- E-roller topik
- Gaming notebook topik
- Elnéztük a mai dátumot
- Kerékpárosok, bringások ide!
- Diablo IV
- További aktív témák...
- Adobe Előfizetések - Adobe Creative Cloud All Apps, Photography Plan - 12 Hónap
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Game Pass Ultimate előfizetések 1 - 25 hónapig azonnali kézbesítéssel a LEGOLCSÓBBAN!
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."
- Adobe Creative Cloud - 2024. 04. 05 - 2025. 04. 05-ig