Miksi PC eikä Mäkki?

[jt.syrja]

Onkohan koko Malare käyttänyt edes koskaan mäkkiä? Oli toi lista Microsoftin propaganda tuubaa varmaan vuodelta 95. Oli sen verran hauskaa luettavaa, että sai naureskella täällä ihan kivasti.

Säästät itseäsi paljon, kun jätät pastettamatta tulevaisuudessa tälläiset listat jotka eivät pidä enää yhtään paikkaansa.

Et taaskaan lukenut juttuani loppuun, onko lukihäiriö, vai vikaa luetun ymmärtämisessä.
Äläkä ole noin tosikko, ei nämä niin vakavia asioita ole, ainakaan mulle.
Kaikki tuossa historiassa kertomani on totta ja on toteennäytettävissä.

Ystävällisin terveisin
Reijo

Tässä varmaan tarkoitettiin tuota sinun postaamaa pitkää listaa miksi win pc olisi parempi kuin osx pc, joka ei siis pidä tänä päivänä paikkaansa vaan lähinnä asia on juuri toisin päin..

[-wk-]

Pointti on se et Vaihdettiin powerpc -->intel ..sen takia muutos oli suuri.

Toisaalta Apple rikkoo kyllä sitä yhteensopivuutta ihan Intel -aikanakin, Core Duo ja Lion eivät toimi yhdessä ja uus tuleva käyttis tiputtaa huhujen mukaan alkupään Core 2 Duo koneita pois. On tietysti hyvin helppo nähdä miksi näin: Apple haluaa myydä uudet rojut tasaseen tahtiin ja Microsoft haluaa että mahdollisimman monella on mahdollisuus ostaa uusi käyttöjärjestelmä.

[dsg4567uhgd]

Pointti on se et Vaihdettiin powerpc -->intel ..sen takia muutos oli suuri.

Toisaalta Apple rikkoo kyllä sitä yhteensopivuutta ihan Intel -aikanakin, Core Duo ja Lion eivät toimi yhdessä ja uus tuleva käyttis tiputtaa huhujen mukaan alkupään Core 2 Duo koneita pois. On tietysti hyvin helppo nähdä miksi näin: Apple haluaa myydä uudet rojut tasaseen tahtiin ja Microsoft haluaa että mahdollisimman monella on mahdollisuus ostaa uusi käyttöjärjestelmä.

Nooh, ei sitä ihan kaikki laitteet pelitä Seiskallakaan Core Duo-ajoilta, voi puuttua ajuria jne... Mutta toisaalta suurempi prosentti toimii ja osa pienellä virittelyllä, kun taas Apple tappaa kaikki laitteet.

[exlex]

Et taaskaan lukenut juttuani loppuun, onko lukihäiriö, vai vikaa luetun ymmärtämisessä.
Äläkä ole noin tosikko, ei nämä niin vakavia asioita ole, ainakaan mulle.
Kaikki tuossa historiassa kertomani on totta ja on toteennäytettävissä.

Ystävällisin terveisin
Reijo

Tässä varmaan tarkoitettiin tuota sinun postaamaa pitkää listaa miksi win pc olisi parempi kuin osx pc, joka ei siis pidä tänä päivänä paikkaansa vaan lähinnä asia on juuri toisin päin..

[adele]

..Apple rikkoo kyllä sitä yhteensopivuutta ihan Intel -aikanakin, Core Duo ja Lion eivät toimi yhdessä ja uus tuleva käyttis tiputtaa huhujen mukaan alkupään Core 2 Duo koneita pois. On tietysti hyvin helppo nähdä miksi näin: Apple haluaa myydä uudet rojut tasaseen tahtiin ...

Lion oli "vain" Intel ja täysin 64-bittinen, joka sulki pois 32-bittiset Core Duot.

Mountain Lion rajan tulee asettamaan grafiikka. Todennäköisesti ML tulee tukemaan OpenGL 4.1:stä. Selitys osalle rajan taakse jääneistä näytönohjaimista, joille voisi tehdä sopivan ajurin, on yksinkertainen. Sitä ei tehdä, koska näytönohjaimen valmistaja ei enää tue näytönohjainta.

Ilmeisesti näytönohjaimienkin valmistaja haluaa myydä uusia?

Itse pidän Applen vähintään neljän vuoden ohjelmistotukea riittävänä (yleensä kauemmin). Tietysti voisi yrittää pitää kaikki paska rattailla, mutta siitä kärsii kaikki. Vanha kone ei jaksa pyöritää uusinta uutta ja käyttis turpoaa, kun sen pitää tukea kaikkea mahdollista.

[nobu178]

..Apple rikkoo kyllä sitä yhteensopivuutta ihan Intel -aikanakin, Core Duo ja Lion eivät toimi yhdessä ja uus tuleva käyttis tiputtaa huhujen mukaan alkupään Core 2 Duo koneita pois. On tietysti hyvin helppo nähdä miksi näin: Apple haluaa myydä uudet rojut tasaseen tahtiin ...

Lion oli "vain" Intel ja täysin 64-bittinen, joka sulki pois 32-bittiset Core Duot.

Itse asiassa Lion ei ole täysin 64-bittinen. Juuri noi alkupään Core 2 Duo -koneet toimivat 32-bittisellä Lionilla (= ytimellä) . Jos ne pois karsitaan Mountain Lionin tuen piiristä, käyttiksessä ei taida olla enää 32-bittistä ydintä.

[-wk-]

Itse asiassa Lion ei ole täysin 64-bittinen. Juuri noi alkupään Core 2 Duo -koneet toimivat 32-bittisellä Lionilla (= ytimellä) . Jos ne pois karsitaan Mountain Lionin tuen piiristä, käyttiksessä ei taida olla enää 32-bittistä ydintä.

Jep ja kun selaa Everymac.comia niin kaikkien Macbookien kohdalla (jotka Lionia voivat pyörittää) lukee näin:

This system can run the latest version of OS X 10.7 "Lion." It is not supported booting into 64-bit mode, although this is believed to be due to an Apple imposed EFI block rather than a technical limitation

EDIT: Jaa voiko tuo muka pitää paikkansa kun oman koneen kohdala mainitaan tuo, mutta kun kirjoittaa päätteessä "uname -a" niin lukee:

root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64

Everymac.comin mukaan kaikki 2007 ja vanhempia MBP-koneita koskis tuo rajoitus mutta kyllä tämä päätteen perusteella pyörii 64-bit tilassa.

EDIT: Ilmeisesti tuota boottitilan rajoitusta voi myös koettaa kiertää:

http://www.ahatfullofsky.comuv.com/Engl ... S/SMS.html

EDIT2: Jaa kaippa tämä sitten on 32-bit modessa bootattu:

http://aijaa.com/001949626949

EDIT3: Ja joku oli hakkeroinut tuon Mountain Lioninkin semmoseen Maciin jossa sitä ei tueta:

http://forums.macrumors.com/showthread.php?t=1325818

[theinonen]

Itse pidän Applen vähintään neljän vuoden ohjelmistotukea riittävänä (yleensä kauemmin). Tietysti voisi yrittää pitää kaikki paska rattailla, mutta siitä kärsii kaikki. Vanha kone ei jaksa pyöritää uusinta uutta ja käyttis turpoaa, kun sen pitää tukea kaikkea mahdollista.

Kyllä vanhemmillakin koneilla tekee vielä vaikka mitä, koska useimmat hommat eivät kuitenkaan vaadi koneelta mitään ihmeitä. Useat uudet versiot ohjelmista ovatkin lähinnä rahastusversioita ja niiden uusien ominaisuuksien hyödyllisyys on lähinnä kyseenalaista. Itse en ainakaan tarvitse yhtä ohjelmaa joka hoitaa kaiken, kun voin käyttää siihen 4-5:ttä eri ohjelmaa ja hoitaa homman paljon joustavammin omalla tavallani enkä millään ennalta määrätyllä kaavalla. Tärkeämpää onkin mielestäni eri ohjelmien yhteensopivuus ja se, että voin siirtää homman toiseen ohjelmaan ja jatkaa siitä mihin toisessa jäin.

Oikeastaan ainoastaan tuo isojen RAW-kuvien käpistely ja videohommat hyötyvät kasvavasta konetehosta. Kaikki eivät kuitenkaan editoi videoita ja kuvatkin voi ottaa suoraan jpg:nä, koska useimmat ihmiset eivät kuitenkaan huomaa mitään eroa. Jos jpg-kuvan säätömahdollisuudet eivät riitä, niin ehkä kuva ei alunperinkään ollut kovin hyvä?

Käyttöjärjestelmät ovat jo niin turvonneita, että mielestäni pitäisi mielummin alkaa karsimaan turhia ominaisuuksia ja poistaa kaikki ylimääräinen mikä voidaan hoitaa yksinkertaisella lisäohjelmalla myöhemmin. Jo olemassa olevien laitteiden tukeminen tuskin kasvattaa sitä käyttöjärjestelmän kokoa niin merkittävästi, kuin esimerkiksi turha silmäkarkki.

[-wk-]

Itse ihmettelen kyllä jos pelkästään käyttöliittymä vaatii jo noin kehittyneen näytönohjaimen oikeasti eikä sitä millään voida toteuttaa vanhemmalla raudalla. Windowsin Aerohan tulee toimeen DirectX 9 -tason näytönohjaimella eli Radeon 9500 ja GeForce FX sekä tietysti uudemmat kelpaa. Linux-puolella Compizilla ja muilla on tehty todella paljon (todella turhaa) silmäkarkkia vanhalla raudalla:

http://www.youtube.com/watch?v=4QokOwvP ... re=related

Erona vielä se että noita Ubuntuja sun muita koodaavat eivät taida tienata tuolla (tietääkseni) kun taas Applella homma on kaupallista, olettaisin myöskin että kun oma rauta tunnetaan ja noihin piirivalmistajiin voidaan olla yhteydessä niin sekin helpottaa.

[adele]

Itse en ....tarvitse yhtä ohjelmaa joka hoitaa kaiken, kun voin käyttää siihen 4-5:ttä eri ohjelmaa ja hoitaa homman paljon joustavammin.....

Meillä on ilmeisesti sanalle joustavuus aivan eri merkitys? Joustavuus sinulle on 4-5 ohjelman käyttöä tilanteessa, jonka voisi hoitaa yhdellä ohjelmalla.
Millä termillä määrittelisit tätä yhden ohjelman käyttöä, joka hoitaa kaiken? Joustamattomuus?

Oikeastaan ainoastaan tuo isojen RAW-kuvien käpistely ja videohommat hyötyvät kasvavasta konetehosta. Kaikki eivät kuitenkaan editoi videoita ja kuvatkin voi ottaa suoraan jpg:nä, koska useimmat ihmiset eivät kuitenkaan huomaa mitään eroa. Jos jpg-kuvan säätömahdollisuudet eivät riitä, niin ehkä kuva ei alunperinkään ollut kovin hyvä?

Ei kiinnosta tippakaan vaikka "useimmat ihmiset eivät kuitenkaan huomaa mitään eroa", kuvan itselleni ja minä huomaan.

Mitä tarkoittaa "ehkä kuva ei alunperinkään ollut kovin hyvä"? Tarkoitetaanko "hyvyydellä" aiheen kiinnostavuutta, kuvan teknista toteutusta, kokonaisuutta, vai kenties jotain ihan muuta?

On järjetöntä ostaa kamera ja käyttää hyödyksi vain 25% siitä informaatiosta, jonka kamera kykenee tuottamaan. Jokainen kuvaaja joka on kuvannut RAW-kuvia ja on niitä käpristellyt, tietää kuinka suuren edun RAW tuottaa. Aivan suora analogia olisi ostaa CD ja sitten pakata se mp3:ksi minimikokoon, heittää CD roskiin ja kuunnella vain pakattua mp3:sta.

Mitä tulee uusien koneiden tuomaan hyötyyn, niin kyllä esimerkiksi Airin SSD tuo käyttäjälle sen verran hyvän käyttäjäkokemuksen, että vaikka konetta ei kuormittaisi tappiin koskaan, niin käyttö on järjettömän paljon mukavampaa kuin pari vuotta vanhemman HD:lla varustetun koneen käyttö.

[Sleepperi]

Oikeastaan ainoastaan tuo isojen RAW-kuvien käpistely ja videohommat hyötyvät kasvavasta konetehosta.

Mikä tahansa homma missä ajetaan jotain virtuaalikoneen sisällä?
Rakennus-, elektroniikka- yms suunnittelu?
Ohjelmointi?
Pelit?

[JuEeHa]

Ohjelmointi?

Ohjelmointi toimii kyllä ihan hyvin vanhallakin koneella.

Itse pidän Applen vähintään neljän vuoden ohjelmistotukea riittävänä (yleensä kauemmin). Tietysti voisi yrittää pitää kaikki paska rattailla, mutta siitä kärsii kaikki. Vanha kone ei jaksa pyöritää uusinta uutta ja käyttis turpoaa, kun sen pitää tukea kaikkea mahdollista.

Entä jos käyttöjärjestelmät suunniteltaisiin kevyiksi(Linux,NetBSD,Haiku)? Linuxilla on suuri osa ajureista valmiina kernelissä ja silti pyörii mukavalla nopeudella vuoden 1994 koneella.

Kyllä vanhemmillakin koneilla tekee vielä vaikka mitä, koska useimmat hommat eivät kuitenkaan vaadi koneelta mitään ihmeitä.

Totta. Vuoden 2004 iBookilla postailen tätäkin.

Itse en ....tarvitse yhtä ohjelmaa joka hoitaa kaiken, kun voin käyttää siihen 4-5:ttä eri ohjelmaa ja hoitaa homman paljon joustavammin.....

Meillä on ilmeisesti sanalle joustavuus aivan eri merkitys? Joustavuus sinulle on 4-5 ohjelman käyttöä tilanteessa, jonka voisi hoitaa yhdellä ohjelmalla.
Millä termillä määrittelisit tätä yhden ohjelman käyttöä, joka hoitaa kaiken? Joustamattomuus?

Theinonen taitaa kannattaa UNIX filosofiaa jonka ideana on että ohjelma tekee mitä sen pitääkin tehdä, ei enempää eikä vähempää. Itse kutsuisin kaiken hoitavaa ohjelmistoa bloatiksi.

Käyttöjärjestelmät ovat jo niin turvonneita, että mielestäni pitäisi mielummin alkaa karsimaan turhia ominaisuuksia ja poistaa kaikki ylimääräinen mikä voidaan hoitaa yksinkertaisella lisäohjelmalla myöhemmin. Jo olemassa olevien laitteiden tukeminen tuskin kasvattaa sitä käyttöjärjestelmän kokoa niin merkittävästi, kuin esimerkiksi turha silmäkarkki.

Olen aivan samaa mieltä kanssasi. <offtpic>Mitä selainta käytät RISC OS:lla</offtopic>

[Quadra700]

Itse pidän Applen vähintään neljän vuoden ohjelmistotukea riittävänä (yleensä kauemmin). Tietysti voisi yrittää pitää kaikki paska rattailla, mutta siitä kärsii kaikki. Vanha kone ei jaksa pyöritää uusinta uutta ja käyttis turpoaa, kun sen pitää tukea kaikkea mahdollista.

Jep. Näin se vain menee. Turhaa on oikeastaan itkeä ettei neljä vuotta tai vanhempaan rautaa saa tukea. Kyllä koneet kannattaa uusia kun kolme vuotta on mittarissa; ellei jopa tiheämmin sillä kyllä se Applenkin rauta lahoaa

Winkkarin "me-tuetaan-kaikkea-aina-ja-iänkaikkisesti"-asenne toimii pääsääntöisesti yritysmaailmassa mutta kyllä siitä haittaakin on. Nimenomaan tuo käyttiksen ajuritietokannan turpoaminen, jokaisen ajuriversion hyväksyttäminen&sertifiointi ja sitä kautta päivitystahdin turha hidastuminen. MS on huomannut asian jo Windows 2008-serverin yhteydessä jossa jouduttiin eriyttämään datacenter-versio omakseen jossa tuetaan vain rajattua määrää rautaa.

Apple on mielestäni oikeilla jäljillä - halusipa sitten kuluttajat tahi eivät. Tämä siis infra-kehittäjän näkökulmasta katsottuna.

[Sleepperi]

Ohjelmointi?

Ohjelmointi toimii kyllä ihan hyvin vanhallakin koneella.

Kaikkea ohjelmointia ei todellakaan tehdä vanhalla koneella. Voit esim. tsekata huviksesi mikä on minimiteho- ja muistisuositus Androidin coren kääntämiseen. Myös jonkun keskikokoisen ohjelman kehityksessä saattaa mennä vahvakin kone polvilleen, jos ajat sitä jonkun raskaan analysaattorin sisällä.

[theinonen]

<offtpic>Mitä selainta käytät RISC OS:lla</offtopic>

NetSurf pyörii ihan mukavasti ja sillä pärjäilee jos ei tarvitse javascriptiä. PC-puolella hoidan sitten raskaamman selailun.

[OmenaOnPunainen]

Ohjelmointi?

Ohjelmointi toimii kyllä ihan hyvin vanhallakin koneella.

Mieluummin sillä!

OmenaOnPunainen: Tämä toimii sikamaisen hitaasti eikä minulla ole kuin miljoona vektorielementtiä testitiedostossani.
Ohjelmoija: Jaa, minun testitiedostollani ja turboahdetulla koneellani se toimii oikein nopeasti.

EDIT
Oikeinkirjoitus on tänään erityisen vaikeaa, etenkin panovihreiden suhteen.

[Sleepperi]

Ohjelmointi?

Ohjelmointi toimii kyllä ihan hyvin vanhallakin koneella.

Mieluummin sillä!

Tuolla logiikalla saat vain käyttöösi kalliimpia ja bugisempia ohjelmia. Hitaalla koneella testaus silloin tällöin on hyvä idea mutta ohjelmoijan koneen ei pidä olla hidas.

[jalski]

]Tuolla logiikalla saat vain käyttöösi kalliimpia ja bugisempia ohjelmia. Hitaalla koneella testaus silloin tällöin on hyvä idea mutta ohjelmoijan koneen ei pidä olla hidas.

Kyllähän sitä pari vuotta vanhalla keskivertokoneella ohjelmointihommissa pärjäilee yleensä ihan hyvin. Ei kai noita omia ohjelmia millään analysaattorilla sentään normaalisti tarvitse testailla?

Itse en ohjelmakoodista vian etsimiseen ole ikinä tarvinnut mitään perus debuggeria kummempaa työkalua ja senkin ominaisuuksista olen yleensä tarvinnut vain stack dumpin. Kun tiedetään missä kohtaa suoritusta ohjelma kaatui ja mitä muuttujissa on tuolla hetkellä, niin vian syy on yleensä pääteltävissä.

[Laterix]

Entä jos kehittää OSX:lle tai iOS:lle? Itsellä on projektit ollu sen verran pieniä, ettei macistä ole tehot loppunut kesken. Mutta tottahan se on, että enterprise softaa tehtäessä projektit ovat isoja ja automatisoitu testaus (yksikkötestit) tulee olla nopeasti ajettavissa. Debuggaajille ja stack tracen metsästäjille suosittelen TDD:tä ja yksikkötestien kirjoittamista. Tulee softan kehittämisestä paljon mukavampaa ja lopputuloksesta toimivampaa.

[JuEeHa]

]Tuolla logiikalla saat vain käyttöösi kalliimpia ja bugisempia ohjelmia. Hitaalla koneella testaus silloin tällöin on hyvä idea mutta ohjelmoijan koneen ei pidä olla hidas.

Kyllähän sitä pari vuotta vanhalla keskivertokoneella ohjelmointihommissa pärjäilee yleensä ihan hyvin. Ei kai noita omia ohjelmia millään analysaattorilla sentään normaalisti tarvitse testailla?

Itse en ohjelmakoodista vian etsimiseen ole ikinä tarvinnut mitään perus debuggeria kummempaa työkalua ja senkin ominaisuuksista olen yleensä tarvinnut vain stack dumpin. Kun tiedetään missä kohtaa suoritusta ohjelma kaatui ja mitä muuttujissa on tuolla hetkellä, niin vian syy on yleensä pääteltävissä.

No itsehän en ole koskaan jaksanut opetella käyttämään debuggeria. (f)printf oikeaan kohtaan monitoroimaan muutaman muutujan arvoa, (f)printf ilmoittamaan aina funktion/aliohjelman alkuun ja (f)printf keskellekkin ohjelmaa jossa epäilee ongelman olevan.

[Laterix]

No itsehän en ole koskaan jaksanut opetella käyttämään debuggeria. (f)printf oikeaan kohtaan monitoroimaan muutaman muutujan arvoa, (f)printf ilmoittamaan aina funktion/aliohjelman alkuun ja (f)printf keskellekkin ohjelmaa jossa epäilee ongelman olevan.

Tämä kyllä lähtee thredin aiheesta ikävästi sivuraiteille, mutta on pakottava tarve kommentoida. Suosittelen todella opettelemaan käyttämään työkaluja ja opettelemaan ohejlmistokehitysprosesseja jos vakavasti aiot softaa tehdä. Harrastellessa tietenkin voi tehdä mitä mieleen juolahtaa. Voisit yhtä hyvin kommentoida "en jaksa opetella käyttämään moottorisahaa, kun käsisahalla onnistuu niin helposti. Kunhan vähän veivaa ja puu kaatuu". Yhden puun kohdalla tuollakaan ei niin ole väliä, mutta kun aletaan tosi toimiin, niin oikeat työkalut ja niiden käyttö on hallittava.

[Sleepperi]

]Tuolla logiikalla saat vain käyttöösi kalliimpia ja bugisempia ohjelmia. Hitaalla koneella testaus silloin tällöin on hyvä idea mutta ohjelmoijan koneen ei pidä olla hidas.

Kyllähän sitä pari vuotta vanhalla keskivertokoneella ohjelmointihommissa pärjäilee yleensä ihan hyvin. Ei kai noita omia ohjelmia millään analysaattorilla sentään normaalisti tarvitse testailla?

Se vähän riippuu. Haluatko että ne ohjelmat toimivat?

Kääntäjä esimerkiksi on tyypillinen softa, jota on varmasti testattu yhdellä jos toisella työkalulla vuosien mittaan, jonka kehittäjissä ei ole yhtäkään tumpeloa ohjelmoijaa, ja jonka bugittomuuteen luottaa lähes-ehdottomasti kymmeniä miljoonia muita koodaajia. Tässä mainitaan, kuinka yksi uusi analysaattori on löytänyt jo nelisensataa bugia kääntäjistä.

Itse en ohjelmakoodista vian etsimiseen ole ikinä tarvinnut mitään perus debuggeria kummempaa työkalua ja senkin ominaisuuksista olen yleensä tarvinnut vain stack dumpin. Kun tiedetään missä kohtaa suoritusta ohjelma kaatui ja mitä muuttujissa on tuolla hetkellä, niin vian syy on yleensä pääteltävissä.

Kaatumiset jotka koodari itse näkee ovat kaikkein helpoimpia bugeja löytää ja korjata. Ne ovat vain murto-osa oikeista bugeista.

Unohdetaan hetkeksi nuo työkalut ja todetaan, että isomman C++ -softan kääntämiseen voi mennä esimerkiksi puoli tuntia nopealla koneella, muutama tunti mopokoneella. Perus buginpaikannusta varten on normaalia joutua kääntämään muutama kerta. Tehokkaalla koneella homma voi olla hoidettu päivän lopussa, mopokoneella ehkä parin viikon päästä olettaen että kone ei sula ennen sitä. Luonnollisesti sillä mopokoneella ei sinä aikana voi tehdä mitään muuta.

[OmenaOnPunainen]

No itsehän en ole koskaan jaksanut opetella käyttämään debuggeria. (f)printf oikeaan kohtaan monitoroimaan muutaman muutujan arvoa, (f)printf ilmoittamaan aina funktion/aliohjelman alkuun ja (f)printf keskellekkin ohjelmaa jossa epäilee ongelman olevan.

Tämä kyllä lähtee thredin aiheesta ikävästi sivuraiteille, mutta on pakottava tarve kommentoida. Suosittelen todella opettelemaan käyttämään työkaluja ja opettelemaan ohejlmistokehitysprosesseja jos vakavasti aiot softaa tehdä. Harrastellessa tietenkin voi tehdä mitä mieleen juolahtaa. Voisit yhtä hyvin kommentoida "en jaksa opetella käyttämään moottorisahaa, kun käsisahalla onnistuu niin helposti. Kunhan vähän veivaa ja puu kaatuu". Yhden puun kohdalla tuollakaan ei niin ole väliä, mutta kun aletaan tosi toimiin, niin oikeat työkalut ja niiden käyttö on hallittava.

Debuggereiden laadussa saattaa olla eroja. Käyttämässäni ohjelmointiympäristössä debug on täysin hyödytön - tai ainakin vie 100 kertaa enemmän aikaa kuin epäilyksenalaisen muuttujan arvon yksittäinen tarkistaminen.

[jalski]

Keskustelu taisi hiukan harhautua uusille poluille alkuperäisestä aiheesta, mutta eipä tuo kai ketään haittaa...

Kaatumiset jotka koodari itse näkee ovat kaikkein helpoimpia bugeja löytää ja korjata. Ne ovat vain murto-osa oikeista bugeista.

Tottahan tuo on, mutta silti suurin osa huolimattomuus virheistä selviää helposti debuggerin avulla ilman analysaattoria varsin yksinkertaisillakin keinoilla. On tietysti ohjelmointikieliä kuten oma suosikkini PL/I, jossa debuggaus-ominaisuuksia kuuluu suoraan ohjelmointikieleen.

Joskus aikoinaan kokeilin Plan9 käyttöjärjestelmään pohjautuvaa tutkimusjärjestelmää ja huomasin, että käyttöliittymä kaatui aina kun yritti suorittaa paneeli-elementissä olevaa tyhjää komentoa.

Plan9 käyttöjärjestelmässä kaatunut prosessi jää broken tilaan ja tätä päästään kohtuullisen helposti tutkimaan:

Yleensä ohjelman kaatuessa shell tulostaa jonkun näköisen diagnostiikka viestin (status variable), jossa on osoite ja program counterin arvo esim: fault read addr=0x0 pc=0x000020ff.

- Src - nimisellä apuohjelmalla saadaan program counteria vastaava lähdekooditiedosto ja rivinumero.

- Broken tilassa olevaan prosessiin päästään kiinni acid - debuggerilla ja komentamalla: lstk() saadaan listaus kaikkien pinossa olevien funktioiden lokaalien muuttujien arvoista.

Lähetin virhekuvauksen ja kyseisen listauksen sähköpostilla bugi-raporttina. Seuraavana päivänä sain korjauksen ongelmaan sähköpostilla.

Unohdetaan hetkeksi nuo työkalut ja todetaan, että isomman C++ -softan kääntämiseen voi mennä esimerkiksi puoli tuntia nopealla koneella, muutama tunti mopokoneella. Perus buginpaikannusta varten on normaalia joutua kääntämään muutama kerta. Tehokkaalla koneella homma voi olla hoidettu päivän lopussa, mopokoneella ehkä parin viikon päästä olettaen että kone ei sula ennen sitä. Luonnollisesti sillä mopokoneella ei sinä aikana voi tehdä mitään muuta.

Harvoin kuitenkaan joka kerta tarvitsee täyttä buildia projektista tehdä. Yleensä muuttuneiden tiedostojen osalta kääntäminen riittää sekä projektin uudelleen linkitys.

[Sleepperi]

Keskustelu taisi hiukan harhautua uusille poluille alkuperäisestä aiheesta, mutta eipä tuo kai ketään haittaa...

Kaatumiset jotka koodari itse näkee ovat kaikkein helpoimpia bugeja löytää ja korjata. Ne ovat vain murto-osa oikeista bugeista.

Tottahan tuo on, mutta silti suurin osa huolimattomuus virheistä selviää helposti debuggerin avulla ilman analysaattoria varsin yksinkertaisillakin keinoilla.

Osa huolimattomuusvirheistä jää kääntäjään ja linkkeriin, osa hyvintehtyihin testeihin, ja iso osa yksinkertaisesti jää ohjelmaan hautumaan. Saattaa tulla esiin kun päivitetään/vaihdetaan kääntäjää, kun ohjelma asennetaan uuteen käyttöjärjestelmään, kun ohjelmalla mennään tekemään jotain mitä ei olla ennen yritetty tehdä tms. Debuggerit ovat kivoja ja nopeuttavat yksittäisen bugin fiksaamista, mutta ilmankin niitä voi elää. Analysaattorit ovat paljon arvokkaampia kuin debuggerit koska ne löytävät bugeja joista ei muuten vielä tiedetä.

Joskus aikoinaan kokeilin Plan9 käyttöjärjestelmään pohjautuvaa tutkimusjärjestelmää ja huomasin, että käyttöliittymä kaatui aina kun yritti suorittaa paneeli-elementissä olevaa tyhjää komentoa.
...

Eli juuri niinkuin sanoin, kuvaamasi bugi oli helppo fiksata, koska ohjelma kaatui toistettavasti. On paljon ikävämpää jos ohjelma toimii huomaamattomalla tavalla väärin ja esim. korruptoi muokkaamansa datatiedoston tavalla joka aiheuttaa virheitä paljon myöhemmin.

Unohdetaan hetkeksi nuo työkalut ja todetaan, että isomman C++ -softan kääntämiseen voi mennä esimerkiksi puoli tuntia nopealla koneella, muutama tunti mopokoneella. Perus buginpaikannusta varten on normaalia joutua kääntämään muutama kerta. Tehokkaalla koneella homma voi olla hoidettu päivän lopussa, mopokoneella ehkä parin viikon päästä olettaen että kone ei sula ennen sitä. Luonnollisesti sillä mopokoneella ei sinä aikana voi tehdä mitään muuta.

Harvoin kuitenkaan joka kerta tarvitsee täyttä buildia projektista tehdä. Yleensä muuttuneiden tiedostojen osalta kääntäminen riittää sekä projektin uudelleen linkitys.

Tyypillisesti asiakkaan raportoima bugi on jonkun vanhan version bugi. Silloin on aika luonnollista aloittaa bugin metsästys buildaamalla täsmälleen se softan versio mikä asiakkaalla on. Ei kiva, jos on alla mopokone ja buildi kestää päivän.
Jos metsästät luotettavasti toistettavissa olevaa bugia joka on syntynyt jossain vaiheessa viime vuoden aikana, syyllisen koodimuutoksen löytää tekemällä binäärihaun menneisiin versioihin. Siinä buildataan nimenomaan koko softaa moneen kertaan.