-
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
-
Szerk: látom, közben megjavult.
Erre ez így nem teljesen alkalmas.
fordított aposztrófokról hosszabb távon javasolt leszokni, mert nehezen ágyazható egymásba.
Az ilyennek lehet baja azzal, ha nagyon sok dir van egy könyvtárban, akkor nem tudja átadni a fornak paraméternek.
awk-t nem javaslom cut helyett, mert nagy, böszme és régebben sok hiba volt benne.
for i in $(ls); do
if [ -d $i ]; then
touch /home/dirtest/$i-$( ls -lG --time-style=long-iso $i | grep '^d' | awk '{print $5}')
fi
done
[Szerkesztve] -
Ha te egyszer bejelentkeztél egy gépre, akkor a teljes kde nem fog más user cuccaival elindulni. Azt tudod csinálni, hogy kde alapú alkalmazások futhassanak. Ehhez vagy azt csinálod, hogy a saját gépedről az ő accountjára ssh-zol be, vagy ha lokálgépen vagy, akkor a lokálgépre jelentkezel be ssh-n.
ssh-ban X11 port forwarding, X szerverben tcp engedélyezés kell hozzá.
Tehát vagy:
ssh -X masikuser@tavoligep.hu
vagy
ssh -X masikuser@localhost
Mostanában a debianban van olyan, hogy több grafikus környezet is futhat egyszerre, a display manager csinálja. Megoldás lehet még a beágyazott X szerver, xnest nevű csomagban, ami teljes grafikus környezetet szimulál, amire akár másik user dolgait is kirakhatod xdmcp-n keresztül. -
válasz
ngabor2
#3961
üzenetére
nem tudom, létezik-e ingyenes víruskergető a clamav-on kívül linuxra. amiket én ismerek, azok már szerverre nem ingyenesek.
12 gigából nem sok mindent lehet osztani
nem emlékszem, hogy mondtad volna, hogy ez nem neked lesz otthoni gép...
Szerverre, tűzfalra user nem ssh-zik... -
válasz
ngabor2
#3955
üzenetére
Miért, most fizetsz a driverért külön? Megveszed a kártyát, adnak hozzá egy drivert, ami nem ritkán kőkori, töltessz le frisset. Nem hinném, hogy fizetni kellett eddig a driverért.
Inkább attól félhettek, hogyha kimegy az opensource driverben a tudás, az segíthet a versenytársnak kideríteni, mit hogyan csinál a kártya. -
válasz
ngabor2
#3938
üzenetére
A nyilvánvaló megoldás lehet még az is, hogy kiveszed a diszket/diszkeket és másik, hasonló scsi vezérlővel felszerelt gépen installálod az egészet, 386-osra optimalizált kernellel. Majd raksz rá pprosat. Én úgy emlékszem, amikor ppro-s gépet telepítettem, azzal semmi extra nem volt.
-
-
Ha már legagyiztad az ext2-t, hagy jegyezzem meg, hogy legoptimálisabb szó nem létezik.
Azt nem írtad le, hogy milyen szempontok vezérelnek, amikor kiválasztod a filerendszert. Amennyiben nincs szükséged arra, hogy nagyon gyorsan bootoljon a rendszer egy esetleges összeomlás után, akkor nem feltétlenül kell naplózó filerendszer.
Reiserfst azért nem tennék fel, mert Reiser feleséggyilkosságért éppen ül, így a reiserfs fejlesztése kérdéses. A többi filerendszerrel is elvben lehetnek bajok, amíg nem tolják meg a linux stack méreteit. Meg lehetnek vele más bajok is.
Ha sebesség fő szempont, akkor ext2. Minden naplózó filerendszer lassabb, a naplózás miatt. -
Tehát akkor ismételjünk: ahhoz, hogy egy gépen grafikus felületet használó programot futtass, nem kell a gépen grafikus felület. A unixok egyik nagy előnye a MáSik világhoz képest, hogy hálózattranszparens a grafikus felületük, tehát arra a gépre kell felrakni az X-es miskulanciát, ami előtt ülsz, nem a sambás szerverre és hálózaton keresztül minden működni fog.
Szerintem a windowsok mindig rawban küldik a cuccot, sajnos. De régebben volt egy magicfilter nevű cucc, annak bármit küldhettél, kinyomtatta. Nem tudom, mostanában cupshoz létezik-e ilyen. -
én régebben használtam, de a gnu awk-ban annyi hiba volt, hogy egy idő után leszoktam róla. azóta megtanultam mindent bashban, amit eddig awk-ban írtam.
meg debianon sose tudhatod, hogy mawk, nawk vagy gawk van felrakva, aztán csak vakaródzás van, hogy valami miért nem működik.
ez persze nem zárja ki azt, hogy mondjuk akár video kazetta kölcsönzés nyilvántartást vagy internet szolgáltató adminisztrációt is megcsináljon benne az ember... -
Nézem ezt a Clint Eastwood filmet pont most az rtlen, épp kikérdez egy tanút. Nekem meg az üti ki a szemem, hogy RedHat Linux 6.1-es doksi van a tanú munkaasztala mellett a polcon...
Neeeem, nem vagyok kocka
-
Nem, az a baj, hogy a kedvedért felraktam a programot én is, (kérem higyjétek el, hogy be tudom állítani az X-et) és nekem is megrohadt ugyanott, ahol neked.
Mivel az én gépem nem mai gyerek (jó eséllyel másfajta darabokból van, mint a tied), valami generális bajba sikerült belecsápolni. -
A pam nem kezeli a DISPLAY-t. Ez architekturális tévedés. Ergo nem kellene belepiszkálni és pláne nem kellene rossz tanácsokat osztogatni.
Van helyette jó megoldás, itt is elhangzott. Ne szoktassuk rá a kezdőket téves megoldásokra.
Most pl. ráklikkeltem a menüre és két lehetőséget is találtam:
- nested X szerver, teljes root sessionnal
- rendszergazda terminál, minden trükközést megold a menü
Minek kell kotorászni a pamban, ahol esély van rá, hogy porbadöntöd a rendszert, mikor kész megoldás van a gépen, kettő is??? -
válasz
ngabor2
#3675
üzenetére
Ha köréraksz egy olyan környezetet, ami a hangup szignált elkapja, akkor nem lép ki. Erre van kész shell parancs, vagyis ha így indítod a programot:
nohup programnev &
akkor nem fogja eldobni, ha kilépsz. A nohup.out fileba rakja bele a kimeneteket.
De a screen, az at és a cron is jó erre.
Szerk: bocs, olvasás terén kihívásokkal küzdök.
[Szerkesztve] -
-
Van itt egy ilyen gép:
00:00.0 Host bridge [0600]: Intel Corporation P965/G965 Memory Controller Hub [8086:29a0] (rev 02)
00:01.0 PCI bridge [0604]: Intel Corporation P965/G965 PCI Express Root Port [8086:29a1] (rev 02)
00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 [8086:283f] (rev 02)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 [8086:2845] (rev 02)
00:1c.4 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 [8086:2847] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev f2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller [8086:2810] (rev 02)
00:1f.2 SATA controller [0106]: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) SATA AHCI Controller [8086:2824] (rev 02)
00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus Controller [8086:283e] (rev 02)
01:00.0 VGA compatible controller [0300]: nVidia Corporation G70 [GeForce 7600 GS] [10de:0392] (rev a1)
02:00.0 SATA controller [0106]: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller [197b:2363] (rev 02)
02:00.1 IDE interface [0101]: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller [197b:2363] (rev 02)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01)
lsmod|grep snd
snd_hda_intel 17332 4
snd_hda_codec 137856 1 snd_hda_intel
snd_pcm_oss 38368 0
snd_pcm 68676 4 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_mixer_oss 15200 1 snd_pcm_oss
snd_seq_dummy 3844 0
snd_seq_oss 28768 0
snd_seq_midi_event 7008 1 snd_seq_oss
snd_seq 45680 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_timer 20996 3 snd_pcm,snd_seq
snd_seq_device 7820 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd 47012 15 snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_pcm,snd_mixer_oss,snd_seq_oss,snd_seq,snd_timer,snd_seq_device
soundcore 9248 1 snd
snd_page_alloc 9640 2 snd_hda_intel,snd_pcm -
-
-
válasz
VladimirR
#3581
üzenetére
Minden olyan processz szeret fejreállni, mint a szög, amelyik dns szervert használ, ha elmegy a hálózat. Az a jobbik eset, ha ilyenkor magától rebootol a gép, ilyet a watchdog csinálhat, a rosszabbik eset, ha ilyenkor úgy megkavarodik az agya, hogy nem lehet rebootolni.
Ez személyes tapasztalat. Illetve mostanában látok gyakran olyat, hogy kis terhelésen elgurul a cucc, de ha megtolják alatta a hálózatot, akkor fejreáll az ethernet kártya drivere. Ilyen régebben realtek kártyáknál volt, mostanában marvell kártyákra jellemző, illetve minden olyanra, amit sky2 driverrel kell hajtani. -
válasz
ngabor2
#3572
üzenetére
Az a link 2001. 40. hetéből való. Eléggé nem sanszos, hogy a kerneled olyan régi, de ha elárulnád, hogy milyen kernel van a gépen, talán tudnánk segíteni. Meg azt is, volt-e valami hibád, van-e software watchdogod, ilyenek. A mostani kernelek elég meredek dolgokat tudnak csinálni raiddel, vagy ha hálózati problémád van, stb.
milyen az a web ÉS http szerver? -
Ezzel szemben a fapados debianban van dbus és hal, udev-vel, meg gnome volume manager. kioslave is volna benne, de még sose használtam kde-t, így ezt nem teszteltem. A debian valóban fapadosnak tűnik, főleg, ha az 5-6 éves verzióit nézzük.
Az lvm2 pedig kezelhető windows alól: [link] -
Szerintem a webmail kliensek nem mysql-ből autentikálnak, hanem a courier imapd-t használják erre a célra. Tehát bármelyiket lehet használni, amelyik kompatibilis az imapd-vel (asszem a courier 4.1-es imap protokollt tud, de nem vagyok biztos benne). Amelyik tetszik. Nekem mókus van, de nagyon ritkán használom.
-
-
-
ott kell lennie, hogy:
hosts: files dns
Amikor a sendmail kézbesíteni próbál egy levelet, akkor kiderítni, hogy ki az mx-e az adott domainnek és utána vagy a hostsból vagy a dns-ből kideríti, hogy hol az a gép.
Ha küldessz egy nev@akarmi.com-ra, akkor először megnézi, hogy az akarmi.com-hoz van-e ip cím rendelve (szerintem nem jó szokás domainhez ip címet rendelni, de elvileg lehet). Ha nincs, megnézi, van-e mx rekord akarmi.com-hoz, ez utóbbi lépést mindig a dns-ben nézi. Ha talált olyat, hogy akarmi.com-nak mx-e a gepnev.akarmi.com, akkor már a gepnev.akarmi.com-ot fogja kikeresni. Ha megtalálja a hosts-ban, akkor odaküldi, ha nem, akkor kikeresi dns-ből.
tehát megnézed, hogy a
host -t mx akarmi.com
utasítás milyen mx-eket sorol és az mx gépeket kell korrigált ip címmel és eredeti névvel bevésni a hosts-ba. -
Tehát akkor mégegyszer: az mx rekord domain NÉVRE mutat, nem domainre, ezt ne keverjük. A domain nevet és a helyes ip címet kell bevésni a hostsba. Kétségeim vannak afelől, hogy a sendmail képes-e figyelmen kívül hagyni a hosts filet, ugyanis az a rezolver dolga, hogy foglakozik-e vele vagy sem, nem a sendmailé. Ha a /etc/nsswitch.conf jól van kitöltve, akkor szerintem a sendmail nem nagyon tudja kikerülni.
-
No, hogy ne hiedelmek meg mítoszok alapján beszéljünk, csináltam most egy mérést. A feltételezés ugye az, hogy minél ócskább a gép, annál lassabb a naplózó filerendszer az ext2-höz képest. További feltételezés még, hogy ez a lassulás akár 40-50%-ot is elérhet.
Itt egy izompacsirta gépen, bonnie++-szal mérve az ext2 98243K/sec-cel írt, az ext3 88054 K/sec-cel, az xfs 82827K/sec-cel, a reiserfs pedig 87764 K/sec-cel (ez utóbbi gondolom reiser3 lehet, a debian csak reiserfs-nek hívja, viszont van külön reiser4 csomag).
98243/82827=1.18612, tehát az eredeti feltételezés majdnem fele megvan. Ez egy két diszkes raid1 volt, ami az átlapolódó műveletek miatt szerintem gyorsabb, mint a gyalog diszk, illetve ez a gép sokkal jobb hardver, mint amit otthon használok fájlok tárolására. Az egy 233Mhz-es p1, 128M rammal, 250Gs samsung pata diszkekkel, ez egy 930D, 2G ddr2/800-as rammal, wd400ks sata diszkekkel. A p1-es gép nem hibás, hanem simán régi.
Nincs most kéznél önálló diszk, pedig lehet, hogy volna értelme nem raid0-n hanem egy darab diszken is tesztelni ugyanezt.
Úgy gondolom, továbbra is maradok annál a véleménynél, hogy minél ócskább gép, annál inkább lassú a naplózó filerendszer az ext2-höz képest. -
A system map arra jó, hogyha valami kernel programozási hiba miatt összeborul a kernel és szeretnéd bejelenteni a fejlesztőknek a hibát, akkor a system mapra szükség van ahhoz, hogy kideríthessék, merre járt a kernel, amikor eldobta az agyát. Régebben mintha a ps is használta volna, de ez nem mostanában volt.
-
''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
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. -
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. -
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
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
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
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
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
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
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. -
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
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
válasz
Vilmoskorte
#3336
üzenetére
Az a domain, amilyen feladóval ki akartad küldeni a levelet, rendesen létezik?
nem emlékszem, hogy mondtad volna, hogy ez nem neked lesz otthoni gép...
Létezik 50-80 eres scsi átalakító.
Új hozzászólás Aktív témák
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- PH! aranyköpések
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Óra topik
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Milyen légkondit a lakásba?
- Milyen TV-t vegyek?
- PLC programozás
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- One otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- HIBÁTLAN iPhone 14 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3017, 100% Akkumulátor
- BESZÁMÍTÁS! MSI H310M i5 9500 16GB DDR4 120GB SSD 2TB HDD RTX 2060 Super 8GB ÚJ Zalman T4 Plus 600W
- Apple iPhone 15 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- HP EliteBook 850 G7 15.6 inch (256GB SSD, i7-10610U, 8GB DDR4) Akció!
- GYÖNYÖRŰ iPhone 13 mini 128GB Green -1 ÉV GARANCIA - Kártyafüggetlen, MS3837, 100% Akkumulátor
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: Laptopműhely Bt.
Város: Budapest