Gedit on harvinaisen paska editori

No ei kyllä minulla kaatuile Debianissa. En edes muista millon Debianissa olisi Gnome tai Gnome -ohjelmat kaatuillut tai ohjelmat ylipäätänsäkään. Siitä on todella kauan. Ja mulla on Debian jatkuvasi käytössäm, tätäkin iestiä kirjoitettaessa.

Sen siitä saa kun käyttää Ubuntua. Eikös sitä ole sanottu ties kuinka monta kertaa, että jos käyttää Ubuntua tai siihen perustuvvia distroja niin sillon pitää myös ymmärtää, että käytössä on distro, jota ei ole testattu kunnolla. Ubuntu perustuu Debianin kehitysversioon ja siitä seuraa, että Ubuntu on buginen. Ubuntun jokainen versio on tavallaan beta -versio.Se nyt vaan on niin, että kaikkein uusimmat ohjelmaversiot on myös niitä kaikkein bugisimpia, jos väkisin haluaa käyttää niitä niin pitää myös hyväksyä se, että niissä on bugeja. Ubuntua ei ole testattu kunnolla ja se näkyy juuri tuona mainitsemanasi kaatuiluna. Tämä ei nyt ole mitään perusteetonta Ubuntun mollausta vaan fakta. Jos käytät Ubuntua niin on myös hyväksyttävä se tosiasi, että Ubuntu perustuu keskeneräiseen Debianin kehitysversioon, koska Ubuntu ottaa aina pakettinsa Debianin keehitysversiiosta kesken Debianin kehityskierron. Lisäksi Ubuntu ei edes testaa suurinta osaa paketeista mitenkään eikä anna niille mitään tukea, suurin osa Ubuntun paketeista tulee sellaisenaan Debianin kehitysversiosta eikä Ubuntu testaa niitä mitenkään ennen julkaisua. Se on valitettavasti fakta, joka Ubuntukäyttäjien pitää vain hyväksyä. Puoli vuotta ei mitenkään riitä distron testaamiseen ja kun Ubuntu julkaiseen uuden version puolen vuoden välein niin siitä seuraa väistämättä, että ohjelmat on bugisia.

JDeToki Debianissakin on bugeja, tottakai, mutta Debianin julkaistuissa vakaissa versioissa on bugeja valtavan paljon vähemmän kuin Ubuntun julkaistuissa versioissa ja se todellakin näkyy.

Eli fakta nyt vain on se, että jos haluat käyttää kunnolla testattua luotettavasti toiivaa distroa niin Ubuntu ei ole sillon oikea valinta. Debian taas on erittäin hyvä valinta. Siitä että käyttää uusimpia versioita aina joutuu maksamaan sen hinan, että ohjelmat on bugisia. Sille asialle nyt vain ei voi mitään. Niin kauan kuin ihmiset tekee koodauksen niin kauan ohjelmissa myös on bugeja ja niin kauan niiden ohjelmien luotettavaksi saaminen myös vaatii testausta ja set taas väkisin vaatii aikaa. Testauksen laiminlyönti näkyy väistämättä bugisuutena.

T. miksuh

Anonyymi kirjoitti:

No ei kyllä minulla kaatuile Debianissa. En edes muista millon Debianissa olisi Gnome tai Gnome -ohjelmat kaatuillut tai ohjelmat ylipäätänsäkään. Siitä on todella kauan. Ja mulla on Debian jatkuvasi käytössäm, tätäkin iestiä kirjoitettaessa.

Sen siitä saa kun käyttää Ubuntua. Eikös sitä ole sanottu ties kuinka monta kertaa, että jos käyttää Ubuntua tai siihen perustuvvia distroja niin sillon pitää myös ymmärtää, että käytössä on distro, jota ei ole testattu kunnolla. Ubuntu perustuu Debianin kehitysversioon ja siitä seuraa, että Ubuntu on buginen. Ubuntun jokainen versio on tavallaan beta -versio.Se nyt vaan on niin, että kaikkein uusimmat ohjelmaversiot on myös niitä kaikkein bugisimpia, jos väkisin haluaa käyttää niitä niin pitää myös hyväksyä se, että niissä on bugeja. Ubuntua ei ole testattu kunnolla ja se näkyy juuri tuona mainitsemanasi kaatuiluna. Tämä ei nyt ole mitään perusteetonta Ubuntun mollausta vaan fakta. Jos käytät Ubuntua niin on myös hyväksyttävä se tosiasi, että Ubuntu perustuu keskeneräiseen Debianin kehitysversioon, koska Ubuntu ottaa aina pakettinsa Debianin keehitysversiiosta kesken Debianin kehityskierron. Lisäksi Ubuntu ei edes testaa suurinta osaa paketeista mitenkään eikä anna niille mitään tukea, suurin osa Ubuntun paketeista tulee sellaisenaan Debianin kehitysversiosta eikä Ubuntu testaa niitä mitenkään ennen julkaisua. Se on valitettavasti fakta, joka Ubuntukäyttäjien pitää vain hyväksyä. Puoli vuotta ei mitenkään riitä distron testaamiseen ja kun Ubuntu julkaiseen uuden version puolen vuoden välein niin siitä seuraa väistämättä, että ohjelmat on bugisia.

JDeToki Debianissakin on bugeja, tottakai, mutta Debianin julkaistuissa vakaissa versioissa on bugeja valtavan paljon vähemmän kuin Ubuntun julkaistuissa versioissa ja se todellakin näkyy.

Eli fakta nyt vain on se, että jos haluat käyttää kunnolla testattua luotettavasti toiivaa distroa niin Ubuntu ei ole sillon oikea valinta. Debian taas on erittäin hyvä valinta. Siitä että käyttää uusimpia versioita aina joutuu maksamaan sen hinan, että ohjelmat on bugisia. Sille asialle nyt vain ei voi mitään. Niin kauan kuin ihmiset tekee koodauksen niin kauan ohjelmissa myös on bugeja ja niin kauan niiden ohjelmien luotettavaksi saaminen myös vaatii testausta ja set taas väkisin vaatii aikaa. Testauksen laiminlyönti näkyy väistämättä bugisuutena.

T. miksuh

Lue lisää

Debian siis aloittajalla käytössä, jos tästä halutaan tehdä taas joku juupas-eipäs väittely.

$ cat /etc/debian_version
10.7

Anonyymi kirjoitti:

No ei kyllä minulla kaatuile Debianissa. En edes muista millon Debianissa olisi Gnome tai Gnome -ohjelmat kaatuillut tai ohjelmat ylipäätänsäkään. Siitä on todella kauan. Ja mulla on Debian jatkuvasi käytössäm, tätäkin iestiä kirjoitettaessa.

Sen siitä saa kun käyttää Ubuntua. Eikös sitä ole sanottu ties kuinka monta kertaa, että jos käyttää Ubuntua tai siihen perustuvvia distroja niin sillon pitää myös ymmärtää, että käytössä on distro, jota ei ole testattu kunnolla. Ubuntu perustuu Debianin kehitysversioon ja siitä seuraa, että Ubuntu on buginen. Ubuntun jokainen versio on tavallaan beta -versio.Se nyt vaan on niin, että kaikkein uusimmat ohjelmaversiot on myös niitä kaikkein bugisimpia, jos väkisin haluaa käyttää niitä niin pitää myös hyväksyä se, että niissä on bugeja. Ubuntua ei ole testattu kunnolla ja se näkyy juuri tuona mainitsemanasi kaatuiluna. Tämä ei nyt ole mitään perusteetonta Ubuntun mollausta vaan fakta. Jos käytät Ubuntua niin on myös hyväksyttävä se tosiasi, että Ubuntu perustuu keskeneräiseen Debianin kehitysversioon, koska Ubuntu ottaa aina pakettinsa Debianin keehitysversiiosta kesken Debianin kehityskierron. Lisäksi Ubuntu ei edes testaa suurinta osaa paketeista mitenkään eikä anna niille mitään tukea, suurin osa Ubuntun paketeista tulee sellaisenaan Debianin kehitysversiosta eikä Ubuntu testaa niitä mitenkään ennen julkaisua. Se on valitettavasti fakta, joka Ubuntukäyttäjien pitää vain hyväksyä. Puoli vuotta ei mitenkään riitä distron testaamiseen ja kun Ubuntu julkaiseen uuden version puolen vuoden välein niin siitä seuraa väistämättä, että ohjelmat on bugisia.

JDeToki Debianissakin on bugeja, tottakai, mutta Debianin julkaistuissa vakaissa versioissa on bugeja valtavan paljon vähemmän kuin Ubuntun julkaistuissa versioissa ja se todellakin näkyy.

Eli fakta nyt vain on se, että jos haluat käyttää kunnolla testattua luotettavasti toiivaa distroa niin Ubuntu ei ole sillon oikea valinta. Debian taas on erittäin hyvä valinta. Siitä että käyttää uusimpia versioita aina joutuu maksamaan sen hinan, että ohjelmat on bugisia. Sille asialle nyt vain ei voi mitään. Niin kauan kuin ihmiset tekee koodauksen niin kauan ohjelmissa myös on bugeja ja niin kauan niiden ohjelmien luotettavaksi saaminen myös vaatii testausta ja set taas väkisin vaatii aikaa. Testauksen laiminlyönti näkyy väistämättä bugisuutena.

T. miksuh

Lue lisää

Ei ubuntu kaadu koskaan, vaan vain nuo g-ohjelmat. Yritäppä avata gnomesubtitles 2 srt tiedostoa, niin toista ikkunaan avatessa rysähtää nurin koko ohjelma.

Anonyymi kirjoitti:

No ei kyllä minulla kaatuile Debianissa. En edes muista millon Debianissa olisi Gnome tai Gnome -ohjelmat kaatuillut tai ohjelmat ylipäätänsäkään. Siitä on todella kauan. Ja mulla on Debian jatkuvasi käytössäm, tätäkin iestiä kirjoitettaessa.

Sen siitä saa kun käyttää Ubuntua. Eikös sitä ole sanottu ties kuinka monta kertaa, että jos käyttää Ubuntua tai siihen perustuvvia distroja niin sillon pitää myös ymmärtää, että käytössä on distro, jota ei ole testattu kunnolla. Ubuntu perustuu Debianin kehitysversioon ja siitä seuraa, että Ubuntu on buginen. Ubuntun jokainen versio on tavallaan beta -versio.Se nyt vaan on niin, että kaikkein uusimmat ohjelmaversiot on myös niitä kaikkein bugisimpia, jos väkisin haluaa käyttää niitä niin pitää myös hyväksyä se, että niissä on bugeja. Ubuntua ei ole testattu kunnolla ja se näkyy juuri tuona mainitsemanasi kaatuiluna. Tämä ei nyt ole mitään perusteetonta Ubuntun mollausta vaan fakta. Jos käytät Ubuntua niin on myös hyväksyttävä se tosiasi, että Ubuntu perustuu keskeneräiseen Debianin kehitysversioon, koska Ubuntu ottaa aina pakettinsa Debianin keehitysversiiosta kesken Debianin kehityskierron. Lisäksi Ubuntu ei edes testaa suurinta osaa paketeista mitenkään eikä anna niille mitään tukea, suurin osa Ubuntun paketeista tulee sellaisenaan Debianin kehitysversiosta eikä Ubuntu testaa niitä mitenkään ennen julkaisua. Se on valitettavasti fakta, joka Ubuntukäyttäjien pitää vain hyväksyä. Puoli vuotta ei mitenkään riitä distron testaamiseen ja kun Ubuntu julkaiseen uuden version puolen vuoden välein niin siitä seuraa väistämättä, että ohjelmat on bugisia.

JDeToki Debianissakin on bugeja, tottakai, mutta Debianin julkaistuissa vakaissa versioissa on bugeja valtavan paljon vähemmän kuin Ubuntun julkaistuissa versioissa ja se todellakin näkyy.

Eli fakta nyt vain on se, että jos haluat käyttää kunnolla testattua luotettavasti toiivaa distroa niin Ubuntu ei ole sillon oikea valinta. Debian taas on erittäin hyvä valinta. Siitä että käyttää uusimpia versioita aina joutuu maksamaan sen hinan, että ohjelmat on bugisia. Sille asialle nyt vain ei voi mitään. Niin kauan kuin ihmiset tekee koodauksen niin kauan ohjelmissa myös on bugeja ja niin kauan niiden ohjelmien luotettavaksi saaminen myös vaatii testausta ja set taas väkisin vaatii aikaa. Testauksen laiminlyönti näkyy väistämättä bugisuutena.

T. miksuh

Lue lisää

"Siitä että käyttää uusimpia versioita aina joutuu maksamaan sen hinan, että ohjelmat on bugisia. Sille asialle nyt vain ei voi mitään. Niin kauan kuin ihmiset tekee koodauksen niin kauan ohjelmissa myös on bugeja ja niin kauan niiden ohjelmien luotettavaksi saaminen myös vaatii testausta"

Ei pidä paikkaansa!

Jos hylättäisiin kokonaan C ja C++ ohjelmointikielet, ja korvattaisiin ne ObjectPascalilla (kääntäjät: Delphi ja FreePascal) niin seuraus olisi: Goodbye, ohjelmointivirheet.

Jostain käsittämättömästä syystä linux -yhteisö haluaa pitää kiinni huonoista ohjelmointikielistä, joiden käyttö takaa sen, että niitä ohjelmointivirheitä tulee jatkossakin.

Kysymys kuuluukin: Mikseivät yritykset ole halukkaita tekemään tällaista päätöstä, että jatkossa koodataan ObjectPascalilla ja unohdetaan C ja C++, niin seuraus olisi virheetön koodi.

ObjectPascalissa (ja Turbo Pascalissa) on aina ollut mahdollisuus kääntää ohjelma {$R+}
-tilassa, jolloin tämä koodi:

A[i] := 6;

aiheuttaa aina poikkeuksen, jos i eli ole sallittu indeksi taulukkoon A, eli on joko liian pieni tai liian suuri.

C -kielessä ei ole koskaan ollut tällaista ominaisuutta.

JA nykyaikaisessa ObjectPascalissa on myös tämä mahdollisuus:

var
A : Array of integer;

begin
SetLength(A, 200);
// Nyt pienin sallittu indeksi on 0, ja suurin sallittu indeksi on 199.

end;

Eli tuo {$R+} toimii oikein myös dynamisesti varattujen taulukoiden osalta, joista esimerkki yllä.

Siinä, missä C -koodaajan pitää noudattaa äärimmäistä huolellisuutta AINA, niin ObjectPascal -koodaajalta edellytetään äärimmäistä huolellisuutta vain silloin, kun käytetään aliohjelmia, jotka ottavat ns. tyypittömiä parametrejä tai osoitinparametrejä.

Muutama esimerkki näistä aliohjelmista (Delphi):

Move()
ZeroMemory()
FillChar()

TStream.WriteBuffer()
TStream.ReadBuffer()

Oikealla ohjelmointikielellä bugittomien ohjelmien koodaustyö EI ole vaikeaa.

Miksi linux -yhteisö jatkaa huonoja kielivalintoja ?

Ja kaikista huonoin valinta on AT&T -syntaksi assembly -kielessä.
Tuollaista syntaksia ei olisi koskaan pitänyt keksiä, eikä varsinkaan ottaa yleisesti käyttöön.

Myös C -koodaajien kaistapäinen asenne kääntäjäoptimointeihin on ongelma.
Miksi kääntäjän pitäisi missään tilanteessa tehdä sellaisia optimointeja, jotka aiheuttavat koodin virheellisen toiminnan ?

Mielestäni: oikein tehty kääntäjä saa tehdä vain turvallisia optimointeja, eli sellaiset optimoinnit, jotka aiheuttavat sen, että koodi alkaa toimia väärin, niitä ei pitäisi tehdä ollenkaan.

Anonyymi kirjoitti:

"Siitä että käyttää uusimpia versioita aina joutuu maksamaan sen hinan, että ohjelmat on bugisia. Sille asialle nyt vain ei voi mitään. Niin kauan kuin ihmiset tekee koodauksen niin kauan ohjelmissa myös on bugeja ja niin kauan niiden ohjelmien luotettavaksi saaminen myös vaatii testausta"

Ei pidä paikkaansa!

Jos hylättäisiin kokonaan C ja C ohjelmointikielet, ja korvattaisiin ne ObjectPascalilla (kääntäjät: Delphi ja FreePascal) niin seuraus olisi: Goodbye, ohjelmointivirheet.

Jostain käsittämättömästä syystä linux -yhteisö haluaa pitää kiinni huonoista ohjelmointikielistä, joiden käyttö takaa sen, että niitä ohjelmointivirheitä tulee jatkossakin.

Kysymys kuuluukin: Mikseivät yritykset ole halukkaita tekemään tällaista päätöstä, että jatkossa koodataan ObjectPascalilla ja unohdetaan C ja C , niin seuraus olisi virheetön koodi.

ObjectPascalissa (ja Turbo Pascalissa) on aina ollut mahdollisuus kääntää ohjelma {$R }
-tilassa, jolloin tämä koodi:

A[i] := 6;

aiheuttaa aina poikkeuksen, jos i eli ole sallittu indeksi taulukkoon A, eli on joko liian pieni tai liian suuri.

C -kielessä ei ole koskaan ollut tällaista ominaisuutta.

JA nykyaikaisessa ObjectPascalissa on myös tämä mahdollisuus:

var
A : Array of integer;

begin
SetLength(A, 200);
// Nyt pienin sallittu indeksi on 0, ja suurin sallittu indeksi on 199.

end;

Eli tuo {$R } toimii oikein myös dynamisesti varattujen taulukoiden osalta, joista esimerkki yllä.

Siinä, missä C -koodaajan pitää noudattaa äärimmäistä huolellisuutta AINA, niin ObjectPascal -koodaajalta edellytetään äärimmäistä huolellisuutta vain silloin, kun käytetään aliohjelmia, jotka ottavat ns. tyypittömiä parametrejä tai osoitinparametrejä.

Muutama esimerkki näistä aliohjelmista (Delphi):

Move()
ZeroMemory()
FillChar()

TStream.WriteBuffer()
TStream.ReadBuffer()

Oikealla ohjelmointikielellä bugittomien ohjelmien koodaustyö EI ole vaikeaa.

Miksi linux -yhteisö jatkaa huonoja kielivalintoja ?

Ja kaikista huonoin valinta on AT&T -syntaksi assembly -kielessä.
Tuollaista syntaksia ei olisi koskaan pitänyt keksiä, eikä varsinkaan ottaa yleisesti käyttöön.

Myös C -koodaajien kaistapäinen asenne kääntäjäoptimointeihin on ongelma.
Miksi kääntäjän pitäisi missään tilanteessa tehdä sellaisia optimointeja, jotka aiheuttavat koodin virheellisen toiminnan ?

Mielestäni: oikein tehty kääntäjä saa tehdä vain turvallisia optimointeja, eli sellaiset optimoinnit, jotka aiheuttavat sen, että koodi alkaa toimia väärin, niitä ei pitäisi tehdä ollenkaan.

Lue lisää

Eräs ohjelmoija sanoi, että ei C ole vaikeaa, kunhan opettelee syntaksin kunnolla. Ilmeisesti C vaatii tietynlaisen ajattelutavan ohjelmointiin.

Anonyymi kirjoitti:

Eräs ohjelmoija sanoi, että ei C ole vaikeaa, kunhan opettelee syntaksin kunnolla. Ilmeisesti C vaatii tietynlaisen ajattelutavan ohjelmointiin.

Itse kokeilin aikoinaan ensin tietokoneella Basic-tulkkia, jotta oppi ohjelmoinnin logiikan. Sitten siirryinkin jo assemblyyn, jonka jälkeen vasta C-kieleen.

Assemblerin osaamisesta on ollut myöhemmin hyötyä mikrokontrollereille ohjelmia väsätessä, ja C-kielen syntaksi taas on melko vastaava monissa muissakin ohjelmointikielissä, eli vaikkei sitä päivittäin enää käytäkään, niin päivittäin tulee suunnilleen samanlaista kirjoiteltua.

C-kieli kannattaa kyllä opetella, koska se opettaa koodaamaan tehokkaasti. Ymmärtää mm. dynaamisen muistinvarauksen merkityksen, jottei tarvtse käyttää hullua pinomuistia jne.

Anonyymi kirjoitti:

No ei kyllä minulla kaatuile Debianissa. En edes muista millon Debianissa olisi Gnome tai Gnome -ohjelmat kaatuillut tai ohjelmat ylipäätänsäkään. Siitä on todella kauan. Ja mulla on Debian jatkuvasi käytössäm, tätäkin iestiä kirjoitettaessa.

Sen siitä saa kun käyttää Ubuntua. Eikös sitä ole sanottu ties kuinka monta kertaa, että jos käyttää Ubuntua tai siihen perustuvvia distroja niin sillon pitää myös ymmärtää, että käytössä on distro, jota ei ole testattu kunnolla. Ubuntu perustuu Debianin kehitysversioon ja siitä seuraa, että Ubuntu on buginen. Ubuntun jokainen versio on tavallaan beta -versio.Se nyt vaan on niin, että kaikkein uusimmat ohjelmaversiot on myös niitä kaikkein bugisimpia, jos väkisin haluaa käyttää niitä niin pitää myös hyväksyä se, että niissä on bugeja. Ubuntua ei ole testattu kunnolla ja se näkyy juuri tuona mainitsemanasi kaatuiluna. Tämä ei nyt ole mitään perusteetonta Ubuntun mollausta vaan fakta. Jos käytät Ubuntua niin on myös hyväksyttävä se tosiasi, että Ubuntu perustuu keskeneräiseen Debianin kehitysversioon, koska Ubuntu ottaa aina pakettinsa Debianin keehitysversiiosta kesken Debianin kehityskierron. Lisäksi Ubuntu ei edes testaa suurinta osaa paketeista mitenkään eikä anna niille mitään tukea, suurin osa Ubuntun paketeista tulee sellaisenaan Debianin kehitysversiosta eikä Ubuntu testaa niitä mitenkään ennen julkaisua. Se on valitettavasti fakta, joka Ubuntukäyttäjien pitää vain hyväksyä. Puoli vuotta ei mitenkään riitä distron testaamiseen ja kun Ubuntu julkaiseen uuden version puolen vuoden välein niin siitä seuraa väistämättä, että ohjelmat on bugisia.

JDeToki Debianissakin on bugeja, tottakai, mutta Debianin julkaistuissa vakaissa versioissa on bugeja valtavan paljon vähemmän kuin Ubuntun julkaistuissa versioissa ja se todellakin näkyy.

Eli fakta nyt vain on se, että jos haluat käyttää kunnolla testattua luotettavasti toiivaa distroa niin Ubuntu ei ole sillon oikea valinta. Debian taas on erittäin hyvä valinta. Siitä että käyttää uusimpia versioita aina joutuu maksamaan sen hinan, että ohjelmat on bugisia. Sille asialle nyt vain ei voi mitään. Niin kauan kuin ihmiset tekee koodauksen niin kauan ohjelmissa myös on bugeja ja niin kauan niiden ohjelmien luotettavaksi saaminen myös vaatii testausta ja set taas väkisin vaatii aikaa. Testauksen laiminlyönti näkyy väistämättä bugisuutena.

T. miksuh

Lue lisää

"Sen siitä saa kun käyttää Ubuntua. Eikös sitä ole sanottu ties kuinka monta kertaa, että jos käyttää Ubuntua tai siihen perustuvvia distroja niin sillon pitää myös ymmärtää, että käytössä on distro, jota ei ole testattu kunnolla. "

Ei varmasti johdu Ubuntustakaan, kyllä se on testattu hyvin. Ubuntussa on ne paremmin testatut julkaisut merkittynä LTS. Sitä vaan pöljät asentelee jotain beeta versiota tai preview versioita jotka kyllä sitten tosiaankin ovat bugisia mutta se johtuu käyttäjästä.

"Ubuntu perustuu Debianin kehitysversioon ja siitä seuraa, että Ubuntu on buginen."

Ubuntu on kyllä ihan itsenäinen. Siihen on tuotu läjä paketteja Debianin testingistä lisäksi, sellaisia community paketteja ja ne ovat testausvaiheessa ja vikoja korjataan kuten Debianissakin ennen julkaisua. Näiden määrä tiettävästi on nykyään hyvin vähäinen. Niin vähäinen että puhutaan yksittäisestä paketista minkä käyttäjä ehkä lisää.

Ubuntussa ovat alusta saakka vähentäneet sitä Debianin osuutta. Ihan aluksi se oli tosiaankin Debianin kehitysversio mihin vaihdettu teema, rakensivat silloin projektin kehittämiseen infraa mutta tästä nyt on aikaa melkein 20 vuotta. Nythän Ubuntussa on varmaan viimeiset 5-7 vuotta ollut sovellukset paketoituna snap paketteihin että niillä ei ole mitään tekemistä Debianin kanssa, niitä ylläpidetään Debianista erillään ja niitä voidaan päivittää milloin vain kun näissä on riippuvuudet katkottu käyttöjärjestelmään.

Anonyymi kirjoitti:

"Siitä että käyttää uusimpia versioita aina joutuu maksamaan sen hinan, että ohjelmat on bugisia. Sille asialle nyt vain ei voi mitään. Niin kauan kuin ihmiset tekee koodauksen niin kauan ohjelmissa myös on bugeja ja niin kauan niiden ohjelmien luotettavaksi saaminen myös vaatii testausta"

Ei pidä paikkaansa!

Jos hylättäisiin kokonaan C ja C ohjelmointikielet, ja korvattaisiin ne ObjectPascalilla (kääntäjät: Delphi ja FreePascal) niin seuraus olisi: Goodbye, ohjelmointivirheet.

Jostain käsittämättömästä syystä linux -yhteisö haluaa pitää kiinni huonoista ohjelmointikielistä, joiden käyttö takaa sen, että niitä ohjelmointivirheitä tulee jatkossakin.

Kysymys kuuluukin: Mikseivät yritykset ole halukkaita tekemään tällaista päätöstä, että jatkossa koodataan ObjectPascalilla ja unohdetaan C ja C , niin seuraus olisi virheetön koodi.

ObjectPascalissa (ja Turbo Pascalissa) on aina ollut mahdollisuus kääntää ohjelma {$R }
-tilassa, jolloin tämä koodi:

A[i] := 6;

aiheuttaa aina poikkeuksen, jos i eli ole sallittu indeksi taulukkoon A, eli on joko liian pieni tai liian suuri.

C -kielessä ei ole koskaan ollut tällaista ominaisuutta.

JA nykyaikaisessa ObjectPascalissa on myös tämä mahdollisuus:

var
A : Array of integer;

begin
SetLength(A, 200);
// Nyt pienin sallittu indeksi on 0, ja suurin sallittu indeksi on 199.

end;

Eli tuo {$R } toimii oikein myös dynamisesti varattujen taulukoiden osalta, joista esimerkki yllä.

Siinä, missä C -koodaajan pitää noudattaa äärimmäistä huolellisuutta AINA, niin ObjectPascal -koodaajalta edellytetään äärimmäistä huolellisuutta vain silloin, kun käytetään aliohjelmia, jotka ottavat ns. tyypittömiä parametrejä tai osoitinparametrejä.

Muutama esimerkki näistä aliohjelmista (Delphi):

Move()
ZeroMemory()
FillChar()

TStream.WriteBuffer()
TStream.ReadBuffer()

Oikealla ohjelmointikielellä bugittomien ohjelmien koodaustyö EI ole vaikeaa.

Miksi linux -yhteisö jatkaa huonoja kielivalintoja ?

Ja kaikista huonoin valinta on AT&T -syntaksi assembly -kielessä.
Tuollaista syntaksia ei olisi koskaan pitänyt keksiä, eikä varsinkaan ottaa yleisesti käyttöön.

Myös C -koodaajien kaistapäinen asenne kääntäjäoptimointeihin on ongelma.
Miksi kääntäjän pitäisi missään tilanteessa tehdä sellaisia optimointeja, jotka aiheuttavat koodin virheellisen toiminnan ?

Mielestäni: oikein tehty kääntäjä saa tehdä vain turvallisia optimointeja, eli sellaiset optimoinnit, jotka aiheuttavat sen, että koodi alkaa toimia väärin, niitä ei pitäisi tehdä ollenkaan.

Lue lisää

"Jos hylättäisiin kokonaan C ja C++ ohjelmointikielet, ja korvattaisiin ne ObjectPascalilla (kääntäjät: Delphi ja FreePascal) niin seuraus olisi: Goodbye, ohjelmointivirheet."

Ei pidä paikkaansa.

ObjectPascal sisältää täysin samoja vajavaisuuksia. Esimerkiksi:
-Osoittimet
-Manuaalinen muistinhallinta
-Ohjemoija voi helposti laittaa olioihin tiloja
-Ohjelman voi saada sumppuun rinnakkaisuudella kääntäjän valittamatta
-Ei kunnollisia verifiointityökaluja

Ja jne.

Ohjelmointikielet joissa kieli itsessään ehkäisee virheitä ovat jotain ihan muuta. Haskell esimerkiksi on sellainen.

" Mikseivät yritykset ole halukkaita tekemään tällaista päätöstä, että jatkossa koodataan ObjectPascalilla ja unohdetaan C ja C++, niin seuraus olisi virheetön koodi."

Koska ObjectPascal on surkea verrattuna vaikka Haskelliin ja Haskell johdannaisiin. Tai vaikka koko ML kieliperhe joka on lähtöisin tarpeista todistaa koodi virheettömäksi.

Bisneskoodista melkoinen määrä tehdään nykyään mm. Javalla, C#:lla ja Typescriptillä. Java mahdollistaa helpommin virheiden välttämisen kuin C++ ja ObjectPascal. Microsoft rekrytoi ObjectPascalin kehittäjän tekemään C#:n joka on hyvin vastaava kuin Java, ja sama tyyppi oli myös Typescriptin pääkehittäjä.

En tiedä mistä olet saanut päähäsi että C:tä tai C++:aa käytettäisiin paljon. C on sularipuolella, C++:lla pyörii muutama merkittävä kirjasto/framework minkä varaan rakennettu paljon softaa mutta ei sillä oikein mitään bisnessoftaa tehdä.

"C -kielessä ei ole koskaan ollut tällaista ominaisuutta."

C-kielessä ollut varmaan aina tuo mutta se toimii eri tavalla. Siinä pitää laittaa väliin makro joka testaa arvon ja se tulostaa virheet stderr https://www.tutorialspoint.com/c_standard_library/c_macro_assert.htm

Sen lisäksi C-kielelle on laajennos joka mahdollistaa käännösaikana varmistaa, että noin ei voi tapahtua. Tuo on niitä kehittyneempiä tekniikoita joita vaaditaan niissä kohteissa joissa ei saa virheitä olla. ObjectPascal ei niihin sovi.

"Miksi linux -yhteisö jatkaa huonoja kielivalintoja ?"

Kernel on lowleveliä, näissä C ollut defacto. Tietääkseni Rustia harkitaan käytettäväksi enemmän lowlevelissä.

"Ja kaikista huonoin valinta on AT&T -syntaksi assembly -kielessä."

Assemblyä ei haluta käyttää.

"Myös C -koodaajien kaistapäinen asenne kääntäjäoptimointeihin on ongelma.
Miksi kääntäjän pitäisi missään tilanteessa tehdä sellaisia optimointeja, jotka aiheuttavat koodin virheellisen toiminnan ?"

Nyt kuvittelet omiasi. Kyllä kääntäjissä on asiat dokumentoitu ja oletuksena ei sellaisia ole. Kääntäjissä voi kyllä olla uusia optimointitoimintoja joita testataan ja niitä voi laittaa lisävivusta päälle mutta ne toki voivat toimia väärin. Siinä on pitkä matka ennen kuin menevät oletuksiin joita käytetään tuotannossa.

Anonyymi kirjoitti:

Eräs ohjelmoija sanoi, että ei C ole vaikeaa, kunhan opettelee syntaksin kunnolla. Ilmeisesti C vaatii tietynlaisen ajattelutavan ohjelmointiin.

"Eräs ohjelmoija sanoi, että ei C ole vaikeaa, kunhan opettelee syntaksin kunnolla. Ilmeisesti C vaatii tietynlaisen ajattelutavan ohjelmointiin."

C on tunnetusti hyvin yksinkertainen kieli.

Suunniteltu siihen että tehdään jotain kerneliä tai sitten tehdään sellaisia pieniä komponentteja jotka ottaa syötettä vastaan stdin, tulostavat stdout ja virheet stderr

Niitä pieniä komponentteja sitten tarkoitus yhdistellä korkemmalla tasolla, kuten komentotulkilla.

Nuo hirveät vi ja emacs on siis vielä olemassa?

Selattu tiedosto oli tosiaan 7z-paketista auki klikattu. Oli useampi editori auki, ja joissain muutama välilehtikin. Välillä on tuota tehty. Pitää seurata liittyykö noihin paketeista auottuihin. Yleensä tulee pikkusäädöt tehtyä nanolla, ja koodaukset vscodella.

Anonyymi kirjoitti:

Selattu tiedosto oli tosiaan 7z-paketista auki klikattu. Oli useampi editori auki, ja joissain muutama välilehtikin. Välillä on tuota tehty. Pitää seurata liittyykö noihin paketeista auottuihin. Yleensä tulee pikkusäädöt tehtyä nanolla, ja koodaukset vscodella.

Lue lisää

7z -pakkausohjelmasta on myös kehittyneempi versio joka kykenee hyödyntämään koneen kaikki coret...

Anonyymi kirjoitti:

Nuo hirveät vi ja emacs on siis vielä olemassa?

........

on, eikä niistä tulla luopumaan koska pääsääntöisesti Linuxissa kaikki tehdään komentojonoriveiltä.

'vi' muuten on ihan uskomattoman pätevä silloin kun boottaa koneen single-user -moodiin, ja muuttelee konfigurointitiedostoja.

yllättävän moni käyttää 'emacs'ia, ja töissä eivät oikein tykänneet kun sanoin että minä käytän 'joe'ta, koska osaan sen koska olen käyttänyt sitä jo vuosia, niin se tulee saada jokaiselle palvelimelle asennettua, ja heitin vähän hunajaa sekaan totemalla 'eihän kukaan halua että teen kirjoitusvirheitä tai muuta sekoilua kun vahingossa tungen joe-komentoja emacsiin'...

Anonyymi kirjoitti:

........

on, eikä niistä tulla luopumaan koska pääsääntöisesti Linuxissa kaikki tehdään komentojonoriveiltä.

'vi' muuten on ihan uskomattoman pätevä silloin kun boottaa koneen single-user -moodiin, ja muuttelee konfigurointitiedostoja.

yllättävän moni käyttää 'emacs'ia, ja töissä eivät oikein tykänneet kun sanoin että minä käytän 'joe'ta, koska osaan sen koska olen käyttänyt sitä jo vuosia, niin se tulee saada jokaiselle palvelimelle asennettua, ja heitin vähän hunajaa sekaan totemalla 'eihän kukaan halua että teen kirjoitusvirheitä tai muuta sekoilua kun vahingossa tungen joe-komentoja emacsiin'...

Lue lisää

Emacs on kyllä paras. Siinä on takana Lisp-kieli ja tälle löytyy emacsiin tehtyjä custom-moduleita moneen tarpeeseen. Esim. 3-way compare on ollut käytössä. Emacs-wiki:stä voi käydä katsomassa, miten pääsee ELPA:amaan.
Btw. tekstieditoinnin lomassa voi pelata tetristä antamalla komennon ESC-x tetris.

Anonyymi kirjoitti:

Nuo hirveät vi ja emacs on siis vielä olemassa?

Parhaat Linuxissa näkemäni tekstieditorit ovat olleet vanhan KDE:n (ehkä KDE 3.1 tai 3.5 ?) mukana tulleet KWrite ja Kate.

Leafpadkin hätätilassa menettelee, muttei ole KWriten ja Katen veroinen.

tekstitilassa paras lienee mcedit, joka asentuu osana MC:tä (midnight commander).

HAH, wintoosahan se varsinainen bugikasa on, ei linuxit tai linuxsovellukset!

Ai niin, milloin Wintoosan notepad alkaa tukea isoja tiedostoja joissa on tekstiä enemmän kuin 64kt???

Anonyymi kirjoitti:

Ai niin, milloin Wintoosan notepad alkaa tukea isoja tiedostoja joissa on tekstiä enemmän kuin 64kt???

Milloin se ensimmäinen NT tuli? Joskus 30 vuotta sitten.

Anonyymi kirjoitti:

Ai niin, milloin Wintoosan notepad alkaa tukea isoja tiedostoja joissa on tekstiä enemmän kuin 64kt???

Notepadilla voit kirjoittaa enimmillään 16TB tiedostoja NTFS-filesysteemissä.

Anonyymi kirjoitti:

Notepadilla voit kirjoittaa enimmillään 16TB tiedostoja NTFS-filesysteemissä.

Älä viitsi valehdella! Notepadissa on 32kt rajoitus kirjoittamiselle ja 64kt rajoitus lukemiselle! Notepad ei ole IKINÄ ymmärtänyt 16Tt tiedostoja edes NTFS:llä! Tiedän koska olen kokeillut sitä ja aina on epäonnistunut liian ison tiedoston aukaisu!

Anonyymi kirjoitti:

Älä viitsi valehdella! Notepadissa on 32kt rajoitus kirjoittamiselle ja 64kt rajoitus lukemiselle! Notepad ei ole IKINÄ ymmärtänyt 16Tt tiedostoja edes NTFS:llä! Tiedän koska olen kokeillut sitä ja aina on epäonnistunut liian ison tiedoston aukaisu!

Lue lisää

Jos kerran käytät vielä Windows 9x -sarjan käyttiksiä, niin sinulla lienee Linuxistakin kernelin ensimmäinen versio käytössä.

Kannatta jossain vaiheessa tulla edes 2000-luvulle.

Anonyymi kirjoitti:

Älä viitsi valehdella! Notepadissa on 32kt rajoitus kirjoittamiselle ja 64kt rajoitus lukemiselle! Notepad ei ole IKINÄ ymmärtänyt 16Tt tiedostoja edes NTFS:llä! Tiedän koska olen kokeillut sitä ja aina on epäonnistunut liian ison tiedoston aukaisu!

Lue lisää

Juuri avasin kokeeksi 993Mt tiedoston Notepadissa kokeeksi(W10-64-bit). 2 sekuntia kesti avaus.

Anonyymi kirjoitti:

Jos kerran käytät vielä Windows 9x -sarjan käyttiksiä, niin sinulla lienee Linuxistakin kernelin ensimmäinen versio käytössä.

Kannatta jossain vaiheessa tulla edes 2000-luvulle.

Lue lisää

En käytä vakituisesti windowsia ja kyllä mulla on uusimpia kerneleitä käytössä.

Anonyymi kirjoitti:

Notepadilla voit kirjoittaa enimmillään 16TB tiedostoja NTFS-filesysteemissä.

Rajoja en tiedä, mutta koska teoriassa kaikki on mahdollista, joka tässä tapauksesa kuitenkin ensin edellyttäisi että on myös 16TB vapaata keskusmuistia tuolle tiedostolle, koska muuten wintuuttisi heittovahtokirjoittaa (virallinen suomennos mutten) koneesi solmuun...

Minä ehkä ensi vuoden puolella ostan 30T lisää levytilaa, ja jos ostan niin lupaan kokeilla tätä; ensin pitää kuitenkin saada luotua tuollainen 16TB tekstitiedosto, johon aivan ensimmäisenä menee sitten oma aikansa.

Sitten päästäisiinkin jännäämään että kuinka kauan tuon tiedoston avaamiseen menee, kuten myös että kuinka kauan kestäisi scrollata sen tiedoston loppuun...

Mulla on vaan 64G keskusmuistia, eli sillä ei kyllä kovin pitkälle tällaisen projektin kanssa pötkitä...

Anonyymi kirjoitti:

Juuri avasin kokeeksi 993Mt tiedoston Notepadissa kokeeksi(W10-64-bit). 2 sekuntia kesti avaus.

Siitä kun alat laskemaan, paljonko tulee tiedonsiirtonopeudeksi voit todeta, että notepad ei avannutkaan koko tiedostoa vaan näkymän tiedoston alkuun!

Äkkiseltään mietittynä siinä melkein kaikki tapahtuu Gnomen kirjastoissa, että tuossa tuskin tarvitsee paljoa koodia.

Eiköhän siihen niitä plugareita saa tehtyä vaivatta jos niin haluaa mutta Visual Studio Codeen on niin paljon valmiina ja siinä hyvä käytettävyys, että itse käytän sitä.

Kollilla kovaa menoa, Taasko Sinol-kansan kutsuhuuto kajahtaa Intialaisissa wiidakoissa! Sinol-ajat ovat palanneet! Bongipiiput savuavat jälleen peräkammarissa.

Eikö gedit koeta avata tiedostoon ensimmäisiä rivejä, joka on hidasta jos alussa on pitkä rivi? Emacs kai avaa ensimmäistä riviä ja renderöi sen usealle riville. Joskus vaan luin näin netistä, en ole varma.

Anonyymi kirjoitti:

Eikö gedit koeta avata tiedostoon ensimmäisiä rivejä, joka on hidasta jos alussa on pitkä rivi? Emacs kai avaa ensimmäistä riviä ja renderöi sen usealle riville. Joskus vaan luin näin netistä, en ole varma.

Lue lisää

Täyttä soopaa: Levykontrollerilta pyydetään yleensä data-blokkia. Tämä on muistikortti-tyyppisillä ratkaisuilla aika usein 512 tavua. Voi jopa olla, että tämä on pienin muistiyksikön koko mitä ylipäänsä voidaan siirtää. Eli jos tallettaa 1 tavun dataa ensin luetaan 512 tavua, muutetaan yksi tavu ja kirjoitetaan takaisin.
Isompiakin blokki-kokoja on käytössä kiintolevyillä. Tekstipohjaisia järjestelmiä sitten "renderoidaan" rivipohjaisiksi, eli tekstistä etitään tiettyä merkkiä tai merkkisarjaa joka tunnistetaan rivinvaihdoksi ja pysäytetään luku tähän. Sitten kun muistipuskuri on käyty läpi annetaan levykontrollerille käsky lukea seuraavat 512 tavua.

Anonyymi kirjoitti:

Täyttä soopaa: Levykontrollerilta pyydetään yleensä data-blokkia. Tämä on muistikortti-tyyppisillä ratkaisuilla aika usein 512 tavua. Voi jopa olla, että tämä on pienin muistiyksikön koko mitä ylipäänsä voidaan siirtää. Eli jos tallettaa 1 tavun dataa ensin luetaan 512 tavua, muutetaan yksi tavu ja kirjoitetaan takaisin.
Isompiakin blokki-kokoja on käytössä kiintolevyillä. Tekstipohjaisia järjestelmiä sitten "renderoidaan" rivipohjaisiksi, eli tekstistä etitään tiettyä merkkiä tai merkkisarjaa joka tunnistetaan rivinvaihdoksi ja pysäytetään luku tähän. Sitten kun muistipuskuri on käyty läpi annetaan levykontrollerille käsky lukea seuraavat 512 tavua.

Lue lisää

Eikö lukunopeus riipu merkistökoodauksesta? Jos kukin merkki vie vakiomuistin, niin oikean kohdan löytäminen on nopeaa. Mutta jos eri merkit vievät eri määrän tilaa, joudutaan lukemaan koko rivi alusta löytääkseen n:nnen merkin?

Anonyymi kirjoitti:

Eikö lukunopeus riipu merkistökoodauksesta? Jos kukin merkki vie vakiomuistin, niin oikean kohdan löytäminen on nopeaa. Mutta jos eri merkit vievät eri määrän tilaa, joudutaan lukemaan koko rivi alusta löytääkseen n:nnen merkin?

Lue lisää

Rivin lukeminen on väärä tapa. Rivi voi olla vaikka triljoona merkkiä pitkä.

Pitää lukea puskuriin binäärinä sopiva määrä ja käsitellä aina palanen kerrallaan.