Kuinka suuri on bugin hinta?

junnukoodari

Mulla on käytössä koneellani avoimen lähdekoodin ohjelmia, joissa on joitain bugeja. Osaako joku arvioida, kunka paljon yksittäisen bugin korjaaminen maksaisi, jos palkkaisi ohjelmoijan tekemään homman, kun käytössä on laajoja miljoonien rivien tuntemattomia koodeja (esim. GTK , Firefox yms.)? Vai onko halvempaa opetella itse paikallistamaan bugi?

43

2085

    Vastaukset

    Anonyymi (Kirjaudu / Rekisteröidy)
    5000
    • ei pysty

      Tuota on aika mahdoton arvioida.
      Riippuu bugin vaikeudesta, koodin määrästä...
      Pahimmillaan bugi voi vaatia koodin tekemisen aivan uudelleen helpoimmillaan se on ihan muutaman minuutin juttu. Jos se johtuu ihan näppäily virheestä/ yhdestä väärästä käskystä voi päästä helpollakin. Mutta jos se ongelma on koko koodin huonoudessa tulee se maksamaan paljon.

      Näistä on mahdotonta antaa minkäänlaista arviota ilman koodin näkemistä.
      Mutta älä tänne laita sitä turvallisuus syistä.
      Paras olisi jos itse pystyt edes paikallistamaan ongelma kohdat.

      • junnukoodari

        "Näistä on mahdotonta antaa minkäänlaista arviota ilman koodin näkemistä."

        Totta. Useimmat ärsyttävät bugit ovat lähinnä sellaisia, että käytän avoimen lähdekoodin ohjelmistoja ja niissä ei sitten joku yksittäinen juttu toimi.

        Esimerkiksi jos avaan geditin komennolla valgrind gedit, niin se tulostaa

        ==10123== LEAK SUMMARY:
        ==10123== definitely lost: 13,668 bytes in 33 blocks
        ==10123== indirectly lost: 30,647 bytes in 1,602 blocks
        ==10123== possibly lost: 39,671 bytes in 1,169 blocks
        ==10123== still reachable: 2,652,599 bytes in 49,389 blocks
        ==10123== suppressed: 0 bytes in 0 blocks

        Mitenkähän noita kadonneita bittejä ja blokkeja kannattaisi lähteä etsimään? Vai kannattaako vaan tyytyä siihen, että asiat pystyy tekemään ohjelmalla vaikka konepellin alla kaikki ei olekaan täysin kunnossa?


      • junnukoodari kirjoitti:

        "Näistä on mahdotonta antaa minkäänlaista arviota ilman koodin näkemistä."

        Totta. Useimmat ärsyttävät bugit ovat lähinnä sellaisia, että käytän avoimen lähdekoodin ohjelmistoja ja niissä ei sitten joku yksittäinen juttu toimi.

        Esimerkiksi jos avaan geditin komennolla valgrind gedit, niin se tulostaa

        ==10123== LEAK SUMMARY:
        ==10123== definitely lost: 13,668 bytes in 33 blocks
        ==10123== indirectly lost: 30,647 bytes in 1,602 blocks
        ==10123== possibly lost: 39,671 bytes in 1,169 blocks
        ==10123== still reachable: 2,652,599 bytes in 49,389 blocks
        ==10123== suppressed: 0 bytes in 0 blocks

        Mitenkähän noita kadonneita bittejä ja blokkeja kannattaisi lähteä etsimään? Vai kannattaako vaan tyytyä siihen, että asiat pystyy tekemään ohjelmalla vaikka konepellin alla kaikki ei olekaan täysin kunnossa?

        Ei liity koodin avoimuuteen mitenkään. Se on vain lisensointiasia.

        Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.


      • Ubuisbest
        M-Kar kirjoitti:

        Ei liity koodin avoimuuteen mitenkään. Se on vain lisensointiasia.

        Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.

        Suljetun koodin bugeja on vielä vaikeampi etsiä, sekä korjata!
        Siksi avoimmen lähdekoodin bukittomuus on mahdollisempaa, tosin bugi ja bugi on joskus makuasia, mikä on bugi. Toki ihan tyhmät jutut.. mutta ei niittä yleensä päädykkään käännettyyn koodiin.
        Avoimen koodin yhteisö, on joukkovoimaa etsiä virheet..

        Sitten on ohjelmia jotka etsii virheitä.. ja että yksi hemmo hakisi bugit?? Heh heh.
        Kaikki mahdollista jos kaveri olisi oikea bugin haistaja :D

        Takaisinkääntäjällä voi myös etsiä bugeja ja reikiä. mm google kunnostautunut tällä alalla.


      • delphikoodaaja
        M-Kar kirjoitti:

        Ei liity koodin avoimuuteen mitenkään. Se on vain lisensointiasia.

        Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.

        "Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

        siis tosiasiassa C:llä ja C :lla kirjoitetut ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.

        Kun koodaan Delphillä, koodaamani ohjelmat toimivat asiallisesti eivätkä syö muistia myöskään ollessaan pidempään käytössä.

        Tässä 1 hyvä syy koodata Delphillä, vaikka M-Karia delphillä koodaaminen tuntuukin v*tuttavan aivan äärettömästi.

        Ehkäpä hän kokee laadukasta Delphi -koodia tuottavat koodaajat liian kovina kilpailijoina.

        Ei ole mikään ihme, että C:llä ja C :lla koodatut ohjelmat ovat täynnä virheitä. Jo kyseisten kielten syntaksi houkuttelee tekemään virheitä, ja syntaksin lisäksi on muitakin syitä, esim C:stä puuttuvat oikeat merkkijonot.

        C ja C ovat aivan liian kryptisiä kieliä, että niillä saisi mitään laadukasta aikaiseksi.


      • delphikoodaaja kirjoitti:

        "Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

        siis tosiasiassa C:llä ja C :lla kirjoitetut ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.

        Kun koodaan Delphillä, koodaamani ohjelmat toimivat asiallisesti eivätkä syö muistia myöskään ollessaan pidempään käytössä.

        Tässä 1 hyvä syy koodata Delphillä, vaikka M-Karia delphillä koodaaminen tuntuukin v*tuttavan aivan äärettömästi.

        Ehkäpä hän kokee laadukasta Delphi -koodia tuottavat koodaajat liian kovina kilpailijoina.

        Ei ole mikään ihme, että C:llä ja C :lla koodatut ohjelmat ovat täynnä virheitä. Jo kyseisten kielten syntaksi houkuttelee tekemään virheitä, ja syntaksin lisäksi on muitakin syitä, esim C:stä puuttuvat oikeat merkkijonot.

        C ja C ovat aivan liian kryptisiä kieliä, että niillä saisi mitään laadukasta aikaiseksi.

        "siis tosiasiassa C:llä ja C :lla kirjoitetut ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

        Valhe.

        Maailmassa on vain kolme ohjelmointikieltä joita kelpuutetaan safety critical käyttöön, eli käyttöön joissa ohjelmointivirheitä EI SAA olla.

        Ne kielet ovat C, C (subset) ja Ada). Javasta on myös tulossa versio safety critical käyttöön, eli joku subset C :n tapaan.

        Se tarkoittaa siis sitä, että näillä kielillä on mahdollista tehdä ohjelmia joissa virheiden määrä on olematon. Sellaisia mitä voi laittaa vaikka lentokoneeseen, ydinohjukseen, avaruussukkulaan jne.

        "Kun koodaan Delphillä, koodaamani ohjelmat toimivat asiallisesti eivätkä syö muistia myöskään ollessaan pidempään käytössä."

        Taidat nyt sekoittaa tähän jotain garbage collectorin puutetta. Garbage collector on tekniikka jolla ohjelmoijan ei tarvitse samalla tavalla huolehtia varatun muistin vapauttamisesta vaan sitä on automatisoitu. Koska muistin vapauttaminen vie aikaa, voi GC:llä saada kivasti lisää suorituskykyä kun muistia vapautetaan silloin kun kuormitusta on vähemmän. Haittapuolena se ei ole sitten niin deterministinen, että jos GC_n tarvitsee vapauttaa se muisti syystä tai toisesta silloin kun on kuormaa niin sehän vie aikaa. Jos on tiukat reaaliaikavaatimukset, GC:tä ei ainakaan vielä voi käyttää.

        Muistin käyttö ei siis olennaisesti ole mikään ongelma tässä koska muisti on sitä varten, että sitä käytetään ja saadaan tehostettua asioita. Ei sitä tyhjänä kannata pitää.

        "Tässä 1 hyvä syy koodata Delphillä"

        Jos se GC häiritsee niin C ja C kyllä toimivat sitten Object Pascalin tapaan ilman GC:tä, että tuo muistinkäyttöasia ei ole mikään syy vaan selvästikin valehtelet.

        "Ehkäpä hän kokee laadukasta Delphi -koodia tuottavat koodaajat liian kovina kilpailijoina."

        Delphiä käyttävät ohjelmoijat eivät missään nimessä ole kovia kilpailijoita, etenkin sellaiset jotka väittävät jonkun C :n olevan "kryptinen". Tuollaiset ovat ammattitaidottomia pilipaliohjelmoijia.

        Ammattilaiselle ei ole mikään ongelma käyttää mitä tahansa ohjelmointikieltä. Ammattilaiselle ohjelmointikieli on vain työkalu sen työn tekemiseen ja se työkalu valitaan sen projektin vaatimusten mukaisesti mitä ollaan tekemässä ja valitsemalla tähän paras työkalu. Yksi työkalu ei ole kaikissa tilanteissa ikinä paras.

        Delphi taas ei taas ei ole missään asiassa paras joten sitä ei ammattilaiset oikein käytä. 10v sitten sai melkein joka suhteessa parempaa maksutta.

        "Ei ole mikään ihme, että C:llä ja C :lla koodatut ohjelmat ovat täynnä virheitä."

        Kuten jo sanoin, ovat niitä harvoja kieliä millä voi tehdä virheettömiä ohjelmia.

        "Jo kyseisten kielten syntaksi houkuttelee tekemään virheitä"

        Roskaa. Kielten syntaksi ei olennaisesti houkuttele mihinkään virheisiin.

        "ja syntaksin lisäksi on muitakin syitä, esim C:stä puuttuvat oikeat merkkijonot."

        C on systeemitason ohjelmointikieli ja sillä ei juurikaan käsitellä merkkijonoja. Sillähän ohjelmoidaan kerneliä, laiteajureita, käyttöjärjestelmän kirjastoja ja jne. Tarve käsitellä merkkijonoja liittyy lähinnä sovellusohjelmointiin. Se toki onnistuu myös C:llä mutta on kömpelöä kun joka asia tehdään omalla funktiolla: https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html

        Sovellusohjelmoinnissa käytetään sovellusohjelmointiin tarkoitettua työkalua ja siinä tietystikin homma käy merkkijonotyypillä.


      • delphikoodaaja
        M-Kar kirjoitti:

        Ei liity koodin avoimuuteen mitenkään. Se on vain lisensointiasia.

        Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.

        Harhaluulo: "Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

        Tosiasia: Noin yleisesti ottaen C:llä, C :lla ja C#:llä ohjelmoidut ohjelmistot ovat lisenssistä riippumatta enemmän (harvemmin vähemmän) täynnä virheitä.

        Sensijaan Delphillä koodatuista harvemmin löytyy ainakaan vakavia virheitä. Delphillä koodatuista yleisin virhe on pikkuvirhe, joka aiheuttaa formin epäsiistin ulkonäön (ja toisinaan sen, että osa formin komponenteista jää piiloon).

        Syynä tuohon on se, että Microsoft on jokaisen uuden Windows -version jhulkaisun yhteydessä uuttanut pelisääntöjä. Eli Delphi -ohjelma, joka toimi täydellisen oikein Windows98:ssa, voi Vistassa ja Windows7:ssa näyttää rumalta. Syynä siis se, että ikkunan ne osat, jotka eivät kuulu ns. "Client area" -alueeseen, niiden koko on kasvanut jokaisen uuden windows -version myötä.

        Mutta esim. vakavia tietoturvan vaarantavia virheitä löytyy C/C -ohelmista moninkertaisesti sen määrän, mitä vastaavista Delphillä koodatuista ohjelmista.

        Tosin, jos koodaaja on oikeasti osaava, niin siinä tapauksessa
        Delphillä koodatuista ohjelmista ei yleensä löydy ensimmäistäkään vakavaa tietoturva -aukkoa, ei vaikka ohjelma olisi käytössä 20 vuotta ilman yhtään muutosta itse koodiin.


      • Vittu-sä-oot-niin-ruma
        M-Kar kirjoitti:

        "siis tosiasiassa C:llä ja C :lla kirjoitetut ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

        Valhe.

        Maailmassa on vain kolme ohjelmointikieltä joita kelpuutetaan safety critical käyttöön, eli käyttöön joissa ohjelmointivirheitä EI SAA olla.

        Ne kielet ovat C, C (subset) ja Ada). Javasta on myös tulossa versio safety critical käyttöön, eli joku subset C :n tapaan.

        Se tarkoittaa siis sitä, että näillä kielillä on mahdollista tehdä ohjelmia joissa virheiden määrä on olematon. Sellaisia mitä voi laittaa vaikka lentokoneeseen, ydinohjukseen, avaruussukkulaan jne.

        "Kun koodaan Delphillä, koodaamani ohjelmat toimivat asiallisesti eivätkä syö muistia myöskään ollessaan pidempään käytössä."

        Taidat nyt sekoittaa tähän jotain garbage collectorin puutetta. Garbage collector on tekniikka jolla ohjelmoijan ei tarvitse samalla tavalla huolehtia varatun muistin vapauttamisesta vaan sitä on automatisoitu. Koska muistin vapauttaminen vie aikaa, voi GC:llä saada kivasti lisää suorituskykyä kun muistia vapautetaan silloin kun kuormitusta on vähemmän. Haittapuolena se ei ole sitten niin deterministinen, että jos GC_n tarvitsee vapauttaa se muisti syystä tai toisesta silloin kun on kuormaa niin sehän vie aikaa. Jos on tiukat reaaliaikavaatimukset, GC:tä ei ainakaan vielä voi käyttää.

        Muistin käyttö ei siis olennaisesti ole mikään ongelma tässä koska muisti on sitä varten, että sitä käytetään ja saadaan tehostettua asioita. Ei sitä tyhjänä kannata pitää.

        "Tässä 1 hyvä syy koodata Delphillä"

        Jos se GC häiritsee niin C ja C kyllä toimivat sitten Object Pascalin tapaan ilman GC:tä, että tuo muistinkäyttöasia ei ole mikään syy vaan selvästikin valehtelet.

        "Ehkäpä hän kokee laadukasta Delphi -koodia tuottavat koodaajat liian kovina kilpailijoina."

        Delphiä käyttävät ohjelmoijat eivät missään nimessä ole kovia kilpailijoita, etenkin sellaiset jotka väittävät jonkun C :n olevan "kryptinen". Tuollaiset ovat ammattitaidottomia pilipaliohjelmoijia.

        Ammattilaiselle ei ole mikään ongelma käyttää mitä tahansa ohjelmointikieltä. Ammattilaiselle ohjelmointikieli on vain työkalu sen työn tekemiseen ja se työkalu valitaan sen projektin vaatimusten mukaisesti mitä ollaan tekemässä ja valitsemalla tähän paras työkalu. Yksi työkalu ei ole kaikissa tilanteissa ikinä paras.

        Delphi taas ei taas ei ole missään asiassa paras joten sitä ei ammattilaiset oikein käytä. 10v sitten sai melkein joka suhteessa parempaa maksutta.

        "Ei ole mikään ihme, että C:llä ja C :lla koodatut ohjelmat ovat täynnä virheitä."

        Kuten jo sanoin, ovat niitä harvoja kieliä millä voi tehdä virheettömiä ohjelmia.

        "Jo kyseisten kielten syntaksi houkuttelee tekemään virheitä"

        Roskaa. Kielten syntaksi ei olennaisesti houkuttele mihinkään virheisiin.

        "ja syntaksin lisäksi on muitakin syitä, esim C:stä puuttuvat oikeat merkkijonot."

        C on systeemitason ohjelmointikieli ja sillä ei juurikaan käsitellä merkkijonoja. Sillähän ohjelmoidaan kerneliä, laiteajureita, käyttöjärjestelmän kirjastoja ja jne. Tarve käsitellä merkkijonoja liittyy lähinnä sovellusohjelmointiin. Se toki onnistuu myös C:llä mutta on kömpelöä kun joka asia tehdään omalla funktiolla: https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html

        Sovellusohjelmoinnissa käytetään sovellusohjelmointiin tarkoitettua työkalua ja siinä tietystikin homma käy merkkijonotyypillä.

        M-paska sekoilee taas, saatana miten tyhmä juntti, joku voi olla.


      • delphikoodaaja kirjoitti:

        Harhaluulo: "Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä."

        Tosiasia: Noin yleisesti ottaen C:llä, C :lla ja C#:llä ohjelmoidut ohjelmistot ovat lisenssistä riippumatta enemmän (harvemmin vähemmän) täynnä virheitä.

        Sensijaan Delphillä koodatuista harvemmin löytyy ainakaan vakavia virheitä. Delphillä koodatuista yleisin virhe on pikkuvirhe, joka aiheuttaa formin epäsiistin ulkonäön (ja toisinaan sen, että osa formin komponenteista jää piiloon).

        Syynä tuohon on se, että Microsoft on jokaisen uuden Windows -version jhulkaisun yhteydessä uuttanut pelisääntöjä. Eli Delphi -ohjelma, joka toimi täydellisen oikein Windows98:ssa, voi Vistassa ja Windows7:ssa näyttää rumalta. Syynä siis se, että ikkunan ne osat, jotka eivät kuulu ns. "Client area" -alueeseen, niiden koko on kasvanut jokaisen uuden windows -version myötä.

        Mutta esim. vakavia tietoturvan vaarantavia virheitä löytyy C/C -ohelmista moninkertaisesti sen määrän, mitä vastaavista Delphillä koodatuista ohjelmista.

        Tosin, jos koodaaja on oikeasti osaava, niin siinä tapauksessa
        Delphillä koodatuista ohjelmista ei yleensä löydy ensimmäistäkään vakavaa tietoturva -aukkoa, ei vaikka ohjelma olisi käytössä 20 vuotta ilman yhtään muutosta itse koodiin.

        "Tosiasia: Noin yleisesti ottaen C:llä, C :lla ja C#:llä ohjelmoidut ohjelmistot ovat lisenssistä riippumatta enemmän (harvemmin vähemmän) täynnä virheitä."

        Samalla tavalla kuin vaikka Delphillä. Olennaisesti tässä vaikuttaa koodirivien määrä ja kompeksisuus. Mitä yksinkertaisemmin saa asian tehtyä, sitä vähemmän on virhettä.

        "Sensijaan Delphillä koodatuista harvemmin löytyy ainakaan vakavia virheitä."

        Roskaa. Miksi niitä Delphillä tehtyjä ohjelmia sitten päivitetään jatkuvasti? Skypeä korjataan monta kertaa vuodessa ja välillä on turvareikiä myös.

        "Syynä tuohon on se, että Microsoft on jokaisen uuden Windows -version jhulkaisun yhteydessä uuttanut pelisääntöjä. Eli Delphi -ohjelma, joka toimi täydellisen oikein Windows98:ssa, voi Vistassa ja Windows7:ssa näyttää rumalta. Syynä siis se, että ikkunan ne osat, jotka eivät kuulu ns. "Client area" -alueeseen, niiden koko on kasvanut jokaisen uuden windows -version myötä."

        Normaalisti ne säädetään oikeaan kokoon. Tietysti ohjelman ulkoasun pitää toimia vaikka vaihdellaan teemaa, fontteja, DPI:tä jne. ja näyttö vaihdetaan vaikka 1024x768 koosta 4K näytöksi. Ei muuta kuin bugikorjausta kehiin vaan. Microsoft on noita ongelmia toki korjannut kun Windowsin vanhat rajapinnat juontavat juurensa jostain 80-luvulta mutta vanhaa WinAPI:a on tekohengitetty .NET 3.0:ssa saatiin noita tehtyä paljon fiksummin. HTML5 ja WinRT korjasivat skaalausongelmat lopullisesti.

        "Mutta esim. vakavia tietoturvan vaarantavia virheitä löytyy C/C -ohelmista moninkertaisesti sen määrän, mitä vastaavista Delphillä koodatuista ohjelmista."

        Toki, koska C/C koodia on moninkertaisesti enemmän kuin jotain marginaalista Delphi koodia. Sitä kun on koneessa vaikka 150 miljoonaa riviä C koodia ja sitten on tuhat riviä Delphi koodia niin onko se nyt mikään ihme jos C koodista löytyy enemmän virheitä?


      • Sotkijalle
        M-Kar kirjoitti:

        "Tosiasia: Noin yleisesti ottaen C:llä, C :lla ja C#:llä ohjelmoidut ohjelmistot ovat lisenssistä riippumatta enemmän (harvemmin vähemmän) täynnä virheitä."

        Samalla tavalla kuin vaikka Delphillä. Olennaisesti tässä vaikuttaa koodirivien määrä ja kompeksisuus. Mitä yksinkertaisemmin saa asian tehtyä, sitä vähemmän on virhettä.

        "Sensijaan Delphillä koodatuista harvemmin löytyy ainakaan vakavia virheitä."

        Roskaa. Miksi niitä Delphillä tehtyjä ohjelmia sitten päivitetään jatkuvasti? Skypeä korjataan monta kertaa vuodessa ja välillä on turvareikiä myös.

        "Syynä tuohon on se, että Microsoft on jokaisen uuden Windows -version jhulkaisun yhteydessä uuttanut pelisääntöjä. Eli Delphi -ohjelma, joka toimi täydellisen oikein Windows98:ssa, voi Vistassa ja Windows7:ssa näyttää rumalta. Syynä siis se, että ikkunan ne osat, jotka eivät kuulu ns. "Client area" -alueeseen, niiden koko on kasvanut jokaisen uuden windows -version myötä."

        Normaalisti ne säädetään oikeaan kokoon. Tietysti ohjelman ulkoasun pitää toimia vaikka vaihdellaan teemaa, fontteja, DPI:tä jne. ja näyttö vaihdetaan vaikka 1024x768 koosta 4K näytöksi. Ei muuta kuin bugikorjausta kehiin vaan. Microsoft on noita ongelmia toki korjannut kun Windowsin vanhat rajapinnat juontavat juurensa jostain 80-luvulta mutta vanhaa WinAPI:a on tekohengitetty .NET 3.0:ssa saatiin noita tehtyä paljon fiksummin. HTML5 ja WinRT korjasivat skaalausongelmat lopullisesti.

        "Mutta esim. vakavia tietoturvan vaarantavia virheitä löytyy C/C -ohelmista moninkertaisesti sen määrän, mitä vastaavista Delphillä koodatuista ohjelmista."

        Toki, koska C/C koodia on moninkertaisesti enemmän kuin jotain marginaalista Delphi koodia. Sitä kun on koneessa vaikka 150 miljoonaa riviä C koodia ja sitten on tuhat riviä Delphi koodia niin onko se nyt mikään ihme jos C koodista löytyy enemmän virheitä?

        Älä sotke näitä asiallisia keskusteluja, kun et tiedä ohjelmoinnista yhtään mitään. HuuHaa höpötykset muualle.


      • Sotkijalle kirjoitti:

        Älä sotke näitä asiallisia keskusteluja, kun et tiedä ohjelmoinnista yhtään mitään. HuuHaa höpötykset muualle.

        Tiedän ohjelmoinnista valtavasti, kaikki mitä tuossa kirjoitin pitää paikkansa ja näitä asioita on mm. sinua viisaammat tutkineet vuosikymmeniä.


      • Valehtelijalle
        M-Kar kirjoitti:

        Ei liity koodin avoimuuteen mitenkään. Se on vain lisensointiasia.

        Noin yleisesti ottaen ohjelmistot ovat lisenssistä riippumatta enemmän tai vähemmän täynnä virheitä.

        Sinähän olet äärimmäisen typeryyden huipentuma, emä valehtelija, keskustelujen sotkija, sinun tietosi on vain sitä että OSTA KAUPASTA, siinä on kaikki mitä tietotekniikasta tiedät.


      • Valehtelijalle kirjoitti:

        Sinähän olet äärimmäisen typeryyden huipentuma, emä valehtelija, keskustelujen sotkija, sinun tietosi on vain sitä että OSTA KAUPASTA, siinä on kaikki mitä tietotekniikasta tiedät.

        Kaupasta ostamista harrastetaan sitten kun halutaan hankkia jotain mikä maksaa. Sitä vaan persaukisia asia ehkä kovin harmittaa jos ei ole vara ostella kaupasta.

        Itse suosin aika paljon asioiden tekemistä itse tai maksutonta.


    • ongelmatonta

      Tuohan on sopimuskysymys - millä ehdoilla korjaukset tehdään, jos tehdään.
      Ja riippuu tietenkin myös siitä, kuinka kipeästi tarvit korjaukset.

      Mutta avoimessa koodissahan kaikki bugit korjataan nopeasti ja ilmaiseksi, eikö se niin ollut?

      • Korjaukset tehdään ylläpidettyihin ohjelmiin tietysti nopeasti, ja kun koodi on avointa niin sen korjauksen saa maksutta kun joku sen tekee.

        Korjauksen tekeminen tai teettäminen tietysti maksaa, kuten yleensäkin työvoima.


    • Helpoin tapa on ostaa ohjelmaan tuki. Kun maksat tuesta, voit avata tukitiketin virheestä ja korjaus tulee sitten päivityksistä.

      Toiseksi helpoin tapa olisi ostaa tämä palveluna. Varmasti löytyy yrityksiä jotka tekee tätä palveluna.

      Kolmas tapa olisi käyttää aikaa siihen, että rakentaisi testaus/kehitysympäristön koodille josta vikaa pitää etsiä ja käyttäisi automatisoituja menetelmiä virheiden löytämiseksi. Se on käytännössä viikon työ.

      Käytännössä tätä varten ei siis kannata palkata ketään töihin, ellei tarkoitus ole korjata niitä virheitä enemmänkin.

      • Sotkijalle

        Ei pidä paikkaansa, mistä sinä olet saanut päähäsi että pystyt koodaajalle antamaan mitään ohjausta. Et itse osaa yhtään mitään kuin setkea näitä keskusteluja.

        Linux Mint 18 Sarah
        Xfce 64-bit


      • Sotkijalle kirjoitti:

        Ei pidä paikkaansa, mistä sinä olet saanut päähäsi että pystyt koodaajalle antamaan mitään ohjausta. Et itse osaa yhtään mitään kuin setkea näitä keskusteluja.

        Linux Mint 18 Sarah
        Xfce 64-bit

        "Ei pidä paikkaansa"

        Todista.

        "mistä sinä olet saanut päähäsi että pystyt koodaajalle antamaan mitään ohjausta."

        Vaikka siksi kun on pitkä kokemus ohjelmoinnista ja olen työnpuolesta antanut sitä ohjausta minua junnummille.

        Sinun olisi parasta olla vaan hiljaa jos et asioista tiedä. Olennaisesti ohjelmointiin pätee perus projektisuunnittelun lainalaisuudet, että valittavissa on laatua, ominaisuuksia ja halpaa hintaa ja näistä voi valita kahta.


      • zfxggfukl

        Olisi hauskaa nähdä karvahatun kirjoittamaa spagettikoodia :)


    • Lähde koodi

      Avoimessa lähdekoodissa on bugeja niin paljon ettei kukaan pysty niitä korjaamaan.

      • Koodin avoimuus ei liity mitenkään bugeihin.


      • Sotkijalle
        M-Kar kirjoitti:

        Koodin avoimuus ei liity mitenkään bugeihin.

        Niin, bugit liittyy vain sinuun, ja sinun höpötyksiin.

        Linux Mint 18 Sarah
        Xfce 64-bit


      • Sotkijalle kirjoitti:

        Niin, bugit liittyy vain sinuun, ja sinun höpötyksiin.

        Linux Mint 18 Sarah
        Xfce 64-bit

        Mikä bugi? Todista.

        Jos et kykene todistamaan väitettäsi, olet puhunut paskaa.


    • Winhihhulix

      Olipa kysymys..
      Voipi olla että tulis niitä bugeja vain lisää!!!

      Moni yritys kuten Google, Firefox yms.. Käyttää Bugin etsintään erilaisia botteja.
      Takaisinkoodaajilla saadaan selville osa, tietoturva bugeihin on kanssa testiohjelmat jotka ronkkii tunnettuja tapoja.

      Pahempi ongelma on jotkut muut bugit kuin ohjalman lähdekoodin bugit.
      Kääntäjien bugit, järjetelmän bugit tai sitten tahallaa näihin tehtyjä juttuja..

      Ihan bugitonta ohjelaa tuskinlöydät, tai ainakin joku olis tehnyt jonkun eritavalla..

    • palkaton.....

      Avoimen lähdekoodin omistaa sen alkuperäinen tekijä.

      Jos parannat sitä bugeja poistamalla, hyötyy siitä ohjelman alkuperäinen tuottaja.

      Avoimen lähdekoodin perusperiaate on tehdä ohjelmasta aina vain parempi.

      Kaikki oikeudet siietyvät ohjelman alkuperäiselle tekijälle, jos hän haluaa ohjelmansa maksulliseksi. Teette siis ilmaista työtä.

      • "Avoimen lähdekoodin omistaa sen alkuperäinen tekijä."

        Tämä nyt taas riippuu lisensoinnista. Yleisesti ottaen jos jonkun koodin on avoimena julkaissut niin sitä voi käyttää kuka tahansa ja kehittää eteenpäin. Se lisenssin muutos ei mene niin, että se aiemmin julkaistujen lisenssi jotenkin muuttuisi.


      • Tutustu_faktoihin

        "Kaikki oikeudet siietyvät ohjelman alkuperäiselle tekijälle, jos hän haluaa ohjelmansa maksulliseksi. Teette siis ilmaista työtä."

        Useilla yleisesti käytetyillä avoimen koodin lisensseillä tuo jälkikäteen kaupalliseksi muuttaminen ei onnistu vaan kerran avoimena koodina julkaistu pysyy avoimena samoin kuin siitä edelleen kehitetyt versiot.

        Parin yleisen avoimen koodin lisenssin toiminta hyvin lyhyesti esitettynä:

        GPL -> Alkuperäinen ja siitä edelleen kehitetyt versiot pysyvät aina avoimena koodina eli GPL-lisensoitua koodia ei voi käyttää kaupallisen ohjelman pohjana.

        BSD -> Alkuperäinen koodi pysyy aina avoimena. Siitä voidaan kehittää edelleen suljetun koodin kaupallinen versio, suljetun version oikeudet ovat sen kehittäjällä eivätkä alkuperäisen koodin kehittäjillä eli BSD-koodia voidaan hyödyntää kaupallisen ohjelman pohjana.

        Kannattaisi tutustua asiaan ennen kommentointia.


      • Tutustu_faktoihin kirjoitti:

        "Kaikki oikeudet siietyvät ohjelman alkuperäiselle tekijälle, jos hän haluaa ohjelmansa maksulliseksi. Teette siis ilmaista työtä."

        Useilla yleisesti käytetyillä avoimen koodin lisensseillä tuo jälkikäteen kaupalliseksi muuttaminen ei onnistu vaan kerran avoimena koodina julkaistu pysyy avoimena samoin kuin siitä edelleen kehitetyt versiot.

        Parin yleisen avoimen koodin lisenssin toiminta hyvin lyhyesti esitettynä:

        GPL -> Alkuperäinen ja siitä edelleen kehitetyt versiot pysyvät aina avoimena koodina eli GPL-lisensoitua koodia ei voi käyttää kaupallisen ohjelman pohjana.

        BSD -> Alkuperäinen koodi pysyy aina avoimena. Siitä voidaan kehittää edelleen suljetun koodin kaupallinen versio, suljetun version oikeudet ovat sen kehittäjällä eivätkä alkuperäisen koodin kehittäjillä eli BSD-koodia voidaan hyödyntää kaupallisen ohjelman pohjana.

        Kannattaisi tutustua asiaan ennen kommentointia.

        Itseasiassa ei...

        Ohjelmaversio joka on julkaistu GPL lisenssillä pysyy GPL:nä, mutta tekijällä on edelleen oikeudet omaan työhönsä niin, että voi tehdä _omasta työstään_ uuden version mikä on suljettu. Se mikä on jo GPL:nä julkaistu toki pysyy GPL:nä. Jos projektiin on joku muu tehnyt GPL koodia niin ne tiedostot pitää siivota sieltä pois. GPL lisensoitua ohjelmaa voidaan myös käyttää kaupallisen ohjelmana pohjana ja niin tehdään myös paljon. Esimerkiksi vaikka tämä Suomi24.

        Asian voisi yksinkertaistaa näin:
        -GPL julkaistu koodi -> yhteisölliseen käyttöön. GPL koodi suojaa sen, että ohjelman lähdekoodi pysyy avoimena tämän koodin käyttäjille.
        -BSD koodi -> vapaaseen käyttöön. Se on olennaisesti public domainia ja sillä voi tehdä mitä haluaa


      • Sotkijalle
        M-Kar kirjoitti:

        "Avoimen lähdekoodin omistaa sen alkuperäinen tekijä."

        Tämä nyt taas riippuu lisensoinnista. Yleisesti ottaen jos jonkun koodin on avoimena julkaissut niin sitä voi käyttää kuka tahansa ja kehittää eteenpäin. Se lisenssin muutos ei mene niin, että se aiemmin julkaistujen lisenssi jotenkin muuttuisi.

        Ei edes tuo mennyt oikein, ottasit asioista selvää ennen kuin rupeat kirjottelemaan soopaa.


        Linux Mint 18 Sarah
        Xfce 64-bit


      • Sotkijalle kirjoitti:

        Ei edes tuo mennyt oikein, ottasit asioista selvää ennen kuin rupeat kirjottelemaan soopaa.


        Linux Mint 18 Sarah
        Xfce 64-bit

        Kyllä meni oikein: https://opensource.org/osd

        Tietokoneohjelmia on julkaistu vuosikymmeniä avoimesti ja niistä on forkattu uusia ohjelmia.


    • 12321

      GPL 3 ainakin on jotain sellaista mitä pitää vältää jos kyse on firmasta tai aikoo joskus softallaan tehdä rahaa. Myöskään ei pidä sisällyttää omaan softaan mitään noilla hyvin avoimilla lisensseillä katetuista kirjastoista tms. Joutuu nimittäin avaamaan omankin softan kaikille.

      Avoimuus on kiva juttu mutta sen riskit ja vaarat pitää ymmärtää.

      Avoimuus on myös kallista. Ihan jo vaikkapa Linux on yrityskuvioissa kallis koska sille pitää ostaa tuki tai palkata omaa henkilöstöä tukea varten.
      Monasti on halvempaa ostaa softaa tai tukea kuin alkaa itse tuhraamaan. Jo pelkkä Linux paketin kattava testaaminen on jopa sadan henkilötyövuoden juttu.
      Jos paketin saa vaikkapa 200e hintaan per asennus/vuosi, tukineen. Sehän on jopa edullista. Jos pitää omaa väkeä käyttää ongelmien selvittelyyn, tuolla rahalla ei tehdä kuin tunti töitä ja se on pois tuottavasta työstä mikä voi maksaa paljon enemmän.

      Ilmaista lounasta ei ole. Ero tehdään sillä mistä milloinkin kannattaa maksaa ja minkä suhteen kannattaa ottaa riskiejä.

      • "GPL 3 ainakin on jotain sellaista mitä pitää vältää jos kyse on firmasta tai aikoo joskus softallaan tehdä rahaa. "

        Miksi muka?

        "Myöskään ei pidä sisällyttää omaan softaan mitään noilla hyvin avoimilla lisensseillä katetuista kirjastoista tms. Joutuu nimittäin avaamaan omankin softan kaikille."

        Sehän on lisenssistä riippuva asia, useinkaan koodin avoimuus ei haittaa liiketoimintaa ja esimerkiksi GPL lisenssissä ei ole useinkaan mitään merkitystä vaikka asiakkaalle toimitetun koodin pitää olla avoin koska ohjelmia tavallisesti myydään palveluna pilvestä ja asiakkaalle ei tarvitse toimittaa yhtään mitään.

        "Avoimuus on myös kallista. Ihan jo vaikkapa Linux on yrityskuvioissa kallis koska sille pitää ostaa tuki tai palkata omaa henkilöstöä tukea varten."

        Ei tietenkään tarvitse. Suurin osa yritysten laitteista käyttää Linuxia ja henkilöstön määrä näkyy vähenevän.

        "Monasti on halvempaa ostaa softaa tai tukea kuin alkaa itse tuhraamaan."

        Ostaa tai hankkii ilmaiseksi, ei merkitystä.

        "Jo pelkkä Linux paketin kattava testaaminen on jopa sadan henkilötyövuoden juttu."

        Minkä ihmeen "Linux paketin" ?

        "Jos paketin saa vaikkapa 200e hintaan per asennus/vuosi, tukineen. Sehän on jopa edullista."

        Yleensä saa ilmaiseksi ja niin hyvätasoista, että tukea ei tarvitse kuin kriittisemmät kohteet kuten vaikka jonkun rahoituslaitoksen tai operaattorin serveri. Tosin tiedän kyllä suomessa operaattoria joka ei ole viitsinyt mitään tukea hankkia vaan käyttää melko moneen ihmiseen vaikuttavassa palvelimessa maksutta.

        "Jos pitää omaa väkeä käyttää ongelmien selvittelyyn, tuolla rahalla ei tehdä kuin tunti töitä ja se on pois tuottavasta työstä mikä voi maksaa paljon enemmän."

        Minkä ongelmien selvittelyyn?

        "Ilmaista lounasta ei ole."

        Ohjelmat ovat useinkin ilmaisia nykyään.


      • Sotkijalle

        "Avoimuus on myös kallista. Ihan jo vaikkapa Linux on yrityskuvioissa kallis koska sille pitää ostaa tuki tai palkata omaa henkilöstöä tukea varten."

        Ei tietenkään tarvitse. Suurin osa yritysten laitteista käyttää Linuxia ja henkilöstön määrä näkyy vähenevän.

        Tietysti tarvitsee, vai sinäkö osaat ja tiedät jotain Linuxia ylläpitävien palkkaamisesta. Sinä joka et edes ymmärrä mikä Linux on.

        Linux Mint 18 Sarah
        Xfce 64-bit


    • seli-selii

      "Avoimuus on myös kallista. Ihan jo vaikkapa Linux on yrityskuvioissa kallis koska sille pitää ostaa tuki tai palkata omaa henkilöstöä tukea varten."

      Kuin sille ny pitäs "palkata omaa henkilöstöä tukea varten" jos henkilösttö ei osaa niin voihan ne irtisanoo ja palkata osaavii tilalle?

      "Jo pelkkä Linux paketin kattava testaaminen on jopa sadan henkilötyövuoden juttu."

      Mitä niitä testaan? testaushan voidaan suorittaa käytön aikana? (lisenssi ehdothan sit takaa et testaus ilmasta vaikka joku kuolis käytön aikana?)

      • 2323423

        Jos olen maksava asiakas jolle sinä olet toimittamassa järjeetelmän mikä perustuu Linuxiin, niin tottahan toki odotan että järjestelmä on testattu kattavasti.
        Myös security pitää olla testattuna vähintään yleisimmillä reikiä etsivillä testijärjestelmillä. Kuormitus ja stabiliteetti pitää myös testata ennen käyttöönottoa.

        Ainakin RedHat testaa hyvinkin kattavasti jokaisen julkaisun ja julkaisujen päivitykset. Mutta niinpä se onkin yleisin ammattikäytön distro.

        Sinun periaatteellasi autokin voidaan testata vasta kentällä. No ei voida koska arvokkaat softat on työkaluja ja niissä olevat bugit on tekee työkalusta käyttökevottoman. Mitä itse tuumaisit jos tekisit vaikkapa taloa ja vasarasta lähtisi pää irti. Onko se hyväksyttävää?


      • 2323423 kirjoitti:

        Jos olen maksava asiakas jolle sinä olet toimittamassa järjeetelmän mikä perustuu Linuxiin, niin tottahan toki odotan että järjestelmä on testattu kattavasti.
        Myös security pitää olla testattuna vähintään yleisimmillä reikiä etsivillä testijärjestelmillä. Kuormitus ja stabiliteetti pitää myös testata ennen käyttöönottoa.

        Ainakin RedHat testaa hyvinkin kattavasti jokaisen julkaisun ja julkaisujen päivitykset. Mutta niinpä se onkin yleisin ammattikäytön distro.

        Sinun periaatteellasi autokin voidaan testata vasta kentällä. No ei voida koska arvokkaat softat on työkaluja ja niissä olevat bugit on tekee työkalusta käyttökevottoman. Mitä itse tuumaisit jos tekisit vaikkapa taloa ja vasarasta lähtisi pää irti. Onko se hyväksyttävää?

        "Jos olen maksava asiakas jolle sinä olet toimittamassa järjeetelmän mikä perustuu Linuxiin, niin tottahan toki odotan että järjestelmä on testattu kattavasti."

        Aika usein ei toimiteta kaikkea mahdollista mikä olisi kiva saada vaan toimitetaan henkilöresurssia järjestelmän tekemiseksi. Sitä sitten maksetaan joka kuukausi niistä henkilöresursseista ketkä lisää toiminnallisuutta tilaajan toiveiden mukaan.

        Tällä tavalla saadaan järjestelmiä käyttöön nopeasti, jopa vain viikossa ja rahaa säästyy.

        "Ainakin RedHat testaa hyvinkin kattavasti jokaisen julkaisun ja julkaisujen päivitykset. Mutta niinpä se onkin yleisin ammattikäytön distro."

        Android, Mac OS, Ubuntu ja Windows ovat yleisempiä.

        "Sinun periaatteellasi autokin voidaan testata vasta kentällä. No ei voida koska arvokkaat softat on työkaluja ja niissä olevat bugit on tekee työkalusta käyttökevottoman. "

        Mitkä ihmeen bugit? Kyllä jokainen toiminto mitä tilaaja pyytää tehdään niin, että ensiksi tehdään hyväksymistestit, sitten tarvittavat yksikkötestit ja toteutetaan toiminto. Toiminto on valmis kun testit menee läpi ja se voidaan viedä tuotantoon.

        Sitten kun toimintoja on tehty sata niin voihan sieltä jostain löytyä bugi ja se korjataan.


      • Sotkijalle

        ("Mitkä ihmeen bugit?"), no sinä tietysti olet se pahin bugi.

        ("Sitten kun toimintoja on tehty sata niin voihan sieltä jostain löytyä bugi ja se korjataan.") Kyllä näkyy hyvin miten Microsoft korjaa, tekee tilalle kaksi bugia. Turha sinun mitään valehdella, se vaan on näin.

        Linux Mint 18 Sarah
        Xfce 64-bit


      • 323423
        M-Kar kirjoitti:

        "Jos olen maksava asiakas jolle sinä olet toimittamassa järjeetelmän mikä perustuu Linuxiin, niin tottahan toki odotan että järjestelmä on testattu kattavasti."

        Aika usein ei toimiteta kaikkea mahdollista mikä olisi kiva saada vaan toimitetaan henkilöresurssia järjestelmän tekemiseksi. Sitä sitten maksetaan joka kuukausi niistä henkilöresursseista ketkä lisää toiminnallisuutta tilaajan toiveiden mukaan.

        Tällä tavalla saadaan järjestelmiä käyttöön nopeasti, jopa vain viikossa ja rahaa säästyy.

        "Ainakin RedHat testaa hyvinkin kattavasti jokaisen julkaisun ja julkaisujen päivitykset. Mutta niinpä se onkin yleisin ammattikäytön distro."

        Android, Mac OS, Ubuntu ja Windows ovat yleisempiä.

        "Sinun periaatteellasi autokin voidaan testata vasta kentällä. No ei voida koska arvokkaat softat on työkaluja ja niissä olevat bugit on tekee työkalusta käyttökevottoman. "

        Mitkä ihmeen bugit? Kyllä jokainen toiminto mitä tilaaja pyytää tehdään niin, että ensiksi tehdään hyväksymistestit, sitten tarvittavat yksikkötestit ja toteutetaan toiminto. Toiminto on valmis kun testit menee läpi ja se voidaan viedä tuotantoon.

        Sitten kun toimintoja on tehty sata niin voihan sieltä jostain löytyä bugi ja se korjataan.

        Kaikkea ei voi monimutkaisissa järjestelmissä ennakoida eikä testeillä voi kuitenkaan kattaa kaikkea mutta ainakin ne pitää pyrkiä kattamaan.
        Jos tilaan vaikka web-kauppa sovelluksen niin vaatimuksissa varmasti lukee ylikuormanhallinta ja luotettava toiminta ylikuorman aikana.
        Sinä sitten testaat sen, eikö niin ja osoitat että se on stabiili.

        Osa bugeista tulee esiin vasta kun käytäjiä on enemmän ja samaan aikaan tehdään useita asioita kuten vaikkapa varmuuskopiota. Ajonaikainen varmuuskopio kannasta on jo sellaisenaan aika haasteellinen ja useimmille suunnittelijoille täysin mahdoton asia ilman että palvelu pysähtyy.

        HA on sitten yksi asia mikä pitää monimutkaisiin systeemeihin aina vaatia koska koodarit ja suunittelijat tekee kuitenkin virheitä. Ylläpitäjät sitten kuorruttaa omilla virheillään koko sopan. Ylipäänsä kaikki tekee virheitä jatkuvasti, myös testaajat :-)


      • 323423 kirjoitti:

        Kaikkea ei voi monimutkaisissa järjestelmissä ennakoida eikä testeillä voi kuitenkaan kattaa kaikkea mutta ainakin ne pitää pyrkiä kattamaan.
        Jos tilaan vaikka web-kauppa sovelluksen niin vaatimuksissa varmasti lukee ylikuormanhallinta ja luotettava toiminta ylikuorman aikana.
        Sinä sitten testaat sen, eikö niin ja osoitat että se on stabiili.

        Osa bugeista tulee esiin vasta kun käytäjiä on enemmän ja samaan aikaan tehdään useita asioita kuten vaikkapa varmuuskopiota. Ajonaikainen varmuuskopio kannasta on jo sellaisenaan aika haasteellinen ja useimmille suunnittelijoille täysin mahdoton asia ilman että palvelu pysähtyy.

        HA on sitten yksi asia mikä pitää monimutkaisiin systeemeihin aina vaatia koska koodarit ja suunittelijat tekee kuitenkin virheitä. Ylläpitäjät sitten kuorruttaa omilla virheillään koko sopan. Ylipäänsä kaikki tekee virheitä jatkuvasti, myös testaajat :-)

        Kahdennetusta kannasta on helppo ottaa backuppia ajon aikana. Sitä kun käytetään aktiivisesti toista niin toisesta voidaan ottaa backuppia.


      • sdfasdfdsadsa
        M-Kar kirjoitti:

        Kahdennetusta kannasta on helppo ottaa backuppia ajon aikana. Sitä kun käytetään aktiivisesti toista niin toisesta voidaan ottaa backuppia.

        Lisäksi useimmiten riittää transaktiologiin perustuva varmistus, toki hieman RTO/RPO-määrityksistä riippuen.


    • Ohjelman oikeaksi todistaminen on vaikeaa. Siksi tyydytään yleensä testaamiseen. Joku yksinkertainen ohjelma voidaan todistaa oikeaksi tietyillä lähtöarvoilla. Jos koodia on miljoonia rivejä testaaminen on mahdotonta. Tiedetään, että ohjelma toimii tietyllä testiaineistolla. Tilastoihinkin vaikutetaan paljon siihen miten otos tehdään. Tutkimukseen saadaan rahoitusta ja toivotaan tietynlaisia tuloksia. C on minusta vaikeasti ymmärrettävää verrattuna Delphiin tai Pascaliin jolla tein ensimmäiset ohjelmani. C:llä saa toki lyhyttä ja tehokasta koodia, mutta ymmärtämisen kustannuksella. Toki on niitä jotka kirjoittavat luettavaa koodia, niin että toinenkin ymmärtää. Sitten on niitä joiden koodista ei saa tolkkua. Sitten kun siitä korjataan virheitä ja niistä tulleita virheitä ei koodia lopulta osaa kukaan ylläpitää. Debuggerilla löytyy yksinkertaiset virheet ja niiden korjaaminen joskus helppoa esim. ehtolause hieman väärin. C:n muistinhallinta ja erilaiset osoittimet hankalia seurattavia. Vahvasti tyypitetyssä kielessä virheitä tulee vähemmän.

      • hjghjghfghgh

        Vaikeaa ja vaikeaa. Jälkikäteen se kyllä on sitä, mutta jos suunnitteluvaiheessa jo hommat ovat tehty formaalia spesifikaatiokieltä käyttäen niin ohjelmasta saadaan kyllä tehtyä todistettavissa oleva matemaattinen malli.


      • hjghjghfghgh kirjoitti:

        Vaikeaa ja vaikeaa. Jälkikäteen se kyllä on sitä, mutta jos suunnitteluvaiheessa jo hommat ovat tehty formaalia spesifikaatiokieltä käyttäen niin ohjelmasta saadaan kyllä tehtyä todistettavissa oleva matemaattinen malli.

        Tuo on totta. Mutta usein otetaan koodia ja erilaisia kirjastoja sieltä täältä. Osa siitä on testattu ja osa ei. Usein vielä kiire. Osaa koodista on vielä kirjoitettu eri kääntäjälle. Noissakin on hieman eroja. Jos aloitus tehty tosiaan fiksusti todistaminen on mahdollista ja monilta virheiltä vältyttäisiin. Silti pitää tietysti testata.


    Ketjusta on poistettu 0 sääntöjenvastaista viestiä.

    Luetuimmat keskustelut

    1. 57-vuotiads muka liian vanha töihin?

      On tämä sairas maailma. Mihin yli 55-vuotiaat sitten muka enää kelpaavat? Hidasta itsemurhaa tekemään, kun eläkkeelle ei
      Maailman menoa
      391
      4996
    2. Haluatteko miellyttää kumppaninne silmää?

      Entä muita aisteja? Mitä olette valmiita tekemään sen eteen että kumppani näkisi teissä kunnioitettavan yksilön? Olette
      Sinkut
      285
      2771
    3. By the way, olet

      mielessäni. Olet minulle tärkeä, niin suunnattoman tärkeä. En kestäisi sitä jos sinulle tapahtuisi jotain. Surullani ei
      Ikävä
      155
      1985
    4. Onko kaivattunne suosittu?

      Onko teillä paljon kilpailijoita? Mies valitettavasti näyttää olevan paljonkin naisten suosiossa :(
      Ikävä
      104
      1678
    5. J-miehelle toivon

      Hyvää yötä. Voisiko nykyistä tilannetta uhmaten vielä pienintäkään toivetta olla, päästä kainaloosi joskus lepääämään.
      Ikävä
      85
      1543
    6. Onkohan sulla enää tunteita

      kun nähdään seuraavan kerran? Niin hyvä fiilis on ollut viime aikoina, että se on nyt pahin pelkoni. Oletkohan unohtanut
      Ikävä
      51
      1410
    7. Haluatko S

      vielä yrittää?
      Ikävä
      63
      1407
    8. Täytyi haukkuu sut lyttyyn

      En haluu tuntee rakkautta sua kohtaan enää ja haluun unohtaa sut mut sit tulee kuiteki paha olo kun haluis vaan oikeesti
      Ikävä
      61
      1377
    9. Kylpyläsaaren Lomakylän kahvilaravintola

      Kävimme syömässä Kylpyläsaaressa. "Naudanliha burgeri" maksoi 18,90 euroa ja lisäksi limsa 4,50 euroa. Annoksen hinnaks
      Haapavesi
      64
      1334
    10. Rakkauden riemuvoitto

      Valta voidaan voittaa tiedolla. Mutta tieto on huonompi kuin kauneus, hellyys ja rakkaus. Siksi kauneus on vallan ja tie
      Hindulaisuus
      349
      1121
    Aihe