- Microsoft Excel topic
- YouTube
- Letartóztatták a bitcoin-Jézust
- A franciáknak elege van abból, hogy minden gyerek mobilozik
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- Mobilinternet
- Crypto Trade
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Synology NAS
- Az iPadOS-re írt appokra is díjat vet ki az Apple
Új hozzászólás Aktív témák
-
Adi
senior tag
Hahaha.
ldm start-reconf primary
-
#51736960
törölt tag
Itt pillanatokon belül flame lesz
-
Sipi
addikt
71 NAP?!?
Na, ezt a büdös életbe nem fogom elhinni... A 71 perc már hihetőbb lenne. Ez kizárt... Linux előtt ülök nap mint nap, az eddigi leghosszabb idő talán két nap volt...
SipiMont-joie! Saint Denis! Je trépasse si je faiblis!
-
Sipi
addikt
Ja, szuper, nagyon fúrja az oldalam, hogy a cikkben nem említett teszt és tesztkörnyezet _pontosan_ mit takar. Katt forrás, hát egy kis pízért már el is olvashatnám.
SipiMont-joie! Saint Denis! Je trépasse si je faiblis!
-
MUŁĐER
addikt
de tök okosak ügyesek, úgy csinálnak mintha az összes Linux egyforma lenne Red Hat nem a legprofibb Linux, szval....
Robotika törvényei: 3. A robot megvédi magát halálos fegyverzettel, mert egy robot rohadt drága.
-
faster
nagyúr
Mindkettő szerverünket törték már meg (Win 2000 és Redhat), csak a FreeBSD-re nem jutottak még be.
-
zLegolas
őstag
Törhetetlen rendszer nincs. Az, hogy mindkettő (három) feltörhető nem hír. 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 ...
A lényeg az arányokon látszik: a 99,999% -kal szemben a maradék 0,001% nem vígasztalja szerintem a Picipuha fejlesztőitÉn normális vagyok! Megmondták a hangok is a fejemben!
-
Sipi
addikt
Ezt nem is vitatja senki. Ha valamit rosszul állítanak be, törhető. Sőt, ha valamit Netre kötsz, törhető.
Na de az a 71 nap!!! Azt hogyan hozták ki?!? Ennyi ideig lekapcsolták a netről a gépet és elutaztak valami eldugott szigetre?
Az eddigi elvi viták is többnyire abban meg tudtak állapodni, hogy bárminemű javítás _sokkal_ hamarabb jelenik meg Linux alá.
Egyébként abba a Windows-os pár napba beleszámolták vajon az olyan hibákat is, melyekre akár fél évig sem volt javítás?
SipiMont-joie! Saint Denis! Je trépasse si je faiblis!
-
domedee
senior tag
Ejnye-ejnye, hát nem tudtad, hogy:
''It's not bug, it's feature!''''és van a végén a városok anyja: Budapest. Csakhogy ez nem olyan anya, aki szoptatja a gyerekeit, ellenkezőleg őt szoptatják a gyerekek, s maradnak mellette örökké satnyák, kicsinyek, vérszegények.'' - Mikszáth Kálmán
-
nap
addikt
Szerintem, egy windows szerver, ha jol bekonfuralja egy hozzaerto ember kvazi ugyanolyan biztonsagos, mint egy jol bekonfiguralt linux.
Nade alapbealitasokkal?
Mellesleg, mindegy melyik rendszert valasztja valaki, a hozzaerto embert ugyanugy meg kell fizetni.
[Szerkesztve]browser.tabs.insertRelatedAfterCurrent;false | wing32.dll -> Windows\SysWOW64 | január, február, itt a nyár...
-
vtechun
veterán
nagyon megerőltethetté magukat a microsoft javításokat író emberek, biztos gőzerővel folyt a túlóra, meg minden, 10 000 emberrel, csakis azért, hogy itt jobban szerepeljenek, feltéve ha igaz a dolog, bár ezt kétlem...
-
Gregorius
őstag
Nade alapbealitasokkal?
Te sem láttál még frissen települt windows server 2003-at.
71 NAP?!?
Na, ezt a büdös életbe nem fogom elhinni... A 71 perc már hihetőbb lenne.
Nos, nagyobb cégeknél csak a peccs befogadása eltart egy napig, és nem azért, mert a rendszergazdák olyan balfaszok, hogy egyenként mennek oda több száz géphez. Szóval hadd kételkedjek a 71 perces peccsek minőségében (már ha vannak ilyenek). Hogy nem ellenőrizték őket alaposan, az biztos. -
Sipi
addikt
válasz Gregorius #17 üzenetére
Kételkedj nyugodtan, de attól még pár nap alatt ki szokták javítani a hibákat. Még a Linux kernelben sem vesz igénybe 71 napot, pedig azt alaposan tesztelni kell.
É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.
SipiMont-joie! Saint Denis! Je trépasse si je faiblis!
-
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 -
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] -
WN31RD
addikt
válasz VladimirR #19 üzenetére
''mas tema, hogy ki es minek akarna megfertozni azt a kb 5%-ot?''
Feltételezem, lényegesen nagyobb hírnevet jelentene bizonyos körökben egy hatékony linuxos vírus elkészítése, mint egy ezredik windowsosé. Nem hiszem, hogy hiányzik a motiváció.''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
VladimirR
nagyúr
megeshet, hogy hirnevet jelentene, de miota a fergeknek leginkabb az a lenyege, hogy zombit csinaljon a gepedbol es igy tamadj egy servert (nagy kedvenc ugye az ms), meg kuldjed a spam-et, mint az orult, inkabb motivalo tenyezo az, hogy ehhez hany gepet tudsz a magadeva tenni (bar virust meg nem irtam, igy ehhez nem ertek igazan)
-
Gregorius
őstag
lényegesen nagyobb hírnevet jelentene bizonyos körökben
Hírnévvel egy valamit lehet nyerni: FBI-t az ember nyakába. A vírusok zömét spammerek(nek) írják, azoknak meg a tömeg a lényeg. Aki hírnevet akar, az publikációt, meg proof-of-concept-et szokott írni.
Ha jól megfigyeled, most hogy elkezdett terjedni a Mozilla, már a vírusíróknak is egyre kedveltebb célpontja. -
WN31RD
addikt
válasz VladimirR #22 üzenetére
Persze, manapság már a vírusok sem a régiek, ez is csak a pénzről szól...
Egyébként igazad van, nem is vitatom, hogy általában sokkal népszerűbb célpont a Windows, de azt nagyon kétlem, hogy nincsenek jópáran, akik nagyon szívesen raknák a szignójukat egy ügyes linuxos vírusra, ha meg tudnák csinálni. Tehát úgy gondolom, hogy erre is van, ugyan lényegesen kisebb, de igenis jelentős motiváció.''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
WN31RD
addikt
válasz Gregorius #23 üzenetére
A ''hírnevet'' ne szószerint értsd...
A spammerek pedig jellemzően inkább idióta (szakmailag érdektelen), bár a céljuknak megfelelő, férgeket írnak.
Mozilla: Jaja, aggódok miatta én is. Nem véletlen, hogy csak grsec-es kernel mellett kizárólag erre a célra fenntartott account alatt vagyok hajlandó futtatni.
[Szerkesztve]''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
Sipi
addikt
válasz Gregorius #20 üzenetére
Bocs, a 71 percnél lemaradt a mosoly.
Ezzel csak arra céloztam, hogy a valós időhöz inkább 71 perc áll közelebb, mint 71 nap.
Nem tudom, szoktál-e Linuxos bugreport-helyeken nézelődni. Neadjisten hibát jelenteni.
A Linux nem monolitikus. Ráadásul hibajelzést is ad, se ez nem az, hogy súlyos hiba történt a rendszerben.
Akkor fogalmazok így: saját tapasztalatom szerint egy bugreportban feltűnt hiba helyét, valószínű okait már a bejelentés napján megállapítják, többnyire másnapra (de sokszor aznap) elkészül a javítás.
(Az más dolog, hogy ebből adott rendszerre csomagot mikor csinálnak, és csak forráskódból telepítek, úgyhogy tudom, hogy maga a kész, javított forrás nagyon hamar készen áll.)
Mivel a Linux iszonyú erősen (kizárólag...) építőkocka-jellegű, sokkal kevésbé valószínű, hogy egy adott komponens (ami a valós rendszerben alig látszik) megváltoztatása az egészet romba döntené.
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), nem valószínű, hogy bármi, ami erre épül, összedőlne.
Pontosítok: nekem még sosem dőlt össze. Az más tészta, ha más _verzió_ jelenik meg, változik a függvény szerkezete.
SipiMont-joie! Saint Denis! Je trépasse si je faiblis!
-
-
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. -
anulu
félisten
részemről nagyon nemszeretem a Linuxot, bár lebeszélni még senkit nem beszéltem le róla. de ez a hír szerintem is LOL!!! Teljes konfigot, tesztkörnyezetet kérnénk.
"Jelenleg a cloud nem más mint a sales által elhazudott és eladott utópia, egy ígéret, csalánba csomagolt mézesmadzag, amit az üzemeltetés f@$zával vernek" | Feel the power! Intel Core i7 | iPhone 14Pro 256GB | iPad Pro 2017 64GB
-
zLegolas
őstag
válasz VladimirR #19 üzenetére
Bocs de:
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
1. NEM 5%! 0,005%!
2. Van egy ismerősöm, egyszer azt mondta, hogy majd ha sokan használnak Linux-ot, sok vírust is fognak rá írni... te ugyanezt állítottad, más szavakkal. Ugye nem gondoltad komolyan! A NET szervereinek hány százaléka Unix/Linux? Legyen kb 1%. (de ennek soxorosa) Az soktízezer gép. És? Hol a tömeges vírusfertőzés?
A lényeg, hogy ha bármi rendszerfájlok csak úgy szíre-szóra módosíthatók, akkor gáz van. Márpedíg a vírusok és trójaiak ezt teszik, javíts ki, ha tévedek!
3. Nem állítottam, hogy az XP-sek nagyarcúak, kérlek ne forgasd ki a szavaimat!
Ha kell elmagyarázom, mi a külömbség a következő kettő között:
- Az XP-sek nagyarcúak
- A nagyarcú XP-sek
Alsó tagozatos téma.Én normális vagyok! Megmondták a hangok is a fejemben!
-
VladimirR
nagyúr
1: azert attol imho tobben hasznalnak linux/unix rendszert, nem csak a 0.005%, de ez vegulis mindegy, mondjuk ugy elhganyagolhatoa a linux/unix felhasznalok, ha az a celod, hogy tomegeket erintsen a fereg, amit irsz
2: jol latod, valoban ezt mondtam, mitobb, komolyan is gondolom -- a net szervereket nem ertem, hogy hogyuan keverted ebbe bele, foleg ugy, hogy az emlitett peldaban 1%-kal szamolsz, ami szinten elhanyagolhato
tisztaban vagyok vele, hogy nem 1%, nanem _joval_ tobb, de azt is vedd figyelembe, hogy nem a szervereket tamadja a virusok/fergek, hanem a juzert -- szervert leginkabb ''tulterheleses tamadnak'', de ott meg jha jol tudom mindegy, hogy milyen rendszer van a gepen
tegyuk fel, hogy Te irsz egy ferget, ami mondjuk tamadja az MS szervereit (pusztan elmeleti sikon beszelunk rola, nem gyanusitgatas, csak ez ugye nepszeru dolog a feregirok koreben -- ugyanakkor ertelmetlen is, a tukrozesek miatt, de ez mas teszta)
kerdes: mit fertoznel meg?
a) tobb tizezer net szervert
b) tobb millio pc-t
3: nem forgatom ki a szavaidat, egyszeruen arrol van szo, hogy altalanositva minden xp-sre mondtad ki, hogy nagykepuek -- legalabbis nekem ez jott at, s nem az, hogy 1-2 nagyarcura celzol
egyebkent ha azt mondom, hogy igenis _van_ linux-ra virus, akkor most en is nagykepu xp-s vagyok? vagy talan Te nem vagy megfeleloen tajekozott, esetleg az elfogultsag szol beloled?
p.s.: ''also tagozatos tema'' -- a kovetkezo post-ban anyam is benne lesz?
[Szerkesztve] -
anulu
félisten
válasz Gregorius #29 üzenetére
nálam volt olyan, h Debian alatt futott X, rajta X11AMP, semmi mást nem használtam. (haverom állította be az egészet, elég régóta foglalkozik Linuxszal) egyszercsak x bezár, szöveges módban annyi van, hogy ''kernel panic''. a vége az lett, hogy az egészet újra kellett telepíteni, mert teljesen meghülyült.
"Jelenleg a cloud nem más mint a sales által elhazudott és eladott utópia, egy ígéret, csalánba csomagolt mézesmadzag, amit az üzemeltetés f@$zával vernek" | Feel the power! Intel Core i7 | iPhone 14Pro 256GB | iPad Pro 2017 64GB
-
anulu
félisten
a Linuxot is meg lehet ölni, csak máshogy mint az XP-t. ezen felesleges vitatkozni. használhatóság szempontjából nálam az XP vezet, a Linuxszal annyit tudok kezdeni, mint kismacska a sziklatömbbel. semmit.
"Jelenleg a cloud nem más mint a sales által elhazudott és eladott utópia, egy ígéret, csalánba csomagolt mézesmadzag, amit az üzemeltetés f@$zával vernek" | Feel the power! Intel Core i7 | iPhone 14Pro 256GB | iPad Pro 2017 64GB
-
Sipi
addikt
válasz Gregorius #29 üzenetére
Mindegy, úgy látom, nem érted, mit akarok mondani, és úgy látom, nem ismered a Linux működését.
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.
Az általam látott, tesztelt Linux foltok természetesen megváltoztatnak valamit a forrásban. Sőt, mivel ezután újrafordítod a programot totál megváltozik maga a file is.
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...
Ja, várj, Linuxban nem a kész binárist foltozod, hanem a forrást!
Itt úgy épülnek a dolgok egymásra, hogy az alapszintre szétbontott funkciók mindegyikét más és más csomag valósítja meg.
Mindegyik külső elérése rögzített. Ez nem változik meg. A patch nem ezt változtatja. Persze, ha jól patchelnek.
Debug: MS-ben nem debugoltam, de máshol sem, ahhoz nem értek. Sőt, a core dumpokat sem szoktam kinyomtatnui és olvasgatni.
''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, sokszor még arra is, mi lehet az oka. Megoldani persze nem tudom, mert nem értek a programozáshoz.
Ezt azonban ne hasonlítsd már össze azzal, hogy ha akarom, totál memory dumpot kérhetek a deails gombbal... Hibajelzést írtam, nem core dumpot! Az utóbbi a supportnak van, az előző a felhasználónak.
Mindegy, szerintem sosem győzzük meg egymást. Ráadásul a jól fejlett hőemelkedésemnek köszönhetően már azt sem tudom, miről is ''vitázunk''.
SipiMont-joie! Saint Denis! Je trépasse si je faiblis!
-
-
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.''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''
-
anulu
félisten
mindegy. én használom továbbra is a winxp-t (nemsokára a 64bites változatot, te pedig a Linuxot. részemről no offense, kiszálltam még a topic olvasásából is.
"Jelenleg a cloud nem más mint a sales által elhazudott és eladott utópia, egy ígéret, csalánba csomagolt mézesmadzag, amit az üzemeltetés f@$zával vernek" | Feel the power! Intel Core i7 | iPhone 14Pro 256GB | iPad Pro 2017 64GB
-
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. -
Sipi
addikt
válasz Gregorius #42 üzenetére
Azt hiszem, jól elbeszélünk egymás mellett.
Te ugye Windows alatt rpogramokat fejlesztesz? Mert Linux alatt szerintem totál máshogy van...
A visszafele kompatibilitást nem értem... Alapvető, hogy egy javítás nem sérti. 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.
Nem értem ezt a viszzafele komp. fenntartást... Egy program x.y verziója mindig is kompatibilis lesz önmagával, akárhogy foltozom. Ha nem az, akkor már nem x.y verzió, kiadják frissebbnek.
Egyébként én még nem találkoztam olyan javítással, ami visszafele nem lett volna komp. Ezt hogyan érted?!? 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?
Megintcsak: nem monolitikus Windows-programokról beszélek, azokhoz semmit sem értek. Linux alatt egy normál program (lényegében az összes) ezer más libre, programra épü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. Ezt definiálják is a headerekben.
Mivel egy Linuxos program lényegében mást sem csinál, csak tonnaszámra hívja meg egyéb programok függvényeit, ha egy függvényben nem változik meg a visszatérési érték, sem a mód, ahogy hívom, mi dőlne össze? Itt nincsenek simlis ''majd betuszkolom a visszatérést két hamburger közé, oszt kecsuppal elcsúszik''. A programod összvissz egy definiált elérési/visszatérési módszrtant lát a másikból. Ha ez egyezik, oké. Max. az adott lib dőlhet össze.
Ez az időzítéses pedig... Izé, ezt már NT kernel alatt sem igen játszhatod el... A párhuzamos műveleteket pedig inkább ne hozd be, mert mutass nekem egy alaprendszert, amiben így, párhuzamosan futhatnak feladatok!
Egyébként ha csak a futási idő nőtt a folttól, akkor nem változik semmi, ugyanis 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. Bár nem programozok, de nem hiszem, hogy ez a szinkronizáció timerrel menne.
Legfeljebb anyázik egy programrész, hogy a másik hol van már.
De ez, úgy látom, a munkádhoz kapcsolódóan, megincsak valamilyen speciális, ''külső'' cég által készített nagy alkalmazás.
Itt a két rendszerről volt szó, és azok javításáról. Ebbe az x napba ne számítsd már bele egy 3rd party alkalmazás kijavítását...
Köszi a jókívánságokat, igyekszem!
SipiMont-joie! Saint Denis! Je trépasse si je faiblis!
-
Jim Tonic
nagyúr
Azt nem értem, minek szólnak bele ebbe a témába olyanok, akik nem is ismerik a Linuxot, esetleg még nem is volt a gépükön, vagy mégcsak nem is látták. Nekem van pár tippem erre az itteni hozzászólók közül...
Alcohol & calculus don't mix. Never drink & derive.
-
VladimirR
nagyúr
hehe, a windoze elerte azt a szintet, hogy minden hibat kijavitottak benne => Bővebben: link
p.s.:
(forras: Bővebben: link)
[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. -
Jim Tonic
nagyúr
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]Alcohol & calculus don't mix. Never drink & derive.
Új hozzászólás Aktív témák
- Milyen TV-t vegyek?
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Házimozi belépő szinten
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Anglia - élmények, tapasztalatok
- antikomcsi: Való Világ: A piszkos 12 - VV12 - Való Világ 12
- World of Tanks - MMO
- nVidia tulajok OFF topikja
- btz: Internet fejlesztés országosan!
- PlayStation 5
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen