- Milyen billentyűzetet vegyek?
- A 3D V-Cache és a rengeteg memória lehet az új PlayStation fő fejlesztési iránya
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- SSD kibeszélő
- Apple MacBook
- Androidos tablet topic
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- OLED TV topic
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Bemutatkoztak a Raijintek "platinás" Ampere II tápjai
-
PROHARDVER!
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
-
-
-
-
válasz
_Dumber_
#30578
üzenetére
Ne szivasd magad nem üzleti géppel, ha linuxot akarsz. Elitbook, thinkpad, latitude akár használtan. Esetleg ezek gagyibb verziói újonnan (E-s thinkpad, probook stb.), de azokkal azért lehetnek érdekes dolgok. A csúcskategória tuti megy Linuxal és abból is jobb 1-2 generációval ezelőtti.
Ugyan ez igaz a desktopokra is, csakis brand gépet érdemes.
-
válasz
vargalex
#30490
üzenetére
Főleg arra, hogy a kernel általában szénné van hackelve, hogy gyorsabb legyen a routing.
(#30492) vargalex Általában az alapprogramoknak kb. 4-5 féle forkja létezik, szóval nincs olyan, hogy teljes verzió
A netcat a legviccesebb, mert annak meg különböző implementációi léteznek különböző flagekkel.Bevallom én az openwrt webui-n be szoktam lőni aztán kész. Szerintem kb. soha nem ssh-ztam be rá.
-
-
válasz
Frawly
#30374
üzenetére
Simán képes "összefirkálni" a fájlrendszert amikor kiíródik a page cache. Nem véletlen, hogy minden szerverben és kritikus rendszerben ECC ram van. Arról nem is beszélve, hogy a kernel képes lapokat hibásnak jelölni, így hibás RAM esetén is biztosítható a folyamatos működés.
-
válasz
bambano
#30364
üzenetére
történhet-e memória hiba detektálatlanul, és az a sima ramnál sem fordulhat elő
De, bőven előfordulhat.
(#30366) Frawly
Erről szoftveres rétegben kéne gondoskodni, hogy az ellenőrző-összeg nyilván legyenek tartva, meg összehasonlítva eltárolásnál. Erről nem tudsz a szoftveres rétegben gondoskodni. Bőven fut olyan kód a rendszeren, amihez nem lehet plusz ellenőrzést rakni (pl. egy interrupt handler a kernelben).
Egyébként mióta PC-zek, kb. 32 éve, nekem sose volt ilyen bitflip hibám. Volt olyan, hogy a RAM vagy az alaplap volt teljes kaka, akkor sem bitflip volt, hanem azonnal fagyott az egész OS-estől, vagy be sem bootolt, olyan szinten volt hibás. Volt bőven, csak nem tudsz róla
(#30368) inf3rno Nagyon ritkán előfordulhat, hogy nem detektál egy több bites hibát, de ennek az esélye minimális. Ha unrecoverable error van akkor meg jön a fatal machine check és a kernel pánik.
-
válasz
Dißnäëß
#30067
üzenetére
Rohadt sok vasat kéne rakni egy sima Linux alá, hogy hozzon egy normálisabb otthoni routert képességben. Nyilván ezek az ASUS meg hasonlók egy vicc. 40 körül értelmes mikrotik vagy edgerouter van, plusz wifi hotspot.
kis passzív mini ITX motyó Sehol nincs egy mai normálisabb mips procis otthoni routerhez képest. Ha igen akkor meg rohadt drága (mondjuk nem vagyok benne biztos, hogy passzívan bármi értelmeset lehetne alkotni x86 alapon).
Nyilván openwrt-vel minden.
-
-
-
válasz
samujózsi
#29506
üzenetére
Az éles rendszer az több ezer node is lehet, tökéletes teszt nincs, főleg nem gyorsan. Célszerű nem cserélni csomag verziót ha nem feltétlen kell, mert túl nagy a veszélye, hogy nem lesz kompatibilis. Csak security patchet érdemes szállítani. Arról nem is beszélve, hogy a saját rendszernek is elképzelhető, hogy több verziója fut.
Ideális esetben a saját kód lesz igazítva az alaprendszerhez. Ha ez nem megoldható akkor jönnek a workaroundok, backportok.
-
válasz
bambano
#29496
üzenetére
Az ilyen webes kódoktól a hideg is kiráz... Meg úgy a webfejlesztéstől alapvetően
![;]](//cdn.rios.hu/dl/s/v1.gif)
(#29499) Frawly
tényleg csak arra lesz jó, hogy valaki megpróbálja jogászkodással a felelősséget áthárítani valaki másra Gyakran ez egy igen fontos szempont.
Szerintem a licenccel sincs probléma, főleg nem szerveren, mert a legtöbb szerveres dolog pont GPL-es opensource. Egy random rolling distrónál ki garantálja, hogy minden ami benne van jogilag jó? Egy normál distró esetén minden verzió adott, bármikor pontosan meg lehet mondani, hogy mit használunk, abban benne van-e egy adott rés stb.
-
válasz
Frawly
#29486
üzenetére
Bármi ami rolling vállati környezetbe teljesen alkalmatlan. Valami kétes licensz-el rendelkező dolog bekerül akkor az tud rohadt nagy gondokat okozni. Kritikus szerver az Redhat vagy nem open Suse.
haddent: ráadásul most már a leap opensuse az konkrétan az SLES alapján megy, a .x verziók a service packek. Szóval konkrétan ki lett tolva a támogatási idő.
-
válasz
a.gabriel
#29430
üzenetére
- továbbá az otthoni hálózatomon lévő synology nas-t sem látom, bármit teszek, mert ott tárolom az audio gyűjteményemet (böngészőn van net, tehát lát kifele a gépből)
Bridged-re kell állítani a VM hálókártyát. Ilyenkor a VM-ed az otthoni hálózattól kap címet DHCP-n és mindent látni fogsz.
(#29422) haddent Ez sem teljesen igaz, megfelelő környezetben egy managed kód lehet gyorsabb, mint egy C kód. A memória foglalás nagyon drága, persze ha jól csinálod akkor foglalsz egy gigás hugepage-et, de eddig a C programozók 99%-a nem jutott el. Mondjuk egyesek egy mmap-ig sem
A Linux kernel kb. objektumorientált kód ANSI C-ben. Van ott minden öröklődés, függvény pointerek, polimorfizmus, csak C-ben... Szóval nem explicit, de egyértelműen használva van. -
-
válasz
inf3rno
#29192
üzenetére
Szokás szerint csak a hiba üzenet fele került ide. Mint korábban már mondtam, valószínűleg dobott valamit ami betriggerelte a backtracet (mondjuk egy Oops-ot). De attól, hogy nem sikerül mountolni valamit pánik még nem lesz. Az init megdölése (vagy az, hogy el sem lehet indítani) viszont instant pánik, és csak az látszik.
-
válasz
bambano
#29190
üzenetére
Alapvetően bőven vannak debuggolási lehetőségek, csak szinte mindegyik performance impacttal jár. Szóval nem igazán érdemes bekapcsolni normál esetben. Ezek képesek akár soronként haladni, pl. ftrace, kgdb. Ha crash van akkor lementődik az egész memória kép (ha be van állítva rendesen a rendszer). Az, hogy az alapján dobjunk hibát, hogy milyen sorban vagyunk szvsz egy agyrém, normál esetben semmi értelme sincs. Ha esetleg kell ilyesmi akkor ott az ftrace.
Azért opensource, hogy bárki küldhessen be patchet. Bele hackelni szerintem otthonra sem szerencsés ötlet, kisebb elcseszések is okozhatnak nagyon furcsa problémákat. Egy kernel backtracenek sosem volt és sosem lesz célja az egyszeri felhasználó számára való olvashatóság.
-
válasz
inf3rno
#29181
üzenetére
Int return-el is ugyanúgy megoldható, egyszerűen magasabb szinten másik integert kell visszaadni, nem azt, amit alacsony szintről kapsz. Ez teljesen megoldhatatlan. A kernel nem valami 10 ezer soros sufni program.
Nyilván kevesebb fejlesztési idő, meg egyszerűbb úgy, ahogy ők csinálják, aztán az end user szívhat vele.
Az end-user beleértve a rendszer gazdit is inkább ne nyúlkáljon kernel kódba pls. A valós kernel hiba tapasztalataim szerint a kernel crash-ek kb. 5%-a, az összes többi hardver hiba (vagy firmware) hiba. -
válasz
inf3rno
#29170
üzenetére
Az van, ha az ember kernel kódot ír, akkor ezt az egész exception dolgot el lehet felejteni. Itt konkrétan int return kódok szoktak lenni, azok jelzik a hibát. A hibakezelés goto err; módon működik.
Ennek több oka is van. A fő probléma, hogy a kernel esemény vezérelt, itt egy esemény simán van, hogy egy pin 0->1 váltása. A kernel nem védett módban fut, ha valós címet akarsz írni bele is fog írni. A függvényhívás nem minden context esetén szerencsés ötlet. Pl. printk-t nem szabad interruptban hívni, mert sleepel.
Az exception ráadásul memóriát foglal ami végképp nem szerencsés ötlet.A backtrace kernel esetén önmagában nem egy egyszerű játék, nem mindig sikerül értelmes infot generálni. De normál esetben az egész memóriát lementjük és azt lehet nézegetni (vmcore).
-
válasz
inf3rno
#29151
üzenetére
Rohadtul nem kéne ext4-et initramfs nélkül csatolgatni. Nem csoda, hogy furcsa dolgokat művel.
kernel fejlesztőknek mond bármit Ok, de mégis ki más olvasgat egy pánik logot?
Amúgy előtte már valami betriggerelt egy trace-t a tsc felett látszik, csak az eleje nem. Utána pánikolt el, de egy sima backtrace az már nem jó jel.
-
válasz
Frawly
#29139
üzenetére
Célszerű lenne valamilyen initramfs-t használni, ez az adjuk meg a root partíciót módszer meglepő, hogy még támogatott. Az Attempted to kill init itt valószínűleg annyit takar, hogy nem sikerült elindítani az initet. Ha ilyet csinálsz akkor mindent be kell fordítani az md raidet is.
Ami az md RAID betöltése után következne az a root filesystem Ha jól értelmezem egy md raidről akarsz bootolni initramfs nélkül? Miért
(#29143) samujózsi Nem statikus, meg dinamikus. In-built és loadable. A kernelben nincsen dinamikus lib.
(#29148) inf3rno Ezek korrekt hibaüzenetek. Csak önmagában a "panic line" az csak egy adott sort mutat a kernelben. De ott a backtrace is. Meg normálisan konfigurált rendszeren van kernel coredump is.
-
válasz
Dißnäëß
#29059
üzenetére
Nem vagyok egy nagy szkript mágus, de ezt szerintem úgy kezdeném, hogy mindennek legenerálom az md5sum-ját. Egy-egy fájlba, aztán onnan kiindulva jöhet a többi funkció megvalósítása.
(#29073) inf3rno A modern fájlrendszerek checksum képessége tényleg hasznos. Sőt én emiatt konkrétan elavultnak tartok bármilyen nem szoftver RAID-et. A hardver RAID vezérlő meghalásától sokkal jobban félnék, mint egy stabil fs-től. A másik meg nyilván az ECC ram, ott ahol fontos adat van mindenképpen ECC ram kell.
A helyzet komolyságától függően lehet a backup-ra is szoftveres RAID-et tenni Ennek normál esetben nem látom értelmét. Ha meg valami tényleg komoly kell, akkor meg georedundancia + backup mágnesszalagra.
-
#28938
ivana
Ármester
_ _ _ _ _2 3
#28937
válasz
_ _ _ _ _2 3
#28937
üzenetére
? Újságírással és irodalommal Remélem ott követhetőbb vagy.
-
válasz
haddent
#28780
üzenetére
Szvsz célszerűbb a Wants= alkalmazása, ha minden service fájl normálisan meg van csinálva akkor elvileg elég lenne dependálni a mount service-ére. A szkriptnek meg ennyi kell egy service fájlba, erre ugyan úgy tudsz dependálni. A oneshot típus aktív marad ha nullával lép ki a szkript.
[Unit]
Description=<...>
[Service]
Type=oneshot
ExecStart=<script path>
RemainAfterExit=true
StandardOutput=journal -
válasz
bambano
#28769
üzenetére
úgy hívták: init Az init az simán csak az elsőként indított program a kernel bootolása után (vagy switchroot után, amikor initramfsből átvált a rendes root fájlrendszerre). Az init az a program, aminek a PID-je 1. A systemd is egy init, ha ezt egy shell scripttel oldod meg az is egy init etc. (Utóbbi pl. egy beágyazott rendszeren működhet, ahol akár nincsenek "rendes toolok, hanem csak busybox.) Amiről te beszélsz az a sysvinit (ami rohadtul nem szabványos, mert nincs két distró, amin ugyan úgy működik).
-
válasz
bambano
#28765
üzenetére
15 éves lappal? Cseréljék le. Ha valamiért nem lehet cserélni, akkor jó drágán támogassák a régi szoftvert. Nagyon hülye ötlet ilyenekre teljesen új szoftver rakni, főleg beágyazott környezetben (Ok mondjuk alapból maximum ott jöhet szóba ilyen, az ilyen szintűnél ezerszer jobb vasakat is rég cseréltek szerverben. LGA1366-ot megy manapság fillérekért, a nagy cégek már nem használnak annyira régi hardvert.)
Aki meg ilyet új custemernek elad annak salesesnek kötelet adnék
-
-
-
válasz
bambano
#28740
üzenetére
minek kellene több programból használni a hangrendszert??? Pl. azért ha a spotify-on leállítom a zenét, hogy megnézzek egy youtube videót ne kelljen valahogy átadni, mert rohadtul nem fog menni normálisan a dolog.
Régen nem csak pulseaudioval lehetett szívni, hanem anélkül is Manapság simán csak megy, nem érdekel különösebben mi van alatta."A BSD init amúgy egy mindennél rosszabb szkript gányolás, komplex rendszerek készítésére alkalmatlan.": merugye a systemd az nem egy szkript gányolás... A klasszik BSD style init lényegében egy shell scriptet indít, esetleg több shell scriptet, rohadtul nem a stabilitás mintaképe.
(#28741) inf3rno Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód, ami fent van a githubon. Daemon fejlesztői szempontból meg egy standardnak mondható interfész, service fájlt írni elég egyszerű.
Irni kell rá egy pár soros scriptet, ami elfedi a különbségeket, ha ennyire fontos neked.
Azért vannak különbségek voltak különbségek a distrók között, mert a sysvinit buta, mint a franc és szét kell hekkelni, hogy használható legyen. Ez a script hidd el nem pár soros lenne, meg ma már igény sincs rá, emlékszem régen mekkora szívás volt a home serveren a transmissiont daemonként beizzítani, ma simán megy, mert service fájl bárki tud írni.nem emelnék be gondolkodás nélkül egyébként stabil rendszerekbe Szerinted egy Redhat vagy SUSE szintű helyen mennyi agyalás előzött meg egy ilyen váltást? Komolyan azt gondolod, hogy csak úgy eszébe jutott valakinek, hogy akkor cseréljük le a full initet aztán megcsinálta? Ez kb. minden fejlesztő több havi munkáját igényli, költsége millió $-ban mérhető. De valószínűleg a Debiannál sem két perc volt a váltás.
Elvileg a musl a szabvány követő, és a gcc ami rosszul lett implementálva. A gcc talán a legkomolyabb compiler jelenleg, talán az icc játszik még ezen a szinten, de a gcc mindenképpen a legelterjedtebb. Az, hogy mennyire szabvány követő csak a flageken múlik.
-
válasz
Jester01
#28735
üzenetére
Az, hogy a hangkártyát normálisan tudja használni több program is egyszerre elvárható egy modern rendszer esetén.
Igen, mert a deb alapú csodák már eddig is stabilak voltak. Maximum a debian, az ubuntu mindig is egy bughalom volt. Valahogy ilyen SUSE, Redhat simán működnek systemd-vel is, meg a openSUSE, Fedora, CentOS hármas is.
beletúrkálsz a megfelelő scriptbe mert pontosan érted mi miért felelős és hogyan működik Magyarul gányolsz, mert rendesen megoldani nem sikerült, aztán a következő update megint szétcseszi. Amúgy a systemd-ben általában elég könnyen megnézhető mi döglött meg, sokkal könnyebben, mint régebbi rendszereken, plusz hatalmas előny, hogy minden distrón elég hasonló. Nincs gányolva buta sysvinit fölé ezer féle script halom.
Nem kell windowst csinálni a linuxból aki azt az architektúrát kedveli az telepítsen windowst egyből. Továbbra sem a windowsra hasonlit a systemd, hanem az OS X-re, ami amúgy certified UNIX.
-
válasz
bambano
#28719
üzenetére
A systemd amúgy az OS X initjére hasonlít erősen, nem a windowsra. Az OS X meg certified unix.
Amúgy érdekes, hogy a deb alapú csodák használói vinnyognak folyamatosan a systemd-re. Az RPM alapú distrók egyértelműen nyertek stabilitásban a váltás után.
(#28721) Jester01 A pulseaudio funkciója feltétlen szükséges a rendszerbe a normális működéshez. Az ALSA magában nem elég több programos használathoz. Azért a mostani állapot előtt voltak érdekességek.
(#28733) haddent A BSD init amúgy egy mindennél rosszabb szkript gányolás, komplex rendszerek készítésére alkalmatlan. A sysvinit meg egy olyan szintű legacy kód, hogy évek óta nem mert hozzányúlni senki.
-
válasz
sh4d0w
#28713
üzenetére
Az a baj, hogy az alternatívái a sysvinit-tel az élen ezerszer szarabbak. Mióta systemd van ezerszer stabilabbak lettek a desktop rendszerek, a szerverek esetén meg a service konfiguráció lett jóval egyszerűbb. Vannak hibái a systemd-nek, de a többihez képest sokkal jobban működik.
Példa: Futtatni akarok egy scriptet boot alatt fejlesztőként...
systemd: csinálok egy service fájlt és bemásolom a megfelelő helyre.
sysvinit: milyen distrón vagyok?
-
-
válasz
sh4d0w
#28401
üzenetére
A mainstream hardware grafikus felületes Linux esetén az üzleti laptop, meg a brand gép. A többi kb. nem érdekel senkit. Ha azzal nyitsz egy bug reportot, hogy x thinkpaden, vagy elitbookon nem megy valami akkor rá fognak nézni, ha valami nevenincs gépre ami senkinek nincs arra keresztet vethetsz.
(#28410) magmakocka Itt valami nagyon el van kefélve. nomodesettel kb. minden elindul, szóval ha azzal sem megy ott jóval nagyobb bajok vannak. Látatlanba javaslom a reinstallt.
-
-
válasz
Frawly
#28248
üzenetére
Debug printeket tuti nem fogsz kapni dyndbg nélkül.
Szóval:
1. Támogatni kell a kernelnek (valószínűleg támogatja)
2. Mountolod a debugfs-t# mount -t debugfs nodev /sys/kernel/debug
3. Bekapcsolod arra amire szeretnéd [link]Arra kell vigyázni, hogy túl sok printeléssel elég lazán ki tudod csinálni a kernelt.
-
válasz
CPT.Pirk
#28245
üzenetére
A dmesg-nél akkor is állítható amikor futtatod, normál esetben használja csak a default levelt (ez utóbbi azt szabályozza, hogy mi menjen ki soros console-ra, de minden bekerül a kürbufferbe). Lásd man dmesg. A defaultot elég sok helyen felül lehet vágni, sysfs entry biztos van hozzá.
Annyi van még, hogy a debug printeket nem fogod látni, ahhoz be kell kapcsolni a dynamic debugot és az adott driverre bekapcsolni sysfs-ben a debug üzeneteket.
-
#27427
ivana
Ármester
Victor Súgó
#27426
válasz
Victor Súgó
#27426
üzenetére
Írd le a problémát az rsync-el, foglalkoztam már vele.
-
Amíg permissivebe vagy addig semmi, a permissive eredetileg fejlesztésre van. Max. annyi baj lehet, hogy rohadt nagy lesz az audit log. Szvsz mivel performance impact van a permissive esetén is én biztos nem állítanám csak permissive-re.
Futó rendszeren a relabel egy nagy adag audit logot fog okozni.
Egy bad sector miatt sehol nem fognak HDD-t cserélni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Azért vannak különbségek voltak különbségek a distrók között, mert a sysvinit buta, mint a franc és szét kell hekkelni, hogy használható legyen. Ez a script hidd el nem pár soros lenne, meg ma már igény sincs rá, emlékszem régen mekkora szívás volt a home serveren a transmissiont daemonként beizzítani, ma simán megy, mert service fájl bárki tud írni.
Új hozzászólás Aktív témák
Hirdetés
- Autós topik
- Windows 11
- Hardcore café
- World of Tanks - MMO
- A fociról könnyedén, egy baráti társaságban
- Milyen billentyűzetet vegyek?
- A 3D V-Cache és a rengeteg memória lehet az új PlayStation fő fejlesztési iránya
- Szuper Szigettel futott be a HyperOS 3
- iPhone topik
- Milyen switch-et vegyek?
- További aktív témák...
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Eladó Steam kulcsok kedvező áron!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Antivírus szoftverek, VPN
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Dell Latitude 5330 i3-1215U 6magos! - 16GB 256GB 13.3" FHD magyarbill 1 év garancia
- Bomba Ár! Lenovo ThinkPad T540P - i7-4800MQ I 8GB I 500GB I Nvidia I 15,6" FHD I Cam I W10 I Gari!
- LG 65C3 - 65" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox!
- GYÖNYÖRŰ iPhone 13 mini 128GB Green -1 ÉV GARANCIA - Kártyafüggetlen, MS3333
- Olcsó Notebook! Dell Latitude E6540! I7 4600U / 8GB DDR3 / 128GB SSD! / HD8790M
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest