- Samsung Galaxy S25 - végre van kicsi!
- Android szakmai topik
- Xiaomi 14 - párátlanul jó lehetne
- Mobil flották
- A sógorokhoz érkezik a kompakt Vivo X200 FE
- Samsung Galaxy A54 - türelemjáték
- Apple iPhone 16 Pro - rutinvizsga
- 6 év biztonsági támogatást ígér a Motorola
- iPhone topik
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
Új hozzászólás Aktív témák
-
Csupán a jómunkásember rencergizdák védelmében akartam kicsit felszólalni!Amugy hiába tüzfalazol, ha a kernelt törik b*szhatod!Iptables rlzz
Erről a tesztről meg annyit, hogy......nah, inkább nem kommentálom!Azért aki egy kicsit is ért hozzá tudja jól, hogy melyik oprendszer való szervernek!Ismim csinált szervert Win 2003-al....fél óráig ment is frankón
Asszem nem kell több komment!
Peace & Love;) -
steveetm
őstag
huh, azért picit kevesebb elvakultsággal mehetne
Linux a monolitikus kernel, windows a mikrokerneles.
''mert mutass nekem egy alaprendszert, amiben így, párhuzamosan futhatnak feladatok!''
Hát az egyik alap funkció a többszáluság, és alaprendszerrel ha nézel egy topot, indit is min. vagy 30 szálat.
És hogy miért lehet gond időzítésből? figyelmetlen volt a programozó. Tegyük fel hogy A progi indit B és C szálat. B szál kiszámol vmit, elteszi vhova, közben C dolgozik, és A nak a további futása Ctől függ. C végez, A fut tovább és dolgozik a B által visszadott adattal. Mármint dolgozna ugye, mert B már tovább fut és valszeg hibás adattal számol.
''Kijön egy puffertúlcs. hiba, megkapod a forráshoz való 1500 byte-os foltot, hozzárakod, lefordít, tesztel. Ez miért változtatná meg a kompatibilitást?''
pl úgy védik ki a túlcsordulást, hogy max 100byte lehet az input. És ha egy proginak ami használja 101byte kéne? szopacs. Nemhiába van ha patchelsz, akkor már változik a verzió(2.6.10 --> 2.6.10-rc1) és a kompatibilitással is lehetnek gondok(emléxel még 2.6.10 környékén megszünt pci_find_class() és tsaira?)
Üdv.: steveetm -
Megtartom magamnak. Nem rád, elhiheted.
A cikk komolytalansága abban kimerül, hogy két szerverről beszélünk. Ez bőven nem dönt el semmilyen csatát.
Beszéljünk az átlag felhasználókról. Arról, hogy ha önmagában feltelepítesz két oprendszert, és semmi más hozzá, leülteted elé Tóth Jakab átlagfelhasználót, mennyi dolgot szed össze 10 perc netezés után. Vagy arról, hogy melyik kér rendszergazda jelszót bizonyos rendszerhozzáférsekhez. Sorolhatnám. Ehhh. Komolytalan a cikk.
Aki meg itt nekiállt arról beszélni, hogy melyik rendszert hogyan lehet használni, annak üzenem, ez a cikk a biztonságról szólt. Az, hogy egyeseknek nehezebb a Linux használata, és emiatt mást használ... Erre mit mondjak, ő a használhatóság kérdése alapján döntött, míg más szempontokat nem is nagyon vett figyelembe. De ez megint nem a biztonságról szól.
[Szerkesztve] -
Gregorius
őstag
Te ugye Windows alatt rpogramokat fejlesztesz?
Mikor mire van szükség. Nem különösebben kedvelem a Linuxot - vagy inkább a C/C++ vonalat - , de a jegyeim többségét ilyen programokra kaptam annó.
Nézd, én most nem Servie Packról beszélek, hanem javításról. Linux alatt ez egy pár kilobájtos szöveges file. Nem lesz új verzió, pár sort ír át.
Persze mit értesz új verzió alatt. Jobb helyeken a build verziószám változik (jobb esetben ez a harmadik vagy negyedik a sorban; ha jól tudom ez is valamilyen szabvány, éppen ezért nem tartja be senki ), különben egy picit komplikált követni, hogy melyik patch van már fent és melyik nem.
Egy program x.y verziója mindig is kompatibilis lesz önmagával, akárhogy foltozom.
Ez a kívánatos cél, amit néhány esetben nem sikerül elérni. Főleg, ha konstrukciójában szar a rendszer. Gondolok itt például biztonsági protokollokra.
Kijön egy puffertúlcs. hiba, megkapod a forráshoz való 1500 byte-os foltot, hozzárakod, lefordít, tesztel. Ez miért változtatná meg a kompatibilitást?
Előszöris, a BOF hiba habár igen gyakori, nem az egyetlen. Másodszoris, a puffertúlírás ugyan megváltoztat a memóriában olyan dolgokat is, amit nem kéne, ez nem mindig fatális a program számára (például már nem használt helyi változókat ír felül). Épp ezért harmadszoris: ha pontos a méretellenőzés a pufferen, ez jelenthet kisebb méretet, mint amekkora méretnél még használható a program (ez alapesetben olyan 4-8 többletkarakter környékén van, de erősen függ a fordítási direktíváktól meg az egyéb változóktól), tehát ha nem is jelentősen, de sérül a ''kompatibilitás''. Ha gondolod, forráskóddal, assemblyvel alátámasztom a gondolatmenetet.
Megintcsak: nem monolitikus Windows-programokról beszélek, azokhoz semmit sem értek.
Internet Explorer? 90kbyte. Mindennek mondanám, csak monolitikus programnak nem, kábé tizennégy rendszermodult használ.
És mivel ott ez az alapvető dolog, a könyvtáraknak kizárólag a hívási módját, valamint a visszatérési értékeit, illesztését kell tudni
Meg azt, hogy az a könyvtár mit csinál, amitől neked jó lesz. Ha a frissítés után már nem működik, hanem visszaszól, hogy a paraméterben megadott érték túl nagy, akkor gáz van (ld. még lentebb).
Itt nincsenek simlis ''majd betuszkolom a visszatérést két hamburger közé, oszt kecsuppal elcsúszik''.
Ez egy kicsit erős állítás. Mondjunk annyit, hogy programozók körében is igen elharapózó tendencia, hogy magasról tojnak a hívási konvenciókra, és olyan ''mellékhatásokat'' használnak ki egy adott függvénynél, amely nem része a specifikációnak. Többek között ezért volt szívás a 9x->NT átállás is. Lehet, hogy az egyes linux disztrók közötti inkompatibilitás is részben ennek a számlájára írható, de ebben nem vagyok kompetens, úgyhogy inkább nem mennék bele.
mutass nekem egy alaprendszert, amiben így, párhuzamosan futhatnak feladatok!
Bármelyik jött-ment webszerver megteszi? Remélem abban egyetértesz, hogy az nem egymás után, hanem egyszerre szolgálja ki a letöltéseket. A biztonsági alrendszeremben 53 - izé, most már 54 - párhuzamos szál fut. De még a legegyszerűbb java programban is legalább két szál van (az egyiket nem a programozó, hanem a futtatókörnyezet adja hozzá).
Múltkor én is babráltam ilyen alkalmazással, amiben mindössze három szál volt. Csupán az egyes folyamatok prioritásán változtatva az átlagos memóriahasználatot ''alig'' négyszeresére tudtam növelni (15M->60M).
ha párhuzamos programozással készítették (máshogy nem is futhatna így), akkor ott különböző módszerekkel szinkronizálod a futást.
És ez az, amit a kedves programozók el szoktak felejteni (persze nem hanyagságból), mert látszólag enélkül is működik(-ött).
Ebbe az x napba ne számítsd már bele egy 3rd party alkalmazás kijavítását
Nem feltétlenül kell 3rd party-nak lennie. Elvégre az oprendszer sem csak egy darabból van.
Bár nem programozok, de nem hiszem, hogy ez a szinkronizáció timerrel menne
Nem, lock-okkal megy. Linuxos berkekben mutexnek szokás hívni. És mint mondtam, gyakran el szokták felejteni, vagy rosszul használják. De sok egyéb apró probléma van, ami a kódoptimalizálás során fogja hazavágni a többszálú programot.
hehe, a windoze elerte azt a szintet, hogy minden hibat kijavitottak benne
Üdv,
G. -
Gregorius
őstag
Egy végfelhasználói bináris (wuftpd) hibája nem ugyanaz, mint egy .so vagy dll-é. Hiba lehet mindkettőben. Ha dll-ben, az sok file-t érint. Ha binárisban, az nem annyira.
A wuftpd-t arra mondtam példának, hogy ami nem valószínű az attól még nem lehetetlen. Rúgtak már ki azért embert, mert azt mondta ''hát ez úgy sem fog megtörténni''. Egyébként épp elég programot, ftp klienst is érinthet a hiba javítása (mert ugye nagyon szeretjük betartani a szabványokat... ).
De ettől, ha egy kukuc.so.1-nek x,y, és z függvényeket kell biztosítania a kukuc.h-ban leírt hívási feltételekkel, az a patch után is ugyanolyan marad.
Az időzítést pedig nem értem, Linux alatt max. a kernelben találsz ilyen funkciókat...
Nem lehetsz biztos abban, hogy egy javítás nem sérti meg a visszafelé kompatibilitást, amíg le nem tesztelted (a ránézek és jó módszer nem valami megbízható), de talán még akkor sem. Deha mégis kompatibilis, akkor irdatlan nehéz fenntartani. Ezért van az, hogy a windóz ott bugzik, ahol, de még a win3.1-re készült programokat is tudja futtatni.
Az időzítésre példa. Vegyük azt a hipotetikus szituációt, amikor az xy komponensben történt egy javítás, ami annyiban merült ki, hogy beépítettek egy függvénybe némi extra ellenőrzést, amitől lassabb lett. Most nézzük a zw komponenst, ami többek között ezt az xy komponenst is használja, méghozzá elég intenzíven. Emellett csinál még mást is. A hosszabb xy-használó idő miatt elképzelhető, hogy a rendszer máshogy fogja ütemezni a zw komponens feladatainak végrehajtását, tehát azok sorrendje potenciálisan felcserélődik (itt most párhuzamos műveletekről van szó, nem a program átrendezéséről). A felcserélődés miatt pedig a két folyamat összebalhézik (sokféle módja van, több szálon egyébként is kiba* nehéz tisztességesen programozni és tesztelni a programot), és zw szépen elhalálozik, de legalábbis nem azt csinálja, amit kellene.
Namost a kedves főnökséget nem szokta érdekelni, hogy az xy javítás vagy a zw hiba miatt nem fog működni, őket csak az érdekli, hogy a rendszer nem megy. Két dolgot lehet csinálni: egy - nem javítjuk ki az xy komponenst. Kettő: kijavítjuk, leteszteljük, és miután látjuk a tesztből, hogy nem passzol össze a zw komponenssel, azt is kijavítjuk.
Persze az is megtehető, hogy a tesztelést az end-júzerek végzik, csak az khmm kínos és imázsromboló tud lenni.
''Felhasználói'' szemmel semmit sem érek a stack strace-szel. Eddig Linux alatt az egyszerű, futás közbeni hibajelzésből következtetni tudtam a hiba helyére,
Azt mondtam, akár stack trace-t. Majd elfelejtettem. Az EventLog is a barátod. Példa:
-----
The IP address lease [**IP cím**] for the Network Card with network address [**MAC cím**] has been denied by the DHCP server [**DHCP szerver IP címe**] (The DHCP Server sent a DHCPNACK message).
-----
Elég részletes?
Jobbulást!
G. -
WN31RD
addikt
Igen, lényegében pontosan úgy értsd.
Igazából nem arra gyanakszom, hogy maga a hír hamis, mert nincs okom feltételezni, hogy a tesztet nem végezték el, de a teszteredményt már meghamisíthatták, bár ezt sincs különösebb okom feltételezni, vagy akár a tesztkörülményekkel is manipulálhattak (ezt már valószínűnek tartom). Szóval nem tudom, hogy ki hazudott vagy csúsztatott, és mit, de az én tapasztalataim alapján egy ilyen eredmény így előadva... elég büdös. -
Gregorius
őstag
Sőt, mivel egy adott program foltozása azon library-k működését, melyeket a program ellát, nem változtatja meg (vagyis nem változnak meg a ''dll''-ben található függvényhívások, nevek)
Attól még, hogy egy függvényhívás neve nem változik meg, a működés megváltozhat. Ha a működés nem változik meg, az időzítés még megváltozhat. És akár az időzítés okozta változás is előhozhat olyan egyéb hibákat, ami potenciálisan használhatatlanná teszi a rendszert.
nem valószínű, hogy bármi, ami erre épül, összedőlne
Az sem valószínű, hogy valaki ftp szervert 300 karakteres jelszóval fog használni, aztán mégis milyen jó kis remote exploitot lehetett rá írni annó (wuftpd volt talán?). Ilyen ügyekben nincs olyan, hogy valószínű, vagy nem. Csak olyan van, hogy lehetséges.
A Linux nem monolitikus. Ráadásul hibajelzést is ad, se ez nem az, hogy súlyos hiba történt a rendszerben.
Ezek szerint még sosem nyomtál ''súlyos hiba történt a rendszerben'' után a details gombra... Ha tudod, hogy mit és hol kell keresni, akkor még az egyes stack-trace-eket meg a rendszerfolyamatok memóriaképét is elő lehet ásni. Ha kicsit utánaolvasol, még arról is találsz publikus információkat a Microsoftnál, hogy hogyan lehet kernel szinten debuggolni. -
Gregorius
őstag
attól még pár nap alatt ki szokták javítani a hibákat
A pár nap már sokkal közelebb áll a hihetőhöz.
Le kell tesztelni, hogy valóban sikerült rendesen kijavítania a hibát.
Le kell tesztelni, hogy az érintett szoftverek működését befolyásolja-e a javítás.
El szoktak gondolkodni, hogy melyik a nagyobb ciki: ha valaki bejön és körülnéz, vagy ha a (saját ember által!) telepített folt működésképtelenné tesz kritikus rendszereket.
mennyi idő alatt javítja ki a már megtalált _és_ bejelentett
Bejelentett hiba az van. Utána meg kell találni, hogy ezt a hibát mi okozza, ami rosszabb esetben a tünet keletkezési helyétől fényévekre van. Ez sem öt perc. Ha megvan a hiba, akkor előszöris lehet workaround-ot keresni, javítani a hibát, elemezni a javítás lehetséges negatív hatásait, stb, stb...
nem arról volt szó, hogy a kész foltot a cégek mennyi idő alatt teszik fel
A fentebb említett tesztelést természetesen a gyártó is elvégzi (jobb helyeken), persze csak az általánosabb rendszerekre tudja, de a saját rendszerben is lehetnek együttműködő komponensek, amiket érint. És akkor a regressziós tesztekről még nem is mondtam semmit. Mindkét (gyártó/vevő) oldalon igen komoly iparág épül peccselésre (sajnos).
[Szerkesztve] -
VladimirR
nagyúr
''És itt nem arról volt szó, hogy a kész foltot a cégek mennyi idő alatt teszik fel (még szép, hogy nem megy egy nagy rendszerben egy nap alatt), hanem a program készítője mennyi idő alatt javítja ki a már megtalált _és_ bejelentett hibát.'' -- es ugye nem a hiba publikalasa (nem feltetlen azonos a hiba napfenyre kerules, bejelentes idejevel, sot...) es a pecs kiadasa kozti ido
71 perc? az kb olyan melysegu hiba javitasara eleg, hogy pl a a programban van egy elgepeles
zLegolas:
Hasonló a téma, mint a vírusok esetében, mint amikor nagyarcú XP-sek mondják, hogy létezik Linux-ra is vírus, ők olvasták ám...
A kérdés, hogy ki látott már vírussal fertőzött Linux-ot/BSD/Unix-ot ...
mas tema, hogy ki es minek akarna megfertozni azt a kb 5%-ot?
feregiro baratainknak nem az a celja, hogy szopjon a linux-os is (ber megerdemelnek, mert erre minden alkalommal verik a melluket), hanem az, hogy a leheto legtobb emberhez jusson el az adott cucc, s a tobbsegnek windoze ketyeg a gepen, meg szarul beallitott ie oslama juzerrel, auutomatikusan OK-ra kattintu pluginnal a juzer kattintto ujjaban
p.s.: meghogy az XP-sek a nagyarcuak -- ROTFLOL
Új hozzászólás Aktív témák
Hirdetés
- Autós topik
- A Micron újszerű módszerrel javítja QLC-s SSD-jének sebességét
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- Milyen autót vegyek?
- Milyen házat vegyek?
- Samsung Galaxy S25 - végre van kicsi!
- Hálózati / IP kamera
- További aktív témák...
- iPhone 12 Pro Max / 128 GB / 88%-os akku / gyári független / Pacific Blue
- GAMER PC : RYZEN 5 4500 / 16GB DDR4 / ASUS RX 480 8GB / WiFi / Bluetooth / 512GB M.2 SSD / 500GB HDD
- Dell Latitude 7390, 13,3" FHD IPS , I5-7300U CPU, 16GB DDR4, 512GB SSD, WIN 11, ( olvasd végig )
- Acer PREDATOR HELIOS NEO 16 / i9-14900HX / RTX 4070 (140W) / 1 TB SSD / 240HZ
- Topping A70 Pro fejhallgató erősítő
- Erő és sebesség? Most az Öné lehet! Ráadásul kamatmentes rèszletre is!
- Motorola G72 128GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
- Microsoft Surface Pro 7 - Újszerű, dobozban, gyári töltővel, billentyűzettel
- Konzol felvásárlás!! Xbox Series S, Xbox Series X
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest