Reikäisimmät sovellukset julkaistu ja eipä yllättäen Linuxjakelu komeile listan kärjessä!
http://www.tivi.fi/Kaikki_uutiset/2015-03-25/Näissä-softissa-oli-eniten-haavoittuvuuksia-–-katso-yllättävä-lista-3218027.html
http://www.tivi.fi/Kaikki_uutiset/2015-03-25/Näissä-softissa-oli-eniten-haavoittuvuuksia-–-katso-yllättävä-lista-3218027.html
Vastaukset 55
Vanhimmat
Linkittäminen ei vissiin oikein onnistu windowsilla.
Google Chrome (504)
Oracle Solaris (483)
Gentoo Linux (350)
Microsoft Internet Explorer (289)
Avant Browser (259)
IBM Tivoli Endpoint Manager (258)
IBM Tivoli Storage Productivity Center (231)
IBM Websphere Application Server (210)
IBM Domino (177)
IBM Notes (174)
Mozilla Firefox (171)
X.Org Xserver (152)
Apple Macintosh OS X (147)
IBM Tivoli Composite Application Manager For Transactions (136)
Vmware Vcenter Server (124)
IBM Tivoli Application Dependency Discovery Manager (122)
Oracle Java (119)
Vmware Vsphere Update Manager (111)
IBM Websphere Portal (107)
Microsoft Windows 8 (105)
Ihanasti Windows viimeisenä! Sitähän mekin käytämme täällä sairaalassa!
Ja huipputurvallinen Ubuntu ei pääse edes reikäohjelmien listalle.
http://www.talouselama.fi/uutiset/vaarallinen reika vaijyi linuxissa 5 vuotta/a2248556
Mutta siellähän se on väijynyt jo viisi vuotta....†
Joko IE on paikattu?
Menikös jauhot suuhun, hihhuli.......†
CentOS (=RHEL) puhumattakaan...
Ei ole Linuxia siellä, Gentoo Linux on eri asia kuin Linux.
Toisekseen tuolta puuttuu versiotiedot.
Mikä on tämä gentoo linux onko se jokin windows distro?
Mitä tarkoittaa tai mihin viittaa sanat gentoo linux?
Gentoo Linux on käyttöjärjestelmä, eri juttu kuin Windows tai joku muu käyttöjärjestelmä.
"Gentoo Linux on eri asia kuin Linux"
"Gentoo Linux on käyttöjärjestelmä"
"tai mihin viittaa sanat gentoo linux?"
Vastaisiko onko tällä gentoo linuxsilla mitään tekemistä linuxsin kanssa?
Jos sinun hakukoneesi ei toimi tai et vaan osaa niin
http://fi.wikipedia.org/wiki/Gentoo_Linux
.
Gentoon sisältä löytyy Linux, on varmaan 1/1000 siitä tms. Yhtä paljon tekemistä siis Linuxin kanssa kuin on vaikka Facebookilla, siinäkin on Linux.
Karvahatun sepustuksista ei yleensä saa selvää kukaan - tuskin edes se itse....†
Gentoolla Linuxilla on yhtä paljon tekemistä Linuxin kanssa kuin Facebookilla, Youtubella tai melkein millä tahansa vekottimella.
Ihan kuin MacBookilla olisi jotain tekemistä BigMac purilaisten kanssa..
Mikä tässä on epäselvää kun jokainen normaaliälyinen ymmärtää tämän?
teitä on kaksi.
Ei se määrä kerro kaikkea. Mieluummin käyttäisin ohjelmaa, jossa on tuhat mitätöntä haavoittuvuutta kuin yksi iso.
Älykkäät on vähemmistönä ÄO:lla mitattunakin.
M-Kar voisi lopettaa kirjoittelun Gentoo Linuxista kun ei näemme ymmärrä siitä mitään. Gentoo Linuxin ajatus on siinä, että kaikki asennettavat ohjelmat (mm.sovellukset) käännetään suoraan lähdekoodista. (toki nyt on saatavana myös valmiiksi käännettyjä binääritiedostoja)
Tämä suunnittelumalli mahdollistaa sen, että Gentoo Linux on aika ylhäällä haavoittuvuuksien listalla.
"Vika" tulee siitä, että ne lähdekoodiset tiedostot voi sisältää korjaamattomia virheitä eli niitä ei olla ehditty korjata tai virhettä EI olla vielä huomattu. Tämä suunnittelumalli edellyttää sitä, että Gentoo Linuxin asentaja on selvillä tästä mallista ja tutustuu myös niiden lähdekoodien sisältöön. (= ymmärtää siis lähdekoodia eli ohjelmointikieltä). Automaattinen asennus ILMAN järkeä ei ole viisas malli.
Gentoo Linux sopii AINOASTAAN osaavalle käyttäjälle eli asentajalle joka TIETÄÄ mitä tekee. Se ei ole aloittelijoiden eikä tubuttajien käyttöjärjestelmä. Omatoiminen lähdekoodin korjaus ENNEN asennuksen suoritusta mahdollistaa käyttöjärjestelmän sovittamisen omiin tarkoituksiin. Esimerkiksi jo lähdekoodin tasolla voi poistaa ne ominaisuudet joita ei tarvitse eikä tule käyttämään. Lähdekoodin muokkaus VAATII osaamista eli tietää "mitä on tekemässä".
Valmiiksi käännetyn binäärikoodisen ohjelmapaketin korjaus ei ole tällä tavalla ennakkoon korjattavissa.
Tämä Gentoo Linuxin erityinen luonne olisi pitänyt huomioida paremmin tällä listalla. Gentoo Linuxin luonteeseen kuuluu se, että kaikki asennukset tehdään lähdekoodista suoraan "asennuksen aikana". (toki nyt on saatavana valmiiksi käännettyjä binääreitäkin)
Tässä mallissa on siis mahdolisuus hyvään ja huonompaan riippuen siitä "mikä on lähdekoodin sisältö". (eli onko se tehty huolella, tarkastettu ja virheet korjattu) Kaikki riippuu lähdekoodin laadusta. Asentaja voi välttää virheitä sisältävien lähdekoodien kääntämisen ja käyttämisen. Näin asentajan tulee olla selvillä siitä MITÄ ASENTAA.
Tämä edellyttää siis edistynyttä käyttäjää eli osaavaa asentajaa.
Tässä suunnittelumallissa käytetään hyväksi täydellisesti "avoimen lähdekoodin" (open source) idea eli asentajan on tutustuttava ennen asennusten alkua niihin lähdekoodien sisältöihin ja asentaa niitä vasta tämä JÄLKEEN. Mitään "sokkoasennuksia" ( "en tiedä enkä välitä mitä ohjelmapaketti sisältää") valmiiksi käännetyillä binääreillä ei ole pakko suorittaa.
Gentoo Linux on edistyneitten käyttäjien järjestelmä. Nämä voivat tietää mitä tarvitsevat ja mitä eivät. Sokeasti binäärejä asentavat saavat sen mitä saavat eli ne haavoittuvuudetkin tulee sitten sokeasti eli automaattisesti binääriasennuksen mukana.
Tutustukaa lähdekoodien sisältöihin ja muokatkaa niitä omiin tarkoituksiin turvalllisesti (ja osaavasti !). Tämä on lyhyesti Gentoo Linuxin idea. Lähdekoodista asentaminen antaa mahdollisuuden tarkempiin asennuksiin koska sitä "binääripakettia" voi muokata ENNEN asennusta (jos osaa). Lähdekoodeja EI OLE PAKKO käyttää sellaisena kuin ne on julkaistu. (tämä sopii siis avoimeen lähdekoodiin jonka lisenssiehdot EIVÄT kiellä muokkaamista.)
Tämä vaatii vain Gentoo Linuxin idean tajuamista.
Taisi mennä tuo kommentti asiantuntevuutensa takia yli finnisen päälaen Wintubbuhtamista harrastavilta. Yritän selventää, vertaamalla leipäveitsen käyttöön.
Pitää tietää, kummasta päästä ottaa työkalusta kiinnni, kun alkaa pullasta itselleen siivua leikata.
Käyttiksistä tietoturvaltaan kehutut *nixit (Solaris-unix ja gentoo-linux) kärjessä. Mielenkiintoista.
Näköjään gentoo on valittu kuvaamaan kaikkien linux-jakelujen "menestystä" tässä kisassa.
Windows siis on yleisimmin käytetyistä työpöytäkäyttiksistä turvallisin. M.O.T.
Ei tietenkään ole, Ubuntua ei ole edes reikäohjelmien listoilla, eli se on turvallisempi kuin Windows. Red Hat Enterprise ei myöskään ole reikäohjelmien listoilla, joten se on turvallisempi.
Voit sillä Gentoolla kuvata vaikka Windowsin menestystä, sillä kun on yhteneväistä sen kanssa niin paljon.
Hankkikaa edes kohtuullinen lukutaito. Ilmeisesti Windows kulttuuri on tuhonnut tietokoneiden käyttäjien osaamistaidot kokonaan. Unixien ja linuxdistrojen turvallisuus ei synny automaattisesta oletusasennuksesta (vaikka ne ovatkin aika turvallisesti mietitty) vaan asennuksen jälkeen suoritettavasta työstä.
Käyttöjärjestelmissä oikea malli ei ole "kaikki kaikille" vaan suoritettavat palvelut ja ohjelmistot on valittava kunkin todellisen käyttötarpeen mukaan.
Turvallisessa käyttöjärjestelmässä on mahdollista valita "se mitä tarvitaan" ja "poistaa se mitä ei tarvita". Windows mallissa ja valitettavasti monessa linuxdistrossa pyritään kumminkin kaikki tyrkyttämään kaikille, myös se tyrkytetään mitä kaikki eivät edes tarvitse. Näin ei saa olla.
Edistyneet käyttäjät tietävät mitä tarvitsevat ja asentavat vain sen.
Gentoo Linuxilla ei mitata Windowsin menestystä. Jos ei kykene ymmärtämään Gentoo Linuxin ideaa niin ei siitä kannata ryhtyä edes kirjoittelemaan. Ota joskus käteesi kunnon oppikirja. Gentoo Linuxin saa turvalliseksi huolellisella asennuksella ja jälki "konffauksella". Minulla ei ole tietoa minkälaisia Gentoo Linux asennuksia Secunia on tutkinut? Ehkä näissä "testaus" asennuksissa on jollakin tavalla tyritty? Esim. joku Windows "osaaja" on suorittanut asennuksen noudattamatta annettuja ohjeita?
PS. Aivan lopuksi vain tämä, avoin lähdekoodi (open source) ei tuota automaattisesti virheetöntä koodia, vaan tämäkin VAATII hyvää osaamista. Avoimen lähdekoodin ETU on siinä, että tässä ohjelmoija antautuu julkiselle kritiikille näyttäessään mitä ja miten on koodannut. Suljetussa lähdekoodissa suuremmat ja pienemmät "mokat" peitetään liikesalaisuuden nimeen.
Avoimen lähdekoodin mahdollistama julkisuus karsii pian pois osaamattomat koodarit, ehkä nämä saavat pian uuden paikan siltä "suljetulta puolelta".
Suljetun puolen "väki" ei taida tarvita osaamistaitoja eikä juuri tietoja mistään, heille riittää kun päivärahat (tai lääkkeet) juoksee. Monen koodarin ammattitauti onkin hermoromahdus kun heiveröiset aivot ylikuormittuu.
Ei minua kiinnosta Gentoo. Ihan sama kuinka reikäinen se on. Red Hatia ja Ubuntua ei koske Gentoon turvareiät.
Kuitenkin Ubuntussa, RedHatissa ja Gentoossa on lähes identtiset koodit.
Ei tietenkään ole. Turvareiät on vähän sellainen juttu, että pitää olla sama versionumero komponentissa eikä sittenkään välttämättä päde kun on voitu konfiguroida niin, että haavoittuva toiminto on vaikka pois käytöstä. Pa5kapuhetta yrittää väittää Gentoon reikien liittyvän Ubuntuun ja Red Hatiin.
Turvareikiä kyllä varmasti on mutta ne ovat tosiaankin käyttöjärjestelmästä ja käyttöjärjestelmän versiosta riippuvaisia.
M-Kar ja muut lukutaidottomat eivät kai ymmärtäneet mitä Tietoviikko sanoi reikäisimmistä. Luetaan nyt se yksi lause tarkemmin:
"Tietoturvasta vastaaville ei siis ole helppoa, ja vaikeutta lisäävät erilaisissa yleisesti käytetyissä kirjastoissa ja komponenteissa olevat haavoittuvuudet. "
Tossahan se syy sanotaan. Tietyt koodarit ovat niin laiskoja henkisesti, että käyttävät joka paikassa ohjelmointikieliin sisältyviä "vakiokirjastoja" sellaisenaan.
Vakiokirjaston sisällön pakkotyrkytys joka paikkaan on virhe, koodarin pitäisi voida itse HARKITA milloin ei ole syytä käyttää vakiokirjastoa vaan kirjoittaa kokonaan uusi käytettävä koodi josta on poistettu "kaikki ne toiminnot" joita ei käytetä. Vakiokirjastojen sisältö voi mahdolistaa ei-toivottuja toimintoja sovelluksissa. Turvallisuusaukko eli "reikä" syntyy toiminnoista jotka ovat mahdollisia koska niitä toimintoja ei olla poistettu. Vakiokirjastoilla on oma kokonainen sisältönsä joka koodarin PITÄISI tuntea.
Mutta kun ollaan henkisesti laiskoja niin nopeaa koodia syntyy käyttämällä vakiokirjastoja koska ei tarvita niin paljon ajatustyötä. Ja palkanmaksaja on mielissään kun syntyy nopeasti koodia.
Ohjelmointikulttuuri ja tietoturva on osaksi ristiriidassa keskenään. Hyvä tietoturva vaatisi usein sitä. että EI käytetä laajoja vakiokirjastoja joka paikassa vaan tuotettaisiin vain sitä tarpeellista koodia. Osaava koodari voi välttää vakiokirjastojen tuomat ongelmat kirjoittamalla "suppeampaa koodia" tarkoituksiinsa jota tavoittelee.
Lähdekoodia käännettäessä binäärikoodiksi mukaan tulee kaikki se mikä sisältyy vakiokirjaston sisältöön vaikka niissä olisi ko. tarkoitukseen sopimatonta. Miksi ei tuoteta enemmän yksilöllistä koodia määriteltyyn tarkoitukseen?
Kyllä koodarin pitää tuntea vakiokirjaston käytön riskit! Tämä kuuluu ammatin hallintaan.
Tietokone toteuttaa sen mitä binäärikoodiin sisältyy ja jos käytettävät komponentit vielä sen sallii. Reikä on syntynyt. Reikä on itse aiheutettu koska koodari ei ole välittänyt (ei kyennyt) ajatella mitä kaikkea vakiokirjastoihin sisältyy. Ohje on selvä: käytä vakiokirjastoja HARKITEN.
Eli VAIN ammattilaiskoodari voi saada linux-jakelun turvalliseksi.
Ammattilaiset niitä käyttöjärjestelmiä tekeekin. Red Hat ja Ubuntu esimerkiksi ovat turvallisia.
Kyllä näin se on. Vain osaava saa linuxdistrot ja muut käyttöjärjestelmät turvallisemmiksi. Käyttöjärjestelmien turvallisuus ei todellakaan synny "mutu" (musta tuntuu) ajattelun pohjalta vaan osaamisesta eli on tunnettava miten se käyttöjärjestelmä toimii ja miten sitä käytetään turvallisesti.
Netti (internetti) on yleisesti ottaen aika turvaton paikka ei sinne kannata mennä seikkailemaan "mutu" (musta tuntuu) tuntumalla. On siis tiedettävä kuinka netissä tulee käyttäytyä. Eli osaamista vaaditaan.
Loppukäyttäjän ei onneksi tarvitse olla ammattikoodari kun ammattilaiset ovat tehneet käyttöjärjestelmän niin helpoksi ja turvalliseksi.
Päinvastoin, loppukäyttäjän nimenomaan pitää olla ammattikoodaritasoa saadakseen konfiguroitua linux-jakelun turvalliseksi käyttää. Muuten menee linux-jakelun kanssa metsään.
Ei tarvitse kun voi käyttää helppokäyttöistä Androidia tai Ubuntua. Tuollainen ammattikoodaritason osaaminen mitä tarvitaan liittyy varmaan Windowsin kernelin kääntöihin.
Ϯ Ϯ Ϯ
Windows on paras ja ainoa...†
Windows 7.................55.92%
Windows XP...............18.93%
Windows 8.1...............10.04%
Windows 8..................3.79%
Mac OS X 10.10..........3.45%
Windows Vista.............2.44%
Mac OS X 10.9............1,82%
Linux...........................1.34%
http://netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0&qpct=6
Windows on paras ja ainoa...†††
Vakiokirjastojen käyttöä ohjelmoinnissa voisi verrata julkisen kirjaston käyttöön.
Jokaisessa julkisessa kirjastossa (esim. kaupungin) on aineistoa joka ei sovi kaikille ja on aineistoa jota kaikki eivät ymmärrä syystä tai toisesta. Useimmin syynä on koulutuksen vaje taikka yksinkertaisesti tyhmyys.
Miksi siis ohjelmoinnissa pitäisi tyrkyttää näitä vakiokirjastoja kaikille?
En nyt tiedä mitä oikein selität mutta kyllä se käyttöjärjestelmän valmistaja kertoo ne natiivikirjastot joita tulisi käyttää ja jotka on parhaiten tuettuna.
Luepa jostakin ohjelmointia käsittelevästä kirjasta miten vakiokirjastoja tulee käyttää. Esittämäsi "natiivikirjasto" voi olla ohjelmointikielen vakiokirjasto tai varta vasten erikseen kirjoitettu "yksilöllinen" kirjastopaketti tiettyyn määriteltyyn tarkoitukseen.
Esimerkiksi Bjarne Stroustrupin kirjassa "C ohjelmointi" on lukukappale 'Vakiokirjaston esittely' ja laajempi esittely on osassa III nimellä 'Vakiokirjasto'. En viitsi alkaa toistamaan kaikkea mitä tässä sanotaan. Näistä vaan sanotaan mm.:
"Ne ovat käteviä, tehokkaita ja KOHTUULLISEN TURVALLISIA tavallisessa käytössä".
Tämä herra on C kielen suunnittelija ja alkuperäinen toteuttaja. Tällä herralla lienee riittävästi asiantuntemusta, enemmän kuin tämän palstan asiantuntijoilla.
Joten en minä omiani selittele kuten kirjoitit "en nyt tiedä mitä oikein selität..." . Hanki edes perustiedot ohjelmoinnista, tutustu C kieleen ja miten siinä käytetään vakio- tai yksilöllisesti tarpeeseen koodattuja kirjastoja.
Kun otsikkotiedostossa viitataan kirjastoihin niin se merkitsee sitä, että ko. kirjastot "otetaan käännökseen mukaan" sellaisena kuin ne kirjastot ovat. Jos kirjastoissa on jotakin joka ei ole tarkoituksenmukaista niin se voi mahdollisesti aiheuttaa haavoittuvuuden. Tämän vuoksi on tehtävä valinta: käytetäänkö valmista vakiokirjastoa vai ryhdytäänkö kirjoittamaan aiotulle tehtävälle yksilölllistä koodipakettia. Kykenetkö edes erottamaan näitä kahta asiaa toisistaan? Kriittisissä turvallisuutta vaativissa tehtävissä kannattaa harkiten käyttää vakiokirjastoja.
Selityksesi on niin epäselvää, ei tässä muuta. Nähtävästi et sitä ohjelmointia tiedä. Katsos kun C :aa ei pahemmin käytetä enää sovellusohjelmoinnissa. Sovellusohjelmoinnissa se käyttöliittymä tehdään useimmiten Javascriptillä tai käännetään Javascriptiksi esim. Typescriptistä tai Coffeescriptistä, tai jos käyttää vaikka Qt:tä niin se tehdään QML:llä joka on Javascript johdannainen.
Minulla on laaja ymmärrys ohjelmoinnista mutta sinä et osaa edes muotoilla asiaasi. Kun tehdään alustalle X softaa niin ihan normaalisti käytetään kyseisen alustan natiivikirjastoja ettei tehdä samaa työtä moneen kertaan, saadaan pisin jatkuvuus ohjelmalle, säästetään muistin käytössä, look & feel, suorituskyky, ja sitten siitä toiminnasta lisäksi huolehtii se alustan toimittaja eikä sovelluksen tekijä. Sovellusohjelmoija keskittyy siihen sovellukseen eikä siihen miten nappi piirretään ruudulle.
Alustan natiivikirjastoja on esim. Androidilla Android API, Mac OS:llä Cocoa, Ubuntulla Qt5, Windowsilla WinRT, Red Hat Enterprisellä GTK 2.
Turvallisuuskriittisiin juttuihin löytyy tietysti sertifiointeja myös, samoin safety critical juttuihin.
Kovin pieni on M-Karin ohjelmointimaailma:
"Sovellusohjelmoinnissa se käyttöliittymä tehdään useimmiten Javascriptillä tai käännetään Javascriptiksi esim. Typescriptistä tai Coffeescriptistä, tai jos käyttää vaikka Qt:tä niin se tehdään QML:llä joka on Javascript johdannainen."
Tässäkö on koko ohjelmointimaailma? Käyttöliittymien ohjelmointiko on se kaiken ohjelmoinnin tarkoitus? Eipä ole sitten ihme, että nämä käyttöliitymä koodaripellet ovat saaneet tietokonekulttuurin menemään aivan pilalle. Toiset koodaripellet koodaa aina mitä ihmeellisimpiä käyttöliittymiä jotka kuluttavat tietokoneen resurssit kokonaan.
Käyttöliittymän "pyörityskö" on se tietokoneen käytön tarkoitus?
Kyllä minä tekisin tietokoneella hyödyllistä työtä ennemmin kuin leikkisin pitkät päivät eriskummallisilla käyttöliittymillä. Onko käyttöliittymä koodaus näiden koodaripelle lauman takia muuttunut perliohjelmoinniksi? Miksi käyttöliittymän pitää olla jokin eriskummallinen tietokonepeli?
Toisen harhasi esitit ajatuksessa:
"Alustan natiivikirjastoja on esim. Androidilla Android API, Mac OS:llä Cocoa, Ubuntulla Qt5, Windowsilla WinRT, Red Hat Enterprisellä GTK 2."
Tähänkö rajoittuu koko ohjelmoinnin pieni maailmasi? Ei, kyllä se maailma on laajempi, paljon laajempi. Ohjelmointikieliä on yli 1000 kappaletta ja yhä uusia luodaan, joista suurin osa unohtuu melko nopeasti. Jotkut ohjelmointikielet taas jäävät elämään varsin pitkään. Äläkä unohda niitä "assembler" kieliä joilla tuotetaan suoraan mikroprosessorin ymmärtämää konekieltä. Näitäkin on useampia koska ne ovat riippuvaisia prosessoriarkkitehtuurista.
Periaatteessa tietokone ei välitä lainkaan millä ohjelmointikielellä mikäkin sovellus on tuotettu koska ne käännetään tai tulkataan aina tietokoneen ymmärtämään "binääriseen" konekieleen.
Unohdit kokonaan komentotulkkien ohjelmoinnin. Näissäkin on useampi kieli vaihtoehto olemassa. Eräs komentotulkki on varsin pitkälle C-kielen tyyliä noudattava (Csh) ja on olemassa myös "Scheme" ohjelmointikieltä noudattava Scsh komentotulkki. Nämä nyt vaan esimerkkeinä.
Älä nyt rupea kutistamaan ohjelmoinnin maailmaa noin pieneksi kun esitit. Windowsin NET-arkkitehtuurikin vaatii "omat" kielensä ("net-kielet", esimerkkinä nyt vaikka C#) ja vakiokirjastonsa.
"Tässäkö on koko ohjelmointimaailma? Käyttöliittymien ohjelmointiko on se kaiken ohjelmoinnin tarkoitus?"
Ei tietenkään. Viestiketjussa vaan on aiheena sovellukset ja sovelluksissa on sitten se frontend (käyttöliittymä) koodi niissä päätelaitteissa ja sitten on backend (tallentava/prosessoiva) koodi palvelimessa.
Käyttöliittymässä Javascript hallitsee ja on defacto standardi, sitten on ne natiivisovellukset (käyttöliittymät) ja palvelimessa sitten on enemmän hajontaa.
"Käyttöliittymän "pyörityskö" on se tietokoneen käytön tarkoitus?"
Tiettyjen tietokoneiden kyllä. Eli läppärit, taskukoneet, taulukoneet, desktop koneet jne. Eli päätelaitteet. Oikeaoppisesti toimittuna päätelaitteissa pyritään ajamaan käyttöliittymiä, ja tallentava/prosessoiva osuus sitten on palvelimissa. Lisäksi on laitteita jotka kiinnittyvät johonkin hassunhauskaan rautaan olennaisella tavalla ja sulautettu sinne, että saa tehtyä sen välttämättömän prosessoinnin ja kiinni IP-verkkoon.
"Ohjelmointikieliä on yli 1000 kappaletta ja yhä uusia luodaan, joista suurin osa unohtuu melko nopeasti."
Suurin osa on vanhaa sontaa jota hävitetään tai sitten jotain uusia jotka tekee samaa mutta eritavalla mitä nykyisin pääasiassa käytetään. Ohjelmointikielen merkitys kyllä vähenee kokoajan. Sekin kun puhuin Javascriptistä niin paljon käännetään Coffeescriptiä Javascriptiksi esimerkiksi.
"Äläkä unohda niitä "assembler" kieliä joilla tuotetaan suoraan mikroprosessorin ymmärtämää konekieltä. Näitäkin on useampia koska ne ovat riippuvaisia prosessoriarkkitehtuurista"
Niitä ei juurikaan käytetä. Itseasiassa niitä ei käytetä ellei ole pakko. Kääntäjät on keksitty.
Mitäs sille voi kun jollekin kaikki on epäselvää. Ei C kieli vielä ole kuollut, vaikka Windows ympäristössä taidetaan suosia enemmän C# kieltä.
Ehkä olen sellainen "fossiili" joka vielä käyttää tälläisiä vanhoja kieliä kuten C , Fortran, Cobol ja Lisp. Nämä taitaa olla nykypolvelle aika tuntemattomia kieliä?
Kumma kyllä näidenkin taidoista vielä maksetaan palkkaa jollekin ja joku kustantaa sillä jopa elämisensä.
Ja Mac OS:ssä suositaan ObjektiveC:tä, Androidissa Javaa, Ubuntussa QML:ää jne.
C on sellainen mitä suositaan pelimoottoreissa, Ubuntussa silloin kun QML ei riitä, käytetään myös crossplatform desktopsovelluksissa Javan ohella kun Javascript ei riitä, rajoitetusti safety critical käytössä kun C ja Ada ei sovellu...
C on se perusvalinta kun tarvitaan prosessorin arkkitehtuurille käännetty oliokieli joka mahdollistaa oikoreittejä C:n tapaan. Toinen prosessorin arkkitehturille käännetty oliokieli mitä käytetään on sitten Ada, mutta siinä on painotettu sitä reaaliaika, rinnakkaisuus ja safety critical ohjelmointia.
Leiki leiki lapsonen niitä käyttöliittymäleikkejäsi. Eihän lapsoset osaa tietokoneella muuta tehdäkään kuin leikkiä sillä käyttöliittymällä jännittävää valikkoleikkiä.
Aina kun muutoksia (päivityksiä) tehdää niitä valikkoja saa kahlata aina uudella tavalla. Väillä on "alasvetovalikoita" ja välillä on tilanteen mukaan muuttuvia "nauhoja". Lopuksi se suuri sininen BSOD yllättää.
Ja se mikä on varmaa, terveytesi kärsii. Nyt suurena uhkatekijänä on ranne- ja sormivammat hiiren ja näytön tökkimisen vuoksi. Käyttöliittymien tekijöillä ei liene mitään tietoa ergonometriasta eli mitä kaikkea ihmisen fysiikka ja psyyke kestää näissä iki-ihanissa käyttöliittymäleikeissä?
Minkälaiset seuraukset tästä on ihmisen evoluutiolle?
Käyttöliittymä ei sitä BSOD:ia tee. C :n kaltaiset kielet voi kyllä tehdä segfaulttia ja kaataa ohjelman.
Käyttöliittymä on rajapinta siinä missä muutkin rajapinnat (esim. API) ja ne pyritään pitämään myös vakaina. Käyttöliittymissä käytetään muuten paljon näppäimistöä.
Osaamattomuus kaataa ohjelman. Ohjelmoijan vastuulla on se, että kirjoittaa toimivaa käyttöjärjestelmän tai sovelluksen lähdekoodia joka käännetään tai tulkataan "binäärisessä muodossaan" tietokoneessa. Tietokone ymmärtää vain binääristä koodia.
Osaamisesta kaikki on kiinni.
Tubuttajat voivat tuottaa sellaista lähdekoodia joka ei toimi ja "kaataa" koneen.
Varsinaiset elektroniikkarikot ja virheet ovat harvinaisempia mutta mahdollisia. Harvoin niitä monikerrospiirilevyjä komponentteineen korjaillaan, useimmin ne vaan vaihdetaan uuteen kokonaan.
BSOD:in yleisin syy on ohjelmavirhe, joka voi tulla myös käyttöliittymä virheestä.
BSOD tarvitsee virheen jossa kerneli kaatuu ja tarvitsee kernelin muistiavaruudessa tapahtuneen virheen.
Viallinen laitteisto, viallinen ajuri (virustutkat ja vastaavat mukaan lukien) jne. aiheuttaa tuota. Ei käyttöliittymävirheet. Käyttöliittymä jos on tehty Javascriptillä niin ei oikein tule segfaulttiakaan kun kieli ei mahdollista sellaista.
Taisitpa nyt unohtaa, se kernelikin on tietokoneohjelma. Kirjoitit näin:
"BSOD tarvitsee virheen jossa kerneli kaatuu ja tarvitsee kernelin muistiavaruudessa tapahtuneen virheen"
Minä kirjoitin näin:
"BSOD:in yleisin syy on ohjelmavirhe, joka voi tulla myös käyttöliittymä virheestä."
Käyttöliittymäohjelman (sovellus) "ajokin" vaatii prosessori toimintoja eli se käyttää oman osansa prosessorin ajoituksesta. Kernelin yhtenä osana on prosessien ajoittaminen eli käyttöajan jakaminen. JOS käyttöliittymä ohjelmasovellus toimii aivan väärin se voi aiheuttaa käyttövirheen joka kaataa prosessorin eli TULEE keskeytys väärästä toiminnosta esim. virhe muistinkäytössä, pinovirhe muistiavaruudessa.
Graafiset käyttöliittymät VOIVAT olla liian raskaita eli ne kuormittavat liikaa prosessoria, näin ainakin "vähämuistisissa" vanhoissa tietokoneissa. Moderni raskas graafinen käyttöliittymä voi aiheuttaa tietokoneen "kaatumista".
Graafinen käyttöliittymä ohjelmasovellus ajetaan "samassa muistissa" kuin muutkin sovellukset. Tähän soveltuu samat vaatimukset kuin muihinkin sovelluksiin eli käyttöliittymä ohjelma ei saa aiheuttaa prosessoriin keskeytyksiä joista ei toivuta ILMAN uudelleen käynnistystä. Käyttöliittymä virheet siis voivat kaataa prosessorin siinä missä muutkin sovellusohjelma virheet.
Kernel on käyttöjärjestelmän ydinohjelma joka toimii mm. sovellusohjelmien "ajoittajana" ja muistiavaruuden "valvojana". Kaikki vakavat ohjelmavirheet voivat aiheuttaa peruuttamattoman toiminnon eli prosessorin kaatumisen.(mm. BSOD) Graafisen käyttöliittymä ohjelmasovelluksen virhe EI tässä tee poikkeusta. Perussääntö on se, että ohjelmasovellukset eivät käytä jo varattuja muistialueita muistiavaruudesta. Muistin "päällekkäiset" käytöt aiheuttavat muistivirheitä, pinovirheitä. Ja nämä voivat kaataa prosessorin toiminnan eli tulee keskeytystoiminto. Eli tässä ollaan käyttöjärjestelmän ydintoiminnoissa. (kernel + käytössä oleva työmuistien koko) Työmuistiin kuuluu prosessorin sisäinen muisti ja mahdolliset ulkoiset lisämuistit (välimuistit). Kernelin yksi tehtävä on muistinhallinta ja kaikki vakavat virheet tässä voi aiheuttaa kaatumisia.
Raskas graafinen käyttöliittymä voi aiheuttaa kaatumisen koska "vapaa muistitila" LOPPUU. Kaikki ohjelmat vaativat tietyn määrän verran työmuistitilaa toimiessaan. ja kun tämä tila loppuu niin tietokone lopulta "jumittuu" tai kaatuu riippuen miten hyvin muistinsuojaus toimii.
Javascriptillä toteutettu ohjelmasovellus voi myös jumittaa tai kaataa tietokoneen kun työmuistin käyttötila (muistiavaruus) ei riitä käynnissä olevien käyttöjärjestelmän omien prosessien ja sovellusten ajoon. Kun prosessorin kuorma on täydet 100 %:a niin voi tapahtua melkein mitä tahansa tilanteessa jossa sovellusohjelmat menee muistissa "päällekkäin" käyttäen jo varattuja muistialueita. Tässä seuraus on keskeytystoiminto.
Muistiavaruutta EI VOI kuormittaa täyteen 100 %:n asti vaan vapaata tilaa (free memory) täytyy löytyä riittävästi. Tämän vuoksi vanhoissa tietokoneissa EI VOI käyttää mammuttimaisia ohjelmasovelluksia vaan on huomioitava "minimivaatimukset" toiminnoille.
"Taisitpa nyt unohtaa, se kernelikin on tietokoneohjelma."
Keskustelun aiheena oli sovellukset.
"JOS käyttöliittymä ohjelmasovellus toimii aivan väärin se voi aiheuttaa käyttövirheen joka kaataa prosessorin eli TULEE keskeytys väärästä toiminnosta esim. virhe muistinkäytössä, pinovirhe muistiavaruudessa."
Siellä on sellainen juttu olemassa kuin muistinsuojaus. Kyseinen prosessi kaatuu, ei kerneli. BSOD on kernelin kaatuminen ja virheen täytyy tapahtua kernelin muistinavaruudessa. Kernelin muistiavaruudessa on kerneli itse, laiteajurit ja laiteajurien tavoin toimivat jutut. Prosesseilla on sitten omat muistiavaruudet ja ne on eristettyjä.
"Graafiset käyttöliittymät VOIVAT olla liian raskaita eli ne kuormittavat liikaa prosessoria, näin ainakin "vähämuistisissa" vanhoissa tietokoneissa."
Edelleenkin ne on eristetty, että prosessit voivat kaatuilla mutta kernelin kaatumiseen tarvitaan virhe kernelin muistiavaruudessa.
"Javascriptillä toteutettu ohjelmasovellus voi myös jumittaa tai kaataa tietokoneen kun työmuistin käyttötila (muistiavaruus) ei riitä käynnissä olevien käyttöjärjestelmän omien prosessien ja sovellusten ajoon."
Ei oikeastaan. Javascript varaa muistia ajoympäristössä ja niihin on tehty rajoitteita muistin varaukselle ettei mikä tahansa nettisivu esimerkiksi varaa muistia täyteen. Taitaa olla nykyiset rajat jossain puolen gigan tietämissä.
"Muistin "päällekkäiset" käytöt aiheuttavat muistivirheitä, pinovirheitä."
Ne muistialueet on suojattu. Eri prosesseilla ja kernelillä on omat muistialueet ja ne eivät pääse sotkemaan toistensa alueita.
"Ei oikeastaan. Javascript varaa muistia ajoympäristössä ja niihin on tehty rajoitteita muistin varaukselle ettei mikä tahansa nettisivu esimerkiksi varaa muistia täyteen. Taitaa olla nykyiset rajat jossain puolen gigan tietämissä."
No niin, taas ollaan ajatussotkussa. Kai nyt ymmärrät sen, että sovellusohjelmien ajoympäristökin luodaan ohjelmallisesti. Javascript ja Java kieli eivät ole samoja, mutta tämä kertonee silti sen, että Javakielisten sovellusten turvallisuus on kiinni siitä miten hyvin se ohjelmallisesti toteutettu ajoympäristö toimii.
Ajoympäristössä voi myös olla virheitä. Nykyäänhän on suositua olio-ohjelmointi jossa muodostetut olitot toimivat yhtessä juuri niiden olioiden rajapintojen välityksellä. Ja näissä ohjelmallisesti luoduissa ajoympäristöissäkin voi olla virheitä.
Ja nämä virheet sitten voi aiheuttaa kyttöjärjstelmän tai sovellusohjelmien kaatumisia tai aiheuttaa siten vain tietoturva haavoittuvuuksia.
Peruskysymys kuuluukin: onko toteutetussa ajoympäristö kokonaisuudessaan virheitä?
Muista, ajoympäristö muodostuu kahdesta osasta: 1) fyysisistä komponenteista ja 2) ohjelmallisesta ajoympäristöistä. Näissä ajoympäristöissä voi olla monenlaisia variaatioita joskus vaaditaan jopa tietylle kielelle luotua erillistä ajoympäristöä käyttöjärjestelmässä. Näin esimerkiksi Javakielisissä sovelluksissa, niitä voidaan ajaa Oraclen JRE ajoympäristössä taikka Androidin Dalvik ajoympäristössä.
Javascriptiä käytetään laajasti selainohjelmoinnin yhteydessä eli tässä selain muodostaa sen ajoympäristön. Javascripti voi olla aivan oikein kirjoitettua koodia, mutta sitten siinä selainohjelmassa voi olla virheitä jotka aiheuttaa ongelmia. Onko selaimissa virheitä? Kyllä ja siksi niitä ajottain joudutaan päivityksin korjaamaan. Selainohjelma on käsitettävä ajoympäristönä joka toimii käyttöjärjsetelmäksi kutsutussa laajemmassa käyttöympäristössä.
Lyhyesti: käyttöjärjestelmä muodostaa ajoympäristöjen kokonaisuuden jossa ohjelmat toimivat. Kysymys kuuluukin: onko tässä ajoympäristössä virheitä? Kyllä.
Käyttöjärjestelmä on suuri ajoympäristö jossa voi olla myös osina muita ajoympäristöjä, kuten selaimia ja ohjelmointikielten vaatimia erillisiä ajoympäristöjä.
Eli kokonaisuus on osiensa summa jossa huonosti toimivat osat voivat kaataa koko järjestelmän.
"Javakielisten sovellusten turvallisuus on kiinni siitä miten hyvin se ohjelmallisesti toteutettu ajoympäristö toimii."
Javan ajoympäristö lähinnä mahdollistaa muistin käytön rajoittamisen, mutta muuten se pystyy kyllä availemaan portteja ja käsittelemään tiedostoja rajoittamatta, eli sovellusten turvallisuudessa olennaista on se, että tietää sovelluksen alkuperän ja luotettavuuden.
"Ja nämä virheet sitten voi aiheuttaa kyttöjärjstelmän tai sovellusohjelmien kaatumisia tai aiheuttaa siten vain tietoturva haavoittuvuuksia."
Niin mutta kun siellä on niiden ohjelmallisten ajoympäristöjen ohella myös se kernelitason hiekkalaatikointi joissa keskeinen tekniikka on muistinsuojaus. Siksi sovelluksen virheellä ei saa BSOD:ia tästä syystä. Siellä tulee segmentation fault. Virhe tarvitaan kernelin muistiavaruudessa tai viallinen rauta.
"Niin mutta kun siellä on niiden ohjelmallisten ajoympäristöjen ohella myös se kernelitason hiekkalaatikointi joissa keskeinen tekniikka on muistinsuojaus. Siksi sovelluksen virheellä ei saa BSOD:ia tästä syystä. Siellä tulee segmentation fault. Virhe tarvitaan kernelin muistiavaruudessa tai viallinen rauta."
M-Kar kirjoitit kauniisti, mutta reaalitodellisuudessa kaikki EI TOIMI niinkuin on suunniteltu teoriassa.
Onhan siellä hiekkalaatikkoa ja muistinsuojausta mutta kun se ei vaan aina toimi ajatellulla tavalla. Katos kun ne koodarit ovat voineet tehdä virheitä koodatessaan hiekkalaatikoita ja muistinsuojaksia. Netissä on julkaistu listaa tavallisimmista ohjelmointivirheistä ja listalla on varsin yleisenä ja toistuvana "ylivuoto" virheet eli sovellukset menevät toistensa muistialueille.
Osaksi tämä johtuu ohjelmointikielestä itsestään , kaikissa kielissä ei ole automaattista roskienkeruuta joten tämä jää koodarin (lähdekoodin tuottajan) vastuulle. C/C kielessä jota käytetään järjestelmäkielenä on tämä puute, jos tähän aiotaan rakentaa muistinsuojaus se on erikseen tehtävä (rakennettava) eli ne muistialueet on vapautettava joita ei enää käytetä. JOS tämä unohtuu niin edessä voi olla ylivuotoa muistissa.
C kielen "isä" Bjarne Strousstrup varoittaa tästä asiasta kirjassaan. Muunmuassa sivulla 603 hän varoittaa alustamattoman muistin käytöstä seuraavasti:
"Tämä merkintätapa on vaarallinen, mutta joskus tärkeä."
C kielen täydellinen hallinta on varsin vaikea alue. Riskejä riittää joten huolimattomuus tuo virheitä.
Valitettavasti tällä palstalle EI voi käsitellä kaikki C kielen tuomia virhe mahdollisuuksista. Lyhyesti viittaan vain sivun 606 tekstiin:
" Esimerkiksi tilan varaaminen oliolle new-operaattorilla ja vapauttaminen free() funtiolla on ongelmien kerjäämistä". Vakiokirjastossa on muistinvaraaja, joka on suunniteltu USEIMMILLE käyttäjille sopivaksi. Käyttäjät VOIVAT kirjoittaa muistinvaraajia, jotka käsittelevät ERI tavoin.
C kielessä muistinhallinta ei siis ole aivan helppo tehtävä, voidaan käyttää vakiokirjastoa tai sitten yksilöllistä erityistoteutusta. Mikä on paras tapa kuhunkin tehtävään on koodarin itsensä ratkaistava eli "mitä käyttää".
Näin siis lyhyesti kun ei voi opettaa enempää C kielestä. Itse olen sitä opiskellut useita vuosia mutta en voi vieläkään sanoa hallitsevani sitä täydellisesti.
"Katos kun ne koodarit ovat voineet tehdä virheitä koodatessaan hiekkalaatikoita ja muistinsuojaksia."
Kyllä kernelistäkin voi löytyä vika mutta enpäs muista nähneeni yhtään SP1 tason Windowsia kohta viiteentoista vuoteen missä tulisi BSOD kernelissä olevan virheen takia.
"Netissä on julkaistu listaa tavallisimmista ohjelmointivirheistä ja listalla on varsin yleisenä ja toistuvana "ylivuoto" virheet eli sovellukset menevät toistensa muistialueille."
Ylivuotovirhe on käytännössä mahdollista koodissa joka on tehty C tai C kielellä, ja sen lisäksi se ylivuoto ei tapahdu toisen sovelluksen muistialueelle vaan SAMAN prosessin muistialueelle. Siellä kun tulee se segfault jos yrittää kirjoittaa toisen prosessin muistialueelle ja Windowsissa ruudulle tulee ilmoitus "järjestelmä virheestä" tai "sovellus on suorittanut laittoman toiminnon" ja pyydetään ottamaan yhteyttä järjestelmänvalvojaan tms.
En nyt muista tarkkaa sanamuotoa mikä nykyisin on mutta ylivuotovirhe tekee juurikin näin. Kokeile vaikka, ei tule BSOD.
"Osaksi tämä johtuu ohjelmointikielestä itsestään , kaikissa kielissä ei ole automaattista roskienkeruuta"
Roskienkeruu tekee sitä, että muistia vapautetaan automaattisesti kun siihen ei enää viitata missään. Se ei kuitenkaan tee muistivuotoa mahdottomaksi.
"jos tähän aiotaan rakentaa muistinsuojaus se on erikseen tehtävä (rakennettava) eli ne muistialueet on vapautettava joita ei enää käytetä."
Vaan ei tarvitse kun se on jo siinä kernelissä. Ei onnistu kirjoittelemaan toisten sovellusten muistialueille vaan pitää mallocilla varata se muistialue mihin kirjoittaa. Vapauttamista jos ei tee niin tulee muistivuoto, ja jos kirjoittaa toisen prosessin muistialueelle tulee se segfault. Ja muistivuotokin sellainen, että kun prosessin lopettaa tai kerneli tappaa sen niin muisti vapautetaan.
"C kielessä muistinhallinta ei siis ole aivan helppo tehtävä, voidaan käyttää vakiokirjastoa tai sitten yksilöllistä erityistoteutusta. Mikä on paras tapa kuhunkin tehtävään on koodarin itsensä ratkaistava eli "mitä käyttää"."
Normaalisti se muistin vapautus tehdään destructorissa mutta olennainen juttu mikä pitää huomioida on se, että joku toinen olio ei sisällä pointteria muistialueeseen minkä poistettava olio vapauttaa.
Eli otetaan vaikka esimerkiksi peli. Ohjelmoi siihen jänis olion hyppimään niitylle. Sitten ilmassa lentää lämpöhakuinen ohjus joka lukittuu jänikseen ja lentää tätä kohti. Sillä välin jänis hyppää jalkaväkimiinaan ja räjähtää pa5kaksi..
Siinä vaiheessa tapahtuu jotain hyvin mielenkiintoista kun jäniksen poistaa muistista ja tähän lukittunut ohjus lukee jäniksen koordinaatteja, ellei tätä huomioi mitenkään.
Noin muuten sitten olioita voidaan myös luoda ja poistaa rekursiivisesti, varsin automaattisesti.
"Näin siis lyhyesti kun ei voi opettaa enempää C kielestä. Itse olen sitä opiskellut useita vuosia mutta en voi vieläkään sanoa hallitsevani sitä täydellisesti."
Ei sinun minua tarvitse opettaa, minä ohjelmoin jo assemblerilla 23v sitten, että kyllä nämä muistinhallintajutut ovat minulle ihan simppeleitä.
Kyllä minä luotan enenmmän C kielen "isän" kirjan tekstiin kuin näiden palstojen "asiantuntijoihin". Hanki vaan se kirja ja lue sieltä itse kappale muistinhallinnasta esimerkkeineen.
Varmasti hän kielen "isänä" tietää minkälaisen kielen teki. Tuntee varmaan myös tekemänsä kielen mahdoliset haavoittuvuudet.
Varmaan olet ohjelmoinut assemblerilla mutta ET kertonut millä assemblerillä? Näitähän on olemassa useampi. Ehkä tarkoitit niitä joilla ohjelmoidaan Intelin x86 arkkitehtuurisia prosessoreja. Nämä assemblerit ovat prosessori riippuvaisia.
Minä en edes yrittäisi x86 assemblerilla tuottaa koodia Motorolan 68000 tai MIPS arkkitehtuurisiin prosessoreihin.
Kommenttisi ovat useimmin sellaisia, että pidät itseäsi AINOANA asiantuntijana ja kaikki muut ovat enemmän tai vähemmän vajakkeja. Viittaan vain lausuntoosi erääseen tulostimen liitintä (so. kaapelia) koskevaan kysymykseen näillä palstoilla. Kaikki tulostimet EIVÄT todellakaan ole verkkotulostimia, vaan moni kotikäyttöön myyty laite on paikallistulostin. (nyt usb liitännällä). Vanhemmissa tulostimissa oli vielä rinnakkaisliitäntä (LPT 1-2) olemassa ja joissakin oli mahdollisuus jopa sarjaliitäntäänkin (COM 1-4)
Että tälläistä se tekniikka on kun historian hallitsee.
Kyllä sinun pitkä 23. vuotinen tietotekniikan "asiantuntijan kokemus" olisi pitänyt tämä tietää, etkä olisi kirjoitellut yksinomaan verkkotulostimen liitännästä. Minulla on aika hyvä muisti joten muistan kyllä vielä tulostin liitäntöjen historiaa.
Käsittäkseni kysymyksentekijä tarkoitti tätä:
Miksi kaikissa tulostinpaketeissa EI OLE vakiona mukana usb-kaapelia vaan se pitää ostaa useimmin erikseen? Näin minäkin olen joutunut ne ostamaan erikseen. Joissakin tapauksissa myyjä vielä on erikseen sanonut: tässä ei ole usb-kaapelia mukana. Tarvitko sellaisen?
Eikö "asiantuntija" tätä myyntitapaa tiedä?
"Kyllä minä luotan enenmmän C kielen "isän" kirjan tekstiin kuin näiden palstojen "asiantuntijoihin"."
Bjarne Stroustrup ei varmasti missään päin kirjaansa kiistä käyttöjärjestelmätason muistinsuojauksen olemassaoloa.
"Varmaan olet ohjelmoinut assemblerilla mutta ET kertonut millä assemblerillä?"
Useita. 6502, x86 ja sitten oli joku microcontrolleri myös.
"Kaikki tulostimet EIVÄT todellakaan ole verkkotulostimia, vaan moni kotikäyttöön myyty laite on paikallistulostin. (nyt usb liitännällä)."
Pa5kallakin on tekijänsä.
"Miksi kaikissa tulostinpaketeissa EI OLE vakiona mukana usb-kaapelia vaan se pitää ostaa useimmin erikseen?"
Koska niitä usein liitetään RJ-45:lla ja matkaa ei tiedetä onko se puoli metriä vai 15 metriä joten ei käydä läpipa5kojen mustesuhkujen hintaa nostamaan laittamalla kasaa kaapeleita mukaan.
""Kyllä minä luotan enenmmän C kielen "isän" kirjan tekstiin kuin näiden palstojen "asiantuntijoihin"."
Bjarne Stroustrup ei varmasti missään päin kirjaansa kiistä käyttöjärjestelmätason muistinsuojauksen olemassaoloa."
Ymmärsit kirjoitukseni aivan väärin. En kirjoittanut muistinsuojauksen kieltämisestä vaan muistinsuojauksen hallinnasta. Se vakiokirjaston tarjoama tapa EI OLE ainoa, se on vain useimpiin tarkoituksiin riittävä.
Turvakriittisiin tarkoituksiin on parempi yksilöllisesti kirjoitettu muistinhallinnan suojaus.
Et siis vieläkään tajunut sitä, että vakiokirjastojen käyttö voi olla riskialtista tietyissä tapauksissa joissa vaaditaan ehdotonta turvallisuutta. EN sanonut, että turvallisuusuhka on väistämätön vaan MAHDOLLINEN. Tämä on sellainen asia jota on syytä harkita turvakriittisissä sovelluksissa.
Enpä jatka tätä aihetta enempää koska kirjoitetut tekstit säännönmukaisesti ymmärretään väärin. Asiantuntijalla ja "asiantuntijalla" on eroa.