-
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
-
bambano
titán
válasz
CPT.Pirk
#34231
üzenetére
nekem az a problémám, hogy ha egy gép nincs publikus hálózaton, nincs vele baj, akkor minek hozzányúlni?
frissíteni? mióta systemd van a legtöbb disztróban? öngyilkosság.
ha nincs olyan sérülékenység vagy hiba, ami téged konkrétan akadályoz és a frissítés megoldja, akkor felesleges frissíteni. főleg, ha "annyi meló van".ismétlem magam: ha nem romlott el, ne akard megjavítani.
-
-
-
bambano
titán
-
-
bambano
titán
válasz
#78522999
#34156
üzenetére
ja, ha mindenféle webes admin felületnek látszó hibahalmazt raksz fel a gépedre, akkor ne csodálkozz, hogy 20 percet se bír ki...
egyébként a dns szervert szokták még megborítani, ha van fent olyanod, szedd le vagy állítsd be rendesen.
lehet még olyan ok is a döglődésben, hogy a vps szolgáltató tűzfala már felfigyelt a gondjaidra, ezért lassítja a hozzáférést. velük is beszélned kellene.
-
bambano
titán
válasz
urandom0
#34153
üzenetére
ha rootként van bent, akkor ami azon a gépen van, az kuka, a komplett gép kompromittálódott.
nyilván hozzáfér az adott gépen levő privát kulcsodhoz is, ahogy leírtam az előző hsz-emben.ha nem követted el azt az orbitális hibát, hogy másolgatod a kulcsaidat mindenféle gépre, akkor ez nem olyan nagy probléma. ha ugyanazt a kulcspárt használtad egy rakás gépről, akkor bajban vagy
-
bambano
titán
válasz
urandom0
#34148
üzenetére
vajon hogyan lopja el a privát kulcsodat, ha azt soha, semmilyen körülmények között sem adod ki a kezedből? oké, a feltört rendszeren levő kulcsaidat ellophatja, de itt arról van szó, hogy aki távolról be akar jelentkezni a feltört gépre, azzal lesz baj. ha be akarsz jelentkezni a feltört gépre, akkor sem adod ki a sajátodról a saját privát kulcsodat.
-
bambano
titán
válasz
urandom0
#34143
üzenetére
ez így a nemlétező esemény. hogy sebezhetőség van az openssh szerverben, azt ki tudta lőni, de a 22-es portra nem tud rábindelni, annak nulla az esélye. a credentials lopásnak meg azért nincs értelme ebben az elképzelt felállásban, mert ha a jogosult user tudja, hogy nem a 22-es portra tette az ssh-t, akkor nem fog a 22-es porton próbálkozni, tehát nem fog legális azonosító adatokat kapni ott, aki meg a 22-es porton próbálkozik, az fake.
ha elköltöztetted az ssh-t a 22-es portról, akkor egy rakás cpu-t megspórolsz, amit a fail2ban elhasználna.
-
#34108
bambano
titán
lionhearted
#34107
bambano
titán
válasz
lionhearted
#34107
üzenetére
unixon a diszk partíció egy hatalmas blobb...
-
#34102
bambano
titán
lionhearted
#34101
bambano
titán
válasz
lionhearted
#34101
üzenetére
"Nem tudom ki hol találkozott enterprise-szal,": otthonra kell neki nas. nem enterspájz hiperkonvergált vállalati ócskavastelep
-
bambano
titán
szerintem mindent, ami állandó, és nincs túl nagy igény a biztonsági szeparációra, azt egy helyre kell tenni.
veszed a vasat, ráraksz egy alap debiant, és azon összedrótozod a kvm hostot meg a nast.egyébként meg az is kérdés, hogy neked mi az, hogy nas? nekem a nas az egy nfs szerver és pont. nincs mit virtualizálni rajta. ha guesteket akarsz rátenni, akkor lvm2.
Szerintem nem kell túlbonyolítani semmit, fájlrendszer az ext4 és jónapot. Arra kell figyelni, hogy alap beállítással kvm-et ne rakj raid1-re.
-
bambano
titán
-
bambano
titán
hogy rotálod a bináris logokat? eldobálsz fájlokat, nem?
a jobb syslogd-knek meg lehet adni, hogy milyen nevű fájlba logoljon. hogy a gép nevét bele lehet-e rakni a logfájl nevébe, azt még nem próbáltam. hogy dátumot bele lehet-e, tetszőleges formátumban, azt igen, működik. simán tudsz csinálni/var/log/%Y/%m/%d/syslog
nevű fájlt. nem kell rajta rotálni semmit, max. ráteszel egy linket a hagyományos helyéről.
-
bambano
titán
nem nekem van elképzelésem a unixról, hanem az alkotóinak. és a teljes rendszert ahhoz igazították. az, hogy csővezeték van, olyan parancssori cuccok vannak, amilyenek, az átirányítás meg a file descriptorok rendszere, mind azt mutatja, hogy szöveges feldolgozásra optimalizálták a kernelt. minden más elhajlás. jelen esetben indokolatlan és helytelen.
ha az operációs rendszer nem felel meg az eredeti, alapvető tervezési filozófiájának, akkor katyvasz lesz belőle. lásd még: m$
majd meglátjuk, hogy a dinamikus dns konfiguráció a fontos-e vagy a jogszabály. mellesleg most is dinamikus a konfig, a dhcp kliens átírja a resolv.conf-ot.
-
bambano
titán
Oké, menjünk éttermi hasonlattal.
Régen volt mindenféle étterem, majd jött a maffia, mindet erőszakkal átvette, és azóta mind vegán étterem. De az ételt mindig elsózzák és kozmás.Tehát ne csak azt az állításomat figyeld, hogy a unix filozófiájának nem felel meg a systemd, hanem azt is, hogy egyébként a systemd jelenlegi állapotában egy bughalom.
Más: az előbb jutott eszembe, míg szűkös magányomban agyaltam (
), hogy a legújabb gyerekvédelmi szabály(tervezet) fényében a systemd-resolvd nem törvénysértő?Alaposabban belegondolva mondhatjuk, hogy a tailscale a saját megoldása miatt erősen elfogult, tehát az, hogy szerintük mi a jó dns rezolválás, messze van az általános objektív valóságtól.
-
bambano
titán
nem kérdés volt, állítás.
unixon alapvetően minden szövegfájl (a szükséges kivételekkel). erre lett az egész optimalizálva.
a bináris log az olyan, hogyha én beülök egy szték vendéglőbe, akkor nekem hiába magyarázza bárki is, hogy a szója meg a tofu jó, én akkor is sztéket fogok enni. azért van unix a gépeimen, mert szöveges logokat akarok.mindig az az oprendszer van a gépemen, amellyel a legegyszerűbben meg tudom oldani a feladatomat. tehát ha ascii log elég (mindig elég), akkor nem lesz bináris logom, pláne nem lesz xml meg json meg binary blob logom.
-
bambano
titán
Ha tényleg ők a linuxos világ teteje, akkor bajban vagyunk.
"This stuff is not documented ": a valóság az, hogy documented. A resolv.conf-ban szereplő dns szerverhez fordul, pont.Egyébként a systemd-resolvd-ben az documented volt, hogyha nem jó a névfeloldásod, akkor a google névszerverére fallback-kel? Mert egy ilyen ötlettől a linux kapásból alkalmatlanná válik komolyabb helyeken való felhasználásra.
A dbus támogatás meg micsoda? Minek dbus támogatás a rezolváláshoz? Megint ez a csináljunk egy naaaagy monolitikus böszmeséget a unix alapfilozófiájából történet, ahol pottering nem érti, hogy amit csinál, az fundamentálisan rossz. vannak dolgok, amiket el kell fogadni, mint egy axiómát. A unix az KISS. Ami nem KISS, az nem unix, hanem pl. windows. a systemd nem egy tuningolt unix init, hanem egy totál más rendszer initje, ami alatt tévedésből linux kernel van.
De ezek "filozófiai" kérdések. Az alapvető probléma, hogy a systemd nem működik rendesen. Nem teljesíti a saját ígéreteit, a doksiját. Amíg nem az történik, mint ami a kottában van, addig nincs miről beszélni, az csak a mostani munkahelyén normális, hogy a világ a bétatesztelőjük, debianban eddig ez nem volt.
A systemd elkaristol, amíg az alap dolgokhoz akarod használni. Amikor nekem bonyolultabb dolgokhoz kellett volna systemd támogatás, soha nem sikerült megcsinálni, mindig valami bugba futottam bele. Egyébként meg például milyen vicces, hogy a systemd gyűjti a logokat és forwardolja a syslogd-nek. Miért nem lehet ilyenkor kihagyni a systemd-t? bináris log unixon? minek?
A systemd alapvető baja egyébként, hogy működő, tesztelt, normális megoldásokat cserél le egy katyvaszra, látható előnyök nélkül. Miközben ezzel a cserével a rendszergazdákat arra kényszeríti, hogy erőforrásokat áldozzanak a változás követésére. Minek? Ki fizeti azt meg? Én fizessem meg pottering egoizmusát? A linux régen a szabadságról szólt, nem arról, hogy minden mocskot letolnak az ember torkán. Ha azt akarom, hogy pár egoista barom hülyeségéhez kelljen erőszakkal igazodnom, veszek windows licenszet.
-
bambano
titán
válasz
urandom0
#33980
üzenetére
az xz egy annyira fontos szoftver, hogy egyáltalán nem az, még egy debian is elgurul nélküle.
Az pedig továbbra is hiba, hogy systemd jellegű óriás bináris blobok vannak a mostani disztrókban, és ész nélkül használják is azt. Jól láthatóan az alapelvtől való eltérés lényegesen elősegítette a kendácsolást.
-
bambano
titán
válasz
urandom0
#33974
üzenetére
A unix úgy született, hogy megpróbáltak komplex operációs rendszert írni, de nem sikerült. Ekkor lett az alapelve, hogy keep it stupid and simple.
A systemd teljesen egyértelműen szembemegy ezzel az alapelvvel, nagy hiba volt integrálni a disztrókba.
Minél több szemetet integrálsz az oprendszerbe, annál több támadási vektort hagysz benne. -
bambano
titán
válasz
#79484416
#33865
üzenetére
"Azóta következetesen idézőjelbe teszek minden ilyet.": az idézőjel pont arra utasítja a shellt, hogy bontsa ki, tehát az erre a célra nem alkalmas.
Ha azt akarod, hogy a wildcardot ne bontsa ki, akkor vagy escape-eled, vagy aposztrófok közé teszed.és ismétlem magam: most teszteltem.
szerk: egyébként unixokon sh volt, vagyis Bourne shell. Solarison anno volt ksh és csh nem default shellként, de már egy jó ideje ott is bash a shell.
-
bambano
titán
válasz
sh4d0w
#33859
üzenetére
De, valójában escapelni kell a wildcardokat, abban az esetben, ha a helyi könyvtárban van a wildcardnak megfelelő nevű fájl.
A shell megpróbálja kifejteni, ha sikerül, helyettesíti, ha nem sikerül, akkor nem. Neked azért működött, mert nem sikerült.szerk: tuttira. az előbb teszteltem.
-
bambano
titán
válasz
Longeye
#33848
üzenetére
A su - végrehajt egy login shellt, vagyis törli az összes korábbi környezeti változót, és megcsinálja az aktuálisat.
emellett persze lehet, hogy a wine egyébként se szeret rootként futni.
elvileg, ha beírod:
userként: xhost +
userként: su -
rootként: export DISPLAY=127.0.0.1:0akkor elvileg mennie kellene, feltéve, hogy beállítottad, hogy az X figyeljen tcp socketen is.
beírod, hogy ps -ax|grep X
erre elvileg egy soros választ kapsz, amiben paraméterként vagy lesz egy -nolisten tcp, akkor bajban vagy, vagy lesz egy -listen tcp, akkor működni fog a fenti. Tudomásom szerint Debianék nolistenesek. -
bambano
titán
első körben firmware-t frissítenék a mikrotiken, második körben megnézném az sfp+ hőmérsékletét másolás közben.
ha rezen kötötted össze, akkor vagy át kellene szokni üvegre, esetleg dac-ra, vagy legalább nem egymás melletti portokba dugni az sfp-t, vagy megnézni, hogy v1 vagy v2 az sfp+ rezed.az tény, hogy ettől a közvetlen kapcsolatos másolásnak nem kellene megdöglenie... esetleg megnézném azt is, hogy gigára lassítva is megdöglend-e.
a crs az switch. cloud router switch.
szerk: a linuxokkal azt lehet kezdeni, hogy nagyobbra veszed az interfészen a queue-t, a kernelben a tcp méreteket (küldés, fogadás buffer) és lecserélheted a tcp ütemezőt is. a google féle ütemező jobb, mint a default linux.
-
bambano
titán
Az agyonbonyolított megoldások helyett:
a root/boot mérete nem változik, tehát dd-vel másolható.
a home méretét csökkenti, azt meg lehet később tar-ral.
szóval berakja az új ssd-t is a gépbe, ráteszi az uefi és a root partíciókat azonos méretben, dd, grub install.
bebootol az új ssd-ről, berakja a régit slave-nek (csakazértis![;]](//cdn.rios.hu/dl/s/v1.gif)
) megcsinálja a maradék helyen a home partíciót, és tar. -
-
#33465
bambano
titán
fatpingvin
#33464
bambano
titán
válasz
fatpingvin
#33464
üzenetére
egyrészt nekem sosem szólt az mdadm, másrészt le lehet állítani a tömböt, és akkor bakfitty.
hardveres hw raiddel nincs tapasztalatom, azokat a diszkeket is sima pc-ben gyalulom, ami hw-s gépből jön. -
bambano
titán
Tapasztalaton alapuló tanácsra lenne szükségem:
van egy gépem, asus prime z690m+ alaplappal, debian, és túl meleg a házban a vinyó. Nagyobb huzatot szeretnék csinálni benne, ha zajosabb, az nem annyira gond. A gépet kitermelni nem nagyon tudom, szóval első körben bios állítgatás nem játszik.A kérdés: hogy tudom acpi-fan interfészen keresztül felgyorsítani a ventilátorokat?
tia -
bambano
titán
ha a redhat bármibe belenyúlt, ami gpl-es, és azt binárisan kiadta, akkor köteles kiadni a patchet is.
az ingyenebéd nem csak akkor van, amikor csinál valamit a redhat és azt gipsz jakab élvezi, hanem akkor is, amikor a redhat kivett a nagy közösből gpl-es cuccokat és abból pénzt csinált.
-
bambano
titán
értem, de azt se írtad le, hogy fixen akarod, véglegesen, vagy most van valami, és ahhoz kell.
buguntuban például a network managerben manualra állítod a kártyát, oszt jónapot.
debianban is, vagy a /etc/network/interfaces-ben beállítod manualra. szóval kaptál még teret a kérdés pontosítására -
bambano
titán
"Namármost az az alap paradigma, hogy egy cégnek törekednie kell a profit maximalizálására.": nincs ilyen paradigma.
Attól, hogy jelentős mennyiségű ilyen cég van, ez még nem általános paradigma.Az általános paradigma az, hogy a cégnek törekednie kell a tulajdonosi érdekek kiszolgálására. Nem vitatom, hogy sok cég esetében ez a profit maximalizálás, normálisabban fogalmazva a roi. (return of investment).
Egy rakás cég van, ahol nem a profit maximalizálása a cél, erre a magyar jogban is van lehetőség a nonprofit kft-knél, alapítványoknál, stb. A redhat érdekkörében egy kézenfekvő példa: a kernelt egy nonprofit alapítvány-szerűség gondozza. Egy rakás cég öntött egy rakás zsetont az alapítványba azzal a kettős céllal, hogy fejlődjön a kernel, és ne jusson senki kezébe, amivel kizárhatná a másikat. Azért pénzelik közösen Linust, hogy ne legyen kizárólag egy konkrét céghez rabosítva.
A redhat nem helyezett semmi humán szabályt sehova, a redhat pontosan értette, hogy ezen a piacon a termék a csatolt szolgáltatás. Ez kb. olyan, hogyha te kalapácsot árulsz, szponzorálod a szöggyárat.
-
#33359
bambano
titán
fatpingvin
#33357
bambano
titán
válasz
fatpingvin
#33357
üzenetére
nem csak neked:
annyi tévedést írtatok, hogy muszáj közbeszólnom.1. számú alapszabály: GPL-T AKKOR LEHET SÉRTENI, HA A CUCC GPL-ES.
2. kiválóan elfilozofálgattatok a systemd gpl sértéséről úgy, hogy senki nem írta ide, hogy a systemd NEM GPL-es.
3. átlagos disztró zöme SEM GPL-es. a fontosabb cuccok közül gyakorlatilag az alap unix segédprogramok és a gnome gpl-es, a többi nem.
4. a redhatnek joga van ahhoz, hogy kiadjon egy disztrót, aminek a 10%-a gpl-es úgy, hogy ad egy linket, hogy a cuccomban levő gpl-es programok forrása itt. és a nem gpl-es cuccainak meg nem adja meg a forrását, illetve a nem gpl-es cuccoknál az adott licenszet teljesíti.
5. az emvy által idézett gpl faq pontot sem sértette senki, főleg, ha feljebb scrollozol és megnézed, hogy 3 sorral korábban mit írtak. elfogadom, hogy a gpl-en a jogászok sokat keccsöltek, ezzel párhuzamosan nagyobb összeggel fogadnék arra, hogy a jelenlevők nem értik a gpl-t.
6. a legnagyobb hülyeség, amit itt olvastam, hogy a gpl nem várja el, hogy visszategyél a közösbe. A gpl, mint dokumentum, gyakorlatilag csak erről szól, meg arról, hogy ha te ezt meg akarnád kerülni, akkor miért nem teheted.A gpl alapja, hogy kiveszel a közösből, hozzáraksz valamit és azt visszaadod. Ettől lett nagy a szabad szoftver közösség. Mindenki tett a közösbe képessége szerint, (legyen az új kód, hiba patch, doksi, teszt erőfeszítés, stb), és mivel egyre többen csinálták ezt, jó nagy lett a kupac. Én pl. egyszer egy pár soros hibaleírással járultam hozzá a kernelhez, ami alapján Mingo percek alatt megtalált egy komoly hibát. Nagy dolog? Személyesen nem. Tömegesen igen.
A többi:
a szabad szoftverben a szoftver rendszerint nem termék. A szabad szoftvert nincs értelme termékként értékesíteni, mert nincs benne akkora profithányad. Lehet, legális, csak nincs értelme. A szabad szoftverben a hozzáadott szolgáltatás a termék. Ezért szoktak vastagon pénzt kérni.A redhat nem azért kér pénzt (egyébként mocskos sokat), mert össze tudtak csomagolni egy linux kernelt meg egy glibc-t rpmbe, hanem azért, mert adnak egy telefonszámot, amit felhívhatsz, és megkapod az ígéretet, hogy a hasfájásodat meg fogják oldani. És a redhat HOSSZÚ ideje bizonyítja, hogy az ígéret szép szó, de ők meg is tartják. Azt fizeted ki, hogy ha egyszer pofára esel majd, jön két konyhaszekrény és felránt.
A redhatnek minden joga megvan ahhoz, hogy a saját cumóját úgy adja, ahogy akarja. És itt most hangsúlyozottan jogról beszélek, nem arról, hogy érdemes-e. A redhatnek is meg kell értenie, hogy van a bazi nagy fazék, elismerésünk, hogy jelentős mennyiségben dobáltak bele, ÉS ELVITTÉK AZ EGÉSZET. Digitális fazék, el lehet vinni úgy, hogy ott marad. A redhat sokat keresett azon, hogy ilyen-olyan patcheket rakott a kernelbe? Igen, ÉS? mennyit keresett a redhat azon, hogy nem kellett leprogramoznia az egész kernelt? a glibc-t? az llvm-et?
szóval szerintem érdemes lenne tájékozódni, mielőtt ilyen alpári szintre hülyítitek ezt a szakmai listát.
-
bambano
titán
"Különböző glibc verziók között papíron nem létezik kompatibilitás.": a glibc-k kompatibilitásáról annyit, hogy felrakom a 4-es firefoxot a debian testingre és megy.
tehát a tizensok évvel ezelőtti glibc-hez fordított firefox simán megy a testinges glibc-vel meg a rakás egyéb X-es könyvtárral. -
bambano
titán
nem kell itt túlgondolni a dolgokat.
lefordítod a programot, átviszed másik gépre, és egy
ldd programnev
utasítás megmondja, hogy mit talált meg a linker és mit nem.
abból tudni fogod azt is, hogy miért nem.
ha azt látod, hogy olyat nem talál, amit nehéz pótolni, azt a fordításkor statikusan hozzálinkeled oszt jónapot. -
bambano
titán
gcc nem exportál libet.
a libekből szokott lenni statikus verzió, ha mindenáron hordozhatót akarsz, akkor a statikusat linkeld hozzá.
szerintem ez rossz megoldás.
a linker meg fogja találni a libeket minden disztrón, ha felrakták őket.
egyébként pedig az LD_LIBRARY_PATH környezeti változóval felül lehet bírálni a linker keresési sorrendjét. -
-
bambano
titán
a rebuildet nem mdadm processz csinálja, hanem kernel thread.
szerk: a privát magánvéleményem pedig az, hogyha bármi kérdés merül fel egy diszkkel kapcsolatban, az nálam repül. sokkal olcsóbb kidobni és venni újat, mint tojtorozni, azután majd három hónap múlva elszáll a legrosszabb időpontban.
-
#33101
bambano
titán
arcoskönyv
#33100
bambano
titán
válasz
arcoskönyv
#33100
üzenetére
"a switch után nem kerül a packetbe az eredeti MAC Address.": lyalyly.
az első router után...
a broadcast domain határának átlépésekor cserélődik a mac. -
bambano
titán
-
bambano
titán
válasz
#68216320
#33079
üzenetére
"ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub"
mivel az rsa titkosítás szimmetrikus abból a szempontból, hogy melyik kulcsot nevezed ki privát kulcsnak, és melyiket publikusnak, az az állítás, hogy egy egyszerű parancssori utasítással le tudod generálni a privát kulcsból a publikusat, ekvivalens azzal az állítással, hogy a publikus kulcsból egy egyszerű paranccsal le lehet generálni a privát kulcsot.azé' ettől az állítástól egy pár ember bokáig összef.sná magát hirtelen, összes bank, katonai titkosítások, stb. ha erre az állításra lenne korrekt bizonyítás és működő megoldás, akkor a Föld gazdasága kb. 20 perc alatt omlana össze a kőkorszakig.
-
-
bambano
titán
válasz
#68216320
#33070
üzenetére
a kulcspár egy identitást azonosít.
több kulcspár egy adott identitáshoz eléggé kilóg a tervezett felhasználásból.
minden egyes gépen, amin kulcsos ssh-t akarsz használni, generálsz egy darab kulcspárt, és utána minden másik gépre, amire be akarsz arról a gépről jelentkezni, átmásolod az azonosítót. akár szövegszerkesztővel, akár ssh-copy-id utasítással."A kérdésem arra irányult, hogy amennyiben minden helyre külön kulcspárt csinálok, akkor több id_rsa (vagy éppen ami a fájlnév az új algoritmusú privát kulcshoz) lesz a laptopomon?": nem.
ha minden helyre külön kulcspárt csinálsz, akkor a notebookod id_rsa.pub fájlja lesz több helyre átmásolva. nem a szerver publikus kulcsát másolod a notebookra, hanem a notebookét a szerverre. -
#33053
bambano
titán
fatpingvin
#33050
bambano
titán
válasz
fatpingvin
#33050
üzenetére
elvileg van egy ilyen szolgáltatás-hirdetési protokoll, nem emlékszem pontosan a nevére. de ha egy cupsot beszélő nyomtatót felraksz a hálózatra, azt a kliensek konfig nélkül meg szokták találni.
-
#33049
bambano
titán
fatpingvin
#33042
bambano
titán
válasz
fatpingvin
#33042
üzenetére
a cups szerver nem tud bonjourt?
-
-
bambano
titán
válasz
CPT.Pirk
#32931
üzenetére
Milyen gyakran változik a memória a gépedben?
Nekem pl. úgy tud változni a memória a gépemben, hogy kihúzom a madzagot több desktopból, utána a racket, ami ezeket a desktopokat tartalmazza, kigurítom, kiveszem a gépet, szétborítom, megváltoztatom a ramot, majd mindezt vissza. közben értelemszerűen takarítok is, mert muszáj.
Ebbe a 2-3 órás procedúrába nekem belefér, hogy még egy szkriptet lefuttatok, bemásolok két fájlt a helyére, majd egy reboot.Azt nem gondolnám jó mérőszámnak, hogy tele van vele a google. Akinek nincs ilyen problémája, az nem írja tele a google-t, vagyis nem egyenletes a statisztika.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Honor 200 Pro - mobilportré
- TP-LINK routerek
- talmida: Változások 2. rész
- Energiaital topic
- Mesterséges intelligencia topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Lexus, Toyota topik
- Sokkal jobb ajánlat lett elődjénél az iPhone 17e
- Óvodások homokozója
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- További aktív témák...
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Bioshock 2 Special Edition
- Microsoft és egyéb dobozos retro szoftverek
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Beszámítás! Apple MacBook Air 13 2020 M1 8GB RAM 256GB SSD notebook garanciával hibátlan működéssel
- BESZÁMÍTÁS! Acer Nitro 5 AN515-55 FHD notebook - i7 10750H 16GB DDR4 512GB SSD GTX 1660 Ti 6GB WIN11
- Ddr5 Laptop Ram 32 gb 2x16gb 5600Mt/s
- Samsung Galaxy S21+ / 8/128GB / Kártyafüggetlen / 12Hó Garancia
- MSI Prestige A16 AI+ Ryzen AI 9, 32GB DDR5 7500, QHD+ 165Hz csúcskategóriás ultralaptop!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest