- Fotók, videók mobillal
- iPhone topik
- Erős specifikáció, kompakt formában
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Honor 200 - kétszázért pont jó lenne
- Samsung Galaxy S21 FE 5G - utóirat
- Samsung Galaxy S23 Ultra - non plus ultra
- Yettel topik
- Android alkalmazások - szoftver kibeszélő topik
- Milyen okostelefont vegyek?
-
Mobilarena
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
-
inf3rno
nagyúr
válasz
Krystal_s
#30202
üzenetére
Nem muszáj lehúzni róla. Én le szoktam, mert úgy biztosan nem formázok semmit véletlenül meg írom be a GRUB-ot oda, ahova nem kéne. Megy anélkül is, ez csak megszokás. Egyébként a GRUB javítható, ha rossz helyre kerül.
Lehet velem van a probléma, de már nem az első eset az itteni kérdéseknél, hogy nem tudom követni melyik gép melyik. Te is először azt írod, hogy fenti meg lenti gép, aztán utána én gépem meg másik gép. Igy azért nem egyszerű rákeresni, ha azt se tudjuk melyik hardver összeállítás a hibás, vagy hogy minek lehet driver gondja a kettő közül. Pl a 6300-ra ezt találni: [link] Mondjuk nekem eleve nem szimpi, hogy lerántatja veled a gedit-et, csak mert ő azt szereti. A gyakorlatban bármelyik szövegszerkesztő jó. Ugyanúgy a wifi powersave-en állítanak, ahogy nézem. Más nincs. A 6200-ra még ennyi sincs. Gondolom neked is ez a driver van fent: [link]. Hallani még olyat, hogyha bluetooth is megy, akkor belassul az egész. Máshol is azt olvasom, hogy a power save-et kapcsolták ki teljesen. [link] Laptopoknál odaverhet az aksinak, de amúgy ennek kéne lennie a megoldásnak. Mennie kéne live linux-al is szerintem. A "sudo modprobe -r iwlwifi" amivel kikapcsolhatod a "sudo modprobe iwlwifi power_save=0", amivel elindíthatod. Valószínűleg ki kell kapcsolni ahhoz, hogy újrainduljon, bár ebben nem vagyok teljesen biztos. A "11n_disable=1" vagy "11n_disable=8" is kipróbálható. Más értékeket is meg lehet nézni rá, de ezekre mondják, hogy a legjobban működnek úgy általánosságban. Még van több paraméter is, de azok nem tűnnek annyira relevánsnak.
-
inf3rno
nagyúr
válasz
Krystal_s
#30194
üzenetére
Hát nem kéne, hogy jobban szeresse a nagyobb távolságot. Ha ugyanúgy live linux-al próbáltad, akkor lehet, hogy hálókártya vagy antenna hiba. Az energiagazdálkodás is szóba jöhet, amit írtál, főleg ha valami laptopról van szó. Ha aksiról megy, akkor leveszi mindenről az áramot. Dugd rá hálózatra. UEFI/BIOS-ban is vannak beállítások energia gazdálkodásra, ahhoz is hozzá lehet nyúlni.
-
-
inf3rno
nagyúr
válasz
bambano
#30171
üzenetére
Nem vagyok benne biztos, hogy erre az egészre van tényleges igény. Mármint egy irodában azért előbb vagy utóbb mindenkinek világossá válik, ha nem megy egy nyomtató, és a másikra kell küldeni a nyomtatni valót. Utána meg pár lépéssel több, de ideiglenesen belefér. Ha valami program nyomtat, akkor meg gondolom az is kap valami visszajelzést, hogy sikerült e a nyomtatás vagy nem. És ha nem, akkor megpróbálhatja a másik nyomtatóval.
Tulajdonképp amit akarsz az az, hogy egy bizonyos porthoz legyen kötve az IP cím. Ezt tudják bizonyos managed switch-ek elvileg. Ez is alátámasztja [link].
Lehet még elé tenni egy gépet, CUPS szervert rátenni, és arra kötni a nyomtatót, pl USB-vel és úgy nyomtatni. Viszont akkor tök felesleges hálózati nyomtatót tartani.
Ezen kívül jogkör nélkül nem hiszem, hogy bárki bele tud nyúlni abba, hogy melyik mac address melyik IP címet kapja. Max még azt lehet, hogy a hosts fájlba írsz bele egy programmal vagy DNS szervert használsz.
-
inf3rno
nagyúr
válasz
Dißnäëß
#30156
üzenetére
Szerintem felesleges. Annyira nem lehet bonyolult a logikája, hogy egy arduino ne bírná el. Egy HTTP szerver is olyan, hogy simán elviszi. Ha loggolni akarod a szenzor adatokat, és feldolgozni, ahhoz esetleg kell valami komolyabb egy ilyen adatbázissal: [link]
Milyen poén lehet úgy enni valamit az asztalon, mondjuk egy kis tepsis fűszeres burgonyát, hogy a krumpli a saját biokrumplink, amit a kütyük neveltek fel, az ubisali uborkája és fokhagymája dettó, paradicsom, stb. minden az asztalon az "üvegházból" van
Csak aztán a végén nehogy ide lyukadjunk ki
"Vannak mezők, végtelen mezők, ahol az emberek többé nem születnek. Tenyésztenek bennünket. Sokáig nem akartam elhinni, de aztán saját szememmel láttam a mezőket. Láttam, hogyan cseppfolyósítják a holtakat, hogy intravénásan táplálhassák az élőket."
-
inf3rno
nagyúr
válasz
Dißnäëß
#30152
üzenetére
Pedig elvileg megy arduino-val is a nodejs. Az elvadultabbak ESP32-vel tolják az ilyen szenzorozást, de az a nagy baja, hogy nincs olyan változat, amin normálisan meg van oldva a POE, úgyhogy két vezetéket kell vinni, meg gondolom valami egyenáramú rendszert is kialakítani. Lehet wifi-vel is, de az megdobja a villanyszámlát gondolom, és bár alacsony a fogyasztása, de ha 100 ilyen kütyüt kiteszel, akkor azért már tud villanyszámlát generálni. Amúgy pont ilyen üvegházas projekthez néztem őket én is. Mindketten lusták vagyunk öntözni asszem.
Az elektronika engem is érdekel, de még nem ástam bele magam. Nagyjából az a végcél, hogy értsem, hogy hogyan működik egy számítógép, egy oprendszer, meg rajta mondjuk egy nodejs, plusz ugye a hálózati kommunikáció. Ez azért legalább egy évtizedre elég anyag szerintem. A mikrokernel azért izgi, mert annál olyan 10k sor a kernel, és azt egy átlagos programozó azért még képes átlátni. Persze ami máshol a kernelben van, az mind kimegy alkalmazásnak, de egyszerűbb így leszűkíteni a minimumra. Pl ha egy hello word-ig eljutok soros porton keresztül az már fincsi, Utána lehet mókolni tovább hálókártya driverrel meg videokártya driverrel, meg ilyesmikkel. Az arduino sem áll olyan nagyon messze ettől. Lehet, hogy mikrokernelezésre veszek egyet, mert a szerver gépet teljesen más célra szánom. Meg egyébként is jobb, ha egy arduino füstöl el, ha valamit elcseszek, mint egy drága gép.
Ja hát nekem most egyelőre a UPC-nek a routere van itt, úgyhogy nem tudok belenyúlni. Ha kimondottan indokolt lenne, akkor vennék valami Asus-t és menne rá a WRT, de most még nem érzem szükségét, és a pénzt meg nem akarom annyira szórni.
-
inf3rno
nagyúr
válasz
Dißnäëß
#30148
üzenetére
Szerintem az alapelvek ugyanazok lehetnek mindegyiknél. Egyszer kell megtanulni, utána meg elég beleolvasni a manual-ba. Én most éppen a microkernel-es operációs rendszerekbe vagyok belezúgva, azon belül is vannak nagyon érdekes projektek: [https://en.wikipedia.org/wiki/MINIX] https://en.wikipedia.org/wiki/L4_microkernel_family https://github.com/seL4/seL4 https://github.com/kernkonzept/l4re-core https://github.com/chrissicool/l4openbsd
https://genode.org/download/sculpt Úgyhogy van mit olvasgatni. De kb. úgy működök, mint egy processzor, csinálok valamit egy ideig, aztán ha megunom, akkor átváltok egy másik folyamatra, úgyhogy előbb vagy utóbb ez a tűzfalazás is sorra fog kerülni. -
inf3rno
nagyúr
válasz
Fecogame
#30141
üzenetére
Ránézésre ez ennyit csinál, a többi meg körítés:
iptables port_scanners hash:ip family inet hashsize 32768 maxelem 65536 timeout 600
iptables scanned_ports hash:ip,port family inet hashsize 32768 maxelem 65536 timeout 60
iptables INPUT -m state --state INVALID -j DROP
iptables INPUT -m state --state NEW -m set ! --match-set scanned_ports src,dst -m hashlimit --hashlimit-above 1/hour --hashlimit-burst 5 --hashlimit-mode srcip --hashlimit-name portscan --hashlimit-htable-expire 10000 -j SET --add-set port_scanners src --exist
iptables INPUT -m state --state NEW -m set --match-set port_scanners src -j DROP
iptables INPUT -m state --state NEW -j SET --add-set scanned_ports src,dstAzért én óvatosabb lennék a helyedben az ilyen scriptekkel, mert ezzel gyakorlatilag átadtad az irányítást a géped felett a script írójának [link] Aztán erősen bízol benne, hogy a következő release nem támadókódot tartalmaz.
-
inf3rno
nagyúr
válasz
Dißnäëß
#30140
üzenetére
Köszi! Igy már jóval világosabb. Erre a DROP témára rákérdeztem egy Q&A oldalon, hátha tudja valaki a választ. Ha nem, akkor majd kipróbálom az itthoni szerveren. Egyelőre most nem Linux van rajta, úgyhogy az iptables nem játszik, de szerintem van valami alternatíva, amivel meg lehet csinálni ugyanezt.
-
inf3rno
nagyúr
válasz
Dißnäëß
#30061
üzenetére
"alapból úgyis zárva az SSH (példánál maradva) és port knocking-al, kopogtatva lehet kinyittatni azt ideiglenesen a host-al, az adott beérkezônek"
Nem teljesen világos, hogy ez alatt mit értettél. Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat. Vagy valamit nagyon nem értek a hálózati kommunikációból.
Ahogy nézem elképzelhető, hogy ez az iptables-es mókolás sem véd port scan ellen:: [link] Legalábbis azt írják, hogy úgy válaszol ezeknél a DROP-oknál a szerver, hogy azt mondja, hogy a szolgáltatás a port mögött éppen nem elérhető. Tehát annyi információ szivárogni fog, hogy melyik port mögött van szolgáltatás, de hozzáférni nem tudnak, ha nem ismerik a kopogási szekvenciát. Ebből viszont már tudnak következtetni arra, hogy kopogni kell, és vannak már botok arra, hogy brute force-al végigpróbálják. Arra jó, hogy még egy réteget beteszünk biztonsági szempontból az SSH fölé, de messze nem rejti el teljesen a szolgáltatásainkat és nem feltörhetetlen.
Tulképp ha a fenti igaz, és csak azokra a portokra tolunk port forwardot, amik a szekvencia részei, akkor baromi gyorsan fel lehet törni. Azt hiszem rászánom majd az időt, hogy demonstráljam. Egyelőre most vannak fontosabb dolgaim.
-
inf3rno
nagyúr
-
inf3rno
nagyúr
válasz
Dißnäëß
#30106
üzenetére
Én úgy tudom, hogy dedup-hoz kell csak sok memória hozzá, ha azt kikapcsolod, akkor egész szolidan eszik. De még csak tanulom ezeket a fájlrendszereket. Esetleg tudnál írni valamit a tényleges memória használatáról a zfs-nek, btrfs-nek, ilyesmiknek pl ext4-hez képest?
-
-
inf3rno
nagyúr
válasz
Dißnäëß
#30063
üzenetére
Jól értem, hogyha van valami OpenWRT-s router, akkor megoldható rajta ez a port knocking, ha meg csak egy szimpla szolgáltatós router van, akkor nem? Akkor mi van, ha beállítok egy port forwardot egy nagy darab port tartományra a routeren, és a szerveren csinálom ezt a port knocking-ot?
-
inf3rno
nagyúr
válasz
bambano
#29941
üzenetére
Itt azt mondják, hogy jobb clusterben csinálni, mert egy gépnél hamar elfogy a memória és a processzor idő. [link]
Itt wireguard-ot ajánlják clusterbe, talán hasznos lehet: [link] Openconnect még amire azt mondták, hogy jobb, mint az OpenVPN, de azt már régebben olvastam, és kb. minden jobb annál az eddigiek alapján. Mondjuk a helyi kórházban attól még OpenVPN-el tolják valamiért, de lehet csak a kliens gépeken. Nem tudok sokat a témáról, de gondolom vannak szabványos megoldások, amik miatt sok VPN kliens kompatibilis sokféle VPN szerverrel...
-
inf3rno
nagyúr
válasz
bambano
#29932
üzenetére
Ja ezt néztem régebben, de nem kell komolyan venni szerintem, többek között azért sem, mert egy systemd fejlesztő mondja. Azok alapján, amit FreeBSD fórumon olvasok systemd-vel kapcsolatban kizártnak tartom, hogy bármi ilyesmit elfogadna a közösség. Nagyjából az az álláspont, hogy megnézik, és ha találnak bármi használható ötletet benne, azt esetleg belekódolják FreeBSD-be, de eddig nem tűnik úgy, hogy kifejezetten rajonganának bármiért is, ami benne van. A gummiboot-ot sajnálom, hogy benyelte az a fekete lyuk, úgy tűnik jó boot loader volt, de így, hogy már a systemd-sek határozzák meg a fejlesztés irányát, supportot, stb., jobb kukázni.
-
inf3rno
nagyúr
Néztem már DragonFly-t, de azt mondják, hogy nem igen van meg az emberanyag ahhoz, hogy komolyan lehessen venni. Amúgy tetszettek az elképzeléseik, de így nem vágnék bele. Nagyjából az a terv, hogy mindent áttelepítek rá asztali gépről, csinálok egy webes felületet, ahol lehet képeket nézni, pdf-et olvasni, videot nézni,, zenét lejátszani helyi hálózatról, meg mindent kereshetővé teszek, a bookmarkjaimat is, mert annyi van, hogy már évek óta nem igazodok ki köztük. Melós, de szerintem megéri. Ezen felül kell rá egy VPN szerver, hogy elérjem akkor is ha utazok, illetve amikor projekteken dolgozok, akkor is jól jön egy olyan szervernek, amin demot be tudok mutatni ügyfeleknek. Valószínűleg teszek rá gitea-t is, hogyha fejlesztek, akkor egyből mehessen rá, és ne feltétlen kelljen mindent feltennem github-ra, akár private repo-ba sem. Tuti még ezen felül is jó lesz valamire, de most nagyjából ezek a tervek. Már halogatom néhány éve amúgy, de most megvan a motiváció hozzá. Rendbe akarom tenni az asztali gépet is, és ahhoz jobb, ha nem ezen vannak az adatok.
-
inf3rno
nagyúr
válasz
Frawly
#29925
üzenetére
Van rajta Wine én úgy tudom, de azért nem teljesen bug mentes. A wiki szerint is van, de ott még 2.1-es Wine-t írnak 2013-ból. [link] Gondolom azóta nem frissítették a wikit. Ettől függetlenül asztalinak nem sokan ajánlják, inkább szervernek való OS. Driverek terén azt mondják, hogy vagy stabilan működik, és sosincs vele bajod, vagy annyira megrogyik már az elején, hogy esélyed sincs. Majd még írok róla, én hajlandó vagyok rászánni az időt, és nem akkora probléma, ha valami nem megy out of the box, ha némi kereséssel találok rá megoldást. Nem annyira komplikált ami most kell, hogy ne lehetne megoldani vele.
-
inf3rno
nagyúr
válasz
sh4d0w
#29906
üzenetére
Köszi, de már úgy néz ki FreeBSD lesz. Alpine felé valahogy nem tudtam úgy elköteleződni, mint efelé. Sokkal szimpatikusabbak ennek a fórumán. Azért majd kísérletezek Alpine-al is desktopon mielőtt felteszem a Void-ot, meg ki tudja ezzel is hova jutok majd szerveren. Egyelőre elkezdtem olvasni egy 700 oldalas könyvet az OS-ről, most tartok 70 oldalnál. Nem valami bonyolult, némi történelem, parancssoros alapok voltak eddig. Majd még jelentkezem, szerintem ezzel elleszek egy hétig.
-
inf3rno
nagyúr
válasz
sh4d0w
#29900
üzenetére
Én FreeBSD-t fogom tesztelni nem sokára. Szerverre még Alpine ami szóba jöhet. Most úgy döntöttem, hogy rászánom az időt, és még ebben a hónapba menni fog a szerver. Már 2 vagy 3 éve halogatom a fellövését, azóta csak porosodik, mert mindig volt jobb dolgom. Ha átpakoltam a fájljaimat, akkor utána az asztalira szerintem Void lesz, a Win7-et váltja majd. Az utóbbi teljesen megette a 120GB-os SSD-met az update-jeivel.
-
inf3rno
nagyúr
-
-
inf3rno
nagyúr
válasz
Frawly
#29540
üzenetére
Itt helyben is Windows és SAP van az egyik nagy cégnél, a helyi informatikus gárdát meg teljesen leépítették. Nem értem személy szerint, hogy minek az SAP, amikor a régi ügyviteli rendszer is működött, amit az itteni informatikusok heggesztettek össze, és irdatlan összegeket költöttek az átállásra. Nem látom értelmét az outsourcing-nak, de biztosan működik, ha ennyi cég csinálja...
-
inf3rno
nagyúr
válasz
Jester01
#29440
üzenetére
Elég beírnom konzolba, hogy node, a repl szükségtelen, azért nem is jegyeztem meg, most kerestem elő google-el, hogy ne véletlen shellt vagy ilyesmit írjak. A node egyébként csomópontot jelent, nem nehéz megjegyezni. Fájl kezeléshez mondjuk kell az fs modul, ami file system, szintén elég szokványos rövidítés. Azon belül mondjuk egy fs.createReadStream vagy fs.readFile nem okoz nehézséget, hogy mit jelent, de ha mégis, akkor a számítástechnika alapjai sem mennek. Ezzel szemben az "ls -1 node_modules | wc -l " ránézésre kínai, vagy akár jelentheti azt is, hogy "let's shit node modules or go to the wc". Persze magyarázhatod tovább, a lényegen nem változtat.
-
inf3rno
nagyúr
válasz
samujózsi
#29421
üzenetére
Ja, de senki sem követi, akkor meg sok értelme nincsen. A JSON meg az XML ezzel szemben standard formátumok. De ha ezen belül is kell valami szabvány külön logra, akkor vagy külön MIME típust kell valamelyik fölé gyártani, ami meghatározza, hogy milyen property-k lehetnek pl egy JSON-ban. A másik megoldás az RDF vagy XML+RDF vagy JSON-LD, aminél lehet vocabot gyártani az adott célra. Nekem egyébként az szimpatikusabb, mert könnyebb módosítani, bővíteni, mint egy szabványt. A schema.org pl ilyen, csak az nem logokra van.
Sokszor jobbak a kész megoldások. Azért érdemes belenézni a kódba, mert ha sűrűn megy az eval, akkor pl injektálhatnak. Markdown parsereknél láttam ilyesmit azt hiszem.
-
inf3rno
nagyúr
válasz
bambano
#29420
üzenetére
"mondtam én, hogy * nem szabványos formátum? hint: nem mondtam." (*: a JSON)
"Monitoring adatokat pont, hogy igenis valamilyen sztenderdizált formátumban és azon belül is szépen formázva adunk ki,: vagyis csv-ben, és még véletlenül sem json-ben."
Egy kicsit önellentmondóak a hozzászólásaid.
-
inf3rno
nagyúr
-
inf3rno
nagyúr
válasz
samujózsi
#29408
üzenetére
Én személy szerint rühellem ezeket a shell scriptes parancsokat, vagy nevezd, aminek akarod. sed = stream editor, grep = global regular expression print. Aztán próbálj emlékezni, hogy melyik fogalomhoz melyik rövidítés tartozik, főleg ha magyarul jegyzed meg, hogy melyik mit csinál. Kb. olyan, mint szótárat magolni. Lehet, hogy a 70-es években még ez volt a menő, de szerintem manapság már elég túlhaladott. Egyébként a funkcionális programozásra emlékeztet elég erőteljesen, nem véletlenül utálom azt is. A hülyék meg pont abban szoktak azzal kérkedni, hogy jajj mekkora májer vagyok, megcsináltam egy ezer karakteres sorban az egész programot...
-
-
inf3rno
nagyúr
válasz
haddent
#29362
üzenetére
Nem tudom, én csak ránézek egy Python kódra és elfog a hányinger. Nekem a Java, ami mindig is tetszett, szép, rendezett. Kivéve a többszálú programozás, az annyira nem jön be egyik nyelven sem, abból nekem az tűnik vállalható iránynak, amit a nodejs csinál, hogy megosztott memória helyett mennek az üzenetek, de az meg gondolom jóval lassabb, mint a többi.
-
inf3rno
nagyúr
válasz
Dißnäëß
#29320
üzenetére
Szerintem teljesen felesleges ezzel bajlódni. Nem jelent számottevő plusz védelmet. A titkosításnak kell jónak lenni, aztán nézheti az NSA is, nem tudják feltörni belátható időn belül, ha nem olyan az algoritmus, ami alapból hibás. Valszeg nem is nagyon fognak próbálkozni vele, hanem megdolgoznak egy kicsit, hogy add meg nekik a kulcsot, ha olyasmiről van szó...
-
inf3rno
nagyúr
válasz
Frawly
#29222
üzenetére
Nem hiszem. Mármint nekem úgy tűnt, hogy a GRUB csak annyit tesz, hogy átadja a paramétereket a kernelnek. A lényegi munkát a kernel végzi ezzel kapcsolatban. Legalábbis ez jött le abból a pár sorból, amit elolvastam a témában, meg ha belegondolsz a soros portos driverek vagy mi a szösz is a kernelben van, nem a GRUB-ban... Nem is vagyok benne biztos, hogy beleférne a GRUB-ba, de mióta bejött a GPT meg az EFI már nehezen követem, hogy mi hány MB lehet. Valami olyasmi rémlik, hogy MBR-el és BIOS-al elég kötött volt a bootloader mérete és valahol a lemez elején kapott helyet valami olyan helyen, amit elvileg nem is erre találtak ki. Mióta bejött a GPT talán már nincs ilyen megkötés, passz.
-
inf3rno
nagyúr
válasz
samujózsi
#29205
üzenetére
Nekem hasznos igazából annyi lenne a napi dolgokban, hogy adjon valami tippet, hogy melyik hardver vagy driver vagy beállítás hibás. Az egész kb egy sor lenne. Ehelyett valami katyvaszt ad, amivel a fejlesztőkön kívül senki nem tud mit kezdeni. Weben is nem véletlenül írunk 500 internal server errort meg 404 not found-ot vagy ilyesmiket ahelyett, hogy a teljes trace-t odanyomnánk az end user pofájába. Egyrészt biztonsági kockázat, másrészt meg úgysem tudna mit kezdeni vele, mert nincs hatásköre hozzá és nagy valószínűséggel nem ért hozzá. Ugyanez a megközelítés lenne jó itt is. Aztán aki hozzáértő az megnézheti debug mode-ban a trace-t meg minden ilyen extra dolgot, aki meg nem, annak elég tudnia, hogy a videokártya adta be a kulcsot vagy annak a driverét kellene frissíteni. Na csak ennyi, gondolom még néhány száz év, mire ilyen OS is lesz.
-
-
inf3rno
nagyúr
válasz
samujózsi
#29193
üzenetére
Nem voltam benne biztos, de rákerestem: [link] Ezek alapján nem lehet az elejére scrollozni kernel panic esetében. Szerinted ennek így mi értelme? Biztos, hogy valahol ott van az elején, de az átlag felhasználó nem fogja tudni elolvasni... Aztán lehet, hogy 5 év alatt változott a dolog, nem szoktam kernel panicokat lapozgatni.
-
inf3rno
nagyúr
Nem nagyon megy át, de nem ezzel van a problémánk, hanem azzal, hogy olyan hibaüzeneteket dob, amik minimálisan vagy egyáltalán nem segítenek a probléma megoldásban. Ennek semmi köze a kernel debuggolásához vagy fejlesztéséhez. A fenti esetben pl annyit kellett volna dobnia, hogy nincs rootfs csatolva és ezért leáll, mert az átlag felhasználónak erre az információra van szüksége. Ehelyett valami baromságot írt. Szerintem ez így nincs rendben, és szerintem megoldható lenne, hogy normális hibaüzeneteket adjon, csak a fejlesztők nem foglalkoznak a kérdéssel, mert plusz munka. Egyébként ez a windows-t is érinti, főleg hardver hibánál csak találgat az ember, mert nálam pl alaplap hibára írta, hogy a videokártya illesztő összeomlott...
-
inf3rno
nagyúr
Int return-el is ugyanúgy megoldható, egyszerűen magasabb szinten másik integert kell visszaadni, nem azt, amit alacsony szintről kapsz. A goto err esetén nyilván nem megoldható, de gondolom legtöbbször az is magasabb szinten dől el, hogy szükség van e rá, vagy áthidalható a probléma máshogy. Nyilván kevesebb fejlesztési idő, meg egyszerűbb úgy, ahogy ők csinálják, aztán az end user szívhat vele.
-
inf3rno
nagyúr
válasz
Papooo
#29168
üzenetére
Hát nem tudom, nekem általában csak a táp és a ház szokott akörül lenni függetlenül attól, hogy mit rakok bele. Azok mondjuk onnantól gyakorlatilag korlátlan ideig mennek, meg nem vágják gallyra a többi elektronikát. A hűtésen sem szoktam spórolni, sosem megy 40 fok fölé a cpu böngészésnél meg ilyen alap dolgoknál, csak játéknál, a hangja meg annyi, hogy sokszor nem is tudom megállapítani az alapján, hogy be van e kapcsolva a gép.
-
inf3rno
nagyúr
válasz
samujózsi
#29166
üzenetére
Az van, hogyha az ember kódot ír, akkor rétegezni szokás a kivételeket. Pl teszem azt fájlt akarok írni, szór egy kivételt, hogy lockolva van a fájl, elkapom, aztán szórok egy magasabb szintű kivételt, hogy sajnos nem sikerült a fájl írása, és ahhoz csatolom az előző kivétel, hogy miért nem. Utána megint elkapom, és dobok mondjuk egy olyat, hogy nem sikerült menteni a játék állását, és ahhoz csatolom az előző kettőt. Nyilván a user ebből csak a legfelső szintű kivételt látja, a maradék meg a fejlesztőknek jó, esetleg bekerülhet logba backtrace-estül, mindenestül. Nem tudom, hogy kernelnél használnak e try-catch-t, mert viszonylag lassú, de valami hasonló elgondolást azért jó lenne, ha követnének, mert most ott tartunk, hogy csak a legalacsonyabb szintű hiba van eldobva, aztán jöjjél rá, hogy az egymillió sorból melyik futott aknára, ami ezt eredményezte. Trace-ből vissza lehet nyomozni valamennyire, ha megvan a forráskód, egyébként meg csak hümmög az ember, hogy ezmiafszom.
-
inf3rno
nagyúr
válasz
Frawly
#29167
üzenetére
Vagy aprón összeütni valamit használt alkatrészekből harmad áron is mehetne, felesleges amúgy is az új gép egy gyereknek, mert úgyis túlhúzza, teleszórja vírussal, leönti gyümölcslével, meg még Isten tudja milyen módon teszi tönkre. Nekem annak idején lent volt a gép oldala, aztán bedugtam a lábujjam a CPU ventilátorba, és úgy égett le. Erre tök felesleges százezreket költeni...
-
inf3rno
nagyúr
Nem éppen, mert korrekt az lenne, ha azt írná, hogy nincs csatolva rootfs, itt meg valami huszadrangú következményt ír, hogy nem tudja az initet elindítani. Igazából még azt sem, azt írja, hogy "not syncing, attempted to kill init", ami szerintem max a kernel fejlesztőknek mond bármit, vagy még nekik sem, annyira alacsony szintű bullshit.
-
inf3rno
nagyúr
válasz
Frawly
#29087
üzenetére
Minden rendszernél előfordulhat, ami egyszerre fájlrendszert és adatbázist is használ adat tárolásra. Ha csak adatbázis van, akkor esetleg a tranzakciók használata védhet ellene.
Én is úgy értettem a sérültet, hogy inkonzisztens lesz a snapshot időben.
Ha folyamatos rendelkezésre állás kell, akkor az írás leállítása nem feltétlen jöhet szóba.
-
inf3rno
nagyúr
válasz
Frawly
#29084
üzenetére
A sok tera lehet, hogy ritka, de egy normál HDD olvasási sebessége 120MB/s körül van. Lehet, hogy a RAID valamit dob rajta, de ha többszáz MB adat van, már annak a másolása is több másodpercig tart, és több másodperc alatt történhetnek írások egy átlagos alkalmazás esetében is. Állítólag a snapshot sem csodaszer erre: [link], szóval könnyen lehet, hogy sok backup-ról, amit manapság mentenek el, éles helyzetben kiderül, hogy használhatatlan vagy minimum sérült.
-
inf3rno
nagyúr
válasz
Frawly
#29078
üzenetére
Nem állítottam, hogy bármelyik is kiváltaná a másikat.
Ha már így szóba került, akkor inkább azzal lenne értelme foglalkozni, hogyha rendelkezésre állás és backup is kell, akkor mégis hogyan írunk föl több terabyte állandóan változó adatot valamire? Elkezdjük a másolást, aztán mire a végére érünk már tök más adat van fent a lemezen...
-
inf3rno
nagyúr
Mert a backup is hozzásegít a rendelkezésre álláshoz, hiszen ha elveszik az adat, akkor minden leáll. Illetve a RAID is hozzásegít a biztonsághoz, mert többször letárolja ugyanazt, így egy meghajtó hibája miatt nem veszik el az adat, és nem kell azonnal a backup-hoz nyúlni. Ezen kívül a modern fájlrendszereknél (zfs, btrfs) RAID-el szokták kombinálni a block checksum-ozást, és így ezek a fájlrendszerek védenek bitrot ellen is, amire a backup önmagában nem képes. A helyzet komolyságától függően lehet a backup-ra is szoftveres RAID-et tenni, illetve lehet több backup-ot is használni, de ez azért a legtöbb projektnél ágyúval verébre.
-
inf3rno
nagyúr
válasz
samujózsi
#28985
üzenetére
Nézd meg valamilyen wifi analyzer appal, hogy elég erős e a jel. Ha igen, akkor teszteld ookla speed test-el, vagy ezzel [link], hogy ténylegesen mennyit tud. Ha alacsonyabb az elvártnál, akkor a helyi hálózaton érdemes tovább folytatni a tesztelést. A legegyszerűbb, ha csinálsz egy http vagy samba servert, és fájl letöltéssel nézed meg, hogy milyen sebességgel megy a helyi hálózaton az adat. 2-3 gép között érdemes mérni, hogy kizárd a hálózati kártya hibát valamelyik gépen, illetve vezetékkel is érdemes kipróbálni, hogy a wifivel van e a gond. Érdemes még pingelni pl google.com-ot, hátha az magas, és azért akad meg egy pillanatra. Nagyjából ezek az ötleteim.
-
inf3rno
nagyúr
-
inf3rno
nagyúr
válasz
haddent
#28792
üzenetére
Én állítottam, de én sem ismerem mélységeiben, csak sok videoban ilyesmit mondtak, hogy a sysvinit csak elindítja a dolgokat, de nem menedzseli, ezért mennyivel jobb a systemd vagy a launchd BSD-nél. Mélyebben belenézni nekem sem volt még időm. Ha nem így van, akkor valóban értelmetlen pénzkidobás volt az átállás systemd-re. A másik érv a sysvinit ellen az volt, hogy distro függő a scriptelése. Ennek se jártam utána, hogy tényleg így van e, viszont ez annyira nem probléma, ha valaki csak a kedvenc disztroját használja. Inkább akkor gond, ha valaki sokak által használt szoftvert ír, és szeretné, hogy eltérő disztrokon is ugyanúgy viselkedjen.
-
inf3rno
nagyúr
válasz
bambano
#28769
üzenetére
"volt service manager, úgy hívták: init." - Ha a sysvinit-re gondolsz, akkor erősen az a benyomásom, hogy túl keveset tud, és nem igazán támogatja a fejlesztést. Mármint az jött le, hogy annyit csinál összesen, hogy elindít egy bash scriptet bootoláskor, amit megadsz neki, aztán kalap. A systemd-ről az jött le, hogy van egy event bus, arra küld mindenki eseményeket, és onnan veszik le a szolgáltatások azokat, amikre nekik reagálni kell. Sokkal kiforrottabb ez így nekem, bár a megvalósításról továbbra is az a benyomásom, hogy fos. De ezeket tényleg csak érzésre mondom az alapján, amiket olvastam. Ma van egy kis időm, rászánok néhány órát, meg belenézek a kódokba is, hogy tisztázódjon ez az egész. Én személy szerint valószínűleg OpenRC vagy ilyesmi mellett kötök ki, de érdekel a téma.
-
inf3rno
nagyúr
Bár nem akartam újra írni a systemd témában, de találtam közben ezt a videot: [link], ami egy kicsit árnyalja a képet (bár az előadó nekem nem szimpatikus, de ez most lényegtelen). Ez alapján tényleg van értelme az alap ötletnek, mert jobb, ha egy külön service manager felel a szolgáltatások futtatásáért, rendszer vagy egyéb események küldéséért feléjük, stb., mintha ők maguk felelnek érte. Egy csomó kód így újrahasznosíthatóvá válik. Mondjuk, mint már előzőleg írtam, azért ráférne a szabványosítás mielőtt ténylegesen kódot írunk rá, mert szinte minden alkalmazás használni fogja. Ez sajnos elmaradt. A tényleges probléma mégsem igazán ezzel van, hanem a megvalósítással. Azzal, hogy még a cron-t is benyeli a rendszerük, ahelyett, hogy a már meglévő könyvtárakat, szolgáltatásokat próbálná meg használni. A "don't reinvent the wheel" [link] gondolom semmit nem mondott a systemd fejlesztőinek, amikor nekiálltak. Gondolom aki a videot csinálta, az is náluk dolgozik, és az az érdekes, hogy ez így utólag lejött neki is, de már késő, nem fognak változtatni. Poettering azt mondja, hogy az IOS-ből a launchd, ami megihlette ezzel kapcsolatban, de igazából a Windows-ban is van hasonló service manager már a kezdetektől, részben mindenkinek igaza volt ezzel kapcsolatban, viszont volt egy komoly félreértés. Nem azért írtuk, hogy nem akarunk Windows-t csinálni a Linux-ból, mert hogy abban van service manager, hanem azért, mert monolit az egész, mindenbe belenőtt, mint a rák, ahelyett, hogy a már meglévő megoldásokat próbálná meg felhasználni, és nagyon úgy tűnik, hogy a folyamat egyáltalán nem állt meg, szóval végső soron kb. olyan lesz majd, mint a Windows. Lehetne ezt sokkal jobban is csinálni, nem szembemenve a Linux/UNIX alapelvekkel. Nem lennék meglepve, ha egy idő után jönne valami jobb helyette.
-
-
inf3rno
nagyúr
"Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód, ami fent van a githubon." - Hát 4 éve még nem volt túl erős a lefedettsége, reméljük azóta javult. [link] Ha már szóba került, akkor inkább OpenRC-hez lenne értelme hasonlítani, az állítólag hasonló tudású rendszer: [link].
Mindkettő fent van githubon. Beszéljenek a számok.
OpenRC: [link]
- 13k sor kód C-ben (összesen 21k sor adatfájlokkal)
- 41 nyitott issue, 114 zárt, 6 alap issue label
- 103 contributor, 52 watcher
- 3k commit, az utolsó 2 hónapja
- benchmark a cikkből 46.5 secSystemD: [link]
- 355k sor kód C-ben (összesen 650k sor adatfájlokkal)
- 1143 nyitott issue, 4226 zárt, 165 issue label
- 1185 contributor, 332 watcher
- 42k commit, az utolsó 3 napja
- benchmark a cikkből 43.5 sec355/13 = 27, tehát 27x annyi sor kód van a systemd-ben
13k/(41+114) = 84, 355k/(1143+4226) = 66, durván 20%-al kevesebb sor kódra jut egy issue a systemd-nél, igazából engem meglepett, hogy csak ennyivel rosszabb
13k/103 = 126, 355k/1185 = 300 sor kódra jut egy contributor
13k/52 = 250, 355k/332 = 1069 sor kódra jut egy watcher
300/126 = 2.4, 1069/250 = 4.3
tehát 2.4x több munkát végez egy contributor, és arányaiban 4.3x annyi kód jut egy watcher-re a systemd-nél, bár az utóbbi csalóka, mert(46.5-43.5)/46.5 = 6.5%-al több idő a bootolás OpenRC-vel
Nagyjából annyi a véleményem, mint eddig is, most vagy nagyon balfaszok a systemd fejlesztői és overengineered az egész, vagy a kód nagyrésze egyáltalán nem is az inittel foglalkozik, ha elfogadjuk, hogy az ő megközelítésükkel ugyanannyi kódból ki lehet hozni egy init rendszert, mint az openrc megközelítésével. Igazából meg lehet nézni még más init rendszereket is. SysVinit 8k sor, upstart 71k sor, mindkettő jóval elmarad a systemd-től, az upstart, ami legalább kicsit megközelíti kód mennyiségben.
Az a fogalom, hogy "standard-nek mondható" nem létezik. Vagy szabványosítva van valami, vagy nincs. A szabvány készítés általában több éves folyamat, nem csak ilyen összeszórunk valamit, aztán jó lesz alapon megy.
"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." - Pont ezért kellett volna valami normális init rendszerre áttérni, nem erre a szemétre. Mindenkinek kevesebb munkájába került volna egy moduláris init rendszerre való áttérés, mint egy ilyen monolitot beletákolni a disztrójukba, ahol minden mindennel összefügg. Sokan hoztak már ostoba döntéseket ilyen vagy olyan okból, elég csak megnézni a főpolgármester választás eredményeit pártpreferenciától függetlenül.
-
inf3rno
nagyúr
válasz
bambano
#28740
üzenetére
"Az én rendszereimet meg hagyja békén, mert az én fizetésem függ tőlük és ezért harapok."
Szerintem erre az egész helyzetre csak az lenne hatással, ha az adakozók elvonnák a támogatásokat a systemd-s rendszerektől, és a systemd nélkülieknek adnák őket. Ha eddig sikerült áttolni a potter dolgait Debianba politikai hátszéllel, akkor ezután is menni fog.
Nekem nem ritka, hogy zene mellett megy valami más is, pl játék, valami youtube video, stb. Szerintem legalább két hangforrás keverésére szükség van. Ami igazán jó lenne, ha tudnám a két hangot eltérő eszközökre küldeni, de akár még olyat is el tudok képzelni, hogy pl egy netkávézóban többen használnak egy gépet több kijelzővel és több fejhallgatóval. Talán létező problémát old meg a pulseaudio, de ha egy instabil bughalmaz, akkor továbbra sincs értelme használni...
Új hozzászólás Aktív témák
Hirdetés
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Antivírus szoftverek, VPN
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Apple iPhone 14 Pro, Kártyafüggetlen, 1 Év Garanciával
- Nike Airmax 720 43-as sneaker eladó
- LG 34GS95UE - 34" Ívelt OLED / QHD 2K / 240Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- ÁRGARANCIA! Épített KomPhone i5 14400F 32/64GB DDR5 RTX 5060Ti 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest