-
Fototrend
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
-
#31601
lionhearted
őstag
bambano
#31600
válasz
bambano
#31600
üzenetére
Azt hiszem ez valóban egy hit kérdés, illetve talán az, hogy ki milyen RAM hibával találkozott eddig.
Amivel én találkoztam, az olyan volt, hogy nagyon rossz, szóval 1 menetből ez kiderült. Ami ezenfelül az én hitem, hogy a nehezebben kiszűrhető hiba kis eséllyel fog pont addig kiesni, amíg "megunom"... de mindezek ellenére egy estét szoktam futtatni, mert általában úgy is estére rakom össze a gépeket.
-
#31254
lionhearted
őstag
Speeedfire
#31253
válasz
Speeedfire
#31253
üzenetére
Vedd fel külön, és időzítsd rá.
-
#31194
lionhearted
őstag
ivana
#31193
-
#31177
lionhearted
őstag
Lenry
#31176
Ez részben van így. Nyilván van egy default, és tudja azt is, hogy mik a privát tartományok, és keres magának.
Ami itt a trükk, hogy ha docker "networkot" hozol létre, az többnyire egy bridge (ez a default linuxon). A másik meg az a trükk, hogy előfodul, hogy a default (docker0) bridge túl nagyot harap, és 172.17.0.0/12 lesz belőle, ami után már a 192.168-ból fog választani (szerinte) szabadot. Nyilvánvalóan, amire nincs "lába" a hosztnak, arról nem tudja, hogy foglalt.default-address-poolsez a konfiguráció segít állítani, hogy mit foglaljon, és mekkorákat...
A default a 192.168/16os címeken az általad is látott /20 -as "szeletek". -
#31129
lionhearted
őstag
regener
#31127
válasz
regener
#31127
üzenetére
Úgy értem, hogy ezzel a 80-as pinggel, ami alaphangon 160ms latency már ilyen 3Mbps korlátoztad magad default beállításokkal (TCP window).
Ha ezt megfejeli időszakosan valami hálózati ingadozás, eldobált csomag, akármi, akkor reccs. Nem általános ping az érdekes, hanem az éppen akkori, amikor gond van. Lehet ma már nincs semmi, még nem írtad.
Adott esetben érdemes lehet más, erre a funkcióra szakosodott protokollt használni.
-
#31126
lionhearted
őstag
regener
#31125
-
#31095
lionhearted
őstag
CPT.Pirk
#31093
-
#31080
lionhearted
őstag
CPT.Pirk
#31077
válasz
CPT.Pirk
#31077
üzenetére
Felhőben VPN szerver, arra csatlakozik mindenki, és kész a kapcsolat.
Mikrotiken pl. van arra lehetőség, hogy a mobilnet forgalmát megjelöld, így az ott megy vissza, ahonnan jött, de ehhez mondjuk fix IP GW kell, hogy be tudd állítani. Ez sima iptables mellett, érzésre nincs benne.
-
#31060
lionhearted
őstag
bambano
#31058
-
#31040
lionhearted
őstag
bambano
#31035
válasz
bambano
#31035
üzenetére
"játék nem lesz, fejlesztés meg hibátlan videó és tecső lejátszás a feladat két displayporton meg egy hdmi-n"
"rx 570 van, ennél kellene egy kicsit jobb"
Magam részéről úgy vélem, hogy az AMD driver most nagyon jó linux alatt, szóval a vonalon maradva nem sok jobb értékű kártya van, mint az rx 570.
Tecsőt nem igazán gyorsítja semmi, de ha az megoldott, akkor esetleg az 5500XT, amin van VP9 decoder is, és kevesebbet eszik default. És egy hangyányit jobban is teljesít. -
#31003
lionhearted
őstag
kovaax
#31001
-
#31000
lionhearted
őstag
I02S3F
#30999
-
#30998
lionhearted
őstag
bambano
#30990
-
#30996
lionhearted
őstag
I02S3F
#30963
válasz
I02S3F
#30963
üzenetére
Egyrészt van az 10 év is, mivel ott az Ubuntu ESM az LTSekre (sőt, ingyen 3 gépre otthoni felhasználásra).
Másrészt, az új software is rétegigény akkor. Lehet, hogy aki Desktopon(!) szeretné ugyanazt az OS-t látni, annak ugyanaz a szoftver is kellhet.
Szerver fronton meg pláne... nem kell mozgó célpontra fejleszteni... -
#30829
lionhearted
őstag
Dißnäëß
#30828
válasz
Dißnäëß
#30828
üzenetére
"A Seagate-eken 100 lehet ezek száma (legalábbis HDS szerint, de lehet rosszul értelmeztem az oszlopok leíróit), a Purple-ön 200."
Ez normalizált érték tresholdja, amit a gyártó algoritmusa alapján számol raw-ból... szóval többnyire értelmetlen összevetni, almát körtével. -
#30458
lionhearted
őstag
F34R
#30438
-
#30351
lionhearted
őstag
Dißnäëß
#30349
-
#30342
lionhearted
őstag
vzozo
#30341
Röviden: nem írja ki, csak megjelöli szemétként, amit a GC egyszer csak törölni fog.
Hosszan: az fstrim megkérdezi a fájlrendszert, hogy melyik fájlrendszer szektor üres, majd a szektor - LBA táblából átadja az eszköznek azon LBA tereket, amik valójában már üresek/szemetek. Az eszköz az LBA - belső címzés alapján bejelöli azokat a pageeket, amik szemetet tartalmaznak. Legközelebb, mikor:
* vagy az egész block (több page) invalid lesz és jön rá egy GC törlés
* vagy újrafelhasználva írni akar a pagere, akkor ugye törölni kell a blockot, majd vagy ott, vagy máshol (dinamikus WearLeveling dönti el) kiírja, akkor már nem viszi magával az invalid paget, helyére új kerülhet
* vagy a statikus WearLeveling úgy dönt, hogy túl sokáig állt ott az adat és áthelyezi, akkor kivágja az SSD a fenébe ezeket a pageeket, nem viszi őket tovább. -
#30340
lionhearted
őstag
vzozo
#30339
-
#30308
lionhearted
őstag
Lenry
#30306
-
#30304
lionhearted
őstag
kovaax
#30301
válasz
kovaax
#30301
üzenetére
Nem tértek, és jobb is így. Az említett docker is igen parádésan viselkedik mondjuk egy CentOS8 firewalld+nftables környezetben....
A lényeg amúgy is az, hogy ezeket már többnyire backendnek tekintik, ez elé teszik az ufw/firewalld/egyéb szolgáltatásokat.
Ezért szomorú, hogy az erre buzdító hozzászólásomat gyakorlatilag mindenki ignorálta. A probléma, és néhány megoldása: [link]
-
#30295
lionhearted
őstag
fecus
#30291
-
#30289
lionhearted
őstag
fecus
#30288
-
#30261
lionhearted
őstag
Fecogame
#30253
-
#30204
lionhearted
őstag
Krystal_s
#30202
válasz
Krystal_s
#30202
üzenetére
Az ugrálás egyébként működésben zavaró? Maga a tény, hogy energiatakarékossági okokból vált, okoz galibát akkor, amikor full kraft kell? Vagy csak kozmetikai hiba.
Adott esetben forceolhatod a másik oldalról is a dolgot, ha az AP-n only-n módra kapcsolsz.A 270 vs 300 témában pedig annyi van, hogy az egyik short GI-n a max, a másik a nem-short-GIn (long?).
-
#29810
lionhearted
őstag
growler
#29809
válasz
growler
#29809
üzenetére
Ez majdnem jogos, viszont vannak erre programok, amik elsősorban fájl header alapján raw adatokból is próbál visszanyerni információt. De nem folytatólagos, vagy újramappelt adatokat, vagy ismeretlen binárisokat nem hoz vissza. Illetve könyvtár struktúra és fájlnevek se lesznek.
Röviden, fájlrendszer nélküli, raw adathalmazt nagy szívás helyrehozni. A dd pedig esélyesen legyalulta az ext4 ide vonatkozó részeit.
-
#29526
lionhearted
őstag
vargalex
#29514
-
#24010
lionhearted
őstag
PumpkinSeed
#24009
válasz
PumpkinSeed
#24009
üzenetére
Én is sokáig ezt hittem, amíg meg nem csináltam az elsőt.
Vagy amikor kézzel át kellett hegesztenem egy deb függőséget... eleinte nehéznek tűnik, de nem hiszem, hogy van olyan feladat ezzel kapcsolatosan, amire még ne gondolt volna senki. -
#24003
lionhearted
őstag
PumpkinSeed
#24002
válasz
PumpkinSeed
#24002
üzenetére
A gitet és a buildet összekötve lehetőség van commitonként buildelni.
Ha megvan a bináris, kell rá egy targéza (vagy txz), meg a git commit msg alapján létre kell hozni egy már előre létrehozott séma alapján az rpm speckót az aktuális changeloggal (= commit msg), plusz verzió/buildszám növeléssel. Az rpmbuild ezután már simaliba. A jó hír, hogy szerintem ezt a Jenkins tudhatja.
A másik oldalra viszont nem tudom hogyan lehet ráerőltetni pushhal az updatet, csak pull módszereket ismerek. -
#23992
lionhearted
őstag
gt7100
#23976
válasz
gt7100
#23976
üzenetére
Nekem is van egy J1800 és J1900 "szerverem" is. A cryptsetup benchmark ad egy becslést, hogy milyen sebességgel bírják a titkosítást. Ilyen mértékben nálam nem okoznak gondot. A különbség szerintem nem az ssh-ban keresendő hanem a transfer schemaban. Az scp lineárisan tunkolja át az adatot, az rsync sokkal komolyabb deltákban és diffekben gondolkozik. Nem tartom kizártnak, hogy összességében jobban optimalizált az ssh kapcsolati sajátosságokra. Egyébként helyi hálón gondolom nem feltétlen akarsz mindig titkosítani, én úgy tudom, hogy rsync daemon titkosítás nélkül fut.
-
#23934
lionhearted
őstag
sonar
#23933
Lehet őket keverni, semmi baja nem lesz. Csak nehézkesebb a köteteket kezelni.
De gondolom azért van így, mert az OS diszkeken több partíciót is létre akart hozni (vagy ennek könnyebb esélyét megadni), míg az adatlemezt egyben akarta tartani, így felesleges volt rá egy újabb réteget húzni, ha úgy is csak egyetlen partíció lesz. -
#23873
lionhearted
őstag
Vasinger!
#23872
-
#23871
lionhearted
őstag
Vasinger!
#23870
-
#23817
lionhearted
őstag
bencze
#23816
-
#23794
lionhearted
őstag
_Dumber_
#23793
válasz
_Dumber_
#23793
üzenetére
Alapból ott van elszúrva az egész, hogy a class neve és a fájl neve egyezni illik.
Egyébként beírtam ugyanezt a kódot, és compile után ment is. De!
[build_settings]
# %f will be replaced by the complete filename
# %e will be replaced by the filename without extension
# (use only one of it at one time)
compiler=javac "%f"
run_cmd=java "%e"
Itt is látható, hogy amíg te alul a java class nevével operálsz, addig ő a fájlnévvel. -
#23778
lionhearted
őstag
kovaax
#23777
-
#23707
lionhearted
őstag
Mr Dini
#23706
-
#23532
lionhearted
őstag
emvy
#23531
-
#23525
lionhearted
őstag
emvy
#23523
Kicsivel a kövi LTS után.
@ubyegon2: Én a haladó topikot úgy értelmezem, hogy az alap, kiinduló pontokat leírva, értelmezéssel együtt megkapja, akkor ő már meg tudja oldani, mert haladó. És nem kell azzal vesződnöm, hogy step-by-step magyarítok egy leírást, kiegészítve olyan elemekkel, hogy hol van a terminál. Ezenfelül vannak a személyes tapasztalatokból gyűjtött információk (legyen az figyelmeztetés, vagy rövidebb út, stb.), melyből a témában nekem nincs.
Bevallom, sosem fogott meg a téma, bízom benne, hogy az alaplapom megoldja a feladatot. Bár szegény CPU hűtő nagyon gyorsan pörög szerintem, de így sincs hangja. -
#23509
lionhearted
őstag
GoZoL
#23506
-
#23500
lionhearted
őstag
bambano
#23498
válasz
bambano
#23498
üzenetére
Ohh, akkor ennek alászaladtam. Mondjuk másodszor, jobban átgondolva jó nagy overhead lenne a network és a központi elosztó szerver miatt...
Azt viszont nem mondanám, hogy nem érik el egymás memóriáit, mivel ezeket a VMeket szükség esetén realtime és runtime dobálja, észrevehetetlenül. -
#23496
lionhearted
őstag
bambano
#23492
válasz
bambano
#23492
üzenetére
Amit linkelt, ott látható, hogy a 24 magos rendszeren elég jó eredménnyel zárt, azaz kizárt, hogy soros programról lenne szó.
Nem 32 cloud gépre teszem fel, hanem 32 gépen átívelő virtual gépre. Az erőforráskezelést a hostgépeket vezérlő oldja meg. Ha a Kuglitól rendelek egy 32 virtuális magos gépet, akkor egyetlen egy gépem lesz, 32 szállal. Ha ezen futtatom az egyébként párhuzamosított programot, akkor az biza mind a 32 szálon futni fog, még ha alatta valójában 32 különböző gép is van, vagy ha csak 2, teljesen mindegy. -
#23491
lionhearted
őstag
bambano
#23490
válasz
bambano
#23490
üzenetére
"a cloud erre természetesen nem jó, csak akkor, ha a szoftver képes cloudon működni. olyan nincs, hogy sok gépet cloudba kapcsolsz és egy program az összes proci lóerőt kihasználja, ha nincs rá felkészítve." Ezt kifejtenéd? Akkor a sok cloud cumpute hogyan működik? Nem gondolnám, hogy egy virtuális gépen én már le tudnám kezelni a cloud akármilyét.
-
#23486
lionhearted
őstag
bucihost
#23485
válasz
bucihost
#23485
üzenetére
Engem azért érdekel, hogy ez ilyen hobbi, néhányan összeülnek típusú elgondolás, vagy ezzel komolyan akarsz kezdeni valamit.
Valószínű, hogy nem írsz új sakkmotort, tehát amit az és a futtatókörnyezete tud, azt tudja, és kész. Innentől kezdve csak azzal tudsz dolgozni, hogy egy cloudban menedzselt gépparkkal virtualizálsz egy gépet, amin ez a szoftver futni fog, így megkapja közel az összes erőforrást az összes géptől. Az erőforrások szétosztása a host OS feladata, tehát azzal a programnak nem kell foglalkozni.
Otthoni hobbi célra az Ubuntu+OpenStack páros lehet nyerő, 10 gépig ingyenes. Már egyszer linkeltem, de újra [link]
Ha komolyan érdekel, de nem akarsz/tudsz vele foglalkozni, akkor ezt megcsinálja neked a Google/Amazon/Azure is, hogy csak a nagyokat mondjam... gépidőt megveszed, és akkora gépet kapsz, amekkorát akarsz. -
#23480
lionhearted
őstag
bucihost
#23478
válasz
bucihost
#23478
üzenetére
"Cluster" van linux alatt, de ennek ugye több szintje is van. Megírhatod a programot úgy, hogy kommunikáljon egymással, megírhatod olyan nyelven, aminek a futtató környezete képes szétosztani a feladatot, illetve használhatod a mostanság menő kláudot, amikor az OS-t a háttérben "összekötik", és neked egy virtuális gépen egy szuperszámítógéped van. Az utolsóra egy példa: [link]
-
#23477
lionhearted
őstag
GoZoL
#23467
Sajnos ebben nem tudok most segíteni, nem ülök előtte és nincs manpage (nincs CLI/dokumentáció, ami könnyítene). Ha nem találod meg a beállításaiban, vagy nincs ilyen lehetőség a ~/.remmina alatt, akkor passz.
Alternatíva: [link]
vagy xfreerdp -d [domain] -u [user name] -p [password] -f [ip]Auto indítás LXDE alatt: lxsession-edit
Vagy kézzel .desktop fájl a /home/username/.config/autostart alá.Remélem segítettem.
-
#23464
lionhearted
őstag
GoZoL
#23463
Ahogy korábban javasolták, legegyszerűbben a minimal telepítővel jársz. [link]
Ennek a lényege, hogy minden lényeges csomagot a netről, a legfrissebb verzióval tölt le. A telepítője nem pilótavizsgás, ncurse alapú, végigvezet minden lényeges ponton...a végefele lehetőség van a főbb DM telepítésére, ekkor kell jól választani: [link] Ez a Tasksel, innen kell neked szerintem a Lubuntu minimal. Aztán, ha elindul, akkor jöhet az RDP kliens. -
#23398
lionhearted
őstag
croixleur
#23397
válasz
croixleur
#23397
üzenetére
Igen, akárhány kulcsot bele lehet tenni. Entert nyomsz közé.
rsync lazán fog menni SSH-n keresztül, ezzel nem lesz gond.
Debianban nem hiszem, hogy lenne nem szükséges daemon vagy port. Portokat iptablesben, vagy kezdőként ufw-ben lehet kezelni. fail2ban ajánlott a további törések hátráltatásában. Valamint a default 22-es portról egy másikra áthelyezni az SSH-t. -
#23391
lionhearted
őstag
Valaki találkozott gnome-panel (3.16) memory leakkel?
Ha nyitok egy ablakot felszalad rá 2MB, és soha nem engedi el.
-
#23387
lionhearted
őstag
Atlantisz48
#23380
válasz
Atlantisz48
#23380
üzenetére
Van ilyen célú speciális linux: KALI
-
#23370
lionhearted
őstag
brickm
#23368
-
#23346
lionhearted
őstag
Fecogame
#23345
-
#23343
lionhearted
őstag
bambano
#23342
-
#22678
lionhearted
őstag
totron
#22664
-
#22641
lionhearted
őstag
Nestor16
#22640
-
#22639
lionhearted
őstag
Nestor16
#22638
válasz
Nestor16
#22638
üzenetére
Megint először letörlöd a drivert, majd újrarakod. Felesleges.
sudo apt-get install fglrxA Szoftverközpont meg már csak ilyen. Általában a kis progiknál működik, de komolyabb használatra valahogy sosem sikerül. Egy ideje mintha már nem is fejlesztenék.
És bocsánat a modortalanságomért. Üdv köztünk. A többi kezdő topikot is szoktam pl én is olvasni, de az Ubuntu-sat is.@bambano: Évek óta még csak plusz multiarch lib sem kell hozzá.
-
#22635
lionhearted
őstag
Nestor16
#22634
-
#22615
lionhearted
őstag
Valakinek van tapasztalata az ext4 belső titkosításával (kernel 4.1+)?
Érdekelne, hogyan lehetne megoldani okosan egy home PC-n, hogy a login auth feloldja a saját homeját mindenkinek. Az arch wiki meglehetősen szűkszavú, és session keyringben gondolkozik, nekem user szinten kéne... -
#22566
lionhearted
őstag
growler
#22565
-
#22564
lionhearted
őstag
bucihost
#22563
-
#22460
lionhearted
őstag
bucihost
#22458
-
#22438
lionhearted
őstag
Nkboy
#22435
-
#22395
lionhearted
őstag
MineFox54
#22384
-
#22205
lionhearted
őstag
Bici
#22204
-
#22202
lionhearted
őstag
Bici
#22201
-
#22200
lionhearted
őstag
Bici
#22199
-
#22194
lionhearted
őstag
KrAt
#22190
-
#22157
lionhearted
őstag
#40935168
#22155
-
#22153
lionhearted
őstag
#40935168
#22151
-
#22150
lionhearted
őstag
subset
#22149
válasz
subset
#22149
üzenetére
A vezérlő halála mondjuk tényleg az a bizonyos roller. Amúgy egy rendes vezérlő tud dobni a performancián (na nem az ilyen összekukázott, hanem a 100k+, RAID5-6 stb esetén.)
Ha van rendes áramellátás, és van bőven kraft a Xeon szerverben, akkor valóban kevés ok van a külön vezérlőhöz. -
#22148
lionhearted
őstag
#40935168
#22147
-
#22146
lionhearted
őstag
#40935168
#22145
-
#22117
lionhearted
őstag
McSzaby
#22116
-
#22083
lionhearted
őstag
janos666
#22081
-
#22022
lionhearted
őstag
Zoli133
#22021
-
#21834
lionhearted
őstag
bambano
#21832
-
#21831
lionhearted
őstag
bambano
#21830
-
#21796
lionhearted
őstag
buherton
#21785
-
#21787
lionhearted
őstag
PumpkinSeed
#21786
válasz
PumpkinSeed
#21786
üzenetére
Ne használj NTFSt, de főleg ne torrentezésre linux alatt. Sajnos az így terhel. Ott a jó öreg ext4, minden probléma megoldója ez ügyben.
-
#21177
lionhearted
őstag
hcl
#21174
-
#21173
lionhearted
őstag
hcl
#21172
-
#21171
lionhearted
őstag
hcl
#21170
-
#21169
lionhearted
őstag
hcl
#21168
-
#21074
lionhearted
őstag
emvy
#21070
-
#21016
lionhearted
őstag
McSzaby
#21015
-
#21003
lionhearted
őstag
Speeedfire
#21002
válasz
Speeedfire
#21002
üzenetére
ssh-copy-id
-
#20879
lionhearted
őstag
Zoli133
#20873
-
#20848
lionhearted
őstag
hcl
#20847
-
#20666
lionhearted
őstag
N0zer0
#20657
válasz
N0zer0
#20657
üzenetére
Nem tudom, hogy a kapcsolatok / kézfogások akármik száma hogy befolyásolja az adatforgalmat, de mindegy, te tudod. Statisztika van benne, összes mért forgalomra (meg sessionre is, persze), meg még 1-2 apróságra.
Jobb cache kezelés alatt azt értem, hogy az uTorrent (amellett, hogy negyvenmillió fajta beállítást mutatnak a neten vérpistiknek) általában kiveszi az oprendszer kezéből az irányítást. Nem mintha winen amúgy tökéletes lenne, de ezen essünk túl. Ellentétben qBiten max az írási cachet tudod beállítani (azt hiszem 128 vagy 256 a max), és ennyi, a többit majd az oprendszer elvégzi. Nem akar azonnal kiírni semmit, nem a program szabja meg, hogy akkor én most csak azért is kiírom, hanem amikor az oprendszer jónak látja, és a diszk is épp olyan állapotban van, hogy kiírható a tartalom. Érdekes mód, qBittel vagy Delugeval sosem volt ilyen Lemez terhelt felirat / probléma, amiből azért van pár poszt uTorrent témában. Egyszóval, sem a legtöbb beállítási útmutató szerintem nem helyes, sem a default. Mindamellett, hogy win < linux RAM és (disk)cache kezelés terén is.
uTorrent RSS arra jó, hogy sorozatokat szedj. És kész. qBithez teljes regex a kezedben van, nem akarja ő jobban tudni. uTorrentnél van * meg ?... Persze, értem én, hogy RSS általában amúgy is sorozatokra van, de nem minden helyzetben. Ebben a témában talán a Deluge az első, címkékkel, címkékre külön szabályokkal, és még hasonló szépségek.
Meg a Deluge tud szerver-kliensként futni, sokkal élvezetesebb, hogy nem webuin kell elérni, ha másik gépen fut. -
#20654
lionhearted
őstag
N0zer0
#20652
válasz
N0zer0
#20652
üzenetére
qBit ebből ezeket tudja: fájl prior, statisztika (alltime fel/le, de a hónapos staton kívűl a többinek értelmét sem látom), kézi trekifrissítés, várakozási sor, torrentek közti keresés, skip hash, superseed, DHT használata (ennek amúgy sincs értelme, DHT mindig csak bizonyosnál, vagy egyiknél sem lehet, mert a privát alapból tiltja, ami meg nem privát, ott meg jó a DHT).
Amit tud, és az uTorrent meg nem: nem bloatware, mérföldekkel jobb cache kezelés, jobb RSS, https webui, miegymás.
-
#20604
lionhearted
őstag
Buci21
#20603
válasz
Buci21
#20603
üzenetére
Hazaértem, tudok kicsit többet írni.
Logok áthelyezése, és /tmp ram-ba (tmpfs) áthelyezése: (nem találtam meg a jó kis leírást, így magamra hagyatkozom)
root shellben:
serivce rsyslog stop
rm -r /var/log/
nano /etc/fstabA fájl végére beszúrod ezt:
tmpfs /var/log tmpfs defaults,noatime,mode=1777 0 0
És ha már ott jársz, akkor a root partícióra illeszd be szintén a noatime kapcsolót. A végén mindig legyen üres sor!
Ctrl+x,ENTER,Yes(/Igen)
mount -a
service rsyslog start
Ezzel a logfájlok a RAM-ba kerülnek, sok kis írástól kímélve meg a pendrive-ot. Cserébe nincsenek reboot után logok. Meggondoltam magam a /tmp-et illetően, szerintem azt ne oda tedd, nem vagyok benne biztos, hogy ahhoz elég a 4gb ram (a felhasználási móddal együtt nézve), maga a /tmp lényege, hogy a nagyadatokat, amik általában túl nagyok ahhoz, hogy a memóriában tartsuk őket, itt lehessen fájlba tárolni. Ennél nagyobb hiba, pedig sok helyen olvasni, hogy a /var/tmp is RAMba kerüljön, hiszen ide azok a fájlok kerülnek, amiket újraindítás után is meg kell tartani. Ez RAMban aligha lenne lehetséges...Swappiness-t szintén root shellben az alábbi módon lehet állítani:
nano etc/sysctl.conf
vm.swappiness = 1
És megint ctrl+x,enter,y(es)
Ezáltal a swappolás is csökkenni fog, csak akkor nyúl hozzá, ha már tele a ram.Maga a swap fájl létrehozása pedig, szintén root shellben:
fallocate -l 1g /mnt/swapfile
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile
nano /etc/fstabÚj sorba
/mnt/swapfile none swap sw 0 0
Természetesen, most is legyen üres sor a végén, ctrl+x,enter,y.Sambára ötlet: Tekintve, hogy privát könyvtárakat szeretnél, ez egyben azt is jelenti, hogy létező felhasználokat kell gyártani, user/pass-szal. Én úgy oldanám meg, hogy miután ez kész, mindenkinek csinálnék névreszóló privátmappákat, abban lenne mindenki samba share belépéskor, majd egy egyszerű symlink a közös mappára (Persze csak ha nem megyünk el a chroot irányában, akkor mount bindig fog kelleni), aminek a tulaja lehet pl a te felhasználód, a groupja pedig egy új közös group, amibe az összes usert bele kell rakni
useradd -G UJ_GROUP_NEVE usernameEnnél egy picit elegánsabb megoldás, ha a közös mappát külön samba share-ként kezeled, amire több ember kap használati jogot, és akkor 2 hálózati eszközt kell majd felcsatolni.
Ami mindkettőre igaz, hogy a különböző usereknek különböző samba share kell, ezt valahogy így kell az /etc/smb.conf:
[homes]
comment = Home Directories
path = /valahol/a/RAIDen/%S
valid users = %S
read only = No
create mask = 0700
directory mask = 0700
browseable = No
Az %S adja meg, hogy a helyi valós felhasználok léphessenek be, és mindenkinek a userneve nevű mappa lesz megosztva (valahol a raiden )Így alakulna?
-
#20601
lionhearted
őstag
Buci21
#20600
válasz
Buci21
#20600
üzenetére
Írásspórolás: Azt nem ajánlom túlságosan, hogy a naplózáson spórolj, de a logfájlok mehetnek tmpfs-re, illetve maga a /tmp is, akkor nem sok írás lesz... meg egy noatime, azzal még nem sokat veszítesz. Ubuntu / MINT-ből LTS, debiből stable, és akkor pár évre letudod a telepítést. Szerintem.
Telepíteni meg kb ugyanúgy, mint bármi mást, max 2 pendrive kell hozzá, az egyik az installer a másik a végleges helye. Én 1 partícióval csinálnám az egészet, swap inkább fájlban valahol, minimális méretben, swappiness persze jelentősen csökkentve (pl 1
). -
#20534
lionhearted
őstag
pakriksz
#20533
-
#20512
lionhearted
őstag
N0zer0
#20507
-
#20499
lionhearted
őstag
#40935168
#20498
válasz
#40935168
#20498
üzenetére
FAT32
Én csak felhívtam a figyelmet, hogy instabil fájlrendszer sosem nagy ötlet, főleg, ha azokon vannak a "mentéseink", és pótolhatatlan dolgaink.
Nem tudom, hogy mennyire kényszer vagy sem, hogy ext4 is csak valami bugot talált, lehet idővel megoldódott volna, vagy újraformázás... vagy új kernel. Tényleg nem tudom.
Egyébként van azért még fájlrendszer, XFS, JFS, ZFS (bár ezt a kernel licenc okok miatt nem támogathatja). -
#20497
lionhearted
őstag
#40935168
#20496
válasz
#40935168
#20496
üzenetére
Persze, én értem, bár hogy mi lesz a default ajánlás, az egy másik kérdés, tény, hogy egyes fícsőreivel jobb, mint az ext4, főleg backupként. Gondolva itt a transzparens tömörítésről, vagy arról, hogy 1 adatot csak 1 helyen tárol, vagy csak a különbségek kiírása...stb. Bár éppen ez utóbbi fícsörje egy szép nagy drawback is, rendesen tud kattogni a winyó a töredezettségtől, ha erről programok / OS fut.
Másfelől, mivel épp Debian alól használod, ami nem arról híres, hogy a latest kernel fut rajta, így nem is gondolnám, hogy a latest BTRFS driver mellett fogsz dolgozni, így azért több buggal szembesülhetsz, persze backportból keresgélhetsz frissebb kerneleket.Azt, hogy mennyire hájp az instabilitása, azt nem tudom felmérni, saját tapasztalataim igazából egy szobával arrébbról szereztem, neki volt, hogy napokig várnia kellett a fixelő toolokra a fejlesztőtől, mert összeomlott a fájlrendszer. Azért szép volt látni, hogy winre kényszerült egy hétre a hülye bétafájlrendszer-mániája miatt.
De, azt nem tudom neked megmondani, hogy mitől seekel be az ext4. Lehet az is valami kernel bug, de nem hinném, hogy ezt senki ne vette volna észre... ilyen problémába még nem ütköztem.
-
#20490
lionhearted
őstag
#40935168
#20489
-
#20443
lionhearted
őstag
Speeedfire
#20442
válasz
Speeedfire
#20442
üzenetére
reverse intelligent search
Ctrl+R
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új lapon, ami RST-s, lehet "Legacy" módban futtatni?
Új hozzászólás Aktív témák
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Vírusirtó, Antivirus, VPN kulcsok
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Gamer laptop felvásárlás Magas áron, gyorsan és egyszerűen!
- LG 27GR95UM - 27" MiniLED - UHD 4K - 160Hz 1ms - NVIDIA G-Sync - FreeSync Premium PRO - HDR 1000
- BESZÁMÍTÁS! MSI MAG321QR 32 165Hz WQHD 1ms monitor garanciával hibátlan működéssel - használt
- Lenovo ThinkPad X270 (16) - i5-7300U, 16GB, 512GB SSD, 12" FULL HD
- Maximális teljesítmény és biztonság, csak az ARCTIC mx-4-el! Adj új erőt a gépednek!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged