Delphi sairaus

"Standardit ovat vain _apukeino_ sitä varten että eri toimijat tekisivät yhteensopivia asioita."

Totta.

"Tiedän muutaman ohjelman jotka on tehty varhaisella Delphillä (Delphi1)
ja sama lähdekoodi on otettu käyttöön Lazaruksella Linuxiin
(siinä käyttöliittymä tuolloin oli GTK -pohjainen). Tätä
nykyä sama ohjelma toimii RaspBerry PI:ssä.
Totean tässä ettei lähdekoodiin ole tarvinnut koskea."

API yhteensopivuus siis säilynyt.

"Voit vain miettiä miten paljon ylimääräistä työtä olisi tarvittu jos se olisi tehty esim. (standardi) C:llä tai jollakin muulla kielellä.
(Esim. käyttöliittymän uudelleen kirjoittaminen)."

Ei standardi C ja silloinen käyttöliittymästandardi IEEE 1295, eli Motif toolkit ja X Instricts GUI komponentit ole tarvinnut mitään uudelleenkirjoittamista. Toimii käytännössä kun kääntää uusiksi. API yhteensopivuus on säilynyt mutta ABI toki muuttunut. Kyllä tuo Raspberry Pi:ssä toimii.

"Miksi tälläistä ominaisuutta ei voi arvostaa?"

Toki. Tuo on sitä arvostaa API:n säilymistä. Mutta se ei tarkoita sitä, että ohjelman pitäisi toimia vaikka kun käyttöjärjestelmää päivittää tai vaihtaa merkkiä. ABI yhteensopivuus sitten eri juttu.

"93 tuli delphi 3 jolla tein sanakirjan, vasta windows 10 teki siitä toimimattoman. Revi siitä sitä pitkäikäisyyttä. "

Delphi 3 tuli vuonna 1997. Ja ihan normaalia, että ABI yhteensopivuus rikkoutuu. Eihän Microsoft lupaa sitä ABI yhteensopivuuden säilymistä Windows versioiden välillä WinAPI:ssa. Se muuttui aiemmin noin 3v välein, nyt 2x vuodessa.

Siinä ON kyllä huomioitu taaksepäinyhteensopivuutta ja sitä matalantason rajapintaa käytetään siihen, että sen päälle voi tehdä näitä korkeamman tason rajapintoja millä tehdään sovellukset, kuten vaikka .NET tai MFC. Näiden vakausvaatimukset pitää sitä sitten vakaana. Ei poistella WinAPI:sta tavaraa jos korkeamman tason rajapinta vaatii sitä toimiakseen. Microsoft kyllä on siihen taaksepäinyhteensopivuuteen myös satsannut mutta ohjelmistokehittäjä tietysti joutuu menemään sen mukaan miten on luvattu.

Nykyään kun Windows API muutossykli on 2x vuodessa enemmän tai vähemmän, riippuen siitä miten korkeamman tason rajapinnat vanhenee ja Delphin luvattu tuki 1,5v ja uusimistahti kerta vuoteen, käytännössä sitä uusitaan nykyään kerran vuodessa jotta saa käännettyä koodia joka toimii luvatusti Windows 10:ssä ja jää se 6kk pelivaraa.

Toki tiedän sen, että jos aikoinaan teki Windows XP:lle Delphi 7:lla sovelluksen, ja se säilyi vaikka yhteensopivana Windows Vistassa ja vielä Windows 7:ssakin niin toki se sama ohjelma toimii Windows 7:ssa niin pitkään kuin sen tukea riittää. Ja miksei vaikka Windows 8:ssakin. Ei ne vakaat Windowsjulkaisut kesken julkaisun pahemmin riko mitään mutta Windows julkaisun vaihdos saattaa rikkoa. Esim. Windows 8->10 muutos tai XP->7. Tai Windows 10:n talvi 2015 -> kesä 2016.

" Windows julkaisun vaihdos saattaa rikkoa. Esim. .......... Tai Windows 10:n talvi 2015 -> kesä 2016"

Eli siis Windows 10 rikkoo ohjelman toimivuuden satunnaisesti päivitysten myötä. No eipä ole ollut aikomustakaan kehittää koodia sellaiselle paskalle, koodaan vain järjestelmille jotka EIVÄT riko ohjelmien toimivuutta mielivaltaisesti.

Windows-10_rikkoo_ohjelm kirjoitti:

" Windows julkaisun vaihdos saattaa rikkoa. Esim. .......... Tai Windows 10:n talvi 2015 -> kesä 2016"

Eli siis Windows 10 rikkoo ohjelman toimivuuden satunnaisesti päivitysten myötä. No eipä ole ollut aikomustakaan kehittää koodia sellaiselle paskalle, koodaan vain järjestelmille jotka EIVÄT riko ohjelmien toimivuutta mielivaltaisesti.

Lue lisää

"Eli siis Windows 10 rikkoo ohjelman toimivuuden satunnaisesti päivitysten myötä."

Vain legacyn. .NET, Visual C , DirectX jne. versiot pysyvät tietysti vakaina luvatun aikaa. Ja tietysti standardi HTML5 toimii ja nykyinen natiivi WinRT.

Delphissä ongelmana se, että kääntää omia kirjastoja WindowsAPI:a vasten ja niiden kirjastoje toimivuudesta vastaa Embarcadero. Lupaavat tukea 1,5v jokaiselle Delphi versiolle.

Eli käytännössä ostetaan Delphi päivitys joka vuosi, ja ajellaan niitä omia ohjelmia Windows 10 insiderilla niin nähdään ennen Windows 10:n tuotantoversion päivittymistä harmit ja tarvittaessa käännellään ohjelmasta uusi versio. Tämä toimii oikein hyvin.

Eli mitään mielivaltaista rikkomista ei ole. Kannattaa vaan valita rajapinta oikein.

Windows-10_rikkoo_ohjelm kirjoitti:

" Windows julkaisun vaihdos saattaa rikkoa. Esim. .......... Tai Windows 10:n talvi 2015 -> kesä 2016"

Eli siis Windows 10 rikkoo ohjelman toimivuuden satunnaisesti päivitysten myötä. No eipä ole ollut aikomustakaan kehittää koodia sellaiselle paskalle, koodaan vain järjestelmille jotka EIVÄT riko ohjelmien toimivuutta mielivaltaisesti.

Lue lisää

Tietysti, olen kyllä sanonutkin sitä että Delphi on käytännössä kuollut viritelmä ollut sieltä jostain vuodesta 2006..2009 ajoista lähtien sattuneista syistä johtuen.

Nyt Windows 10 aikoina se on aika kallis myös.

M-Kar kirjoitti:

"Eli siis Windows 10 rikkoo ohjelman toimivuuden satunnaisesti päivitysten myötä."

Vain legacyn. .NET, Visual C , DirectX jne. versiot pysyvät tietysti vakaina luvatun aikaa. Ja tietysti standardi HTML5 toimii ja nykyinen natiivi WinRT.

Delphissä ongelmana se, että kääntää omia kirjastoja WindowsAPI:a vasten ja niiden kirjastoje toimivuudesta vastaa Embarcadero. Lupaavat tukea 1,5v jokaiselle Delphi versiolle.

Eli käytännössä ostetaan Delphi päivitys joka vuosi, ja ajellaan niitä omia ohjelmia Windows 10 insiderilla niin nähdään ennen Windows 10:n tuotantoversion päivittymistä harmit ja tarvittaessa käännellään ohjelmasta uusi versio. Tämä toimii oikein hyvin.

Eli mitään mielivaltaista rikkomista ei ole. Kannattaa vaan valita rajapinta oikein.

Lue lisää

Haista paska M-Kar, et tiedä mistään mitään

Painusit-vittuun-sössö kirjoitti:

Haista paska M-Kar, et tiedä mistään mitään

Kaikki mitä sanon on vahvistettavissa todeksi.

M-Kar kirjoitti:

Tietysti, olen kyllä sanonutkin sitä että Delphi on käytännössä kuollut viritelmä ollut sieltä jostain vuodesta 2006..2009 ajoista lähtien sattuneista syistä johtuen.

Nyt Windows 10 aikoina se on aika kallis myös.

Lue lisää

Suomalaisen maahantuojan sivuilla http://moonsoft.fi/products/000479.aspx Delphin 10.1 version päivityshinta liikkuu
- Delphi 10.1 Berlin Architect 1 Named User Upgrade 4 601,00 € 5 705,24 €
- Delphi 10.1 Berlin Enterprise 1 Named User Upgrade 2 797,00 € 3 468,28 €
- Delphi 10.1 Berlin Professional 1 Named User Upgrade 1 053,00 € 1 305,72 €

Noista voi kuka tahansa laskea kuinka monta firman sisäistä laskutustuntia se maksaa.

Jaa eikö Delphi olekkaan enää "Xe" =D, en ole seurannut vuosiin tuon kehitystä. Järkyttävät hinnat kyllä, olisi paras lääke tuollekkin kun pistäisivät open-sourceksi.

hintatietoa kirjoitti:

Suomalaisen maahantuojan sivuilla http://moonsoft.fi/products/000479.aspx Delphin 10.1 version päivityshinta liikkuu
- Delphi 10.1 Berlin Architect 1 Named User Upgrade 4 601,00 € 5 705,24 €
- Delphi 10.1 Berlin Enterprise 1 Named User Upgrade 2 797,00 € 3 468,28 €
- Delphi 10.1 Berlin Professional 1 Named User Upgrade 1 053,00 € 1 305,72 €

Noista voi kuka tahansa laskea kuinka monta firman sisäistä laskutustuntia se maksaa.

Lue lisää

Vähän selvemmin sanottua, tällaiset vuosimaksut:

Starter: 328.60€
Professional: 1,305.72€
Enterprise: 3,468.28€
Architect: 5,705.24€

Ja sitten tuo juttu, että lisenssit on samanaikaisten käyttäjien mukaan. Käytännössä vuosimaksu per kehittäjä.

Jotkut muuten vissiin luulee, että olisi pitänyt Delphiä jotenkin paskana aikoinaan mutta itsehän pidin tästä silloin 90-luvulla ja vielä viime vuosikymmenen alussa tehty Delphi 7 oli oikein hyvä. Aika vaan meni ohitse tuosta. Tuo ei vaan ole ollut oikein millään mittarilla perusteltu valinta uusiin projekteihin tyyliin kymmeneen vuoteen.

Embarcaderolla ne tietää tämän. Ne vaan lypsää siitä mitä saa ja kerran spämmiosoitteella rekisteröidyin sinne jotain 3v sitten tutkiakseni jotain trialia tms. niin spämmiä tuli sitten joka päivä.

Ihan kauheata se touhu. Pakko niiden hintojen olla tuollaiset että pystyvät palkkoja maksamaan.

M-Kar kirjoitti:

Vähän selvemmin sanottua, tällaiset vuosimaksut:

Starter: 328.60€
Professional: 1,305.72€
Enterprise: 3,468.28€
Architect: 5,705.24€

Ja sitten tuo juttu, että lisenssit on samanaikaisten käyttäjien mukaan. Käytännössä vuosimaksu per kehittäjä.

Jotkut muuten vissiin luulee, että olisi pitänyt Delphiä jotenkin paskana aikoinaan mutta itsehän pidin tästä silloin 90-luvulla ja vielä viime vuosikymmenen alussa tehty Delphi 7 oli oikein hyvä. Aika vaan meni ohitse tuosta. Tuo ei vaan ole ollut oikein millään mittarilla perusteltu valinta uusiin projekteihin tyyliin kymmeneen vuoteen.

Embarcaderolla ne tietää tämän. Ne vaan lypsää siitä mitä saa ja kerran spämmiosoitteella rekisteröidyin sinne jotain 3v sitten tutkiakseni jotain trialia tms. niin spämmiä tuli sitten joka päivä.

Ihan kauheata se touhu. Pakko niiden hintojen olla tuollaiset että pystyvät palkkoja maksamaan.

Lue lisää

Niin näiden lisäksi tulevat eri kaupallisista komponenteista tulevat maksut (jos sellaisia käytetään). Nuo kaupalliset delphi-komponentit ovat oma ohjelmistoteollisuuden haara.

Eli noista maksuista voi päätellä että Delphi käyttäjät ovat harvoin harrastajia

Combo kirjoitti:

Niin näiden lisäksi tulevat eri kaupallisista komponenteista tulevat maksut (jos sellaisia käytetään). Nuo kaupalliset delphi-komponentit ovat oma ohjelmistoteollisuuden haara.

Eli noista maksuista voi päätellä että Delphi käyttäjät ovat harvoin harrastajia

Lue lisää

No niitä maksullisia komponentteja nyt on riippumatta kehitysvälineestä ja myös komponentteja jotka ovat riippumattomia kehitysvälineestä jossa niitä voidaan käyttää.

Nuo maksut ovat sellaisia, että ei sitä käytä oikein kukaan muukaan kun maksutta saa parempiakin. Ne rahastaa sillä, että vanhoja Delphiohjelmia ylläpidetään.

M-Kar kirjoitti:

Vähän selvemmin sanottua, tällaiset vuosimaksut:

Starter: 328.60€
Professional: 1,305.72€
Enterprise: 3,468.28€
Architect: 5,705.24€

Ja sitten tuo juttu, että lisenssit on samanaikaisten käyttäjien mukaan. Käytännössä vuosimaksu per kehittäjä.

Jotkut muuten vissiin luulee, että olisi pitänyt Delphiä jotenkin paskana aikoinaan mutta itsehän pidin tästä silloin 90-luvulla ja vielä viime vuosikymmenen alussa tehty Delphi 7 oli oikein hyvä. Aika vaan meni ohitse tuosta. Tuo ei vaan ole ollut oikein millään mittarilla perusteltu valinta uusiin projekteihin tyyliin kymmeneen vuoteen.

Embarcaderolla ne tietää tämän. Ne vaan lypsää siitä mitä saa ja kerran spämmiosoitteella rekisteröidyin sinne jotain 3v sitten tutkiakseni jotain trialia tms. niin spämmiä tuli sitten joka päivä.

Ihan kauheata se touhu. Pakko niiden hintojen olla tuollaiset että pystyvät palkkoja maksamaan.

Lue lisää

("Vähän selvemmin sanottua, tällaiset vuosimaksut:")

Mitä vittua sinä höriset vuosimaksista. Lopeta se paskan puhuminen. Saatanan taukki ei ymmärrä hevonpersettä asioista kunhan vaan säheltää mitä sattuun.

Perkele-mikä-urpo kirjoitti:

("Vähän selvemmin sanottua, tällaiset vuosimaksut:")

Mitä vittua sinä höriset vuosimaksista. Lopeta se paskan puhuminen. Saatanan taukki ei ymmärrä hevonpersettä asioista kunhan vaan säheltää mitä sattuun.

Lue lisää

Delphin julkaisujen tuki on 18kk, uusi julkaisu vuosittain ja tuo on päivityssumma. Se on siis vuosimaksu!

Täälläkin Delphi tyypit ovat sanoneet kuinka Delphin VCL kääntää koodia Windows API:a vasten eikä .NET:iä tai muuta vastaavaa vakaana pidettävää. Windows API taas voi muuttua pari kertaa vuodessa Windows 10:ssä joten ainoa lupaus toimivuudelle on se Delphissä oleva tuki.

Joka vuosi siis tarvisee päivittää.

M-Kar kirjoitti:

Delphin julkaisujen tuki on 18kk, uusi julkaisu vuosittain ja tuo on päivityssumma. Se on siis vuosimaksu!

Täälläkin Delphi tyypit ovat sanoneet kuinka Delphin VCL kääntää koodia Windows API:a vasten eikä .NET:iä tai muuta vastaavaa vakaana pidettävää. Windows API taas voi muuttua pari kertaa vuodessa Windows 10:ssä joten ainoa lupaus toimivuudelle on se Delphissä oleva tuki.

Joka vuosi siis tarvisee päivittää.

Lue lisää

Ei mikään pakota käyttämään VCL:ää, VCL:stä voi käyttää vain osia jne
Toki VCL on vakiona Delphin mukana. (ja VCL.n käyttö on helppoa)

VCL kirjoitti:

Ei mikään pakota käyttämään VCL:ää, VCL:stä voi käyttää vain osia jne
Toki VCL on vakiona Delphin mukana. (ja VCL.n käyttö on helppoa)

Niin onhan siellä uudempi Firemonkey esimerkiksi mutta pääasia tällä nyt onkin se, että mitä Windowsin rajapintaa vasten se koodi käännetään.

Jos se koodi käännetään .NET:iä vasten niin tiedetään sen jatkuvuus mutta jos se oksentaa ulos jonkun vanhaa Windows API:a käyttävän .exe filen niin sitten tarvitsee maksaa vuosimaksua Delphistä koska vanha Windows API ei ole luvatusti vakaa vaan muutoksessa.

Itse aion tänä vuonna kääntää useita ohjelmia Delphi 7:lla.

Ja aion ajaa niitä ohjelmia vuonna 2050, sellaisenaan ilman, että sitä NYT tehtyä .exe -tiedostoa tarvitsee muuttaa yhtään mitenkään.

Jää nähtäväksi, toimiiko Windows 10:llä vai ei.

Mutta se on varmaa, että toimii:

Windows 2000
Windows XP
Windows Vista
Windows 7
Windows 8
Windows 8.1

.net on aivan väärä alusta kääntää yhtän mitään!

Delphi 8.0 oli tehty kääntämään ohjelmia .net 1.0:lle.

Tuetaanko tuota .net 1.0:aa vielä jossain/jollain tavalla?

Jos vastaus on "ei tueta", niin .net on pelkkä järjettömyys.

Aivan, niinkuin .net 1.0:aa ei enää tueta, niin vaikkapa .net 3.0:n tuki varmasti loppuu myös joskus.

Haluatko sinä sellaisen maailman, että nyt .net 3.0:lle tekemäsi koodi joudutaan jossain vaiheessa pakkopäivittämään ensin .net 10.0:lle, ja myöhemmin vielä uudelleen .net 15.0:lle ?

