- Betiltották a Pixel 7-et Japánban
- Telekom mobilszolgáltatások
- Profi EKG-s óra lett a Watch Fitből
- QWERTY billentyűzet és másodlagos kijelző is lesz a Titan 2-ben
- iPhone topik
- Samsung Galaxy Z Fold5 - toldozás-foldozás
- Google Pixel topik
- Xiaomi 14 - párátlanul jó lehetne
- Apple iPhone 15 Pro Max - Attack on Titan
- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
Új hozzászólás Aktív témák
-
Sipi
addikt
Ebben a hozzászólásban azt is írtam, hogy ha netre kötöd, már törhető...
De az ilyen hibák egy részét is el lehet kerülni jó beállításokkal (pl. tűzfal, SELinuxos ACL-ek...).
Mindenesetre nem hidd, hogy elvakult Linux-guru vagyok, tisztában vagyok eme OS hibáival is.
Nem állítom, hogy törhetetlen, sőt, még azt sem, hogy atomstabil. (Pl. egy jól dokumentáltan beta feature bekapcsolásával mindig lefagy a gépem. Igaz, ezt a doksi is írja, hogy ha bekapcsolom, valószínűleg lefagy. )
Sipi -
Sipi
addikt
Ilyen esetben lép be az, hogy ez viszont nagyon durva programozási hiba.
Az adott kódot elég sokan látják már azelőtt is, hogy ''forgalomba'' kerülne.
Durva hibákat pedig elég könnyű kiszűrni.
És itt megint az jön elő, hogy én nem a PistikeSWS cég UngabungaWriter nevű programjának 26-dik ''javításáról'' beszélek, amit a fenti ''szoftverfejlesztő'' cég nagy vonalakban összegányol, hanem magáról a szerver operációs rendszerről. Mint ahogy a cikk is erről szólt, s erre reagáltam.
Gregorius hozott pár példát, ami totál másról szól, ő kereskedelmi kiegészítő szoftverek fejlesztéséről írt. Én az oprendszerről.
Azon belül is inkább a Linuxról, mert saját tapasztalataim tökéletesen ellentmondanak a cikkben leírtaknak.
Lassan már azt is elfelejtem, miről kezdtünk el vitázni...
Sipi -
Sipi
addikt
Höhö, kb. ugyanezt elkezdtem válaszírnui, de lemondtam róla, mert valahogy nagyon nem érthető, amit mondani akarok.
Köszi!
Noszóval: igen, a Windows alapvető felépítésére, nem a kernelre hivatkoztam. Egyébként a Linux monolitikus volt, mára már nem mondható teljesen annak. Vagy a modul, mint olyan, a monolitikusságot erősíti?
Nem többszálról, hanem párhuzamosságról beszéltem. Így, konkrétan csak több processzor esetén lehet róla beszélni, egy procin NINCS párhuzamosság. (Az újkeletű hyperthreadet most ne keverjük bele.)
A puffercsordulásról: amennyit én látok Linuxos programokat, ott a következő a helyzet: egy adott program, pl. egy levéltitkosító GUI, igényli az openssl-t. Lehet, hogy Win alatt ezt összefossák a programozók, egybegányolják (ezt értettem momnolitikus alatt, hogy ha valami SSL-t igényel, sokszor megírnak hozzá egy akármilyen házibarkács SSL-t, nem használják az elérhető libeket).
Linux alatt van p. az openssl. Az ezt igénylő program nem marháskodik mindenféle assembly-vel, nem próbálja meg kicselezni az architektúrát, hanem a megfelelő, dokumentált, definiált interfészen ekresztül meghívja a függvényt és kéri a visszatérési értéket. Ez az érték definiált, hogy pl. longint, nem más, sosem lesz más.
Nem mindenféle 3rd party csapat csodáiról beszélek, hanem az alaprendszerről és az ahhoz adott cuccokról. Pl. Windows+IIS, illetve egy adott Linux disztrib Apache-csal.
Eddig még sosem láttam az említett felesztési módszereket Linux alatt. Itt nem veri senki a programozókat, hogy adják ki a programot, mert idő van, aztán majd jön a patch nemsokára.
Itt nincsen gányolás, mivel mindenki látja, mit és hogyan írsz.
Kizárólag forrásból telepítek mindent, látom a foltokat, látom, mi az eredménye egy _rendszerfoltozásnak_. És megint, nem a PistikeSWS által megírt Ungabunga Writer frissítéseiről van szó, a cikkben sem arról volt.
A kernelben valóban szűnnek meg dolgok. De téves azt állítani, hogy egyzer csak hopp!, nincsenek sehol. Részletesen dokumentált váltás, hogy mikorra várható a kiesésük, miért történik így, stb.
Sipi -
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!
Sipi -
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''.
Sipi -
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.
Sipi -
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.
Sipi -
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?
Sipi
Új hozzászólás Aktív témák
Hirdetés
- Kerékpárosok, bringások ide!
- Léghűtés topik
- Asztalos klub
- Anglia - élmények, tapasztalatok
- iRacing.com - a legélethűbb -online- autós szimulátor bajnokság
- Betiltották a Pixel 7-et Japánban
- Saab, Volvo topik
- Kevesebb dolgozó kell az Amazonnak, AI veszi át a rutinfeladatokat
- Donald Trump azt mondja, hogy megtalálta a TikTok vevőjét
- Napelem
- További aktív témák...
- Xiaomi Redmi Note 13 Pro 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- Xiaomi Redmi Note 13 Pro 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- GARANCIÁLIS! Apple Watch Series 10 GPS 42mm Rose Gold!
- Asus ROG STRIX Z370-F GAMING Alaplap
- T14s Gen4 14" FHD+ IPS érintő Ryzen 5 PRO 7540U 16GB 256GB NVMe ujjlolv IR kam gar
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- BESZÁMÍTÁS! Asus A520 R5 3600 16GB DDR4 500GB SSD RTX 2060 8GB Rampage SHIVA CoolerMaster 700W
- Honor Magic7 Lite 8/512GB, Kártyafüggetlen
- TELJES KÖRŰ IT BESZERZÉS
- Telefon felvásárlás!! Samsung Galaxy S24/Samsung Galaxy S24+/Samsung Galaxy S24 Ultra
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged