Hirdetés

  2. Fórumok
  3. OS, alkalmazások
  4. Linux haladóknak
  5. (kiemelt téma)
Legfrissebb anyagok
Mobilarena témák
PROHARDVER! témák
IT café témák
GAMEPOD témák
  • Téma összefoglaló
    Utoljára frissítve: 2013-09-30 15:51

    Mobilarena

    Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.

Új hozzászólás Aktív témák

  • #34670 urandom0 őstag sh4d0w #34668
    Új Válasz #34670
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    urandom0

    őstag

    LOGOUT blog

    válasz sh4d0w #34668 üzenetére

    Pl. azert akarhatsz logokat olvasni 10 ev mulva, mert torveny irja elo.

    De ez nem 10 év múlva derül, hogy hoppá, vissza kéne olvasni, hogy mi volt 2015 március 18-n, hanem ezt tudja az ember. Ha pedig tudja, akkor nyilván fel is készül rá, átküldi log szerverre, amit aztán archivál.

    lehetne, hogy ne huzza fel a halozatot, ha valamiert nem sikerul betolteni a tuzfal konfigot?

    Biztos lehet, kérdés, hogy hogy van megoldva a tűzfal konfig betöltése. Ha az egy systemd service, és hibára fut, akkor meg lehet adni a network service-nek is, hogy ne induljon el.

    Lehetne, hogy a screenben inditott tavoli processeket ne loje le?

    Én tmuxot használok, de sosem lőtte még le a systemd egyetlen processzemet sem. Amikor mégis ilyesmi történt, az az OOM Killer okozta, de hát annak pont az a dolga, hogy lelőjje a túl sokat zabáló processzt.

    Lehetne, hogy az alaplap EFI ertekei ne valtozokba toltodjenek be, hanem konstansokba?

    Itt nem tudom, mire gondolsz, én a dmidecode és a biosdecode programokat ismerem, de azoknak semmi köze a systemdhez.

Új hozzászólás Aktív témák