Se, että .net 1.0 -tuki on lopetettu on hyvä osoitus siitä, että .net 4.0 on jonain päivänä myös täysin vanhentunut, ja sen tuki lopetetaan.

Sensijaan Windows 32 API on täysin toimiva niin kauan, kun 32 -bittisiä windows EXEjä ylipäätään tuetaan. Ja sinä päivänä, kun ei enää tueta, aion ostaa siinä vaiheessa uusimman Delphin (olipa se sitten 64- tai 128 -bittinen) ja kääntää sillä Delphi -lähdekoodit uusiksi.

Sen jälkeen Windows 64 API on ihan yhtä pätevä kuin Windows 32 API on ollut tähän saakka.

veikkaanpa, että M-Kar saa tulonsa siitä, kun jotain Delphin kanssa kilpailevaa ohjelmistotyövälinettä joko myydään, tai, jos kysessä on ilmainen väline, niin siitä, kun sinänsä ilmaiselle välineelle myydään maksullista tukea.

Siksi M-Kar ei voi sietää Delphi -ohjelmoinnin helppoutta, se kun uhkaa hänen omia ansioitaan !

delphi_rules kirjoitti:

Itse aion tänä vuonna kääntää useita ohjelmia Delphi 7:lla.

Ja aion ajaa niitä ohjelmia vuonna 2050, sellaisenaan ilman, että sitä NYT tehtyä .exe -tiedostoa tarvitsee muuttaa yhtään mitenkään.

Jää nähtäväksi, toimiiko Windows 10:llä vai ei.

Mutta se on varmaa, että toimii:

Windows 2000
Windows XP
Windows Vista
Windows 7
Windows 8
Windows 8.1

.net on aivan väärä alusta kääntää yhtän mitään!

Delphi 8.0 oli tehty kääntämään ohjelmia .net 1.0:lle.

Tuetaanko tuota .net 1.0:aa vielä jossain/jollain tavalla?

Jos vastaus on "ei tueta", niin .net on pelkkä järjettömyys.

Aivan, niinkuin .net 1.0:aa ei enää tueta, niin vaikkapa .net 3.0:n tuki varmasti loppuu myös joskus.

Haluatko sinä sellaisen maailman, että nyt .net 3.0:lle tekemäsi koodi joudutaan jossain vaiheessa pakkopäivittämään ensin .net 10.0:lle, ja myöhemmin vielä uudelleen .net 15.0:lle ?

Se, että .net 1.0 -tuki on lopetettu on hyvä osoitus siitä, että .net 4.0 on jonain päivänä myös täysin vanhentunut, ja sen tuki lopetetaan.

Sensijaan Windows 32 API on täysin toimiva niin kauan, kun 32 -bittisiä windows EXEjä ylipäätään tuetaan. Ja sinä päivänä, kun ei enää tueta, aion ostaa siinä vaiheessa uusimman Delphin (olipa se sitten 64- tai 128 -bittinen) ja kääntää sillä Delphi -lähdekoodit uusiksi.

Sen jälkeen Windows 64 API on ihan yhtä pätevä kuin Windows 32 API on ollut tähän saakka.

veikkaanpa, että M-Kar saa tulonsa siitä, kun jotain Delphin kanssa kilpailevaa ohjelmistotyövälinettä joko myydään, tai, jos kysessä on ilmainen väline, niin siitä, kun sinänsä ilmaiselle välineelle myydään maksullista tukea.

Siksi M-Kar ei voi sietää Delphi -ohjelmoinnin helppoutta, se kun uhkaa hänen omia ansioitaan !

Lue lisää

"Itse aion tänä vuonna kääntää useita ohjelmia Delphi 7:lla.

Ja aion ajaa niitä ohjelmia vuonna 2050, sellaisenaan ilman, että sitä NYT tehtyä .exe -tiedostoa tarvitsee muuttaa yhtään mitenkään."

Eivät toimi koska Delphi 7 ei käännä sellaiselle rajapinnalle mikä olisi tuettuna.

"Jää nähtäväksi, toimiiko Windows 10:llä vai ei.

Mutta se on varmaa, että toimii:

Windows 2000
Windows XP
Windows Vista
Windows 7
Windows 8
Windows 8.1"

Nuo ovat kaikki kadonneet vuonna 2050 ja yhteensopimattomia.

Pisimmälle pääsee Windows 7 Embedded, vuoteen 2025 saakka, kun käyttää erityishintaisia Windows 7 yhteensopivia laitteita hankkii niitä erityishintaisia Windows 7 Embedded lisenssejä. Nettiä nissä ei tietenkään voi käyttää koska niitä ei saa päivitettyä.

Seuraavaksi pisimmälle pääsee Windows 8.1 vuoteen 2023 saakka ja normi Windows 7 2020 saakka.

Toki kannattaa huomioida se, että kaikkien muiden versioiden paitsi embeddedin myynti häviää melko tehokkaasti puolen vuoden kuluttuja jo, ja sitten saa pari vuotta pelleillä jonkun downgraden kanssa kunnes sekin mahdollisuus katoaa.

"Delphi 8.0 oli tehty kääntämään ohjelmia .net 1.0:lle. Tuetaanko tuota .net 1.0:aa vielä jossain/jollain tavalla?"

Ei tietenkään. Ei myöskään tueta Delphi 7:aa siksi sillä ei voi tehdä Windows ohjelmia jotka toimisi Windows API:n kanssa nykypäivänä.

Delphillä jos haluaa tehdä nykyaikana toimivia Windowssovelluksia niin sen pitää olla uusin versio Delphistä ja päivittää joka vuosi uudempaan.

"Sensijaan Windows 32 API on täysin toimiva niin kauan, kun 32 -bittisiä windows EXEjä ylipäätään tuetaan."

Niiden yhteensopivuus muuttuu kaiken aikaa.

2000->XP->Vista->7->8 ->Windows 10 2015 kesä->Windows 10 2015 talvi -> Windows 10 2016 kesä

Delphi 7 kun tuli XP:ssä niin se yhteensopivuus muuttunut kuusi kertaa ja muuttuu jatkossakin kaksi kertaa vuodessa ja jokainen näistä muutoksista rikkoo puhtaasti 32-bit Windows API:a vasten tehtyjä ohjelmia. Joku muutos rikkoo tai on rikkonut jo kaikki Delphi 7 ohjelmat.

Sinulla on Delphi selvästikin tuhonnut järjenjuoksun kun kuvittelet 32-bittisen Windows API:n pysyvän jotenkin samanlaisena. Tosiasia on, että se .NET pysyy samanlaisena aina vähintään 10v. Windows API ei pysy vaan rikkoutuvaa muutosta voi tapahtua nykyään 2x vuodessa.

"veikkaanpa, että M-Kar saa tulonsa siitä, kun jotain Delphin kanssa kilpailevaa ohjelmistotyövälinettä joko myydään, tai, jos kysessä on ilmainen väline, niin siitä, kun sinänsä ilmaiselle välineelle myydään maksullista tukea."

Ei ole mitään tällaista. Minä haluan että ohjelmistojen tekijät lopettavat suomen talouden tuhoamisen tekemällä heikkolaatuisia Delphiohjelmia.

Kannatan sellaista lakia, että ohjelmiston tekijä sitoutuu siihen, että sen tekemä ohjelma toimii vähintään N vuotta. Mikäli ohjelma lakkaa toimimasta ennenaikaisesti, ohjelmiston tekemiseen menneet rahat pitää voida periä ohjelmiston tekijältä ulosottokelpoisesti.

Vastaavalla tavalla kannatan sellaista lakia, että kiinteistöjen omistajat joissa asukkaat saavat asumistukea, pitää sitoutua huoltamaan sitä kiinteistöä tai asukkaiden saamat asumistuet pitää olla perittävissä ulosottokelpoisesti vaikka viiden vuoden ajalta. Eihän se nyt vetele, että jätetään putkirempat ja vastaavat tekemättä ja lihotetaan vaan omaa tiliä välillisesti verovaroilla.

Tuollaiset lait voimaan niin alkaa ehkä vähän enemmän kiinnostamaan se oman tekemisen jälki ja jää ne roskaohjelmat tekemättä ja pysyy kiinteistöt kunnossa.

Ja minä kannatan sellaista lakia, että ohjelmiston tekijä sitoutuu siihen, että sen tekemä ohjelma toimii ILMAN puskurin ylivuotovirheitä vähintään 50 vuotta. Mikäli ohjelma ennen tämän ajan umpeutumista päästää rikollisen krakkerin puskurin ylivuotohaavoittuvuuden takia läpi suojauksista, ohjelmiston tekemiseen menneet rahat pitää voida periä ohjelmiston tekijältä ulosottokelpoisesti.

delphikoodaaja kirjoitti:

Ja minä kannatan sellaista lakia, että ohjelmiston tekijä sitoutuu siihen, että sen tekemä ohjelma toimii ILMAN puskurin ylivuotovirheitä vähintään 50 vuotta. Mikäli ohjelma ennen tämän ajan umpeutumista päästää rikollisen krakkerin puskurin ylivuotohaavoittuvuuden takia läpi suojauksista, ohjelmiston tekemiseen menneet rahat pitää voida periä ohjelmiston tekijältä ulosottokelpoisesti.

Lue lisää

Virheetöntä koodia on nykyisellään mahdotonta vaatia koska ihmiset eivät osaa kirjoittaa virheettömiä ohjelmia.

Sen sijaan voidaan vaatia ongelmiin reagointia ja sitä, että toimii luvatulla tavalla luvatun aikaa eikä lopeta toimintaansa yks kaks.

delphikoodaaja kirjoitti:

Ja minä kannatan sellaista lakia, että ohjelmiston tekijä sitoutuu siihen, että sen tekemä ohjelma toimii ILMAN puskurin ylivuotovirheitä vähintään 50 vuotta. Mikäli ohjelma ennen tämän ajan umpeutumista päästää rikollisen krakkerin puskurin ylivuotohaavoittuvuuden takia läpi suojauksista, ohjelmiston tekemiseen menneet rahat pitää voida periä ohjelmiston tekijältä ulosottokelpoisesti.

Lue lisää

Ja kannattaa ymmärtää se pointti, että puskurin ylivuoto on virhe siinä missä mikä tahansa muukin virhe joten on naurettavaa käydä tuollaisiin takertumaan.

Etenkin kun mitään puskurin ylivuotovirheitä ei käytännössä ole tehty mihinkään sovellukseen viimeisen 18v aikana.

M-Kar: "Etenkin kun mitään puskurin ylivuotovirheitä ei käytännössä ole tehty mihinkään sovellukseen viimeisen 18v aikana."

Niin, vastahan keväällä 2014 löytyi OpenSSL -kirjastosta puskurin ylivuotovirhe, jonka seuraus käytännössä oli HeartBleed -haavoittuvuus.

Tästä on siis aikaa noin 2 vuotta 6 kuukautta, eli vuosina 2.5.

Matemaattisesti 18v > 2.5, joten väitteesi on väärä.

Ja jos vetoat siihen, ettei OpenSSL ole sovellus, vaan dynaaminen linkkikirjasto (windowsissa DLL, linuxissa .so) niin kyllähän tuollainen dynaaminen linkkikirjasto ladataan suoritusaikaisesti sovelluksen osaksi. Itseasiassa kirjaston haavoittuvuus on jopa pahempi, koska se koskee yhden sijasta useita sovelluksia.

Asia vaan on niin, että C ja C -koodaajat kirjoittavat puskurin ylivuotovirheitä jatkuvalla syötöllä, joten niin kauan kuin C ja C -kielten käyttöä ohjelmistokehitytyössä jatketaan, puskurin ylivuotovirheitä tulee aina olemaan.

Sensijaan Delphillä on helppo kirjoittaa sovelluksia, joissa ei ole puskurin ylivuotovirheitä, eikä näinollen niistä johtuvia haavoittuvuuksiakaan.

MIKÄLI väitteesi siitä, että Windows 10 päivittää itseään automaattisesti siten, että joku yli 10 vuotta windowsiin kuulunut API -kutsu yhtäkkiä poistuu (eli se ei enää jatkoss aole osa esim. uutta päivittyä versiota olevassa kernel32.dll -kirjastossa), niin silloin ainoa oikea johtopäätös on tämä: kenenkään ei pitäisi missään käyttää Windows 10 -käyttöjärjestelmää.

Windows on näihin päiviin saakka ollut linuxjakeluja parempi juuri siksi, että kerran oikein tehty windows EXE on sellaisenaan toiminut windows -versiosta toiseen ilman mitään muutoksia.

Linuxissa taas esim. ubuntu 7.10:lle oikein tehty sovellus ei välttämättä toimi oikein tai edes ollenkaan ubuntu 16.04:ssä.

Mutta jos Microsoft todella on rikkonut tämän kaikissa muissa windows -versioissa olleen periaatteen Windows 10:ssä, silloin ei kenenkään pitäisi Windows 10:ä käyttää.

"Ja kannattaa ymmärtää se pointti, että puskurin ylivuoto on virhe siinä missä mikä tahansa muukin virhe joten on naurettavaa käydä tuollaisiin takertumaan."

Miksi olisi suurempi virhe koodata Delphillä tietoturvallinen ohjelma, joka toimii kaikissa nykyisissä Windows -versioissa oikein, ja lakkaa toimimasta vain siinä tapauksessa, että Microsoft todella poistaisi vaikkapa GetDC -funktiokutsun GDI32.DLL -kirjastosta ?

Ja silti itse olet valmis hyväksymään C:llä tai C :lla tehdyn koodin, joka sisältää yhden tai useamman puskurin ylivuotovirheen ?

Puskurin ylivuotovirhe on vakava asia. Sellainen johtaa onnistuneisiin tietovarkauksiin, sillä voidaan varastaa esimerkiksi:

Käyttäjätunnuksia
Salasanoja
Salausavaimia
Pankkitunnuksia
Luotto- tai debit -korttien numeroita, CVV -koodeja ja voimassaoloaikoja.

Näillä varastetuilla tiedoilla rikollisten on helppo varastaa myös rahaa tao rahanarvoista tavaraa tilaamalla nettikaupasta, laittomasti kopioidun luottokortin numerolla.

Kun koodaa Delphillä (ja käyttää Delphiä oikein), ei ohjelmassa ole tällaisia haavoittuvuuksia.

Sensijaan vastoin vääriä väitteitäsi, viimeisessä löydetyssä puskurin ylivuotovirheessä oli kyse C:llä ja/tai C :lla tehdystä koodista, eikä siitä ole aikaa yli 18 vuotta kuten väität, vaan vain n. 2.5 vuotta.

M-Kar levittää näillä palstoilla useita vääriä tietoja.

Yksi siis on se, että viimeisestä C/C -koodista löydetystä puskurin ylivuotovirheestä olisi yli 18 vuotta, kun totuus on 2.5 vuotta, jollei sitten tuon HeartBleed -tapauksen jälkeen ole löytynyt muitakin vastaavia.

Delphillä koodatessa kun kirjottaa ohjelman ja jokaisen ohjelmassa köytetyn UNITin alkuun {$R } niin mahdollinen puskurin ylivuotovirhe yleensä johtaa joko poikkeukseen tai Runtime erroriin.

Ohjelma ei siis jatka toimintaansa ikään kun mitään ei olisi pielessä.

Toki, ei Delphissäkään ole tarkoitus kirjoittaa huolettomasti koodia jossa on em. kaltaisia virheitä. Tuo {$R } -kääntäjäoptio ei siis ole huolellisen koodaustyön korvike, vaan se on ns. viimeinen hätävara, joka lopettaa ohjelmansuorituksen sen sijaan, että sallisi verkkorikollisten varastaa tietoja, siis siinä epätodennäköisessä tapauksessa, että ohjelmoija kaikesta huolimatta tekisi vastaavanlaisen vakavan virheen, joka C -ohjelmissa johtaa puskurin ylivuototilanteeseen, ja sitä myötä sallii verkkorikollisille helpot tietovarkaudet.

Toki Delphi selkeä syntaksi on huomattava kilpailuetu Delphi -koodaajalle, jos verrataan C tai C -koodaajaan.

C ja C -koodaajan aivokapasiteetista kun menee huomattavan suuri osa sekavan ja harhaanjohtavan syntaksin kanssa tappeluun, niin sitte ei enää aina riitä tarpeeksi aivokapasiteettia oikein toimivan ohjelman kirjoittamiseen.

Delphissä taas on selkeä ja hyvin suunniteltu syntaksi, joka mahdollistaa sen, että Delphi -koodaajan aivokapasiteetista kaikki menee oikein toimivan ohjelman kirjoittamiseen, kun sitä ei tarvitse tuhlata toisarvoisiin tarkoituksiin, kuten huonon syntaksin kanssa tappeluun.

delphikoodaaja kirjoitti:

M-Kar: "Etenkin kun mitään puskurin ylivuotovirheitä ei käytännössä ole tehty mihinkään sovellukseen viimeisen 18v aikana."

Niin, vastahan keväällä 2014 löytyi OpenSSL -kirjastosta puskurin ylivuotovirhe, jonka seuraus käytännössä oli HeartBleed -haavoittuvuus.

Tästä on siis aikaa noin 2 vuotta 6 kuukautta, eli vuosina 2.5.

Matemaattisesti 18v > 2.5, joten väitteesi on väärä.

Ja jos vetoat siihen, ettei OpenSSL ole sovellus, vaan dynaaminen linkkikirjasto (windowsissa DLL, linuxissa .so) niin kyllähän tuollainen dynaaminen linkkikirjasto ladataan suoritusaikaisesti sovelluksen osaksi. Itseasiassa kirjaston haavoittuvuus on jopa pahempi, koska se koskee yhden sijasta useita sovelluksia.

Asia vaan on niin, että C ja C -koodaajat kirjoittavat puskurin ylivuotovirheitä jatkuvalla syötöllä, joten niin kauan kuin C ja C -kielten käyttöä ohjelmistokehitytyössä jatketaan, puskurin ylivuotovirheitä tulee aina olemaan.

Sensijaan Delphillä on helppo kirjoittaa sovelluksia, joissa ei ole puskurin ylivuotovirheitä, eikä näinollen niistä johtuvia haavoittuvuuksiakaan.

MIKÄLI väitteesi siitä, että Windows 10 päivittää itseään automaattisesti siten, että joku yli 10 vuotta windowsiin kuulunut API -kutsu yhtäkkiä poistuu (eli se ei enää jatkoss aole osa esim. uutta päivittyä versiota olevassa kernel32.dll -kirjastossa), niin silloin ainoa oikea johtopäätös on tämä: kenenkään ei pitäisi missään käyttää Windows 10 -käyttöjärjestelmää.

Windows on näihin päiviin saakka ollut linuxjakeluja parempi juuri siksi, että kerran oikein tehty windows EXE on sellaisenaan toiminut windows -versiosta toiseen ilman mitään muutoksia.

Linuxissa taas esim. ubuntu 7.10:lle oikein tehty sovellus ei välttämättä toimi oikein tai edes ollenkaan ubuntu 16.04:ssä.

Mutta jos Microsoft todella on rikkonut tämän kaikissa muissa windows -versioissa olleen periaatteen Windows 10:ssä, silloin ei kenenkään pitäisi Windows 10:ä käyttää.

"Ja kannattaa ymmärtää se pointti, että puskurin ylivuoto on virhe siinä missä mikä tahansa muukin virhe joten on naurettavaa käydä tuollaisiin takertumaan."

Miksi olisi suurempi virhe koodata Delphillä tietoturvallinen ohjelma, joka toimii kaikissa nykyisissä Windows -versioissa oikein, ja lakkaa toimimasta vain siinä tapauksessa, että Microsoft todella poistaisi vaikkapa GetDC -funktiokutsun GDI32.DLL -kirjastosta ?

Ja silti itse olet valmis hyväksymään C:llä tai C :lla tehdyn koodin, joka sisältää yhden tai useamman puskurin ylivuotovirheen ?

Puskurin ylivuotovirhe on vakava asia. Sellainen johtaa onnistuneisiin tietovarkauksiin, sillä voidaan varastaa esimerkiksi:

Käyttäjätunnuksia
Salasanoja
Salausavaimia
Pankkitunnuksia
Luotto- tai debit -korttien numeroita, CVV -koodeja ja voimassaoloaikoja.

Näillä varastetuilla tiedoilla rikollisten on helppo varastaa myös rahaa tao rahanarvoista tavaraa tilaamalla nettikaupasta, laittomasti kopioidun luottokortin numerolla.

Kun koodaa Delphillä (ja käyttää Delphiä oikein), ei ohjelmassa ole tällaisia haavoittuvuuksia.

Sensijaan vastoin vääriä väitteitäsi, viimeisessä löydetyssä puskurin ylivuotovirheessä oli kyse C:llä ja/tai C :lla tehdystä koodista, eikä siitä ole aikaa yli 18 vuotta kuten väität, vaan vain n. 2.5 vuotta.

M-Kar levittää näillä palstoilla useita vääriä tietoja.

Yksi siis on se, että viimeisestä C/C -koodista löydetystä puskurin ylivuotovirheestä olisi yli 18 vuotta, kun totuus on 2.5 vuotta, jollei sitten tuon HeartBleed -tapauksen jälkeen ole löytynyt muitakin vastaavia.

Delphillä koodatessa kun kirjottaa ohjelman ja jokaisen ohjelmassa köytetyn UNITin alkuun {$R } niin mahdollinen puskurin ylivuotovirhe yleensä johtaa joko poikkeukseen tai Runtime erroriin.

Ohjelma ei siis jatka toimintaansa ikään kun mitään ei olisi pielessä.

Toki, ei Delphissäkään ole tarkoitus kirjoittaa huolettomasti koodia jossa on em. kaltaisia virheitä. Tuo {$R } -kääntäjäoptio ei siis ole huolellisen koodaustyön korvike, vaan se on ns. viimeinen hätävara, joka lopettaa ohjelmansuorituksen sen sijaan, että sallisi verkkorikollisten varastaa tietoja, siis siinä epätodennäköisessä tapauksessa, että ohjelmoija kaikesta huolimatta tekisi vastaavanlaisen vakavan virheen, joka C -ohjelmissa johtaa puskurin ylivuototilanteeseen, ja sitä myötä sallii verkkorikollisille helpot tietovarkaudet.

Toki Delphi selkeä syntaksi on huomattava kilpailuetu Delphi -koodaajalle, jos verrataan C tai C -koodaajaan.

C ja C -koodaajan aivokapasiteetista kun menee huomattavan suuri osa sekavan ja harhaanjohtavan syntaksin kanssa tappeluun, niin sitte ei enää aina riitä tarpeeksi aivokapasiteettia oikein toimivan ohjelman kirjoittamiseen.

Delphissä taas on selkeä ja hyvin suunniteltu syntaksi, joka mahdollistaa sen, että Delphi -koodaajan aivokapasiteetista kaikki menee oikein toimivan ohjelman kirjoittamiseen, kun sitä ei tarvitse tuhlata toisarvoisiin tarkoituksiin, kuten huonon syntaksin kanssa tappeluun.

Lue lisää

Pikaisen testin tulos:

JOS taulukon rajoja ei kunnioiteta, silloin Delphi -sovellus automaattisesti generoi poikkeuksen ERangeError, viestillä 'Range check error' (Kun SysUtils -UNITia on käytetty).

JOS SysUtils -UNITia EI käytetä, johtaa tilanne Run -time erroriin.

delphikoodaaja kirjoitti:

M-Kar: "Etenkin kun mitään puskurin ylivuotovirheitä ei käytännössä ole tehty mihinkään sovellukseen viimeisen 18v aikana."

Niin, vastahan keväällä 2014 löytyi OpenSSL -kirjastosta puskurin ylivuotovirhe, jonka seuraus käytännössä oli HeartBleed -haavoittuvuus.

Tästä on siis aikaa noin 2 vuotta 6 kuukautta, eli vuosina 2.5.

Matemaattisesti 18v > 2.5, joten väitteesi on väärä.

Ja jos vetoat siihen, ettei OpenSSL ole sovellus, vaan dynaaminen linkkikirjasto (windowsissa DLL, linuxissa .so) niin kyllähän tuollainen dynaaminen linkkikirjasto ladataan suoritusaikaisesti sovelluksen osaksi. Itseasiassa kirjaston haavoittuvuus on jopa pahempi, koska se koskee yhden sijasta useita sovelluksia.

Asia vaan on niin, että C ja C -koodaajat kirjoittavat puskurin ylivuotovirheitä jatkuvalla syötöllä, joten niin kauan kuin C ja C -kielten käyttöä ohjelmistokehitytyössä jatketaan, puskurin ylivuotovirheitä tulee aina olemaan.

Sensijaan Delphillä on helppo kirjoittaa sovelluksia, joissa ei ole puskurin ylivuotovirheitä, eikä näinollen niistä johtuvia haavoittuvuuksiakaan.

MIKÄLI väitteesi siitä, että Windows 10 päivittää itseään automaattisesti siten, että joku yli 10 vuotta windowsiin kuulunut API -kutsu yhtäkkiä poistuu (eli se ei enää jatkoss aole osa esim. uutta päivittyä versiota olevassa kernel32.dll -kirjastossa), niin silloin ainoa oikea johtopäätös on tämä: kenenkään ei pitäisi missään käyttää Windows 10 -käyttöjärjestelmää.

Windows on näihin päiviin saakka ollut linuxjakeluja parempi juuri siksi, että kerran oikein tehty windows EXE on sellaisenaan toiminut windows -versiosta toiseen ilman mitään muutoksia.

Linuxissa taas esim. ubuntu 7.10:lle oikein tehty sovellus ei välttämättä toimi oikein tai edes ollenkaan ubuntu 16.04:ssä.

Mutta jos Microsoft todella on rikkonut tämän kaikissa muissa windows -versioissa olleen periaatteen Windows 10:ssä, silloin ei kenenkään pitäisi Windows 10:ä käyttää.

"Ja kannattaa ymmärtää se pointti, että puskurin ylivuoto on virhe siinä missä mikä tahansa muukin virhe joten on naurettavaa käydä tuollaisiin takertumaan."

Miksi olisi suurempi virhe koodata Delphillä tietoturvallinen ohjelma, joka toimii kaikissa nykyisissä Windows -versioissa oikein, ja lakkaa toimimasta vain siinä tapauksessa, että Microsoft todella poistaisi vaikkapa GetDC -funktiokutsun GDI32.DLL -kirjastosta ?

Ja silti itse olet valmis hyväksymään C:llä tai C :lla tehdyn koodin, joka sisältää yhden tai useamman puskurin ylivuotovirheen ?

Puskurin ylivuotovirhe on vakava asia. Sellainen johtaa onnistuneisiin tietovarkauksiin, sillä voidaan varastaa esimerkiksi:

Käyttäjätunnuksia
Salasanoja
Salausavaimia
Pankkitunnuksia
Luotto- tai debit -korttien numeroita, CVV -koodeja ja voimassaoloaikoja.

Näillä varastetuilla tiedoilla rikollisten on helppo varastaa myös rahaa tao rahanarvoista tavaraa tilaamalla nettikaupasta, laittomasti kopioidun luottokortin numerolla.

Kun koodaa Delphillä (ja käyttää Delphiä oikein), ei ohjelmassa ole tällaisia haavoittuvuuksia.

Sensijaan vastoin vääriä väitteitäsi, viimeisessä löydetyssä puskurin ylivuotovirheessä oli kyse C:llä ja/tai C :lla tehdystä koodista, eikä siitä ole aikaa yli 18 vuotta kuten väität, vaan vain n. 2.5 vuotta.

M-Kar levittää näillä palstoilla useita vääriä tietoja.

Yksi siis on se, että viimeisestä C/C -koodista löydetystä puskurin ylivuotovirheestä olisi yli 18 vuotta, kun totuus on 2.5 vuotta, jollei sitten tuon HeartBleed -tapauksen jälkeen ole löytynyt muitakin vastaavia.

Delphillä koodatessa kun kirjottaa ohjelman ja jokaisen ohjelmassa köytetyn UNITin alkuun {$R } niin mahdollinen puskurin ylivuotovirhe yleensä johtaa joko poikkeukseen tai Runtime erroriin.

Ohjelma ei siis jatka toimintaansa ikään kun mitään ei olisi pielessä.

Toki, ei Delphissäkään ole tarkoitus kirjoittaa huolettomasti koodia jossa on em. kaltaisia virheitä. Tuo {$R } -kääntäjäoptio ei siis ole huolellisen koodaustyön korvike, vaan se on ns. viimeinen hätävara, joka lopettaa ohjelmansuorituksen sen sijaan, että sallisi verkkorikollisten varastaa tietoja, siis siinä epätodennäköisessä tapauksessa, että ohjelmoija kaikesta huolimatta tekisi vastaavanlaisen vakavan virheen, joka C -ohjelmissa johtaa puskurin ylivuototilanteeseen, ja sitä myötä sallii verkkorikollisille helpot tietovarkaudet.

Toki Delphi selkeä syntaksi on huomattava kilpailuetu Delphi -koodaajalle, jos verrataan C tai C -koodaajaan.

C ja C -koodaajan aivokapasiteetista kun menee huomattavan suuri osa sekavan ja harhaanjohtavan syntaksin kanssa tappeluun, niin sitte ei enää aina riitä tarpeeksi aivokapasiteettia oikein toimivan ohjelman kirjoittamiseen.

Delphissä taas on selkeä ja hyvin suunniteltu syntaksi, joka mahdollistaa sen, että Delphi -koodaajan aivokapasiteetista kaikki menee oikein toimivan ohjelman kirjoittamiseen, kun sitä ei tarvitse tuhlata toisarvoisiin tarkoituksiin, kuten huonon syntaksin kanssa tappeluun.

Lue lisää

Hitto kun osaat selvittää asiat hyvin, ja paikansa pitävästi,
kiitän ja kumarran.

delphikoodaaja kirjoitti:

M-Kar: "Etenkin kun mitään puskurin ylivuotovirheitä ei käytännössä ole tehty mihinkään sovellukseen viimeisen 18v aikana."

Niin, vastahan keväällä 2014 löytyi OpenSSL -kirjastosta puskurin ylivuotovirhe, jonka seuraus käytännössä oli HeartBleed -haavoittuvuus.

Tästä on siis aikaa noin 2 vuotta 6 kuukautta, eli vuosina 2.5.

Matemaattisesti 18v > 2.5, joten väitteesi on väärä.

Ja jos vetoat siihen, ettei OpenSSL ole sovellus, vaan dynaaminen linkkikirjasto (windowsissa DLL, linuxissa .so) niin kyllähän tuollainen dynaaminen linkkikirjasto ladataan suoritusaikaisesti sovelluksen osaksi. Itseasiassa kirjaston haavoittuvuus on jopa pahempi, koska se koskee yhden sijasta useita sovelluksia.

Asia vaan on niin, että C ja C -koodaajat kirjoittavat puskurin ylivuotovirheitä jatkuvalla syötöllä, joten niin kauan kuin C ja C -kielten käyttöä ohjelmistokehitytyössä jatketaan, puskurin ylivuotovirheitä tulee aina olemaan.

Sensijaan Delphillä on helppo kirjoittaa sovelluksia, joissa ei ole puskurin ylivuotovirheitä, eikä näinollen niistä johtuvia haavoittuvuuksiakaan.

MIKÄLI väitteesi siitä, että Windows 10 päivittää itseään automaattisesti siten, että joku yli 10 vuotta windowsiin kuulunut API -kutsu yhtäkkiä poistuu (eli se ei enää jatkoss aole osa esim. uutta päivittyä versiota olevassa kernel32.dll -kirjastossa), niin silloin ainoa oikea johtopäätös on tämä: kenenkään ei pitäisi missään käyttää Windows 10 -käyttöjärjestelmää.

Windows on näihin päiviin saakka ollut linuxjakeluja parempi juuri siksi, että kerran oikein tehty windows EXE on sellaisenaan toiminut windows -versiosta toiseen ilman mitään muutoksia.

Linuxissa taas esim. ubuntu 7.10:lle oikein tehty sovellus ei välttämättä toimi oikein tai edes ollenkaan ubuntu 16.04:ssä.

Mutta jos Microsoft todella on rikkonut tämän kaikissa muissa windows -versioissa olleen periaatteen Windows 10:ssä, silloin ei kenenkään pitäisi Windows 10:ä käyttää.

"Ja kannattaa ymmärtää se pointti, että puskurin ylivuoto on virhe siinä missä mikä tahansa muukin virhe joten on naurettavaa käydä tuollaisiin takertumaan."

Miksi olisi suurempi virhe koodata Delphillä tietoturvallinen ohjelma, joka toimii kaikissa nykyisissä Windows -versioissa oikein, ja lakkaa toimimasta vain siinä tapauksessa, että Microsoft todella poistaisi vaikkapa GetDC -funktiokutsun GDI32.DLL -kirjastosta ?

Ja silti itse olet valmis hyväksymään C:llä tai C :lla tehdyn koodin, joka sisältää yhden tai useamman puskurin ylivuotovirheen ?

Puskurin ylivuotovirhe on vakava asia. Sellainen johtaa onnistuneisiin tietovarkauksiin, sillä voidaan varastaa esimerkiksi:

Käyttäjätunnuksia
Salasanoja
Salausavaimia
Pankkitunnuksia
Luotto- tai debit -korttien numeroita, CVV -koodeja ja voimassaoloaikoja.

Näillä varastetuilla tiedoilla rikollisten on helppo varastaa myös rahaa tao rahanarvoista tavaraa tilaamalla nettikaupasta, laittomasti kopioidun luottokortin numerolla.

Kun koodaa Delphillä (ja käyttää Delphiä oikein), ei ohjelmassa ole tällaisia haavoittuvuuksia.

Sensijaan vastoin vääriä väitteitäsi, viimeisessä löydetyssä puskurin ylivuotovirheessä oli kyse C:llä ja/tai C :lla tehdystä koodista, eikä siitä ole aikaa yli 18 vuotta kuten väität, vaan vain n. 2.5 vuotta.

M-Kar levittää näillä palstoilla useita vääriä tietoja.

Yksi siis on se, että viimeisestä C/C -koodista löydetystä puskurin ylivuotovirheestä olisi yli 18 vuotta, kun totuus on 2.5 vuotta, jollei sitten tuon HeartBleed -tapauksen jälkeen ole löytynyt muitakin vastaavia.

Delphillä koodatessa kun kirjottaa ohjelman ja jokaisen ohjelmassa köytetyn UNITin alkuun {$R } niin mahdollinen puskurin ylivuotovirhe yleensä johtaa joko poikkeukseen tai Runtime erroriin.

Ohjelma ei siis jatka toimintaansa ikään kun mitään ei olisi pielessä.

Toki, ei Delphissäkään ole tarkoitus kirjoittaa huolettomasti koodia jossa on em. kaltaisia virheitä. Tuo {$R } -kääntäjäoptio ei siis ole huolellisen koodaustyön korvike, vaan se on ns. viimeinen hätävara, joka lopettaa ohjelmansuorituksen sen sijaan, että sallisi verkkorikollisten varastaa tietoja, siis siinä epätodennäköisessä tapauksessa, että ohjelmoija kaikesta huolimatta tekisi vastaavanlaisen vakavan virheen, joka C -ohjelmissa johtaa puskurin ylivuototilanteeseen, ja sitä myötä sallii verkkorikollisille helpot tietovarkaudet.

Toki Delphi selkeä syntaksi on huomattava kilpailuetu Delphi -koodaajalle, jos verrataan C tai C -koodaajaan.

C ja C -koodaajan aivokapasiteetista kun menee huomattavan suuri osa sekavan ja harhaanjohtavan syntaksin kanssa tappeluun, niin sitte ei enää aina riitä tarpeeksi aivokapasiteettia oikein toimivan ohjelman kirjoittamiseen.

Delphissä taas on selkeä ja hyvin suunniteltu syntaksi, joka mahdollistaa sen, että Delphi -koodaajan aivokapasiteetista kaikki menee oikein toimivan ohjelman kirjoittamiseen, kun sitä ei tarvitse tuhlata toisarvoisiin tarkoituksiin, kuten huonon syntaksin kanssa tappeluun.

Lue lisää

"Niin, vastahan keväällä 2014 löytyi OpenSSL -kirjastosta puskurin ylivuotovirhe, jonka seuraus käytännössä oli HeartBleed -haavoittuvuus.

Tästä on siis aikaa noin 2 vuotta 6 kuukautta, eli vuosina 2.5.

Matemaattisesti 18v > 2.5, joten väitteesi on väärä."

OpenSSL on vuodelta 1998, eli 18v vanha.

Kyseessä on vanhan ohjelman reikä, eikä OpenSSL edes ole mikään sovellus vaan matalan tason kirjasto mitä käytetään käyttöjärjestelmissä.

"Ja jos vetoat siihen, ettei OpenSSL ole sovellus, vaan dynaaminen linkkikirjasto (windowsissa DLL, linuxissa .so) niin kyllähän tuollainen dynaaminen linkkikirjasto ladataan suoritusaikaisesti sovelluksen osaksi."

Mutta se ei ole sovelluksessa olevaa koodia vaan systeemitason koodia.

"Asia vaan on niin, että C ja C -koodaajat kirjoittavat puskurin ylivuotovirheitä jatkuvalla syötöllä, joten niin kauan kuin C ja C -kielten käyttöä ohjelmistokehitytyössä jatketaan, puskurin ylivuotovirheitä tulee aina olemaan."

C kieli on C ABI:n takia defacto systeemitason koodissa ja sille ei käytännössä ole vaihtoehtoja. Sovellusohjelmointi on täysin eri asia. C taas on täysin eri kieli kuin C ja eihän siinä C :ssa oikein tule mitään puskuriylivuotoja kun on reunatarkistukset.

"Sensijaan Delphillä on helppo kirjoittaa sovelluksia, joissa ei ole puskurin ylivuotovirheitä, eikä näinollen niistä johtuvia haavoittuvuuksiakaan."

Kuten muillakin työkaluilla.

delphikoodaaja kirjoitti:

M-Kar: "Etenkin kun mitään puskurin ylivuotovirheitä ei käytännössä ole tehty mihinkään sovellukseen viimeisen 18v aikana."

Niin, vastahan keväällä 2014 löytyi OpenSSL -kirjastosta puskurin ylivuotovirhe, jonka seuraus käytännössä oli HeartBleed -haavoittuvuus.

Tästä on siis aikaa noin 2 vuotta 6 kuukautta, eli vuosina 2.5.

Matemaattisesti 18v > 2.5, joten väitteesi on väärä.

Ja jos vetoat siihen, ettei OpenSSL ole sovellus, vaan dynaaminen linkkikirjasto (windowsissa DLL, linuxissa .so) niin kyllähän tuollainen dynaaminen linkkikirjasto ladataan suoritusaikaisesti sovelluksen osaksi. Itseasiassa kirjaston haavoittuvuus on jopa pahempi, koska se koskee yhden sijasta useita sovelluksia.

Asia vaan on niin, että C ja C -koodaajat kirjoittavat puskurin ylivuotovirheitä jatkuvalla syötöllä, joten niin kauan kuin C ja C -kielten käyttöä ohjelmistokehitytyössä jatketaan, puskurin ylivuotovirheitä tulee aina olemaan.

Sensijaan Delphillä on helppo kirjoittaa sovelluksia, joissa ei ole puskurin ylivuotovirheitä, eikä näinollen niistä johtuvia haavoittuvuuksiakaan.

MIKÄLI väitteesi siitä, että Windows 10 päivittää itseään automaattisesti siten, että joku yli 10 vuotta windowsiin kuulunut API -kutsu yhtäkkiä poistuu (eli se ei enää jatkoss aole osa esim. uutta päivittyä versiota olevassa kernel32.dll -kirjastossa), niin silloin ainoa oikea johtopäätös on tämä: kenenkään ei pitäisi missään käyttää Windows 10 -käyttöjärjestelmää.

Windows on näihin päiviin saakka ollut linuxjakeluja parempi juuri siksi, että kerran oikein tehty windows EXE on sellaisenaan toiminut windows -versiosta toiseen ilman mitään muutoksia.

Linuxissa taas esim. ubuntu 7.10:lle oikein tehty sovellus ei välttämättä toimi oikein tai edes ollenkaan ubuntu 16.04:ssä.

Mutta jos Microsoft todella on rikkonut tämän kaikissa muissa windows -versioissa olleen periaatteen Windows 10:ssä, silloin ei kenenkään pitäisi Windows 10:ä käyttää.

"Ja kannattaa ymmärtää se pointti, että puskurin ylivuoto on virhe siinä missä mikä tahansa muukin virhe joten on naurettavaa käydä tuollaisiin takertumaan."

Miksi olisi suurempi virhe koodata Delphillä tietoturvallinen ohjelma, joka toimii kaikissa nykyisissä Windows -versioissa oikein, ja lakkaa toimimasta vain siinä tapauksessa, että Microsoft todella poistaisi vaikkapa GetDC -funktiokutsun GDI32.DLL -kirjastosta ?

Ja silti itse olet valmis hyväksymään C:llä tai C :lla tehdyn koodin, joka sisältää yhden tai useamman puskurin ylivuotovirheen ?

Puskurin ylivuotovirhe on vakava asia. Sellainen johtaa onnistuneisiin tietovarkauksiin, sillä voidaan varastaa esimerkiksi:

Käyttäjätunnuksia
Salasanoja
Salausavaimia
Pankkitunnuksia
Luotto- tai debit -korttien numeroita, CVV -koodeja ja voimassaoloaikoja.

Näillä varastetuilla tiedoilla rikollisten on helppo varastaa myös rahaa tao rahanarvoista tavaraa tilaamalla nettikaupasta, laittomasti kopioidun luottokortin numerolla.

Kun koodaa Delphillä (ja käyttää Delphiä oikein), ei ohjelmassa ole tällaisia haavoittuvuuksia.

Sensijaan vastoin vääriä väitteitäsi, viimeisessä löydetyssä puskurin ylivuotovirheessä oli kyse C:llä ja/tai C :lla tehdystä koodista, eikä siitä ole aikaa yli 18 vuotta kuten väität, vaan vain n. 2.5 vuotta.

M-Kar levittää näillä palstoilla useita vääriä tietoja.

Yksi siis on se, että viimeisestä C/C -koodista löydetystä puskurin ylivuotovirheestä olisi yli 18 vuotta, kun totuus on 2.5 vuotta, jollei sitten tuon HeartBleed -tapauksen jälkeen ole löytynyt muitakin vastaavia.

Delphillä koodatessa kun kirjottaa ohjelman ja jokaisen ohjelmassa köytetyn UNITin alkuun {$R } niin mahdollinen puskurin ylivuotovirhe yleensä johtaa joko poikkeukseen tai Runtime erroriin.

Ohjelma ei siis jatka toimintaansa ikään kun mitään ei olisi pielessä.

Toki, ei Delphissäkään ole tarkoitus kirjoittaa huolettomasti koodia jossa on em. kaltaisia virheitä. Tuo {$R } -kääntäjäoptio ei siis ole huolellisen koodaustyön korvike, vaan se on ns. viimeinen hätävara, joka lopettaa ohjelmansuorituksen sen sijaan, että sallisi verkkorikollisten varastaa tietoja, siis siinä epätodennäköisessä tapauksessa, että ohjelmoija kaikesta huolimatta tekisi vastaavanlaisen vakavan virheen, joka C -ohjelmissa johtaa puskurin ylivuototilanteeseen, ja sitä myötä sallii verkkorikollisille helpot tietovarkaudet.

Toki Delphi selkeä syntaksi on huomattava kilpailuetu Delphi -koodaajalle, jos verrataan C tai C -koodaajaan.

C ja C -koodaajan aivokapasiteetista kun menee huomattavan suuri osa sekavan ja harhaanjohtavan syntaksin kanssa tappeluun, niin sitte ei enää aina riitä tarpeeksi aivokapasiteettia oikein toimivan ohjelman kirjoittamiseen.

Delphissä taas on selkeä ja hyvin suunniteltu syntaksi, joka mahdollistaa sen, että Delphi -koodaajan aivokapasiteetista kaikki menee oikein toimivan ohjelman kirjoittamiseen, kun sitä ei tarvitse tuhlata toisarvoisiin tarkoituksiin, kuten huonon syntaksin kanssa tappeluun.

Lue lisää

"Windows on näihin päiviin saakka ollut linuxjakeluja parempi juuri siksi, että kerran oikein tehty windows EXE on sellaisenaan toiminut windows -versiosta toiseen ilman mitään muutoksia."

Tämä nyt on täysin käyttöjärjestelmäkohtainen asia eikä liity millään tavalla Linuxiin

"Linuxissa taas esim. ubuntu 7.10:lle oikein tehty sovellus ei välttämättä toimi oikein tai edes ollenkaan ubuntu 16.04:ssä."

Linuxilla ei ole mitään tekemistä Ubuntun kanssa ja Ubuntu 7.10 oli kehitysversio. Vähän sama kuin selittäisit jostain Windows Vista beetaversion ohjelmien yhteensopivuudesta Windows 10:ssä.

Ubuntussa on ABI yhteensopivuutta toki huolehdittu omilla käytännöillään. Ubuntu 16.04 LTS:lle natiivisti tehdyt ohjelmat toimivat koko Ubuntu 16.04 LTS:n elinkaaren ajan 5v vaikka siihen päivityksiä tuleekin.

Ubuntussa on lisäksi aiemmin ollut käytäntöjä taaksepäinyhteensopivuudelle natiiviohjelmille mutta niistä ehkä vähitellen luovutaan kun tekevät isompaakin remonttia nyt siellä ja ei ole enää tarvetta. Taaksepäinyhteensopivuus kun toteutuu standardilla HTML5:lla ja muutokset on niin vähäisiä natiivissa, että sitä sitten tarvittaessa käännetään parin vuoden välein natiiveissa sovelluksissa uusi käännös kun tulee uusi julkaisu Ubuntusta.

"Mutta jos Microsoft todella on rikkonut tämän kaikissa muissa windows -versioissa olleen periaatteen Windows 10:ssä, silloin ei kenenkään pitäisi Windows 10:ä käyttää."

Sellaista periaatetta ei tosiasiassa ole ollut Windows API:lla. Microsoft ON kyllä satsannut taaksepäinyhteensopivuuteen kuten muutkin sitä tehneet mutta Windowsissa yhteensopivuuksissa ollut muutosta Windows julkaisujen välillä ja toivat sitten korkeamman tason rajapintoja joissa ABI yhteensopivuus säilyy.

Ja säilyyhän se ABI yhteensopivuus siinä Windows API:ssä myös niiltä osin kuin korkeamman tason rajapinnat sitä tarvitsee. Mutta niiltä kun luvatut tuet loppuvat ja poistuvat ja Windows API:n jää jää kutsuja mitä enää tarvita niin niitä voidaan poistella tai muutella erilaiseksi. Sitähän tapahtui jo Windows 8 aikana.

"Miksi olisi suurempi virhe koodata Delphillä tietoturvallinen ohjelma, joka toimii kaikissa nykyisissä Windows -versioissa oikein, ja lakkaa toimimasta vain siinä tapauksessa, että Microsoft todella poistaisi vaikkapa GetDC -funktiokutsun GDI32.DLL -kirjastosta ?"

Koska et tiedä milloin ohjelma lakkaa toimimasta.

"Ja silti itse olet valmis hyväksymään C:llä tai C :lla tehdyn koodin, joka sisältää yhden tai useamman puskurin ylivuotovirheen ?"

Ei tarvitse olla yhtään puskurin ylivuotovirhettä.

"Kun koodaa Delphillä (ja käyttää Delphiä oikein), ei ohjelmassa ole tällaisia haavoittuvuuksia."

Ei mitään eroa C :n nähden.

"Sensijaan vastoin vääriä väitteitäsi, viimeisessä löydetyssä puskurin ylivuotovirheessä oli kyse C:llä ja/tai C :lla tehdystä koodista, eikä siitä ole aikaa yli 18 vuotta kuten väität, vaan vain n. 2.5 vuotta."

OpenSSL on vuodelta 1998, se on siis VANHAA koodia. Se on lisäksi tehty C:llä ja on systeemitason komponentti eikä sovellus. C on myös täysin eri kieli kuin C .

"Delphillä koodatessa kun kirjottaa ohjelman ja jokaisen ohjelmassa köytetyn UNITin alkuun {$R } niin mahdollinen puskurin ylivuotovirhe yleensä johtaa joko poikkeukseen tai Runtime erroriin."

No mitenkäs tuo nyt sitten eroaa C :aa käyttämällä jossa tulee ajonaikainen assertio virhe automaattisesti jos yrittää ohi taulukon käytellä?

"joka C -ohjelmissa johtaa puskurin ylivuototilanteeseen, ja sitä myötä sallii verkkorikollisille helpot tietovarkaudet."

C:llä ei ole mitään tekemistä C :n kanssa ja C:llä ei käytännössä tehdä sovelluksia.

"Toki Delphi selkeä syntaksi on huomattava kilpailuetu Delphi -koodaajalle, jos verrataan C tai C -koodaajaan.

C ja C -koodaajan aivokapasiteetista kun menee huomattavan suuri osa sekavan ja harhaanjohtavan syntaksin kanssa tappeluun, niin sitte ei enää aina riitä tarpeeksi aivokapasiteettia oikein toimivan ohjelman kirjoittamiseen."

Todista. Laitoin jo aiemmin tämän: https://en.wikipedia.org/wiki/Halstead_complexity_measures

Tuolla on helposti laskettavissa mikä koodi on virheelle altiimpaa.

Huomioi, että C ei tarvitse mitään {$R } -sotkua reunatarkistukseen.

"Delphissä taas on selkeä ja hyvin suunniteltu syntaksi"

Todista.

delphikoodaaja kirjoitti:

M-Kar: "Etenkin kun mitään puskurin ylivuotovirheitä ei käytännössä ole tehty mihinkään sovellukseen viimeisen 18v aikana."

Niin, vastahan keväällä 2014 löytyi OpenSSL -kirjastosta puskurin ylivuotovirhe, jonka seuraus käytännössä oli HeartBleed -haavoittuvuus.

Tästä on siis aikaa noin 2 vuotta 6 kuukautta, eli vuosina 2.5.

Matemaattisesti 18v > 2.5, joten väitteesi on väärä.

Ja jos vetoat siihen, ettei OpenSSL ole sovellus, vaan dynaaminen linkkikirjasto (windowsissa DLL, linuxissa .so) niin kyllähän tuollainen dynaaminen linkkikirjasto ladataan suoritusaikaisesti sovelluksen osaksi. Itseasiassa kirjaston haavoittuvuus on jopa pahempi, koska se koskee yhden sijasta useita sovelluksia.

Asia vaan on niin, että C ja C -koodaajat kirjoittavat puskurin ylivuotovirheitä jatkuvalla syötöllä, joten niin kauan kuin C ja C -kielten käyttöä ohjelmistokehitytyössä jatketaan, puskurin ylivuotovirheitä tulee aina olemaan.

Sensijaan Delphillä on helppo kirjoittaa sovelluksia, joissa ei ole puskurin ylivuotovirheitä, eikä näinollen niistä johtuvia haavoittuvuuksiakaan.

MIKÄLI väitteesi siitä, että Windows 10 päivittää itseään automaattisesti siten, että joku yli 10 vuotta windowsiin kuulunut API -kutsu yhtäkkiä poistuu (eli se ei enää jatkoss aole osa esim. uutta päivittyä versiota olevassa kernel32.dll -kirjastossa), niin silloin ainoa oikea johtopäätös on tämä: kenenkään ei pitäisi missään käyttää Windows 10 -käyttöjärjestelmää.

Windows on näihin päiviin saakka ollut linuxjakeluja parempi juuri siksi, että kerran oikein tehty windows EXE on sellaisenaan toiminut windows -versiosta toiseen ilman mitään muutoksia.

Linuxissa taas esim. ubuntu 7.10:lle oikein tehty sovellus ei välttämättä toimi oikein tai edes ollenkaan ubuntu 16.04:ssä.

Mutta jos Microsoft todella on rikkonut tämän kaikissa muissa windows -versioissa olleen periaatteen Windows 10:ssä, silloin ei kenenkään pitäisi Windows 10:ä käyttää.

"Ja kannattaa ymmärtää se pointti, että puskurin ylivuoto on virhe siinä missä mikä tahansa muukin virhe joten on naurettavaa käydä tuollaisiin takertumaan."

Miksi olisi suurempi virhe koodata Delphillä tietoturvallinen ohjelma, joka toimii kaikissa nykyisissä Windows -versioissa oikein, ja lakkaa toimimasta vain siinä tapauksessa, että Microsoft todella poistaisi vaikkapa GetDC -funktiokutsun GDI32.DLL -kirjastosta ?

Ja silti itse olet valmis hyväksymään C:llä tai C :lla tehdyn koodin, joka sisältää yhden tai useamman puskurin ylivuotovirheen ?

Puskurin ylivuotovirhe on vakava asia. Sellainen johtaa onnistuneisiin tietovarkauksiin, sillä voidaan varastaa esimerkiksi:

Käyttäjätunnuksia
Salasanoja
Salausavaimia
Pankkitunnuksia
Luotto- tai debit -korttien numeroita, CVV -koodeja ja voimassaoloaikoja.

Näillä varastetuilla tiedoilla rikollisten on helppo varastaa myös rahaa tao rahanarvoista tavaraa tilaamalla nettikaupasta, laittomasti kopioidun luottokortin numerolla.

Kun koodaa Delphillä (ja käyttää Delphiä oikein), ei ohjelmassa ole tällaisia haavoittuvuuksia.

Sensijaan vastoin vääriä väitteitäsi, viimeisessä löydetyssä puskurin ylivuotovirheessä oli kyse C:llä ja/tai C :lla tehdystä koodista, eikä siitä ole aikaa yli 18 vuotta kuten väität, vaan vain n. 2.5 vuotta.

M-Kar levittää näillä palstoilla useita vääriä tietoja.

Yksi siis on se, että viimeisestä C/C -koodista löydetystä puskurin ylivuotovirheestä olisi yli 18 vuotta, kun totuus on 2.5 vuotta, jollei sitten tuon HeartBleed -tapauksen jälkeen ole löytynyt muitakin vastaavia.

Delphillä koodatessa kun kirjottaa ohjelman ja jokaisen ohjelmassa köytetyn UNITin alkuun {$R } niin mahdollinen puskurin ylivuotovirhe yleensä johtaa joko poikkeukseen tai Runtime erroriin.

Ohjelma ei siis jatka toimintaansa ikään kun mitään ei olisi pielessä.

Toki, ei Delphissäkään ole tarkoitus kirjoittaa huolettomasti koodia jossa on em. kaltaisia virheitä. Tuo {$R } -kääntäjäoptio ei siis ole huolellisen koodaustyön korvike, vaan se on ns. viimeinen hätävara, joka lopettaa ohjelmansuorituksen sen sijaan, että sallisi verkkorikollisten varastaa tietoja, siis siinä epätodennäköisessä tapauksessa, että ohjelmoija kaikesta huolimatta tekisi vastaavanlaisen vakavan virheen, joka C -ohjelmissa johtaa puskurin ylivuototilanteeseen, ja sitä myötä sallii verkkorikollisille helpot tietovarkaudet.

Toki Delphi selkeä syntaksi on huomattava kilpailuetu Delphi -koodaajalle, jos verrataan C tai C -koodaajaan.

C ja C -koodaajan aivokapasiteetista kun menee huomattavan suuri osa sekavan ja harhaanjohtavan syntaksin kanssa tappeluun, niin sitte ei enää aina riitä tarpeeksi aivokapasiteettia oikein toimivan ohjelman kirjoittamiseen.

Delphissä taas on selkeä ja hyvin suunniteltu syntaksi, joka mahdollistaa sen, että Delphi -koodaajan aivokapasiteetista kaikki menee oikein toimivan ohjelman kirjoittamiseen, kun sitä ei tarvitse tuhlata toisarvoisiin tarkoituksiin, kuten huonon syntaksin kanssa tappeluun.

Lue lisää

Noniin... http://www.hardware.fi/uutiset/artikkeli.cfm/2016/08/20/windows-10-n-anniversary-paivitys-rikkoi-miljoonia-web-kameroita

Windows 10:ssä oli deprekoitu muutama kuvakodekki ja ne nyt sitten poistettiin Windows 10:n päivityksen myötä. Siinä sitten muutama miljoonaa web kameraa joutaa roskiin ja voi ostaa uudemmat tilalle.

Tämä sama pätee myös sovelluksiin kun Microsoft poistaa deprekoituja rajapintakutsuja.

Toki siellä hommat toimii vähintään sen aikaa mitä on luvattu. Delphi jutuissa toimivuudesta vastaa Delphin valmistaja ja joka julkaisulle luvataan 1,5v tuki.

M-Kar kirjoitti:

Noniin... http://www.hardware.fi/uutiset/artikkeli.cfm/2016/08/20/windows-10-n-anniversary-paivitys-rikkoi-miljoonia-web-kameroita

Windows 10:ssä oli deprekoitu muutama kuvakodekki ja ne nyt sitten poistettiin Windows 10:n päivityksen myötä. Siinä sitten muutama miljoonaa web kameraa joutaa roskiin ja voi ostaa uudemmat tilalle.

Tämä sama pätee myös sovelluksiin kun Microsoft poistaa deprekoituja rajapintakutsuja.

Toki siellä hommat toimii vähintään sen aikaa mitä on luvattu. Delphi jutuissa toimivuudesta vastaa Delphin valmistaja ja joka julkaisulle luvataan 1,5v tuki.

Lue lisää

Minulla on se käsitys että Delphillä tehty sovellus voi hajota "heti" (Ja näin on ollut aina. Esimerkkinä vaikkapa se että joskus pääsi suoraan I/O-portteihin käsiksi). Ilmeisesti tuo nimimerkin M-Kar esittämä 1,5 vuotta tarkoittaa (nimenomaan) VCL-komponenttien käyttöä. Eli VCL "nojaa" sellaisiin rajapintoihin joita MS tukee vähintään kyseisen ajan.

Delphissä on luokka TOSVersion joka kertoo missä käyttöjärjestelmän versiossa ollaan (vanhemmissa Delpheissä oli Win32MajorVersion ja Win32MinorVersion).

Yleisohje on että mitä vähemmän ollaan kiinni windowsin rajapinnoissa niin sitä kauemmin sovellus toimii eli mitä enemmän siinä on "puhdasta" Pascal-koodia.

Delphif kirjoitti:

Minulla on se käsitys että Delphillä tehty sovellus voi hajota "heti" (Ja näin on ollut aina. Esimerkkinä vaikkapa se että joskus pääsi suoraan I/O-portteihin käsiksi). Ilmeisesti tuo nimimerkin M-Kar esittämä 1,5 vuotta tarkoittaa (nimenomaan) VCL-komponenttien käyttöä. Eli VCL "nojaa" sellaisiin rajapintoihin joita MS tukee vähintään kyseisen ajan.

Delphissä on luokka TOSVersion joka kertoo missä käyttöjärjestelmän versiossa ollaan (vanhemmissa Delpheissä oli Win32MajorVersion ja Win32MinorVersion).

Yleisohje on että mitä vähemmän ollaan kiinni windowsin rajapinnoissa niin sitä kauemmin sovellus toimii eli mitä enemmän siinä on "puhdasta" Pascal-koodia.

Lue lisää

Se systeemi meni ennen niin, että jos Win32 sovellus toimii jossain Windowsissa, esim. Windows XP:ssä, niin se toimi koko tämän Windows XP:n eliniän loppuun saakka. Päivittäminen uudempaan Windowsiin saattoi rikkoa sovelluksen.

Sitten Microsoftilla oli nämä omat rajapinnat, eli MFC, .NET, Silverlight jne. joille luvattiin myöselinkaari ja ne eivät välitä siitä mikä versio Windowsista on käytössä. Ne noudattavat omia elinkaarikäytäntöjään ja se päti myös edelleen, että jos teki vaikka Windows XP:ssä .NET 1.1 sovelluksen joka toimi Windows 7:ssa, niin se sovellus toimii Windows 7:n koko eliniän loppuun saakka vaikka .NET 1.1 ei saisikaan enää korjauksia.

Windows 10:ssä sitten muutossykli on pari kertaa vuodessa ja vain niiden Microsoftin rajapintojen elinkaarikäytännöt pätevät. Windows kestää tavallaan puolivuotta ja sitten pakkopäivitys uuteen seuraavaksi puoleksi vuodeksi eikä niitä käytetä vuosikausia rinnalla.

Tuo 1,5v tuki VCL:lle ja muille ei siis ole Microsoftin lupaus vaan Embarcaderon lupaus. He ovat varmistaneet, että nykyinen versio Delphistä käyttää sellaisia rajapintakutsuja joita Microsoftin rajapinnat (.NET, MFC jne.) käyttää vielä vähintään luvatun aikaa ja jos jotain hämminkiä kävisikin niin pystyvät tuon aikaa vielä reagoimaan ja tarjoamaan Delphin kirjastoihin vaikka päivitystä tai Delphiin päivitystä millä ohjelman voi kääntää toimivaksi.

Eli siis ymmärsit oikein. VCL ja mikä tahansa Delphin käyttämä rajapintakutsu on luvatusti toimiva 1,5v julkaisusta ja juuri tuolla tavalla, että se katsoo vähän mitä vasten on käännetty ja miten pitkään Embercaderolla riittää resurssit.

"Yleisohje on että mitä vähemmän ollaan kiinni windowsin rajapinnoissa niin sitä kauemmin sovellus toimii eli mitä enemmän siinä on "puhdasta" Pascal-koodia."

Jokseenkin näin, riippuvuuksien kasvu lisää hajoamisriskiä. Puhdas Pascal koodikaan ei suoraan suojaa tätä koska sehän on prosessorin natiivia Delphissä ja suuntaus on vahvasti se, että koodi käännetään CLR tavukoodiksi mitä .NET käyttää ja sitä käyttää myös WinRT sovellukset. Tuollainen välitason tavukoodi mahdollistaa sen, että Microsoft voi vaikka siististi poistaa kaiken 32-bittisen kuran pois ja vaikka kaiken 64-bittisen x 86 koodin ja siirtää Windowsit ARM laitteille.

Näillä näkymin Microsoft tukee x86 koodia jossain muodossa vähintään 9v vielä mutta 32-bit versiot Windowsista voi poistua hyvinkin nopeasti ja 32-bit koodi toimii vain niiden apukirjastojen kautta 64-bittisissa x86 prossuissa.

"Esimerkkinä vaikkapa se että joskus pääsi suoraan I/O-portteihin käsiksi)."

Niin... Windows 7 oikeastaan viimeinen päätelaitteiden Windows mikä soveltui tuon kaltaiseen ohjelmointiin. Tekniikkahan ollut kuitenkin jostain vuodesta 1998 lähtien sellaista, että I/O porttien luku ollut järkevää pitää täysin omassa laitteessa ja etäkäyttää sitä vaikka selaimella tai omalla asiakassovelluksella.

Jostain kumman syystä jotkut haluavat väkisin tunkea käyttöliittymän siihen samaan keskusyksikköön mikä on adapterina verkossa jonkun laitteen ohjauksessa. Eihän siinä ole mitään järkeä kun ymmärtää nuo riippuvuudet ja tietää myös sen Mooren lain mikä halventaa kaikkia keskusyksikköjä loputtomiin. On ollut niin naurettavan halpaa laittaa jokaisen laitteen ohjaukseen oma keskusyksikkö.

Tämä kuva esittää hyvin miten "marketista" saa kaupanhyllyltä kokoajan pienempäää, halvempaa ja tehokkaampaa millä päivittää sitä adapteripalikkaa: https://en.wikipedia.org/wiki/Mini-ITX#/media/File:VIA_Mainboards_Form_Factor_Comparison.jpg

Sitä kun se lauta maksoi silloin 1998 nykyrahassa jotain sataa euroa ja nyt vitosen ja se vitosen vekotin on suoraan vaihdettavissa aikaisemman tilalle, että riittää kun laittaa töpselit seinään niin ehkä kannattaa vähän ymmärtää jotain siitä tietojärkestelmien arkkitehtuuristakin.

Ei ARM (tai mukaan prosessoriarkkitehtuuri) ole mikään kompastuskivi Pascalille.
Pascalissahan voi kirjoittaa suoraan konekieltä jolloin siitä voi tulla ongelma jos sitä ei osaa kiertää.

Eri prosessori arkkitehtuuri on (ollut) lähinnä windowsin ongelma.

Mutta huomaa myös se että nämä .net-kirjastot käyttävät tiettyjä rajapintoja. Jos niiden halutaan toimivan
niin käyttöjärjestelmän on tuettava niitä.

Samat ongelmat tulenevat javan ja QT:n kirjaston kanssa.

Delphin kirjoitti:

Ei ARM (tai mukaan prosessoriarkkitehtuuri) ole mikään kompastuskivi Pascalille.
Pascalissahan voi kirjoittaa suoraan konekieltä jolloin siitä voi tulla ongelma jos sitä ei osaa kiertää.

Eri prosessori arkkitehtuuri on (ollut) lähinnä windowsin ongelma.

Mutta huomaa myös se että nämä .net-kirjastot käyttävät tiettyjä rajapintoja. Jos niiden halutaan toimivan
niin käyttöjärjestelmän on tuettava niitä.

Samat ongelmat tulenevat javan ja QT:n kirjaston kanssa.

Lue lisää

"Ei ARM (tai mukaan prosessoriarkkitehtuuri) ole mikään kompastuskivi Pascalille.
Pascalissahan voi kirjoittaa suoraan konekieltä jolloin siitä voi tulla ongelma jos sitä ei osaa kiertää."

Ei se ohjelmointikielelle ole mutta käännetyille ohjelmille on. Sitä kun kääntää Windowsille vaikka x86 sovelluksen niin ei toimi ARM:lla. CLR:lle kun kääntää niin poistuu tuo typerä riippuvuus laitearkkitehtuuriin.

"Mutta huomaa myös se että nämä .net-kirjastot käyttävät tiettyjä rajapintoja. Jos niiden halutaan toimivan niin käyttöjärjestelmän on tuettava niitä."

Käytännössä kyllä. Oletan, että sitten kun .NET tai MFC versioiden luvatut tuet loppuvat ja niitä voidaan siivota pois niin niiden käyttämiä matalan tason kutsuja voidaan myös siivota. Samoin sellaisia rajapintakutsuja mitä ei näissä käytetä.

"Samat ongelmat tulenevat javan ja QT:n kirjaston kanssa."

Ei ihan. Qt kääntää myös Visual C :lla kääntäen tämän kirjastoja vasten, eli Visual C 2015 käännetty Qt sovellus toimii luvatusti vähintään vuoteen 2025 saakka Windows 10:ssä.

Javassa taas auttaa ABI tason taaksepäinyhteensopivuus, sillä nykyisellä Java 8:lla käännetyt sovellukset toimivat käytännössä Java 11 versiolla ilman mitään hämminkiä, aivan kuten Java 5:lla tehdyt toimivat Java 8:lla. Se Java JRE kyllä voi mennä rikki Windows 10:n päivittyessä, että sitä kun päivittää uudemmaksi niin hommat toimii taas ja Oracle vastaa sitten siitä Java JRE:n toimivuudesta. Tarvitsee kuitenkin olla tuen piirissä oleva julkaisu (7, 8, 9 jne.) täysin päivitettynä.

"Minuun ei M-Kar hihulin paska puheet vaikuta mitenkään, olen ikäni ohjelmoinut Delpihillä ja ohjelmoin jatkossakin, 7 versiota unohtamatta."

Entä missä vastuunotto? Paljon maksat vahingoista?

"Kas kummaa ne vaan toimii"

Ei se riitä mihinkään, että toimii kehittäjän koneella nyt. Pitää tietää toimiiko vaikka vuoden kuluttua tuotannossa ja sinulla ei ole mitään käsitystä tästä.

"ja mailman nopein kääntäjä."

Ei kääntämisen suorituskyky nyt muutenkaan ole mikään ongelma. Saman tien ohjelma käynnistyy.

"DELPHI 7 ON PARAS."

Delphin täytyy olla läpipaska jos pitää jotain museoversioita käyttää eikä nykyistä.

Tietenkin ainakin VCL:ssä käytetään GDI:tä.

Jos jollekulle ei GDI kelpaa, niin sitten on FireMonkey (vaatii riittävän uuden version Delphistä).

Pitäisiköhän hankkia jostain siirtokelpoinen Windows 7 lisenssi?

Ihan siksi, että Delphi -sovelluksia voi sitten ajaa "maailman tappiin " Windows 7:lla.

M-Kar jaksaa levittää väitteitään siitä, että perinteinen Windows API olisi katoamassa tulevista windows -versioista (siis Windows 10a päivittyy itsestään Windows10b:ksi, ja yhtäkkiä esim. GetDC -funktiota ei sitten enää olekaan GDI32.DLL -kirjastossa kutsuttavissa, niinkö ?)

(Windows 10a ja Windows 10b eivät ehkä ole virallisia termejä, mutta kuvaavat parhaiten sitä, mistä on kysymys tuossa Windows 10:n itsepäivittyvyydessä).

Jos asia todella on näin, niin silloin oikein on:

1) käyttää Windows7:aa "ikuisesti", eli ainakin niin kauan, kunnes saadaan aikaiseksi järkevästi koodattu linux, ja siirtyä siinä vaiheessa linux -käyttäjäksi.

2) asiasta kiinnostuneiden pitäisi yhteistyössä perustaa jonkunlainen linux -säätiö, jossa päätösvaltaa EI anneta nykyisille linuxfanaatikoille, syynä se, että esim. Debian on varoittava esimerkki siitä, miten käy, kun linuxfanaatikot päästetään päättämään asioista.

Debianin vikalista on pitkä:

1) Joissakin koneissa asennusohjelma tunnistaa että koneessa muka ei ole BIOSia, vaan se uudempi BIOSin korvike, jonka nimeä en juuri nyt muista.

Tämän takia asennusohjelma asentaa väärän buuttilataajan, joka ei kyseisessä koneessa toimi. Niin, Debianin kehittäjille teknisesti oikein toimivuus ei merkitse yhtään mitään, vaan heille tärkeintä on fanatismi GPL -lisenssin suhteen.

Samasta syystä, Debianissa ei ole oikein toimivaa Jörg Schillingin cdrecord -ohjelmaa, vaan sen surkea klooni nimeltä wodim. Tuolla Wodimilla cd -levyn kirjoitus saattaa vielä jotenkuten jopa toimia, mutta DVD-R -levyjä en ole wodimilla saanut aikaiseksi ensimmistäkään oikein kirjoitettua.

Täsmälleen samalla tietokoneella jossa täsmälleen sama DVD-RW -asema, aito cdrecord kirjoittaa DVD-R -levyn aina oikein, olettaen että aihio ei satu olemaan viallinen kappale.

Tarvittaisiin todellakin parempi linux, jonka kehittäjäyhteisön päättäviin asemiin ei saa päästää yhtään GPL ja /tai GNU -fanaatikkoa asioita sotkemaan.

Parempaan linuxiin valitaan ohjelmat teknisen toimivuuden perusteella, ei lisenssin.

Ja siihen koodataan parempia ohjelmia esim. FreePascal/Lazarus -yhdistelmällä.

Sitten jos/kun tällainen parempi linux saadaan aikaan, siirryn siihen. Sitä ennen aion jatkaa Windows 7:n käyttöä, myös sen jälkeen kun Microsoftin tuki sille loppuu. Jos MS tämän estää, niin downgradetan XP tai Windows 2000 -käyttöjärjestelmään.

Parempaan linuxiin muuten EI oteta GIMP -ohjelmaa lainkaan. Sen sijaan siihen lisensioidaan kaupallinen grafiikkaeditori, yksi hyvä vaihtoehto on Windows XP:n mukana tuleva MS Paint. Jos MS suostuu lisensioimaan sen kohtuuhintaan, niin se, muussa tapauksessa lisensioidaan joku kilpaileva tuote tai kehitetään FreePascal/Lazarus -yhdistelmällä oma grafiikkaeditori.

Windows 7:ssa Paint on selvästi huonompi kuin XP:n mukana tulevassa versiossa.

Niin, laskimeksi voisin itse kehittää FreePascal/Lazarus -yhdistelmällä laskinohjelman, joka on lähes Windows XP -laskimen klooni, mutta parannettu versio siitä.

Tuota tosin voi vaikeuttaa, jollei FreePascal/Lazarus -yhdistelmän TBitmap -komponentista löydy Scanline -ominaisuutta !

Tuo Scanline -ominaisuus kun on välttämätön, jotta ohjelma täyttää myös nopeusvaatimukset.

Pelkällä Pixels -arraylla kun homma kyllä muuten toimisi, mutta olisi järkyttävän hidas.

Mutta huonoilla ohjelmilla (kuten GIMP, jonka käyttöliittymä on per?eestä), ei ole mitään asiaa parempaan linuxiin.

"Pyöriikö .NET 1.0 tehty sovellus esim. Win10:ssa vai pitääkö se uudelleenkääntää yms?"

Se pitää uudelleenkääntää. .NET 1.0:n luvattu elinkaari on tullut täyteen ja sillä tehdyt ohjelmat saa toimimaan niissä Windowseissa mihin .NET 1.1 on asennettavissa. Eli Windows 7 ja vanhemmat.

.NET 2.0 ja uudemmat toimivat vielä kaikissa Windowseissa kuten on luvattu. Parin vuoden kuluttua loppuu luvattu tuki .NET 3.5:sta vanhemmilta, että sen jälkeen ne voi lakata toimimasta Windows 10:llä mutta ei vanhemmilla Windowseilla. Nykyiset .NET 4.x ohjelmat toimivat vähintään 10v eteenpäin kaikilla Windowseilla ja Windows API:n muutokset ei niihin hetkauta.

"Käyttääkö Delphin VCL-komponentit vielä GDI:tä vai Direct 2D:ta, ensimmäinen on deprekoitu ja joku kaunis päivä katoaa bittiavaruuteen, siinä vaiheessa Delphi 7 ja sillä tehdyt sovelluksen käynnistyy vain vanhassa windowsissa."

GDI kyllä, eli voivat lakata toimimasta yks kaks Windows 10:n päivittyessä. Pari kertaa vuodessa tulee sellainen päivitys mikä voi näitä muutella.

delphikoodaaja kirjoitti:

Tietenkin ainakin VCL:ssä käytetään GDI:tä.

Jos jollekulle ei GDI kelpaa, niin sitten on FireMonkey (vaatii riittävän uuden version Delphistä).

Pitäisiköhän hankkia jostain siirtokelpoinen Windows 7 lisenssi?

Ihan siksi, että Delphi -sovelluksia voi sitten ajaa "maailman tappiin " Windows 7:lla.

M-Kar jaksaa levittää väitteitään siitä, että perinteinen Windows API olisi katoamassa tulevista windows -versioista (siis Windows 10a päivittyy itsestään Windows10b:ksi, ja yhtäkkiä esim. GetDC -funktiota ei sitten enää olekaan GDI32.DLL -kirjastossa kutsuttavissa, niinkö ?)

(Windows 10a ja Windows 10b eivät ehkä ole virallisia termejä, mutta kuvaavat parhaiten sitä, mistä on kysymys tuossa Windows 10:n itsepäivittyvyydessä).

Jos asia todella on näin, niin silloin oikein on:

1) käyttää Windows7:aa "ikuisesti", eli ainakin niin kauan, kunnes saadaan aikaiseksi järkevästi koodattu linux, ja siirtyä siinä vaiheessa linux -käyttäjäksi.

2) asiasta kiinnostuneiden pitäisi yhteistyössä perustaa jonkunlainen linux -säätiö, jossa päätösvaltaa EI anneta nykyisille linuxfanaatikoille, syynä se, että esim. Debian on varoittava esimerkki siitä, miten käy, kun linuxfanaatikot päästetään päättämään asioista.

Debianin vikalista on pitkä:

1) Joissakin koneissa asennusohjelma tunnistaa että koneessa muka ei ole BIOSia, vaan se uudempi BIOSin korvike, jonka nimeä en juuri nyt muista.

Tämän takia asennusohjelma asentaa väärän buuttilataajan, joka ei kyseisessä koneessa toimi. Niin, Debianin kehittäjille teknisesti oikein toimivuus ei merkitse yhtään mitään, vaan heille tärkeintä on fanatismi GPL -lisenssin suhteen.

Samasta syystä, Debianissa ei ole oikein toimivaa Jörg Schillingin cdrecord -ohjelmaa, vaan sen surkea klooni nimeltä wodim. Tuolla Wodimilla cd -levyn kirjoitus saattaa vielä jotenkuten jopa toimia, mutta DVD-R -levyjä en ole wodimilla saanut aikaiseksi ensimmistäkään oikein kirjoitettua.

Täsmälleen samalla tietokoneella jossa täsmälleen sama DVD-RW -asema, aito cdrecord kirjoittaa DVD-R -levyn aina oikein, olettaen että aihio ei satu olemaan viallinen kappale.

Tarvittaisiin todellakin parempi linux, jonka kehittäjäyhteisön päättäviin asemiin ei saa päästää yhtään GPL ja /tai GNU -fanaatikkoa asioita sotkemaan.

Parempaan linuxiin valitaan ohjelmat teknisen toimivuuden perusteella, ei lisenssin.

Ja siihen koodataan parempia ohjelmia esim. FreePascal/Lazarus -yhdistelmällä.

Sitten jos/kun tällainen parempi linux saadaan aikaan, siirryn siihen. Sitä ennen aion jatkaa Windows 7:n käyttöä, myös sen jälkeen kun Microsoftin tuki sille loppuu. Jos MS tämän estää, niin downgradetan XP tai Windows 2000 -käyttöjärjestelmään.

Parempaan linuxiin muuten EI oteta GIMP -ohjelmaa lainkaan. Sen sijaan siihen lisensioidaan kaupallinen grafiikkaeditori, yksi hyvä vaihtoehto on Windows XP:n mukana tuleva MS Paint. Jos MS suostuu lisensioimaan sen kohtuuhintaan, niin se, muussa tapauksessa lisensioidaan joku kilpaileva tuote tai kehitetään FreePascal/Lazarus -yhdistelmällä oma grafiikkaeditori.

Windows 7:ssa Paint on selvästi huonompi kuin XP:n mukana tulevassa versiossa.

Niin, laskimeksi voisin itse kehittää FreePascal/Lazarus -yhdistelmällä laskinohjelman, joka on lähes Windows XP -laskimen klooni, mutta parannettu versio siitä.

Tuota tosin voi vaikeuttaa, jollei FreePascal/Lazarus -yhdistelmän TBitmap -komponentista löydy Scanline -ominaisuutta !

Tuo Scanline -ominaisuus kun on välttämätön, jotta ohjelma täyttää myös nopeusvaatimukset.

Pelkällä Pixels -arraylla kun homma kyllä muuten toimisi, mutta olisi järkyttävän hidas.

Mutta huonoilla ohjelmilla (kuten GIMP, jonka käyttöliittymä on per?eestä), ei ole mitään asiaa parempaan linuxiin.

Lue lisää

"Tietenkin ainakin VCL:ssä käytetään GDI:tä."

Eli se on kelvoton muuten paitsi uusimmassa Delphi versiossa mitä löytyy.

"Pitäisiköhän hankkia jostain siirtokelpoinen Windows 7 lisenssi?

Ihan siksi, että Delphi -sovelluksia voi sitten ajaa "maailman tappiin " Windows 7:lla."

Ei käytännössä voi ajaa maailman tappiin saakka koska Windows 7 yhteensopivat laitteet katoavat.

"M-Kar jaksaa levittää väitteitään siitä, että perinteinen Windows API olisi katoamassa tulevista windows -versioista"

En minä ole missään sanonut että se yks kaks katoaisi vaan sanoin, että se muuttuu jatkuvasti kuten on tähänkin mennessä ollut muutosta. Esim. Win32s oli erilainen kuin Win32c ja sen jälkeen riski rikkoutumiselle oli joka Windows julkaisussa muutosten vuoksi.

" (siis Windows 10a päivittyy itsestään Windows10b:ksi, ja yhtäkkiä esim. GetDC -funktiota ei sitten enää olekaan GDI32.DLL -kirjastossa kutsuttavissa, niinkö ?)"

Nyt on jo Windows10c ja muutosta on ja tottakai GetDC voi kadota. GDI on deprekoitu ja Microsoft ilmoittanut siis kehittäjille, että älkää nyt helvetissä tehkö mitään mikä sitä käyttää. Menee muuten rikki ennenaikaisesti.

delphikoodaaja kirjoitti:

Tietenkin ainakin VCL:ssä käytetään GDI:tä.

Jos jollekulle ei GDI kelpaa, niin sitten on FireMonkey (vaatii riittävän uuden version Delphistä).

Pitäisiköhän hankkia jostain siirtokelpoinen Windows 7 lisenssi?

Ihan siksi, että Delphi -sovelluksia voi sitten ajaa "maailman tappiin " Windows 7:lla.

M-Kar jaksaa levittää väitteitään siitä, että perinteinen Windows API olisi katoamassa tulevista windows -versioista (siis Windows 10a päivittyy itsestään Windows10b:ksi, ja yhtäkkiä esim. GetDC -funktiota ei sitten enää olekaan GDI32.DLL -kirjastossa kutsuttavissa, niinkö ?)

(Windows 10a ja Windows 10b eivät ehkä ole virallisia termejä, mutta kuvaavat parhaiten sitä, mistä on kysymys tuossa Windows 10:n itsepäivittyvyydessä).

Jos asia todella on näin, niin silloin oikein on:

1) käyttää Windows7:aa "ikuisesti", eli ainakin niin kauan, kunnes saadaan aikaiseksi järkevästi koodattu linux, ja siirtyä siinä vaiheessa linux -käyttäjäksi.

2) asiasta kiinnostuneiden pitäisi yhteistyössä perustaa jonkunlainen linux -säätiö, jossa päätösvaltaa EI anneta nykyisille linuxfanaatikoille, syynä se, että esim. Debian on varoittava esimerkki siitä, miten käy, kun linuxfanaatikot päästetään päättämään asioista.

Debianin vikalista on pitkä:

1) Joissakin koneissa asennusohjelma tunnistaa että koneessa muka ei ole BIOSia, vaan se uudempi BIOSin korvike, jonka nimeä en juuri nyt muista.

Tämän takia asennusohjelma asentaa väärän buuttilataajan, joka ei kyseisessä koneessa toimi. Niin, Debianin kehittäjille teknisesti oikein toimivuus ei merkitse yhtään mitään, vaan heille tärkeintä on fanatismi GPL -lisenssin suhteen.

Samasta syystä, Debianissa ei ole oikein toimivaa Jörg Schillingin cdrecord -ohjelmaa, vaan sen surkea klooni nimeltä wodim. Tuolla Wodimilla cd -levyn kirjoitus saattaa vielä jotenkuten jopa toimia, mutta DVD-R -levyjä en ole wodimilla saanut aikaiseksi ensimmistäkään oikein kirjoitettua.

Täsmälleen samalla tietokoneella jossa täsmälleen sama DVD-RW -asema, aito cdrecord kirjoittaa DVD-R -levyn aina oikein, olettaen että aihio ei satu olemaan viallinen kappale.

Tarvittaisiin todellakin parempi linux, jonka kehittäjäyhteisön päättäviin asemiin ei saa päästää yhtään GPL ja /tai GNU -fanaatikkoa asioita sotkemaan.

Parempaan linuxiin valitaan ohjelmat teknisen toimivuuden perusteella, ei lisenssin.

Ja siihen koodataan parempia ohjelmia esim. FreePascal/Lazarus -yhdistelmällä.

Sitten jos/kun tällainen parempi linux saadaan aikaan, siirryn siihen. Sitä ennen aion jatkaa Windows 7:n käyttöä, myös sen jälkeen kun Microsoftin tuki sille loppuu. Jos MS tämän estää, niin downgradetan XP tai Windows 2000 -käyttöjärjestelmään.

Parempaan linuxiin muuten EI oteta GIMP -ohjelmaa lainkaan. Sen sijaan siihen lisensioidaan kaupallinen grafiikkaeditori, yksi hyvä vaihtoehto on Windows XP:n mukana tuleva MS Paint. Jos MS suostuu lisensioimaan sen kohtuuhintaan, niin se, muussa tapauksessa lisensioidaan joku kilpaileva tuote tai kehitetään FreePascal/Lazarus -yhdistelmällä oma grafiikkaeditori.

Windows 7:ssa Paint on selvästi huonompi kuin XP:n mukana tulevassa versiossa.

Niin, laskimeksi voisin itse kehittää FreePascal/Lazarus -yhdistelmällä laskinohjelman, joka on lähes Windows XP -laskimen klooni, mutta parannettu versio siitä.

Tuota tosin voi vaikeuttaa, jollei FreePascal/Lazarus -yhdistelmän TBitmap -komponentista löydy Scanline -ominaisuutta !

Tuo Scanline -ominaisuus kun on välttämätön, jotta ohjelma täyttää myös nopeusvaatimukset.

Pelkällä Pixels -arraylla kun homma kyllä muuten toimisi, mutta olisi järkyttävän hidas.

Mutta huonoilla ohjelmilla (kuten GIMP, jonka käyttöliittymä on per?eestä), ei ole mitään asiaa parempaan linuxiin.

Lue lisää

"1) käyttää Windows7:aa "ikuisesti", eli ainakin niin kauan, kunnes saadaan aikaiseksi järkevästi koodattu linux, ja siirtyä siinä vaiheessa linux -käyttäjäksi."

Mikä Linuxin koodauksessa on pielessä? Miksi pitää käyttää Linuxia jos ei tykkää?

"2) asiasta kiinnostuneiden pitäisi yhteistyössä perustaa jonkunlainen linux -säätiö, jossa päätösvaltaa EI anneta nykyisille linuxfanaatikoille, syynä se, että esim. Debian on varoittava esimerkki siitä, miten käy, kun linuxfanaatikot päästetään päättämään asioista. "

Linux Foundation on olemassa. Debian ei liity Linux Foundationiin eikä Linux porukoihin vaan on oma organisaationsa.

"Debianin vikalista on pitkä:

1) Joissakin koneissa asennusohjelma tunnistaa että koneessa muka ei ole BIOSia, vaan se uudempi BIOSin korvike, jonka nimeä en juuri nyt muista."

Tuo ei ole Debianin vika vaan laiteyhteensopivuusasia.

"Niin, Debianin kehittäjille teknisesti oikein toimivuus ei merkitse yhtään mitään, vaan heille tärkeintä on fanatismi GPL -lisenssin suhteen."

Debianin teknisessä toimivuudessa ei ole havaintojen perusteella mitään moitittavaa. Yhteensopimattomat laitteet eivät ole Debianin vikoja.

Debianissa suosivat GPL lisenssiä koska Free Software Foundation on rahoittanut Debiania mutta tässä ei ole mitään fanatismia sillä hyväksyvät muita lisenssejä. Toimivat tämän yhteisösopimuksen mukaisesti: https://www.debian.org/social_contract

Kuten huomaat niin lähes kaikki lisenssit käy tuohon.

"Tuolla Wodimilla cd -levyn kirjoitus saattaa vielä jotenkuten jopa toimia, mutta DVD-R -levyjä en ole wodimilla saanut aikaiseksi ensimmistäkään oikein kirjoitettua."

Miksi mitään DVD-R levyjä pitäisi edes kirjoittaa? Eihän tuollaisia ole tarvittu missään yli kymmeneen vuoteen.

"Ja siihen koodataan parempia ohjelmia esim. FreePascal/Lazarus -yhdistelmällä."

Debianiin voi koodata ohjelmia Lazaruksella. Sehän on itseasiassa paras alusta tähän.

"Jos MS tämän estää, niin downgradetan XP tai Windows 2000 -käyttöjärjestelmään."

Windows XP ja 2000 yhteensopivat laitteet ovat jo aika pitkälti kadonneet.

"Parempaan linuxiin valitaan ohjelmat teknisen toimivuuden perusteella, ei lisenssin."

"Parempaan linuxiin muuten EI oteta GIMP -ohjelmaa lainkaan"

Linux ei liity mitenkään johonkin muihin ohjelmiin.

"Sen sijaan siihen lisensioidaan kaupallinen grafiikkaeditori, yksi hyvä vaihtoehto on Windows XP:n mukana tuleva MS Paint."

Sillä ei tee yhtään mitään. Kelvoton roska.

"Tuo Scanline -ominaisuus kun on välttämätön, jotta ohjelma täyttää myös nopeusvaatimukset."

Maailmassa tuskin on mitään ohjelmointivälinettä missä suorituskyky ei riittäisi laskinsovelluksen suorituskykyvaatimuksille.

"Mutta huonoilla ohjelmilla (kuten GIMP, jonka käyttöliittymä on per?eestä), ei ole mitään asiaa parempaan linuxiin."

Ei GIMP:n käyttöliittymässä ole mitään vikaa. Tuollaisia selittää lähinnä jotkut Windowsin käyttäjät joilla ei ole GIMP:lle suunniteltua ikkunamanageria.

M-Kar kirjoitti:

"1) käyttää Windows7:aa "ikuisesti", eli ainakin niin kauan, kunnes saadaan aikaiseksi järkevästi koodattu linux, ja siirtyä siinä vaiheessa linux -käyttäjäksi."

Mikä Linuxin koodauksessa on pielessä? Miksi pitää käyttää Linuxia jos ei tykkää?

"2) asiasta kiinnostuneiden pitäisi yhteistyössä perustaa jonkunlainen linux -säätiö, jossa päätösvaltaa EI anneta nykyisille linuxfanaatikoille, syynä se, että esim. Debian on varoittava esimerkki siitä, miten käy, kun linuxfanaatikot päästetään päättämään asioista. "

Linux Foundation on olemassa. Debian ei liity Linux Foundationiin eikä Linux porukoihin vaan on oma organisaationsa.

"Debianin vikalista on pitkä:

1) Joissakin koneissa asennusohjelma tunnistaa että koneessa muka ei ole BIOSia, vaan se uudempi BIOSin korvike, jonka nimeä en juuri nyt muista."

Tuo ei ole Debianin vika vaan laiteyhteensopivuusasia.

"Niin, Debianin kehittäjille teknisesti oikein toimivuus ei merkitse yhtään mitään, vaan heille tärkeintä on fanatismi GPL -lisenssin suhteen."

Debianin teknisessä toimivuudessa ei ole havaintojen perusteella mitään moitittavaa. Yhteensopimattomat laitteet eivät ole Debianin vikoja.

Debianissa suosivat GPL lisenssiä koska Free Software Foundation on rahoittanut Debiania mutta tässä ei ole mitään fanatismia sillä hyväksyvät muita lisenssejä. Toimivat tämän yhteisösopimuksen mukaisesti: https://www.debian.org/social_contract

Kuten huomaat niin lähes kaikki lisenssit käy tuohon.

"Tuolla Wodimilla cd -levyn kirjoitus saattaa vielä jotenkuten jopa toimia, mutta DVD-R -levyjä en ole wodimilla saanut aikaiseksi ensimmistäkään oikein kirjoitettua."

Miksi mitään DVD-R levyjä pitäisi edes kirjoittaa? Eihän tuollaisia ole tarvittu missään yli kymmeneen vuoteen.

"Ja siihen koodataan parempia ohjelmia esim. FreePascal/Lazarus -yhdistelmällä."

Debianiin voi koodata ohjelmia Lazaruksella. Sehän on itseasiassa paras alusta tähän.

"Jos MS tämän estää, niin downgradetan XP tai Windows 2000 -käyttöjärjestelmään."

Windows XP ja 2000 yhteensopivat laitteet ovat jo aika pitkälti kadonneet.

"Parempaan linuxiin valitaan ohjelmat teknisen toimivuuden perusteella, ei lisenssin."

"Parempaan linuxiin muuten EI oteta GIMP -ohjelmaa lainkaan"

Linux ei liity mitenkään johonkin muihin ohjelmiin.

"Sen sijaan siihen lisensioidaan kaupallinen grafiikkaeditori, yksi hyvä vaihtoehto on Windows XP:n mukana tuleva MS Paint."

Sillä ei tee yhtään mitään. Kelvoton roska.

"Tuo Scanline -ominaisuus kun on välttämätön, jotta ohjelma täyttää myös nopeusvaatimukset."

Maailmassa tuskin on mitään ohjelmointivälinettä missä suorituskyky ei riittäisi laskinsovelluksen suorituskykyvaatimuksille.

"Mutta huonoilla ohjelmilla (kuten GIMP, jonka käyttöliittymä on per?eestä), ei ole mitään asiaa parempaan linuxiin."

Ei GIMP:n käyttöliittymässä ole mitään vikaa. Tuollaisia selittää lähinnä jotkut Windowsin käyttäjät joilla ei ole GIMP:lle suunniteltua ikkunamanageria.

Lue lisää

"Miksi mitään DVD-R levyjä pitäisi edes kirjoittaa? Eihän tuollaisia ole tarvittu missään yli kymmeneen vuoteen."

Markkinataloudessa (jollaisena Suomea voidaan pitää) yritykset pitävät kaupan tuotteita / palveluita, joille löytyy maksukykyisiä asiakkaita.

Mikäli väitteesi siitä, ettei kukaan ole tarvinnut DVD-R -levyjä yli kymmeneen vuoteen, pitäisi paikkansa, ei niitä myöskään kukaan myisi, kun ei olisi maksavia asiakkaitakaan.

Katsotaanpa:

https://www.jimms.fi/fi/Product/List/000-08R/tarvikkeet--tallennustarvikkeet--cd-dvd-br-mediat--cd-r-w-dvd-r-w-mediat

https://www.verkkokauppa.com/fi/catalog/3883c/Mediat-DVD-R

https://www.teknikmagasinet.fi/hakutulokset?ProductGroups=c1cfae2e-9f1f-4ae6-bd44-20e08e8ab824&q=DVD-R

http://www.clasohlson.com/fi/b/Elektroniikka/Tallennustarvikkeet/CD-,-DVD--&-Blu-ray-säilytys

http://www.mikroaitta.fi/index.php?id_category=238&controller=category

Siis ainakin jimm's, verkkokauppa.com, teknikmagasinet.fi, clasohlson.fi sekä mikroaitta.fi kaikki ovat yrityksinä sitä mieltä, että DVD-R -tallennusmedioiden myynnille löytyy maksavia asiakkaita.

Eiköhän tämä riitä osoittamaan väitteesi huuhaaksi.

DVD-R -levyille tulee riittämään kysyntää vielä pitkään.

Yksi (joskaan ei ainoa) syy muuten siihen, MIKSI DVD-R:lle riittää kysyntää vielä pitkään, on linux -jakelujen onneton laatu.

Lähes jokainen linux -jakelu on asennettavissa joko CD tai DVD -levyltä.

Mutta vain jotkut jakelut ovat sellaisia, että niiden CD tai DVD iso imagen voisi sellaisenaan kopioida esim. USB -muistitikulle, ja ko. jakelun voisi sitten asentaa ko. USB -muistitikulta.

Jotta jakelun voisi hyväksyä sellaiseksi, että ISO image on sellaisenaan kelpaava USB -muistitikulle, niin sen pitää täyttää tämä ehto:

kokeillaan, onko jakelu kelvollinen:

dd if=/path/to/isoimage/linuxjakelun_asennuslevy.iso bs=2048 of=/dev/sd?

(edelläolevassa korvaa ? asianmukaisella kirjaintunnuksella, joka viittaa USB -muistitikkuun ns. raakamuodossa, eli "koko levy".

JOS em. komennon suoritus linuxissa, esim knoppixissa, johtaa buuttikelpoiseen USB -muistitikkuun, jolta ko. linuxjakelun voi asentaa, silloin ko. jakelu on sellaisenaan asennuskelpoinen USB -tikulta.

JOS edellämainittu dd -komento EI JOHDA buuttikelpoiseen USB -muistitikkuun, tai asennusyritys ko. tikulta epäonnistuu, silloin tällainen linuxjakelu ei ole USB -muistitikkukelpoinen, ja tällaisessa tapauksessa on viisainta joko:

a) hylätä tällainen huonosti tehty linuxjakelu kokonaan (edllyyttää toki, että on olemassa joku muu linuxjakelu, joka on muistitikkukelpoinen JA joka täyttää käyttäjän muut tarpeet)

tai

b) asentaa jakelu vanhaan tapaan CD tai DVD -levyltä.

Veikkaanpa, että alle 10% linuxjakeluista on muistitikkukelpoisia em. kriteereillä.

turha tarjota jotain unetbootin -ohjelmaa buuttaavan muistitikun tekemiseksi, kun moiset ohjelmat eivät toimi kunnolla.

oma kokemus unetbootin -ohjelmasta:

Unetbootin sai aikaiseksi muistitikun, jolta ubuntu YRITTI asentua. Asennus kuitenkin keskeytyi varhaisessa vaiheessa virheilmoitukseen siitä, että /tmp on read-only, eikä asennusta tämän takia voi jatkaa.

Tuo on niin malliesimerkki siitä, miten asiat linux -maailmassa "toimivat".

Eli kun ilmaiseksi saa, kukaan ei ole missään vastuussa siitä, kun asiat menevät pieleen.

Windowsin eri versioita olen asentanut lukuisia kertoja useisiin eri tietokoneisiin, ja joka kerta on asennus onnistunut.

Johtunee siitä, että kun Microsoft saa rahaa jokaisesta myydystä windows -lisenssistä, niin MS:llä on sekä halua että resursseja huolehtia siitä, että tuote on sellainen, joka myös käytännössä on asennettavissa ja toimii.

Linuxissa taas, kun kenelläkään ei ole taloudellisia intressejä pitää huolta tuotteen toimivuudesta, niin linux -puolella jää asentajan ongelmaksi, jos homma ei jostain syystä toimi.

Käyttiksen_asentaja kirjoitti:

"Miksi mitään DVD-R levyjä pitäisi edes kirjoittaa? Eihän tuollaisia ole tarvittu missään yli kymmeneen vuoteen."

Markkinataloudessa (jollaisena Suomea voidaan pitää) yritykset pitävät kaupan tuotteita / palveluita, joille löytyy maksukykyisiä asiakkaita.

Mikäli väitteesi siitä, ettei kukaan ole tarvinnut DVD-R -levyjä yli kymmeneen vuoteen, pitäisi paikkansa, ei niitä myöskään kukaan myisi, kun ei olisi maksavia asiakkaitakaan.

Katsotaanpa:

https://www.jimms.fi/fi/Product/List/000-08R/tarvikkeet--tallennustarvikkeet--cd-dvd-br-mediat--cd-r-w-dvd-r-w-mediat

https://www.verkkokauppa.com/fi/catalog/3883c/Mediat-DVD-R

https://www.teknikmagasinet.fi/hakutulokset?ProductGroups=c1cfae2e-9f1f-4ae6-bd44-20e08e8ab824&q=DVD-R

http://www.clasohlson.com/fi/b/Elektroniikka/Tallennustarvikkeet/CD-,-DVD--&-Blu-ray-säilytys

http://www.mikroaitta.fi/index.php?id_category=238&controller=category

Siis ainakin jimm's, verkkokauppa.com, teknikmagasinet.fi, clasohlson.fi sekä mikroaitta.fi kaikki ovat yrityksinä sitä mieltä, että DVD-R -tallennusmedioiden myynnille löytyy maksavia asiakkaita.

Eiköhän tämä riitä osoittamaan väitteesi huuhaaksi.

DVD-R -levyille tulee riittämään kysyntää vielä pitkään.

Yksi (joskaan ei ainoa) syy muuten siihen, MIKSI DVD-R:lle riittää kysyntää vielä pitkään, on linux -jakelujen onneton laatu.

Lähes jokainen linux -jakelu on asennettavissa joko CD tai DVD -levyltä.

Mutta vain jotkut jakelut ovat sellaisia, että niiden CD tai DVD iso imagen voisi sellaisenaan kopioida esim. USB -muistitikulle, ja ko. jakelun voisi sitten asentaa ko. USB -muistitikulta.

Jotta jakelun voisi hyväksyä sellaiseksi, että ISO image on sellaisenaan kelpaava USB -muistitikulle, niin sen pitää täyttää tämä ehto:

kokeillaan, onko jakelu kelvollinen:

dd if=/path/to/isoimage/linuxjakelun_asennuslevy.iso bs=2048 of=/dev/sd?

(edelläolevassa korvaa ? asianmukaisella kirjaintunnuksella, joka viittaa USB -muistitikkuun ns. raakamuodossa, eli "koko levy".

JOS em. komennon suoritus linuxissa, esim knoppixissa, johtaa buuttikelpoiseen USB -muistitikkuun, jolta ko. linuxjakelun voi asentaa, silloin ko. jakelu on sellaisenaan asennuskelpoinen USB -tikulta.

JOS edellämainittu dd -komento EI JOHDA buuttikelpoiseen USB -muistitikkuun, tai asennusyritys ko. tikulta epäonnistuu, silloin tällainen linuxjakelu ei ole USB -muistitikkukelpoinen, ja tällaisessa tapauksessa on viisainta joko:

a) hylätä tällainen huonosti tehty linuxjakelu kokonaan (edllyyttää toki, että on olemassa joku muu linuxjakelu, joka on muistitikkukelpoinen JA joka täyttää käyttäjän muut tarpeet)

tai

b) asentaa jakelu vanhaan tapaan CD tai DVD -levyltä.

Veikkaanpa, että alle 10% linuxjakeluista on muistitikkukelpoisia em. kriteereillä.

turha tarjota jotain unetbootin -ohjelmaa buuttaavan muistitikun tekemiseksi, kun moiset ohjelmat eivät toimi kunnolla.

oma kokemus unetbootin -ohjelmasta:

Unetbootin sai aikaiseksi muistitikun, jolta ubuntu YRITTI asentua. Asennus kuitenkin keskeytyi varhaisessa vaiheessa virheilmoitukseen siitä, että /tmp on read-only, eikä asennusta tämän takia voi jatkaa.

Tuo on niin malliesimerkki siitä, miten asiat linux -maailmassa "toimivat".

Eli kun ilmaiseksi saa, kukaan ei ole missään vastuussa siitä, kun asiat menevät pieleen.

Windowsin eri versioita olen asentanut lukuisia kertoja useisiin eri tietokoneisiin, ja joka kerta on asennus onnistunut.

Johtunee siitä, että kun Microsoft saa rahaa jokaisesta myydystä windows -lisenssistä, niin MS:llä on sekä halua että resursseja huolehtia siitä, että tuote on sellainen, joka myös käytännössä on asennettavissa ja toimii.

Linuxissa taas, kun kenelläkään ei ole taloudellisia intressejä pitää huolta tuotteen toimivuudesta, niin linux -puolella jää asentajan ongelmaksi, jos homma ei jostain syystä toimi.

Lue lisää

"Markkinataloudessa (jollaisena Suomea voidaan pitää) yritykset pitävät kaupan tuotteita / palveluita, joille löytyy maksukykyisiä asiakkaita."

Se ei tarkoita sitä, että maksukykyiset asiakkaat tekisi järkeviä päätöksiä.

Tiesitkös sitä, että on olemassa sellainen juttu myös kuin "finanssimarkkinat" joka perustuu täysin siihen, että niin moni ihminen ei osaa käyttää rahaa.

"Yksi (joskaan ei ainoa) syy muuten siihen, MIKSI DVD-R:lle riittää kysyntää vielä pitkään, on linux -jakelujen onneton laatu."

Minkään Linuxia käyttävän käyttöjärjestelmän laatu ei liity mihinkään toiseen käyttöjärjestelmään joka käyttää Linuxia, joten tuo väite on roskaa.

Vaihtoehtoisesti se onneton laatu liity Windowsiin koska se on ainoa viestissäsi mainittu käyttöjärjestelmä.

"Mutta vain jotkut jakelut ovat sellaisia, että niiden CD tai DVD iso imagen voisi sellaisenaan kopioida esim. USB -muistitikulle, ja ko. jakelun voisi sitten asentaa ko. USB -muistitikulta."

Miksi kaikkien mahdollisten käyttöjärjestelmien pitäisi olla asennettavissa muistitikulta? Onko sellainen käyttöjärjestelmässä onneton laatu jota ei pysty asentamaan tikulta?

"Jotta jakelun voisi hyväksyä sellaiseksi, että ISO image on sellaisenaan kelpaava USB -muistitikulle, niin sen pitää täyttää tämä ehto:"

Et nähtävästi tunne PC-tekniikan perusteita sillä boottaavat CD-levyt toimivat El Torito:lla eikä se ole sama kuin USB-tikuissa. Boottaavissa USB-tikuissa käytetään eri imagea kuin CD/DVD -levyissä.

"JOS edellämainittu dd -komento EI JOHDA buuttikelpoiseen USB -muistitikkuun, tai asennusyritys ko. tikulta epäonnistuu, silloin tällainen linuxjakelu ei ole USB -muistitikkukelpoinen, ja tällaisessa tapauksessa on viisainta joko:"

Ei tämä liity millään tavalla Linuxiin. USB-tikut tavallisesti kirjoitetaan ohjelmalla joka tekee niistä USB-tikuille yhteensopivia. Eri käyttöjärjestelmissä on erilaiset työkalut.

"a) hylätä tällainen huonosti tehty linuxjakelu kokonaan (edllyyttää toki, että on olemassa joku muu linuxjakelu, joka on muistitikkukelpoinen JA joka täyttää käyttäjän muut tarpeet)"

Windows 7 pitää siis hylätä kelvottomana ja huonosti tehtynä. Sinne menee sinun Delphi 7 ohjelmat myös.

"turha tarjota jotain unetbootin -ohjelmaa buuttaavan muistitikun tekemiseksi, kun moiset ohjelmat eivät toimi kunnolla."

USB-tikku tehdään käyttöjärjestelmän valmistajan omalla työkalulla. Applella, Canonicalilla, Microsoftilla, Red Hatilla jne. on jokaisella oma työkalu tähän.

"Unetbootin sai aikaiseksi muistitikun, jolta ubuntu YRITTI asentua. Asennus kuitenkin keskeytyi varhaisessa vaiheessa virheilmoitukseen siitä, että /tmp on read-only, eikä asennusta tämän takia voi jatkaa.

Tuo on niin malliesimerkki siitä, miten asiat linux -maailmassa "toimivat"."

No ei tämä liity mitenkään Linuxiin eikä Ubuntuun vaan sinuun. Miksi et käytä sitä Ubuntun virallista työkalua USB-tikun tekoon mikä toimii? Ihan selvästi oma vikasi.

"Windowsin eri versioita olen asentanut lukuisia kertoja useisiin eri tietokoneisiin, ja joka kerta on asennus onnistunut."

No kerro miten Windows 7 kirjoitetaan USB-tikulle dd komennolla vai puhuitko paskaa?

"Johtunee siitä, että kun Microsoft saa rahaa jokaisesta myydystä windows -lisenssistä, niin MS:llä on sekä halua että resursseja huolehtia siitä, että tuote on sellainen, joka myös käytännössä on asennettavissa ja toimii."

Tuotteet toimii muillakin ja on tehty kunnollisilla resursseilla mutta tässä nyt olikin asentajan mokailua.

"Linuxissa taas, kun kenelläkään ei ole taloudellisia intressejä pitää huolta tuotteen toimivuudesta"

Linux ei liity mitenkään tähän.

Paskanjauhanta jatkuu,
suurimman osan yleisimmistä Linux-jakeluista saa asennettua tikulta.

M-Kar kirjoitti:

"Markkinataloudessa (jollaisena Suomea voidaan pitää) yritykset pitävät kaupan tuotteita / palveluita, joille löytyy maksukykyisiä asiakkaita."

Se ei tarkoita sitä, että maksukykyiset asiakkaat tekisi järkeviä päätöksiä.

Tiesitkös sitä, että on olemassa sellainen juttu myös kuin "finanssimarkkinat" joka perustuu täysin siihen, että niin moni ihminen ei osaa käyttää rahaa.

"Yksi (joskaan ei ainoa) syy muuten siihen, MIKSI DVD-R:lle riittää kysyntää vielä pitkään, on linux -jakelujen onneton laatu."

Minkään Linuxia käyttävän käyttöjärjestelmän laatu ei liity mihinkään toiseen käyttöjärjestelmään joka käyttää Linuxia, joten tuo väite on roskaa.

Vaihtoehtoisesti se onneton laatu liity Windowsiin koska se on ainoa viestissäsi mainittu käyttöjärjestelmä.

"Mutta vain jotkut jakelut ovat sellaisia, että niiden CD tai DVD iso imagen voisi sellaisenaan kopioida esim. USB -muistitikulle, ja ko. jakelun voisi sitten asentaa ko. USB -muistitikulta."

Miksi kaikkien mahdollisten käyttöjärjestelmien pitäisi olla asennettavissa muistitikulta? Onko sellainen käyttöjärjestelmässä onneton laatu jota ei pysty asentamaan tikulta?

"Jotta jakelun voisi hyväksyä sellaiseksi, että ISO image on sellaisenaan kelpaava USB -muistitikulle, niin sen pitää täyttää tämä ehto:"

Et nähtävästi tunne PC-tekniikan perusteita sillä boottaavat CD-levyt toimivat El Torito:lla eikä se ole sama kuin USB-tikuissa. Boottaavissa USB-tikuissa käytetään eri imagea kuin CD/DVD -levyissä.

"JOS edellämainittu dd -komento EI JOHDA buuttikelpoiseen USB -muistitikkuun, tai asennusyritys ko. tikulta epäonnistuu, silloin tällainen linuxjakelu ei ole USB -muistitikkukelpoinen, ja tällaisessa tapauksessa on viisainta joko:"

Ei tämä liity millään tavalla Linuxiin. USB-tikut tavallisesti kirjoitetaan ohjelmalla joka tekee niistä USB-tikuille yhteensopivia. Eri käyttöjärjestelmissä on erilaiset työkalut.

"a) hylätä tällainen huonosti tehty linuxjakelu kokonaan (edllyyttää toki, että on olemassa joku muu linuxjakelu, joka on muistitikkukelpoinen JA joka täyttää käyttäjän muut tarpeet)"

Windows 7 pitää siis hylätä kelvottomana ja huonosti tehtynä. Sinne menee sinun Delphi 7 ohjelmat myös.

"turha tarjota jotain unetbootin -ohjelmaa buuttaavan muistitikun tekemiseksi, kun moiset ohjelmat eivät toimi kunnolla."

USB-tikku tehdään käyttöjärjestelmän valmistajan omalla työkalulla. Applella, Canonicalilla, Microsoftilla, Red Hatilla jne. on jokaisella oma työkalu tähän.

"Unetbootin sai aikaiseksi muistitikun, jolta ubuntu YRITTI asentua. Asennus kuitenkin keskeytyi varhaisessa vaiheessa virheilmoitukseen siitä, että /tmp on read-only, eikä asennusta tämän takia voi jatkaa.

Tuo on niin malliesimerkki siitä, miten asiat linux -maailmassa "toimivat"."

No ei tämä liity mitenkään Linuxiin eikä Ubuntuun vaan sinuun. Miksi et käytä sitä Ubuntun virallista työkalua USB-tikun tekoon mikä toimii? Ihan selvästi oma vikasi.

"Windowsin eri versioita olen asentanut lukuisia kertoja useisiin eri tietokoneisiin, ja joka kerta on asennus onnistunut."

No kerro miten Windows 7 kirjoitetaan USB-tikulle dd komennolla vai puhuitko paskaa?

"Johtunee siitä, että kun Microsoft saa rahaa jokaisesta myydystä windows -lisenssistä, niin MS:llä on sekä halua että resursseja huolehtia siitä, että tuote on sellainen, joka myös käytännössä on asennettavissa ja toimii."

Tuotteet toimii muillakin ja on tehty kunnollisilla resursseilla mutta tässä nyt olikin asentajan mokailua.

"Linuxissa taas, kun kenelläkään ei ole taloudellisia intressejä pitää huolta tuotteen toimivuudesta"

Linux ei liity mitenkään tähän.

Lue lisää

"Miksi et käytä sitä Ubuntun virallista työkalua USB-tikun tekoon mikä toimii? Ihan selvästi oma vikasi"

tämä kuvastaa parhaiten linux -fanaatikkojen asennevammaa!

Siis miten sitä ubuntun omaa työkalua edes teoriassa voisi käyttää, kun en omista yhtään PC -tietokonetta, jossa jo olisi ubuntu asennettuna ?

On toki totta, että CD ja DVD -levyillä käytetään El Torito -systeemiä, jolloin CD tai DVD -levystä saadaan buuttaava.

JOS olisit viitsinyt hieman tutustua siihen, mitä tuo El Torito käytännössä tarkoittaa, niin levyn alussa on aikamoinen määrä määrittelemätöntä dataa (joka on usein pelkkiä nollia). Mutta kukaan ei estä tekemästä fiksua .ISO -asennusmediatiedostoa, jossa levyn alussa olevat nollat on korvattu sellaisella konekielikoodilla, että jos ISOn sellaisenaan kopioi muistitikun alkuun, niin seurauksena on oikein toimiva buuttaava muistitikku.

Parhaat linuxjakelut toimivat juuri näin, muut todennäköisesti eivät (kun kehittäjiä ei tekninen toimivuus kiinnosta).

Ja mitä Windows 7:aan tulee, sen ostaja saa tietysti ihan tehdasprässätyn DVD -asennuslevyn kaupan mukana, joten sen asennuksessa ei ole mitään ongelmaa. Windows 7:n asennus on helppoa, ja kiitos Microsoftilla tehdyn huolellisen työn, se onnistuu yleensä kaikkiin PC -tietokoneisiin ongelmitta.

delphikoodaaja kirjoitti:

"Miksi et käytä sitä Ubuntun virallista työkalua USB-tikun tekoon mikä toimii? Ihan selvästi oma vikasi"

tämä kuvastaa parhaiten linux -fanaatikkojen asennevammaa!

Siis miten sitä ubuntun omaa työkalua edes teoriassa voisi käyttää, kun en omista yhtään PC -tietokonetta, jossa jo olisi ubuntu asennettuna ?

On toki totta, että CD ja DVD -levyillä käytetään El Torito -systeemiä, jolloin CD tai DVD -levystä saadaan buuttaava.

JOS olisit viitsinyt hieman tutustua siihen, mitä tuo El Torito käytännössä tarkoittaa, niin levyn alussa on aikamoinen määrä määrittelemätöntä dataa (joka on usein pelkkiä nollia). Mutta kukaan ei estä tekemästä fiksua .ISO -asennusmediatiedostoa, jossa levyn alussa olevat nollat on korvattu sellaisella konekielikoodilla, että jos ISOn sellaisenaan kopioi muistitikun alkuun, niin seurauksena on oikein toimiva buuttaava muistitikku.

Parhaat linuxjakelut toimivat juuri näin, muut todennäköisesti eivät (kun kehittäjiä ei tekninen toimivuus kiinnosta).

Ja mitä Windows 7:aan tulee, sen ostaja saa tietysti ihan tehdasprässätyn DVD -asennuslevyn kaupan mukana, joten sen asennuksessa ei ole mitään ongelmaa. Windows 7:n asennus on helppoa, ja kiitos Microsoftilla tehdyn huolellisen työn, se onnistuu yleensä kaikkiin PC -tietokoneisiin ongelmitta.

Lue lisää

"Siis miten sitä ubuntun omaa työkalua edes teoriassa voisi käyttää, kun en omista yhtään PC -tietokonetta, jossa jo olisi ubuntu asennettuna ?"

Osta sitten sellainen tietokone tai teetä se levy muualla.

"Ja mitä Windows 7:aan tulee, sen ostaja saa tietysti ihan tehdasprässätyn DVD -asennuslevyn kaupan mukana"

Mutta sinä sanoit, että käyttöjärjestelmä on kelvoton jos sitä ei saa dd komenolla tikulle.

"joten sen asennuksessa ei ole mitään ongelmaa."

On toki kun kaikki tietokoneet eivät ole Windows 7 yhteensopivia tai niissä ei ole DVD-asemaa.

"kysmys: miksi Debianin asennusohjelma tunnistaa joissain vanhoissa PC -koneissa virheellisesti, että koneessa muka on UEFI, vaikka todellisuudessa koneessa EI OLE UEFI:a, vaan ihan se perinteinen BIOS"

Vaikka siksi kun se BIOS/UEFI ja myös ACPI on jotain järkyttävää paskaa. Kaikkea ei ole standardoitu ja se mitä on standardoitu niin kaikki eivät toteuta standardia tai tulkitsevat sitä miten sattuu.

Jos sitä vikaa jostain pitää etsiä niin todennäköinen sijainti on firmware jota on ties kenen kiinalaisen alihankkijan alipalkattu kaveri krapulapäissään koodaillut.

Käytännössä näitä kun asennellaan sellaisiin laitteisiin missä kukaan ei ole lupaa mitään niin noitahan sitten värkätään eri asentoihin noita vipuja ja katsotaan mikä toimii.

Teollisuusvehkeissä ja servereissä asiat huomattavasti paremmalla mallilla ja toimivat kuten pitää ja markettien halpisläppärit sitten kauheimpia.

EI, vaan se vika on huonosti tehdyssä debianin asennusohjelmassa.

Hyvin tehty ohjelma tunnistais oikein, onko koneessa perinteinen BIOS vai se uudempi UEFI.

JOS GPL -fanaatikkokoodaajat eivät kykene kirjoittamaan koodia, joka luotettavasti tuon tunnistaisi, niin 2. paras vaihtoehto:

Asennusohjelma tunnistaa (virheellisesti): "koneessa tunnistettu UEFI". Jos hyväksyt tämän, paina "Jatka". Voit myös käsin korjata väärän tiedon klikkaamalla ensin radionappia "BIOS" ja vasta sen jälkeen painaa "Jatka".

Mutta kun näitä avoimen lähdekoodin virityksiä (kuten Debian) tekevät tahot, joita lopputuloksen toimivuus ei pätkääkään kiinnosta, niin eipä ole tuollaistakaan mahdollisuutta.

Kuten todettu, Windowsista olen asentanut lukuisia versioita, enkä ole kertaakaan törmännyt tällaiseen ongelmaan.

Kumma asia, että Microsoftin koodaajat osaavat tehdä oikein toimivan tunnistuksen, onko koneessa BIOS vai UEFI.

Taitaa ollakin se GPL -lisenssifanatismi, joka aiheuttaa sen, ettei oikein toimivaa koodia enää osata kirjoittaa.

Tai ehkä johtuu siitä, että on koodattu C -kielellä, ja kyseisen kielen sekava ja epälooginen syntaksi on harhauttanut ohjelmoijaparan koodaamaan väärin ja lopputulos on juuri edellä kuvattu.

ehkä on kirjoitettu C:llä:

if (Has_UEFI = 1) {
install_UEFI_bootloader();
} else {
install_BIOS_bootloader();
}

Tässä siis C -kielen paska syntaksi on harhauttanut koodaajan tekemään virheen, ja surkuhupaisaa on se, että jos olisi kirjoitettu FreePascalilla, koodi toimisi oikein. FreePascalissa ei ole tällaista C-kielelle tyypillistä virhemahdollisuutta.

Windows asentuu ja toimii hyvin, Debian ei asennu, kun virheellisesti luulee koneessaa olevan UEFI, vaikka kone on niin vanha, ettei sen valmistushetkellä UEFIa ollut olemassakaan, vaan se oli vasta työn alla.

delphikoodaaja kirjoitti:

EI, vaan se vika on huonosti tehdyssä debianin asennusohjelmassa.

Hyvin tehty ohjelma tunnistais oikein, onko koneessa perinteinen BIOS vai se uudempi UEFI.

JOS GPL -fanaatikkokoodaajat eivät kykene kirjoittamaan koodia, joka luotettavasti tuon tunnistaisi, niin 2. paras vaihtoehto:

Asennusohjelma tunnistaa (virheellisesti): "koneessa tunnistettu UEFI". Jos hyväksyt tämän, paina "Jatka". Voit myös käsin korjata väärän tiedon klikkaamalla ensin radionappia "BIOS" ja vasta sen jälkeen painaa "Jatka".

Mutta kun näitä avoimen lähdekoodin virityksiä (kuten Debian) tekevät tahot, joita lopputuloksen toimivuus ei pätkääkään kiinnosta, niin eipä ole tuollaistakaan mahdollisuutta.

Kuten todettu, Windowsista olen asentanut lukuisia versioita, enkä ole kertaakaan törmännyt tällaiseen ongelmaan.

Kumma asia, että Microsoftin koodaajat osaavat tehdä oikein toimivan tunnistuksen, onko koneessa BIOS vai UEFI.

Taitaa ollakin se GPL -lisenssifanatismi, joka aiheuttaa sen, ettei oikein toimivaa koodia enää osata kirjoittaa.

Tai ehkä johtuu siitä, että on koodattu C -kielellä, ja kyseisen kielen sekava ja epälooginen syntaksi on harhauttanut ohjelmoijaparan koodaamaan väärin ja lopputulos on juuri edellä kuvattu.

ehkä on kirjoitettu C:llä:

if (Has_UEFI = 1) {
install_UEFI_bootloader();
} else {
install_BIOS_bootloader();
}

Tässä siis C -kielen paska syntaksi on harhauttanut koodaajan tekemään virheen, ja surkuhupaisaa on se, että jos olisi kirjoitettu FreePascalilla, koodi toimisi oikein. FreePascalissa ei ole tällaista C-kielelle tyypillistä virhemahdollisuutta.

Windows asentuu ja toimii hyvin, Debian ei asennu, kun virheellisesti luulee koneessaa olevan UEFI, vaikka kone on niin vanha, ettei sen valmistushetkellä UEFIa ollut olemassakaan, vaan se oli vasta työn alla.

Lue lisää

"EI, vaan se vika on huonosti tehdyssä debianin asennusohjelmassa."

Todista.

Koitin hakea tietoa mutta en nyt löytänyt mitään standardia tälle enkä myöskään vahvistusta siitä, että Debianissa olisi tehty jotain standardin vastaisesti.

"Asennusohjelma tunnistaa (virheellisesti): "koneessa tunnistettu UEFI". Jos hyväksyt tämän, paina "Jatka". Voit myös käsin korjata väärän tiedon klikkaamalla ensin radionappia "BIOS" ja vasta sen jälkeen painaa "Jatka".""

Onhan siellä Debianin installerissa ne käynnistysoptiot: https://www.debian.org/releases/stable/amd64/ch05s01.html.en#boot-screen

"Kuten todettu, Windowsista olen asentanut lukuisia versioita, enkä ole kertaakaan törmännyt tällaiseen ongelmaan."

Kuten todettu. Debiania olen asentanut lukusia versioita enkä ole kertaakaan törmännyt tällaiseen ongelmaan. Havaintojen perusteella tämä johtuu siis sinusta tai sitten tietokonelaitteistasi.

"Delphi 4 näyttää toimivan hyvin WIN10 (64bit):ssä."

Mutta et tiedä missä päivityksessä se ja kaikki Delphi 4:llä tehdyt ohjelmat lakkaavat toimimasta.

Itseasiassa tiedetään jo Delphi 4 aikaisen Windowsin versiotarkistuksen, GetVersionEx toiminnan muuttuneen. Se tarkoittaa sitä Delphi 4:llä tehty ohjelma joka tarkistaa Windowsin versiota voi vaikka kaatua käynnistyksessä.

"Päinvastoin kuin Delphi 2006, joka ei suostunut edes asentumaan (NET-juttujensa takia ilmeisesti)."

Eli todistettavasti vanhat ohjelmat hajoavat itsekseen. .NET:stä se ei johdu, vanhat .NET 2.0-3.5 versiot toimivat täysin varmasti vielä vuoden verran Windows 10:ssä 64-bittisesti. Oletuksena .NET 2.0-3.5 ei ole Windows 10:ssä päällä kun vanhoista jutuista hankkiudutaan eroon.

.NET:n ja vanhempien rajapintojen ero on se, että .NET toimii luvatusti vähintään tietyn aikaa. Vanhimmat viritykset lakkaavat toimimasta asteittain. Eli kun vaikka GDI tai Windows metafile poistuu niin kaikki näistä riippuvaiset jutut lakkaavat toimimasta.

Myöskin päivitys vanhasta .NET:stä .NET 4.x:n käy käytännössä ilman muutoksia koodiin, vanhat Delphi 4 aikaiset kurttaukset kirjoitetaan täysin uusiksi.