Kuinka suuri on bugin hinta?

"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?

Lue lisää

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ä.

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ä.

Lue lisää

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.

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ä.

Lue lisää

"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.

Lue lisää

"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-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ä.

Lue lisää

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.

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ä.

Lue lisää

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.

Lue lisää

"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ä?

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ä?

Lue lisää

Ä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ä.

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ä.

Lue lisää

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.

Lue lisää

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.

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.

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

Lue lisää

"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.

Olisi hauskaa nähdä karvahatun kirjoittamaa spagettikoodia :)

Koodin avoimuus ei liity mitenkään bugeihin.

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.

"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.

"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.

Lue lisää

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

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.

Lue lisää

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.

"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.

"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

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ää?

Lue lisää

"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.

("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

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.

Lue lisää

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 :-)

Lue lisää

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

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.

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.

Lue lisää

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.