-
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
''mindezt csak véleménycsereként nem kötekedés vagy okoskodás'': ne aggódj, majd hétfőn felébrednek a linux fanok és fogok kapni hideget-meleget, hogy rosszat mertem szólni a kernelre
''azért nem gondolom hogy túl nagy veszteség lenne a naplózó történet'': naplózó filerendszer elképzelésem szerint kétféleképpen működhet:
1. - jön adat, leteszik az adatot a metadata (a journalba) területre
- leteszik a szükséges rendszerterület változtatást a metaadat területre (inode-ok, clusterek, stb).
- átmásolják a metaadat területről az adatot a rendes helyére
- átmásolják a metaadat területről a rendszerterület változtatásokat a rendszerterületre
- adminisztrálják a journalt
2. - jön az adat, leteszik a végleges helyére
- a rendszerterület változtatást leteszik a metaadat területre
- a rendszerterület változtatást végrehajtják a rendszerterületen
- adminisztrálják a journalt.
Ezzel szemben az ext2-nél lerakják az adatot a végleges helyére és lerakják a rendszerváltozásokat a végleges helyükre. Ez pont fele annyi lemezio művelet.
Ami már nem az én elképzelésem, hanem az én mérésem, hogy ez nagyságrendileg 40-50% teljesítményvesztés, minél kisebb gépen és minél gyengébb hdd-vel nyomod, annál látványosabban lassú a naplózás. Én pont a felét mértem a gépemen. Amíg valaki nem mutat egy 200MB/sec fölötti írási végeredményt bonnie++ kimenetben, addig pesszimista vagyok a naplózós rendszerek írásával kapcsolatban. Az olvasás vélhetőleg nem lassul jelentősen, tehát egy ext3-ról fat32-re másolás az simán lefuthat teljes sebességen.
Elfogadom, ha azt mondod, hogy neked a felezett teljesítmény nem észrevehető, irigyellek a gépedért. De ne szvsz legyen hanem konkrét mérés.
Szerintem a hw nem előzött sehova, a kernel simán kihajt mindent a vasból, ami benne van.
A raid, lvm, ext3, xfs, reiser4 használata esetén azt lehet állítani, hogy ha és amennyiben a tisztelt programozók nem rontottak el semmit az adott alrendszer programkódjában, akkor az adott alrendszer a tőle elvárt előnyöket nyújtja.
Na ezen szokott megbukni a dolog, mostanában annyi ótvaros pocsék kód került a kernelbe, hogy sírhatnékom van. Ennek van pl. olyan eredménye, hogy megdöglik a raid1 kötet második diszkje, ami lehúzza az egész gépet, elérhetetlen, használhatatlan lesz tőle minden. Pedig a raid1-nek elvileg a rendelkezésre állást is javítania kellene diszkhiba esetén, de nem, hanem ettől omlik porba a gép.
Vagy: diszk hiba miatt megdöglik raid1, szabályosan kicserélem a diszket, újraindítom a gépet és pillanatok alatt felbootol. Majd pár óra múlva megomlik az egész. Alapos vizsgálat után kiderül, hogy a frissen berakott lemezt a raid1 nem szinkronizálta, maradt üresen. Minden olvasási művelet, ami a második lemezen zajlott, 0-val feltöltött szektorokat olvas be, ettől a bináris programokban folytonossági hiba keletkezik és értelmezhetetlen problémák kerülnek elő. Végül az egész összeborul. Visszabootolva egy korábbi kernelt, pár óra alatt lemegy a szinkronizálás és utána megy minden korrekten.
Vagy: mostanában valami olyan baja van a raid kódnak, hogy ha kidöglik a diszk alóla, megpróbálja szinkronizálással helyrehozni. Na ettől szépen megáll az egész blokkos eszköz, mint a szög.
Nem merném azt állítani, hogy minden fejlesztő mindig gondolkodik és mindig helyes eredményre jut. Szoktunk néha agyhalottazni, nem minden ok nélkül. Fentiek megtörtént esetek, tehát aki vitatkozni akar vele, annak azt kell bizonyítania, hogy vak vagyok vagy hazudok. Meg azt is, hogy az általam leírt hibára a hivatalos kernel changelogban adott magyarázat nem igaz. -
#3474
bambano
titán
rokefeller
#3473
bambano
titán
válasz
rokefeller
#3473
üzenetére
Először is a csúnya nagy fagyás még nem indok a gondolkodás nélküli resetre. Attól, hogy a kernel és/vagy az oprendszer nagyrésze lefagyott, még lehet menteni az adatokat, a magic sysrequest dologgal. Ez szerencsés esetben akár jelentős adatvesztést is megakadályozhat.
Nekem még nem volt rossz tapasztalatom ext2-vel, amit éppen akkor ír a rendszer, mikor fagy, az természetesen megy a levesbe, más nem szokott. Nem zárom ki, de nem valószínű.
Én nem mondom meg senki helyett, hogy neki a journal erőforráspazarlás-e, sőt, azt se, hogy egy gépen mi neki a jobb. A journal egyértelmű előnye, hogy akár sok száz gigás partíciót is pillanatok alatt felmountol a rendszer, még összeomlás után is, viszont a journal metadata írása pont ugyanolyan írás, mint a többi, ez peches esetben simán lefelezi a teljesítményt. Ami nagy méretű filmek írásakor jól jöhet, tehát még az is simán előfordulhat, hogy valakinek egyik gépe ilyen, másik olyan vagy egy gépen belül egyik partíció ilyen, másik olyan. -
bambano
titán
Az lvm nem filerendszer, hanem volume manager.
Az ext3 általában fele olyan gyors, mint az ext2. Ha nincs szükséged a naplózásra valami nyomós okból, akkor szerintem nem éri meg kézifékes fájlrendszert választani.
Bajod majd akkor lesz a raid1-gyel, amikor elromlik egy diszked. -
bambano
titán
A filerendszer típusát mindig az határozza meg, mennyi idő van egy probléma utáni újraindulásra. Ha nem kritikus a reboot ideje, akkor minden esetben kizárólag ext2.
Ha kritikus a reboot ideje, akkor nem tudom, leginkább ext3, de gyakorlatilag mindegyik filrendszerre volt panasz mostanában, a reiser fő alkotója éppen feleséggyilkosság vádjával sitten van, a többinek is voltak ilyen-olyan bajai.
Kernel verziótól is függ.
A raid1 nekem nem gyorsított semmit, annyi előnye van, hogyha bedöglik egy diszk, nem 0 eséllyel marad meg az adatod, ámde sokkal nagyobb valószínűséggel borul meg tőle a gép. Úgyhogy ha nem félsz a diszk hibától (mert bízol a diszkben vagy mert nem tartod értékesnek a rajta tárolt dolgokat), akkor ne használj raidet és ne használj ext3-at, mindkettő nagyban egyszerűsíti a rendszert és nagyon sokat csökkent azon programkód mennyiségén, amiben hibát lehet találni.
Ha igazán sokat akarsz kockáztatni, akkor tedd az összes adatod raid-re, lvm-re vagy evms-re és használj xfs-t vagy reiser4-et lehetőleg a legújabb kernelekkel. Ez a tutti módja annak, hogy legnagyobb rizikó felvállalása mellett legvalószínűbben összeboruljon a géped.
Tudom, hogy amit ide írtal, az szembe megy a mainstreaim véleménnyel, ennek ellenére a személyes tapasztalataim alapján ezt tudom javasolni (én is kerülöm a raidet és csak ext2-m van, ha lehet). -
#3464
bambano
titán
dr_strange
#3462
bambano
titán
válasz
dr_strange
#3462
üzenetére
Kernel csinál System mapot fordítás közben. Nem nagyon tudom elképzelni, hogy gentoo alatt ezt a fontos dolgot külön kitakarították belőle, csak hogy több baja legyen vele az embernek.
-
#3459
bambano
titán
dr_strange
#3456
bambano
titán
válasz
dr_strange
#3456
üzenetére
Szerintem nem gyártja le a modulokat, a modules_install gyártja le, ha nem találja őket telepítés előtt.
A System.map-ot is illik a bootba másolni. -
#3446
bambano
titán
dr_strange
#3444
bambano
titán
válasz
dr_strange
#3444
üzenetére
Azok az élő kiadások, amelyikek írnak a diszkre, azok nagyon hamar szétnyúzzák a pendrive-ot. Lehet, hogy a windows is ilyen. Azt szabad pendrive-ra tenni, amelyik ramdiszkbe bepakolja magát és utána onnan fut.
-
#3441
bambano
titán
dr_strange
#3440
bambano
titán
válasz
dr_strange
#3440
üzenetére
Nem értem ezt a kérdést. Az állítása az volt, hogy neki nem sikerült pendrive-ra ubuntut rakni, nem az, hogy egyáltalán nem is lehet.
-
#3439
bambano
titán
Veriakilis
#3438
bambano
titán
válasz
Veriakilis
#3438
üzenetére
Nem tudom. A knoppix az debian alapú live. De sose volt a kezemben live cd...
-
#3437
bambano
titán
Veriakilis
#3436
bambano
titán
válasz
Veriakilis
#3436
üzenetére
Akik a kernelt csinálják, azokat egy dolog érdekli: szakmailag a lehető legjobb kernelt csinálják meg. Hogy finoman fogalmazzak: a felhasználó barátság nem top prioritás.
Nekem az uhuval rossz tapasztalataim voltak, azóta mindig mindenhova mindenkinek debian. Sokkal kevesebb bajom van, mióta ezt csinálom. -
bambano
titán
válasz
Jester01
#3396
üzenetére
samli: ~$ expr 6.00 '<' 6.01
1
samli:~$ expr 6.02 '<' 6.01
0
samli:~$ expr 6.01 '<' 6.01
0
Ez bizony becsapós, mert ennyit ellenőriztem le és ez jó.
De neked van igazad, mert ezt:
expr '601' '<' '6.1'
már nem tudja rendesen.
Akkor megoldás lehet még a teljes script átírása awk-ba. Awk (nawk, mawk vagy gawk) minden linuxon van, bc csak azokon, amelyikre felrakták. -
-
#3359
bambano
titán
rokefeller
#3357
bambano
titán
válasz
rokefeller
#3357
üzenetére
De minek átbootolni windowsra? Főleg, ha nincs is windowsa vagy telepített windowsa az embernek...
-
#3339
bambano
titán
Vilmoskorte
#3336
bambano
titán
válasz
Vilmoskorte
#3336
üzenetére
Az a domain, amilyen feladóval ki akartad küldeni a levelet, rendesen létezik?
-
bambano
titán
Nem vagyok én mester, nálam sokkal jobb linuxosok is vannak.
Egyébként nem túl sok nap múlva töltöm be a 38-at, azt is levonhattad volna következtetésül, hogy vén trotty
Ti egy dologból fogtok kimaradni: milyen az, amikor még a hálózat is meg a linux is hardcore dolog abban az értelemben, hogy nincs szines szagos telepítő, másik gépen kell keresztfordítani a kernelt, úgy kell mindent odataszigálni a diszkre. Meg a hálózat összerakásából is sokat lehetett tanulni anno. Ha az ember ott van a kezdeteknél, akkor sokat tanulhat az alapokról.
A blogomban van hálózati történelem, reménykedem benne, hogy a korai dolgok feelingje azért megérezhető belőle. -
bambano
titán
Ha jól emlékszem, a 0.95.0 körüli kerneleknél szálltam be a linuxozásba, akkor még csak slackware volt elérhető, debiannak híre-hamva se volt még. Az volt a harmadik unix verzióm, előtte Interactive meg Sco unixom volt kb. 1991-től, dos is volt kicsit, de windowst soha nem használtam szinte semennyire se. Melóban meg 4.7-es meg 5.4-es vms volt, később (1993 nyarán) lett 2.2-es solarisom. 1995-ben kerültem olyan munkahelyre, ahol még a régebbi, sunos 4-es szerverek voltak, az meg teljesen bsd jellegű rendszer.
A wikipedia szerint az 1.0-s slack 1993. július 16-án jelent meg, akkor már nekem régen slackwarem volt, de nem sokkal később átálltam debianra. Debianból rex-em biztosan volt, 1996. decemberi megjelenéssel, de mintha lett volna előtte buzz-om is, de ebben nem vagyok biztos.
Hát innen -
#3334
bambano
titán
Vilmoskorte
#3333
bambano
titán
válasz
Vilmoskorte
#3333
üzenetére
Szerintem amikor el akarja küldeni a levelet, akkor konnektál a linux.hu smtp szerverére, az az ip cím alapján csinál egy reverse dns kérést. A korábbi postodban leírt ip címnek van reverseje egy román domainből. Utána a feladó ellenőrzésekor nézi meg, hogy az akarmi@valahol.hu-ból a valahol.hu létező cím-e, de erre sender domain not exists hibaüzenetet szokott nekem adni, ha nincs.
Nem látom, mitől nem jó neked...
De lehet, egyszerűbb lenne a szolgáltató smtp szerverét használni. Csak ott meg találkoztam olyannal, hogy a relay-t nem engedélyezték (tvnetwork nevű bagázs). -
bambano
titán
Gondolom tudod, hogy a bash viselkedése függ attól, hogyan indítod. Ha a script első sora:
#!/bin/sh
akkor eredeti Bourne shell kompatibilis verzióban fut, ilyenkor pár dolgot másképp csinál. Ha
#!/bin/bash a script eleje, akkor Bourne *AGAIN* shell-ként indul. Ahhoz, hogy ez működjön, a /etc/shells-ben szerepelnie kell mindkét verziónak.
Amit szeretnél, az programíró program, emiatt az eval utasítást kell használnod. Vagy elmeséled az eredeti gondodat és megoldjuk másképp Persze csak ha nem itt akarod megirattatni a nagyházidat. -
bambano
titán
Induljunk ki abból, hogy a legtöbb linux azt állítja magáról, hogy svr4-es initje van. Ennek ellenére shutdown -h now utasítással lehet kikapcsolni, ami bsd shutdown, az svr4-es shutdown-t shutdown -i0 -g0 -y -nak hívják.
A redhat pl. előszeretettel pakolja a saját lomjait a /opt alá. Aminek azért nincs értelme, mert bármi, amiről a csomagkezelőnek pontos tudomása van, mehetne a /usr alá is, mivel onnan is le lehet szedni, fel lehet upgrade-lni. Emellett, amikor csináltak volna linuxos fájlrendszer szabványt, az lfs-t, akkor a redhat beintett, mondván, hogy nem az apróságok fogják szabályozni a nagy cég linuxát.
Amikor utoljára néztem a suse-t, akkor volt neki olyan registry-je, mint a windowsnak, csak nem bináris, hanem txt. A debianban mostanában kezdik elkapni ezt a betegséget és firkálnak a /etc/default alá.
A legtöbb linuxban /home dir van, az svr4-es solarisban /exports/home vagy /export/home (nem emlékszem). Ami elvileg azért van, hogy nfs-en egyszerűen exportálhasd.
Azt is érdemes lenne megnézni, a /usr/share hogyan van összerakva linuxonként. Vagy a reformattált man lapokat melyik hova teszi. A több architektúrás lib-eknél is lehet kavarodás, van, ahol /lib64 könyvtár van. A /etc/alternatives is megérne egy misét, a /etc alatt rendes unixokon csak konfigok vannak, nem pedig végrehajtható állományok (vagy azok linkjei).
Azután itt van ez a /var/lib dolog, kódkönyvtárak a /var alatt? majd utána beletenyerel a postgresql adatbázisokkal? én nem oda tettem volna, ez tutti.
biztos derülne még ki pár dolog, ha megkapirgálná az ember...
szerk: a cdrom és a floppy mountolása szokott még egyedi lenni..
[Szerkesztve] -
#3317
bambano
titán
Vilmoskorte
#3315
bambano
titán
válasz
Vilmoskorte
#3315
üzenetére
Azt írd még meg, hogy te kinek küldted az emailt (első ránézésre a dmcc smtp szerverének) és mi volt a levélben szereplő feladó domain neve?
-
#3312
bambano
titán
Vilmoskorte
#3310
bambano
titán
válasz
Vilmoskorte
#3310
üzenetére
Maradjunk annyiban, hogy mítoszok és teóriák helyett egzaktul ki kellene deríteni, hogy konkrétan mi a baj, mert anélkül csak falra hányt borsó az egész.
-
#3311
bambano
titán
Vilmoskorte
#3309
bambano
titán
válasz
Vilmoskorte
#3309
üzenetére
Miért ne biztosítanák? A dns szempontjából az, hogy egy ip dinamikus-e, tökmindegy. De ha megírnád, hogy milyen ip-d volt, amikor a hibát nyomta, vagy mid van most, az segítené az ellenőrzést.
-
#3305
bambano
titán
Forest_roby
#3302
bambano
titán
válasz
Forest_roby
#3302
üzenetére
Ha csak linuxok között kell megosztani, akkor az nfs szerintem jobb. Ha igaz, xp-re is van nfs kliens, a unix services csomagban, de ott gondok lehetnek a felhasználók azonosításával.
-
#3292
bambano
titán
Vilmoskorte
#3290
bambano
titán
válasz
Vilmoskorte
#3290
üzenetére
Ezt te konkrétan sehogy, a szolgáltatódnál kell panaszkodni, hogy nincs reverse dns-ed az ip-dhez.
-
bambano
titán
válasz
Claudius
#3288
üzenetére
nem tudom, hogy hogyan telepítetted, de kellene legyen ablakkezelő, meg egy halom dolog.
ls -l /etc/alternatives/x-window-manager
nekem ilyet ír:
lrwxrwxrwx 1 root root 17 2006-11-10 20:51 /etc/alternatives/x-window-manager -> /usr/bin/metacity
ha nincs ilyened (mindegy, mire mutat az x-window-manager link, csak legyen, akkor rakj fel egyet, pl. metacity-t, vagy sawfish-t vagy enlightenment-et (elég egy a háromból)
szerk: nekem debianom van
[Szerkesztve] -
-
-
bambano
titán
-
bambano
titán
válasz
Whaskes
#3218
üzenetére
A linux konzolok között nem tudsz váltani a screen-nel. A screen azt csinálja, hogy több karakteres terminálablakot tudsz elindítani screen-en belül.
Tehát elindítod, hogy:
screen
majd az első progit elindítod ott.
a második progi indításához új screen ablakot kell nyitni a ctrl A majd c gombokkal
és minden újabb screen ablakhoz ez kell. Ha így nyitottad meg az ablakokat, akkor lehet ctrl A és sorszámmal odakapcsolni. -
-
bambano
titán
válasz
ngabor2
#3196
üzenetére
Pine helyett mutt, ha mindenáron karakteresen akarsz levelezni.
Magánvéleményem, hogy nem szeretek semmit, ami wu- -val kezdődik, mert régebben sok bugjuk volt.
Azt lehet még tudni, hogy szabványos mailbox fileban kizárólag a levelek első sora kezdődhet From<szóköz>string szöveggel, tehát elvileg a csplit-tel vagy split-tel szét lehet szedni levelekre, és azt egyesével betolni a procmail-nek.
Egy ilyen utasítás:
csplit /var/mail/akarki '/^From /' '{*}'
szétszórja a mailbox file-odat annyi darabra, ahány levél, érdemes külön, üres, ideiglenes könyvtárba elkövetni.
ezt utána egyesével beletolhatod a procmail-be, valahogy így:
for i in xx*; do procmail<$i; done
de ezt teszteld előtte, mielőtt élesben mail vesztést csinálsz -
#3192
bambano
titán
rokefeller
#3191
bambano
titán
válasz
rokefeller
#3191
üzenetére
Nem nyert 2.0. A linkedről van az idézet:
''The Intel driver uses the bios to determine resolutions'': inkorrekt fordításban a biosból olvassa ki a monitor paramétereit. Korrekt fordításban a bios felhasználásával (a bios segítségével) állapítja meg a felbontásokat.
Érdemes még ezt elolvasni:
[link]
Továbbá a /var/log/Xorg.log.0 alapján:
(II) Module i2c: vendor=''X.Org Foundation''
compiled for 7.1.1, module version = 1.2.0
ABI class: X.Org Video Driver, version 1.0
(II) RADEON(0): I2C bus ''DDC'' initialized.
(II) RADEON(0): Legacy BIOS detected
(II) RADEON(0): Connector0: DDCType-2, DACType-1, TMDSType-0, ConnectorType-4
(II) RADEON(0): Connector1: DDCType-3, DACType-0, TMDSType--1, ConnectorType-2
(II) RADEON(0): I2C device ''DDC:ddc2'' registered at address 0xA0.
(II) RADEON(0): I2C device ''DDC:ddc2'' removed.
(II) RADEON(0): DDC Type: 2, Detected Type: 3
(II) RADEON(0): I2C device ''DDC:ddc2'' registered at address 0xA0.
(II) RADEON(0): I2C device ''DDC:ddc2'' removed.
(II) RADEON(0): I2C device ''DDC:ddc2'' registered at address 0xA0.
(II) RADEON(0): I2C device ''DDC:ddc2'' removed.
(II) RADEON(0): I2C device ''DDC:ddc2'' registered at address 0xA0.
(II) RADEON(0): I2C device ''DDC:ddc2'' removed.
(II) RADEON(0): DDC Type: 3, Detected Type: 0
(II) RADEON(0): EDID data from the display on port 1 ----------------------
(II) RADEON(0): Manufacturer: VSC Model: 6911 Serial#: 16843009
(II) RADEON(0): Year: 2005 Week: 26
(II) RADEON(0): EDID Version: 1.3
(II) RADEON(0): Digital Display Input
...
(II) RADEON(0): Panel infos found from DDC detailed: 1600x1200
(II) RADEON(0): Valid Mode from Detailed timing table: 1600x1200
(II) RADEON(0): Valid Mode from standard timing table: 1600x1200
(II) RADEON(0): Valid Mode from standard timing table: 1280x1024
(II) RADEON(0): Valid Mode from standard timing table: 1280x960
(II) RADEON(0): Valid Mode from standard timing table: 1152x864
(II) RADEON(0): Valid Mode from established timing table: 1280x1024
(II) RADEON(0): Valid Mode from established timing table: 1024x768
(II) RADEON(0): Valid Mode from established timing table: 1024x768
(II) RADEON(0): Valid Mode from established timing table: 1024x768
(II) RADEON(0): Valid Mode from established timing table: 832x624
(II) RADEON(0): Valid Mode from established timing table: 800x600
(II) RADEON(0): Valid Mode from established timing table: 800x600
(II) RADEON(0): Valid Mode from established timing table: 800x600
(II) RADEON(0): Valid Mode from established timing table: 800x600
(II) RADEON(0): Valid Mode from established timing table: 640x480
(II) RADEON(0): Valid Mode from established timing table: 640x480
(II) RADEON(0): Valid Mode from established timing table: 640x480
(II) RADEON(0): Total of 17 mode(s) found.
(II) RADEON(0): Total number of valid DDC mode(s) found: 17
(--) RADEON(0): Virtual size is 1600x1200 (pitch 1600)
(**) RADEON(0): *Default mode ''1600x1200'': 162.0 MHz (scaled from 0.0 MHz), 75.0 kHz, 60.0 Hz
Maradjunk annyiban, hogy nem a biosból olvassa ki. -
#3189
bambano
titán
rokefeller
#3188
bambano
titán
válasz
rokefeller
#3188
üzenetére
A biosból biztosan nem, mert nem cserélsz biost minden monitorhoz...
A monitorról tölti le közvetlenül, ha rendesebb a monitor. -
bambano
titán
válasz
Salvatore
#3174
üzenetére
lrwxrwxrwx 1 root root 18 2007-03-31 17:00 /usr/lib/libasound.so.2 -> libasound.so.2.0.0
-rw-r--r-- 1 root root 784004 2007-02-26 18:35 /usr/lib/libasound.so.2.0.0
dpkg -S libasound.so.2.0.0
libasound2: /usr/lib/libasound.so.2.0.0
tehát a libasound2 csomagot kell feltenni. hm. libasound nincs is, akkor nem tudom, mi okozhatta a keveredést. de nézd meg, hogy a /usr/lib-ben ott van-e a file. -
bambano
titán
válasz
VladimirR
#3168
üzenetére
Én hallottam olyan chipsetekről, amelyek nem bírták az sdramot meg az edo-t egyszerre lekezelni.
Az is előfordulhat, hogy az ide vezérlőben a dma nem tudott rendesen dma-zni úgy, hogy két féle ram volt benne. Vagy hogy a két féle ram miatt olyan címekre remappelte a memóriát, ahova nem tudott a diszk vezérlő dma-zni, egyes buffereket elért, másokat meg nem.
de volt olyan gépem, egy gigabyte alaplapos p1, ahol pl. kontakthibás lett az egyik ram foglalata. minden értelmes ok nélkül. -
-
bambano
titán
válasz
Nagytalp
#3147
üzenetére
Amennyire én tudom, busz hibát akkor adnak az intel processzorok, ha valami címzési kísérlet rosszul sikerül. Hozzá akar férni a memória egy olyan területéhez, amihez semmi köze. HW gondnak tippelem, ha van túlhajtás, akkor azt visszább kellene venni, valami nem bírja (tippem szerint a memória).
-
bambano
titán
-
-
#3078
bambano
titán
rokefeller
#3077
bambano
titán
válasz
rokefeller
#3077
üzenetére
A kérdés az, mi a célod az ubuntuval. Ha nem szakmád, csak használni akarod valahogy a géped, akkor jó az ubuntu. Ha szakmád és az a célod, hogy pc-s unixokon tapasztalatot szerezz, hogy később átülhess (mondjuk munkaviszony keretén belül) nagyobb unixokra, akkor nem jó az ubuntu, akkor debian, mert az hasonlít legjobban az svr4-es nagy unixokra.
Hehe, én olyan környezetben kezdtem a szakmát, ahol előbb volt rendes, hálózatos, erőforrás megosztós nagygép (mainframe, vax, sun hálózat, minden volt), mint dos meg windows. Szövegszerkesztésre latex-et használtak és mindenki boldog volt. Nagyon bambán néztek, amikor megjelent a 3.11-es windows az összes bajával, amik közül párat azóta se nőtt ki -
-
bambano
titán
válasz
k.krisz03
#3069
üzenetére
Ez rendben, de egy betűt nem írtál arról, hogy a telepítési kísérlet vagy a bekapcsolási folyamat melyik pontján jön elő a hibaüzenet, mit tettél addig, stb. stb. Így azután semmi nem derül ki arról, hogy merre kell a problémát keresni. Enélkül marad az a jótanács, hogy írd be guglinak a hibaüzenetet.
Anno volt uhum, a dist-upgrade-t úgy elrontotta, mint atom, azóta nem próbálkoztam vele. Hogy finoman fogalmazzam meg azt, hogy szerintem nem érdemes uhuval foglalkozni. -
bambano
titán
tehát: egy süket rajz miatt vitatkoztak a debiánosok a mozillásokkal, ennek az lett a következménye, hogy a debianban nem használhatják a firefox nevet. a firefoxot, mint programot, szabad használni, csak a nevet nem, emiatt a debiánosok átneveztek minden programot, ami a mozilla alapítványtól származik. Mivel a régi nevek kapcsolhatók a tűzhöz, az új neveket a jéghez kapcsolták.
tehát: azt akarod, hogy legyen firefoxod. arra gondolsz, hogy legyen firefoxom és azt gépeled be a debianodnak, hogy legyen iceape-m és látod, hogy ugyan iceape-t telepített a debiánod, de mégiscsak tűzrókád lett.
tehát ne keress sehol firefoxot, írd be, hogy apt-get install iceape és kész.
dvd:
cd, dvd formátum nemsok féle van, azt szokták tudni a programok. A gnome környezet cd/dvd írója a gnome-baker, a kde környezeté a k3b, de nekem a k3b jobban kézreállt. Amit ezzel megírsz, azt lemeztípus függéstől eltekintve minden el fogja tudni olvasni. Lemeztípus függés alatt a +R -R bohóckodást értem. Ha iso-t írsz, minden el fogja olvasni, ami iso-t tud olvasni, windows, linux, asztali dobozos dvd lejátszó, stb. -
#3047
bambano
titán
Forest_roby
#3043
bambano
titán
válasz
Forest_roby
#3043
üzenetére
A szervernek nem okoz problémát, de az ssh kapcsolat, amin keresztül buheráltad, értelemszerűen lebomlik, bármelyik végét is rebootolod. Ha lebomlik, akkor a szerver lebontja a terminál adatokat is, amit az ssh-hoz épített fel, és kirugdossa az összes, előtérben futó, adott terminálhoz tartozó programot. Vagyis ha valamit elindítol, ami sokáig fut, és lenyomod a windowsodat közben, akkor a linux kirugdalja, amit elindítottál. Ennek megakadályozására jó a screen.
-
#3038
bambano
titán
Forest_roby
#3035
bambano
titán
válasz
Forest_roby
#3035
üzenetére
Ha nem a linuxot rebootolod, amit piszkálni akarsz, hanem a kliens gépet, akkor a linuxra ha felraksz egy screen-t, és abban indítod a programokat, akkor nem szakad meg.
-
#3032
bambano
titán
Forest_roby
#3031
bambano
titán
válasz
Forest_roby
#3031
üzenetére
ha terminál szükséges csak, akkor legyen sshd a linuxon, ha linuxról szeretnéd turkálni, akkor azon ssh, ha winről, akkor putty. ssh telepítést a disztribúciód doksija mondja meg, putty-ot guglival lehet találni.
-
bambano
titán
A legtöbb linux havonta rotálja és törli a régi utmp,wtmp fileokat, ergo ha nem tetted el évekre visszamenőleg, akkor sehogy.
A /bin/bash nem jó szokás, egyre kevesebb linuxon lesz olyan, dash-ra akarnak átszokni valami számomra ismeretlen okból. /bin/sh elég.
Ha már awk-kal lőssz ágyúval verébre, egyszer is elég szegényt elindítani. Mezők kivágására vagy cut vagy sed.
pl. cut -d \( -f2 | cut -d \) -f1
User idejének kiválogatására grep.
read x
echo -n $x felhaszáló ideje:
last|grep $x | sed -e 's/[^(]*(//' -e 's/)//'| awk -F: '{perc=perc+$1*60+$2} END {print perc}' -
bambano
titán
A ''hogyan lehetne használni'' kérdésre:
apt-cache search vga
svgatextmode - enable higher resolution text modes
és van még csomag arra is, hogy konzolba fontokat töltsenek le,
apt-cache search console fonts
console-data - Keymaps, fonts, charset maps, fallback tables for console-tools
stb.
Az svgatextmode csomagnak a régi x konfighoz hasonló konfigja van, olyan módot kavarhatsz ki magadnak, amit a monitorod csak elbír.
Azt nem tudom, mi lassú egy terminálon, ha van rendes xorg driver alatta (atihoz szokott lenni), akkor a különböző alapműveleteket a vga csinálja, nem a proc és úgy nekem nem lassú.
Mazohista akkor leszel, ha idenyomsz egy parancssort, ami csv formátumú file két oszlopát felcseréli vi-ban Régi szép időkben ascii art kicket lehetett érte kapni ircen
ui: most megteszteltem xtermet. már értem, miről beszélsz.
de hidd el nekem, ha beletolnád a fontokat a vga memóriájába és karakteres képernyőt használnál, az nagyon sokkal gyorsabb lenne bárminél. mondjuk akkor a grafikus böngészés nem működne...
w3m helyett én links-et használok, ha nincs kéznél X. Ha gyors, de buta böngésző is megfelel X alá, akkor meg dillo-t. A dillo-ban az is jó, hogy hangosan pofázik, ha nem szabályos html kódot kap, hibát keresni is jó. -
bambano
titán
válasz
Jester01
#3017
üzenetére
Sun fontot szerintem a karakteres konzolba is be lehet tölteni, 69x64-es képernyőt meg lehet karakteresből is csinálni.
Szubjektív: én akkor szoktam le a karakteres konzolról, amikor lett rendes monitorom. Mindent meg lehet csinálni xterm-ben vagy debian-vtermben, amit karakteres konzolon is, váltogatás nélkül. De ez mindenkinek a szubjektív magánvéleménye, hogy egyetért-e velem ebben.
Szerk: szerintem a framebuffer sokkal lassabb, mint ugyanaz a felbontás karakteresen...
[Szerkesztve] -
bambano
titán
Szubjektív leszek: nem kötözködni akarok, de ha framebufferen megy a karakteres konzol, az miben kényelmesebb, mint az X? Lassú, mint a csiga, azon szerintem nem lehet rendesen dolgozni. Ha a karakteres konzolt használsz nagyobb felbontásban, nem framebuffereset, az szerintem jobb. De X-en is megy minden rendesen, normális terminált vagy normális editort használva.
-
bambano
titán
Tartok tőle, hogy ez nem nagyon fog menni. Amikor az xorg átveszi a videokártya fölötti hatalmat, akkor lementi a kártya állapotát és beletölti a saját dolgait. Közben vannak időpontok, amikor nincs a kártyában konfig. Amikor visszaváltol karakteres konzolra, akkor ugyanez, fordítva.
Személy szerint nem szeretem, ha az xorg konfigban modeline van, a mostani rendszerek már automatikusan képesek konfigurálni magukat.
Egy járható út, ha karakteres konzolon is framebuffert használsz, meg X alatt is.
apt-cache search xserver xorg
xserver-xorg-video-vesa - X.Org X server -- VESA display driver
és:
xserver-xorg-video-fbdev - X.Org X server -- fbdev display driver
ezeket a csomagokat kellene kipróbálni, de ettől jó lassú lesz az X.
A szép megoldás az lenne, ha elmondanád, minek kell neked visszaváltani és esetleg ezt a gondot oldalnánk meg másképpen.
[Szerkesztve] -
bambano
titán
Minden domain név-ip összerendelésnek van alapértelmezett élettartama és frissítési tartama. pl:
host -t soa no-ip.com
no-ip.com SOA nf1.no-ip.com hostmaster.no-ip.com (
2020062252 ;serial (version)
600 ;refresh period (10 minutes)
300 ;retry interval (5 minutes)
604800 ;expire time (1 week)
600 ;default ttl (10 minutes)
)
vagy:
host -t soa dyndns.org
dyndns.org SOA ns1.dyndns.org hostmaster.dyndns.org (
3436526720 ;serial (version)
600 ;refresh period (10 minutes)
300 ;retry interval (5 minutes)
604800 ;expire time (1 week)
600 ;default ttl (10 minutes)
)
Ez azt mutatja, hogy 10 percnél gyakrabban teljesen felesleges frissíteni, mert akkor sem fognak frissülni a szerverek. Az expire egy hét, tehát az sem tekintendő hibának, ha egy hetes adat van a szervereken. Ezen határokon belül van értelme a dinamikus ip frissítésével foglalkozni, ennél gyakrabban nem.
Új hozzászólás Aktív témák
- E-book olvasók
- OnePlus 15 - van plusz energia
- Méretét meghazudtolóan hatékony Akasa léghűtő jön inteles vasakhoz
- AMD Navi Radeon™ RX 9xxx sorozat
- PlayStation 5
- AliExpress tapasztalatok
- League of Legends
- Samsung Galaxy S25 - végre van kicsi!
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- PlayStation 4
- További aktív témák...
- Vírusirtó, Antivirus, VPN kulcsok GARANCIÁVAL!
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - 15% AKCIÓ
- MS SQL Server 2016, 2017, 2019
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Bomba ár! HP ProBook 430 G5 - i5-8GEN I 8GB I 128SSD I HDMI I 13,3" FHD I Cam I W11 I Garancia!
- Apple iPhone 16 Pro 256GB Natural Titanium használt, karcmentes 6 hónap garancia
- Apple iPhone 13 / 128GB / Kártyafüggetlen / 12Hó Garancia / Akku: 88%
- AKCIÓ! Huawei Watch 4 Pro eSIM okosóra garanciával hibátlan működéssel
- Apple iPhone 17 Pro Max 256GB,Újszerű,Dobozaval,24 hónap garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest