Asenna kehitystyökalut kerralla

Kehitystyökalut voidaan asentaa joko yksitellen tai kaikki kerralla, kuten tässä neuvotaan. Näin tehtynä se on paljon helpompaa.

sudo apt-get install build-essential

Tuon tuloksena asentuu seuraavat kehitystyökalut:

binutils
cpp
gcc-5-locales
g++-multilib
g++-5-multilib
gcc-5-doc
gcc-multilib
autoconf
automake
libtool
flex
bison
gdb
gcc-doc
gcc-5-multilib

Nyt ei GitHubilta ladatut käännettävätkään ole enään ongelma.

Linux Mint 18.1 Serena
Xfce 64-bit
Ilmianna
Jaa

90 Vastausta


Ja mitäs noilla kehitystyökaluilla tekee jos ei osaa ohjelmoida mitään. Mutta nyt sekin on helppo oppia sillä tällä ohjeella lataa sata kunta ilmaista EBOOK käsikirjaa kerralla, siististi omiin kansioihinsa sijoitettuna.

wget -x -i http://pastebin.com/raw/nyFtp2EG

Eikä siinä kaikki, tämä wget auttaa myös silloin kun DepositFiles Filemanager asettelee ilmaiselle latauksille ikäviä aika ja yhtaikaisten latauksien rajoituksia. Tuo sinun pitää kuitenkin opetella ihan itse. Myös katkennut verkkoyhteys ei ole ongelma, voit jatkaa siitä mihin jäit, kun taas yhteys on käytettävissä.

Eikun mukavia lukuhetkiä asiasta kiinnostuneille.

Linux Mint 18.1 Serena
Xfce 64-bit
Kommentoi
1
Ilmianna
Jaa
1 VASTAUS:
Tuossa meinas unohtua nämä Windows käyttäjät, myös heille on satoja ilmaisia EBOOKeja. Tähän linkkiin kannattaa tutustua, jokaiselle jotakin, ja eikä maksa mitään.

https://blogs.msdn.microsoft.com/mssmallbiz/2016/07/10/free-thats-right-im-giving-away-millions-of-free-microsoft-ebooks-again-including-windows-10-office-365-office-2016-power-bi-azure-windows-8-1-office-2013-sharepoint-2016-sha/

Linux Mint 18.1 Serena
Xfce 64-bit

PS: Hyvien vinkkien peukuttaminen ei ole kiellettyä.
Kommentoi
1
Ilmianna
Jaa
+Lisää kommentti
Tai vielä helpommin: lataa ja asenna Visual Studio Community.
Kommentoi
1
Ilmianna
Jaa
41 VASTAUSTA:
Sehän vähän riippuu mitä tekee.

Nyt oli selvästikin kyse C ja C++ ohjelmoinnista ja Visual Studio Community on siihen aika huono.
Kommentoi
Ilmianna
Jaa
En asenna Windows ohjelmia vaikka vähän maksettaisiinkin.

Linux Mint 18.1 Serena
Xfce 64-bit
Kommentoi
1
Ilmianna
Jaa
M-Kar kirjoitti:
Sehän vähän riippuu mitä tekee.

Nyt oli selvästikin kyse C ja C++ ohjelmoinnista ja Visual Studio Community on siihen aika huono.
C ja C++ ohjelmointi ylipäätään on aika huonoa.
Kommentoi
2
Ilmianna
Jaa
fsafdsfdsafsa kirjoitti:
C ja C++ ohjelmointi ylipäätään on aika huonoa.
Riippuu mitä tekee.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Riippuu mitä tekee.
Sellainen ihminen joka tarvii opastuksen käännöstyökalujen asennukseen ei tee mitään sellaista missä c/c++ olisi järkevää.
Kommentoi
2
Ilmianna
Jaa
En-sitten-ikinä-asenna kirjoitti:
En asenna Windows ohjelmia vaikka vähän maksettaisiinkin.

Linux Mint 18.1 Serena
Xfce 64-bit
Visual Studio ei ole "windows-ohjelma".
Kommentoi
1
Ilmianna
Jaa
sdfasdasdasdas kirjoitti:
Visual Studio ei ole "windows-ohjelma".
Kyllä kaveri puhu "Tai vielä helpommin: lataa ja asenna Visual Studio Community" joka on windows ohjelma, mutta IDE Visual Studio Code on saatavissa lähes kaikille alustoille, jopa minäkin sitä kokeilin, ei miellyttänyt ja poistin.

Linux Mint 18.1 Serena
Xfce 64-bit
Kommentoi
1
Ilmianna
Jaa
Eikä ole, Visual Studion saa myös Macille ja oletettavasti siitä on Linux-versiokin tekeillä.
Kommentoi
1
Ilmianna
Jaa
M-Kar kirjoitti:
Riippuu mitä tekee.
'''''''Riippuu mitä tekee.''''''''
Mitähän sinä luulisit C ja C++ tehtävän. Tuossa ei järki päätä pakota, kun kirjotellaan.
Pistä nyt hitossa pientä rajaa tuolle mutuilulle.
Kommentoi
2
Ilmianna
Jaa
fyukitklyut kirjoitti:
'''''''Riippuu mitä tekee.''''''''
Mitähän sinä luulisit C ja C++ tehtävän. Tuossa ei järki päätä pakota, kun kirjotellaan.
Pistä nyt hitossa pientä rajaa tuolle mutuilulle.
C on työkalu systeemiohjelmointiin. Sillä tehdään matalan tason palikat järjestelmään.

C++:lla sitten on vähän erilaisia tarkoituksia. Käytetään middlewaressa, raskaassa numeronmurskauksessa OpenMP:n kanssa, CAD kernelit ja jne.

Eli eri työkaluja ja käytetään eri asioihin.

Visual Studio Community on vähän huono näihin kun se toimii Windowsissa. Windowspalvelimia ei käytetä laskentaklustereissa. Windows on suljettu järjestelmä eikä Windowsiin tehdä itse uusia kirjastoja tai muokata kerneliä. Koska Windows on yleisesti ottaen väärä ympäristö lähes aina C++:n sekä C:n käytössä niin myös Visual Studio Community on väärä valinta tähän.

Eli kyllä nyt ihan ensiksi pitäisi tietää mitä halutaan saada aikaiseksi, sitten valitaan työkalut sen mukaan.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
C on työkalu systeemiohjelmointiin. Sillä tehdään matalan tason palikat järjestelmään.

C++:lla sitten on vähän erilaisia tarkoituksia. Käytetään middlewaressa, raskaassa numeronmurskauksessa OpenMP:n kanssa, CAD kernelit ja jne.

Eli eri työkaluja ja käytetään eri asioihin.

Visual Studio Community on vähän huono näihin kun se toimii Windowsissa. Windowspalvelimia ei käytetä laskentaklustereissa. Windows on suljettu järjestelmä eikä Windowsiin tehdä itse uusia kirjastoja tai muokata kerneliä. Koska Windows on yleisesti ottaen väärä ympäristö lähes aina C++:n sekä C:n käytössä niin myös Visual Studio Community on väärä valinta tähän.

Eli kyllä nyt ihan ensiksi pitäisi tietää mitä halutaan saada aikaiseksi, sitten valitaan työkalut sen mukaan.
''''''''''Eli eri työkaluja ja käytetään eri asioihin.''''''''''''
Ihanko sinä itse tuon keksit. Sinä epäilit että kaveri ei tuota itse tiedä, niinkö.
Kommentoi
2
Ilmianna
Jaa
dtujyttoy8ulpu90 kirjoitti:
''''''''''Eli eri työkaluja ja käytetään eri asioihin.''''''''''''
Ihanko sinä itse tuon keksit. Sinä epäilit että kaveri ei tuota itse tiedä, niinkö.
Tältähän se vahvasti vaikuttaa kun kerran sanoo, että C:llä ja C++:lla ohjelmointi on "huonoa". Ei perustu mihinkään tuollainen naurettava väite.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Tältähän se vahvasti vaikuttaa kun kerran sanoo, että C:llä ja C++:lla ohjelmointi on "huonoa". Ei perustu mihinkään tuollainen naurettava väite.
Eli kaverilla voi olla vain sinun hyväksymä mielipide asiasta, tai muuten alat nälvimään kaverin ymmärrystä, eikä kaverin ajatus voi perustua mihinkään, ja on erittäin naurettava väite.

Mistä tiedät että vain sinun mielipide on se ainut oikea.
Kommentoi
1
Ilmianna
Jaa
e56ur67iu7t68o6 kirjoitti:
Eli kaverilla voi olla vain sinun hyväksymä mielipide asiasta, tai muuten alat nälvimään kaverin ymmärrystä, eikä kaverin ajatus voi perustua mihinkään, ja on erittäin naurettava väite.

Mistä tiedät että vain sinun mielipide on se ainut oikea.
Toistaiseksi vain minun mielipide perustuu johonkin. On perusteltu ja todistettavissa: http://keskustelu.suomi24.fi/t/14680392/asenna-kehitystyokalut-kerralla#comment-89735922

Ei ole esitetty minkäänlaisia perusteita "huonolle", mutta on todistettavissa että ei pidä paikkaansa. C kieli on defacto systeemiohjelmoinnissa. Kaikki tuotantokernelit ja matalan tason komponentit käyttöjärjestelmissä on tehty C:llä. Se on siis siihen juurikin ideaalinen ohjelmointikieli eikä "huono".

Havaintojen perusteella tähän ketjuun ei ole kukaan esittänyt muuta järjestellistä mielipidettä joka ei olisi todistettavissa virheelliseksi.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Toistaiseksi vain minun mielipide perustuu johonkin. On perusteltu ja todistettavissa: http://keskustelu.suomi24.fi/t/14680392/asenna-kehitystyokalut-kerralla#comment-89735922

Ei ole esitetty minkäänlaisia perusteita "huonolle", mutta on todistettavissa että ei pidä paikkaansa. C kieli on defacto systeemiohjelmoinnissa. Kaikki tuotantokernelit ja matalan tason komponentit käyttöjärjestelmissä on tehty C:llä. Se on siis siihen juurikin ideaalinen ohjelmointikieli eikä "huono".

Havaintojen perusteella tähän ketjuun ei ole kukaan esittänyt muuta järjestellistä mielipidettä joka ei olisi todistettavissa virheelliseksi.
Mitä nämä '''''''Kaikki tuotantokernelit''''' ovat ?
Mitä tämä '''''''defacto''''''' tarkoittaa ?
Kommentoi
2
Ilmianna
Jaa
tttktu7ktu7gk7it kirjoitti:
Mitä nämä '''''''Kaikki tuotantokernelit''''' ovat ?
Mitä tämä '''''''defacto''''''' tarkoittaa ?
Tuotantokäytössä olevien käyttöjärjestelmien kernelit tietysti. C on käytössä joka paikassa.

Defacto tarkoittaa teollisuusstandardia. C on teollisuusstandardi tekniikka systeemiohjelmoinnissa.

https://en.wikipedia.org/wiki/De_facto
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Tuotantokäytössä olevien käyttöjärjestelmien kernelit tietysti. C on käytössä joka paikassa.

Defacto tarkoittaa teollisuusstandardia. C on teollisuusstandardi tekniikka systeemiohjelmoinnissa.

https://en.wikipedia.org/wiki/De_facto
Noin siinä käy kun viljelee sivystyssanoja joiden merkitystä ei ymmärrä:

Defacto-standardeja
Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja.

"Tuotantokäytössä olevien käyttöjärjestelmien kernelit"
Anna nyt muutama esimerkki että voin tarkistaa onko kirjoitettu C:llä tai C++:lla
Kommentoi
2
Ilmianna
Jaa
rffffftiii78 kirjoitti:
Noin siinä käy kun viljelee sivystyssanoja joiden merkitystä ei ymmärrä:

Defacto-standardeja
Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja.

"Tuotantokäytössä olevien käyttöjärjestelmien kernelit"
Anna nyt muutama esimerkki että voin tarkistaa onko kirjoitettu C:llä tai C++:lla
https://www.kernel.org/
https://github.com/opensource-apple/xnu
http://cvsweb.netbsd.org/bsdweb.cgi/?only_with_tag=MAIN
https://cvsweb.openbsd.org/cgi-bin/cvsweb/
https://github.com/freebsd/freebsd
http://community.qnx.com/sf/sfmain/do/downloadAttachment/projects.core_os/wiki/BuildKernelWithIDE?id=atch1253

C näkyy olevan universaalisti.

"Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja."

Ei tarvitse edes olla kaupallisuutta mutta jos koko maailma käyttää tiettyä tekniikkaa jossain asiassa tai toimialalla niin se on defacto. Ja jos on defacto niin se on tällä hetkellä kyseissä hommassa soveltuvin.

Esimerkiksi C:n korvaaminen jollain toisella systeemiohjelmoinnissa on jokseenkin varmasti askel taaksepäin.

C:ssä kun on semmoisia juttuja kuin että soveltuu siihen, että ollaan lähellä rautaa. On pitkälle viedyt työkalut oikeellisuuden tarkistamiseen, suorituskyky, sertifiointia kriittisiin kohteisiin, standardoitu, yksinkertaisuus (saa vaatimattomassakin raudassa toimimaan) ja jne.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
https://www.kernel.org/
https://github.com/opensource-apple/xnu
http://cvsweb.netbsd.org/bsdweb.cgi/?only_with_tag=MAIN
https://cvsweb.openbsd.org/cgi-bin/cvsweb/
https://github.com/freebsd/freebsd
http://community.qnx.com/sf/sfmain/do/downloadAttachment/projects.core_os/wiki/BuildKernelWithIDE?id=atch1253

C näkyy olevan universaalisti.

"Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja."

Ei tarvitse edes olla kaupallisuutta mutta jos koko maailma käyttää tiettyä tekniikkaa jossain asiassa tai toimialalla niin se on defacto. Ja jos on defacto niin se on tällä hetkellä kyseissä hommassa soveltuvin.

Esimerkiksi C:n korvaaminen jollain toisella systeemiohjelmoinnissa on jokseenkin varmasti askel taaksepäin.

C:ssä kun on semmoisia juttuja kuin että soveltuu siihen, että ollaan lähellä rautaa. On pitkälle viedyt työkalut oikeellisuuden tarkistamiseen, suorituskyky, sertifiointia kriittisiin kohteisiin, standardoitu, yksinkertaisuus (saa vaatimattomassakin raudassa toimimaan) ja jne.
"Tuotantokäytössä olevien käyttöjärjestelmien kernelit"
Anna nyt muutama esimerkki että voin tarkistaa onko kirjoitettu C:llä tai C++:lla
Et sitten antanut yhtään linkkiä tuotantoympäristöön.

"Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja."
Tuo oli antamasi linkin sivulta lainattu.

'''''''Esimerkiksi C:n korvaaminen jollain toisella systeemiohjelmoinnissa on jokseenkin varmasti askel taaksepäin.''''''''
Perustele.

''''''''''C:ssä kun on semmoisia juttuja kuin että soveltuu siihen, että ollaan lähellä rautaa. On pitkälle viedyt työkalut oikeellisuuden tarkistamiseen, suorituskyky, sertifiointia kriittisiin kohteisiin, standardoitu, yksinkertaisuus (saa vaatimattomassakin raudassa toimimaan) ja jne.'''''''''
Mitkä työkalut ?
Suorituskyky, mihin verrattuna ?
''''''sertifiointia kriittisiin kohteisiin'''': Mistä löytää nää serifikaatit ?
'''''yksinkertaisuus''''': Mihin verrattuna ?
Kommentoi
1
Ilmianna
Jaa
tr78io7t8o66 kirjoitti:
"Tuotantokäytössä olevien käyttöjärjestelmien kernelit"
Anna nyt muutama esimerkki että voin tarkistaa onko kirjoitettu C:llä tai C++:lla
Et sitten antanut yhtään linkkiä tuotantoympäristöön.

"Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja."
Tuo oli antamasi linkin sivulta lainattu.

'''''''Esimerkiksi C:n korvaaminen jollain toisella systeemiohjelmoinnissa on jokseenkin varmasti askel taaksepäin.''''''''
Perustele.

''''''''''C:ssä kun on semmoisia juttuja kuin että soveltuu siihen, että ollaan lähellä rautaa. On pitkälle viedyt työkalut oikeellisuuden tarkistamiseen, suorituskyky, sertifiointia kriittisiin kohteisiin, standardoitu, yksinkertaisuus (saa vaatimattomassakin raudassa toimimaan) ja jne.'''''''''
Mitkä työkalut ?
Suorituskyky, mihin verrattuna ?
''''''sertifiointia kriittisiin kohteisiin'''': Mistä löytää nää serifikaatit ?
'''''yksinkertaisuus''''': Mihin verrattuna ?
"Et sitten antanut yhtään linkkiä tuotantoympäristöön."

Kyseisiä kerneleitä on yleisesti tuotantoympäristöissä käytössä.

Tuotannossahan ne on tietysti käännettynä binäärimuotoon, että sorsistahan se tarkistetaan, tietysti.

"Perustele."

C on standardoitu
C mahdollistaa helposti vakaana pysyvän ABI:n
C on suorituskykyinen
C sopii laitteistonläheiseen ohjelmointiin
C:lle sopivia työkaluja ja systeemikoodia on sertifioitu
C sopii reaaliaikasovelluksiin

Ja sitten vielä se tärkeä juttu, nykyisin käytössä oleva unix arkkitehtuuri on tehty käsi kädessä C kielen kanssa, ja käyttöjärjestelmien ja tämän ohjelmointikielen "filosofia" vastaavat toisiaan. Toista kieltä käyttämällä tulee helposti kummallisuuksia, että ei ole niin unixmainen. Lopputulos on herkästi joku kummajainen.

"Mitkä työkalut ?"

Esimerkiksi työkaluja formaaliin verifiointiin. Vaikka tällainen: https://en.wikipedia.org/wiki/Frama-C

"Suorituskyky, mihin verrattuna ?"

Vaikka tulkattuihin kieliin. Tai kieliin jotka käyttävät garbage collectionia. Tai melkein mihin tahansa kun nuo C kielen kääntäjät ovat niin pitkään optimoituja.

"Mistä löytää nää serifikaatit ?"

Serfifioitujen tuotteiden valmistajat osaavat kertoa tarkemmin. Esim. QNX on IEC 62304 ja sitten lentokoneiden järjestelmissä on DO-178B sertifiointi. Se on itseasiassa vaatimus lentokoneiden tietokonejärjestelmille, että sellaisia päästetään ilmaan ja lentokoneisiin on tehty koodia C:llä.

DO-178B sertifiointi edellyttää myös sitä, että käytettävät työkalut kuten kääntäjä on perusteellisesti varmistettu oikeelliseksi.

'''''yksinkertaisuus''''': Mihin verrattuna ?

Verrattuna vaikka Adaan, joka olisi semmoinen toinen suorituskykyinen kieli mikä sopii reaaliaikatarpeisiin ja löytyy sertifioituja työkaluja.

Että voit toki esittää niitä vaihtoehtoja C:lle mutta jokseenkin varmasti et keksi mitään mikä olisi joka asiassa parempi, ja viimeistään kun vaatimuksena on yhdenmukaisuus unix arkkitehtuurin kanssa tarkoittaisi sitä, että korvaaminen toisella tarkoittaisi helposti kaiken mahdollisen koodin tekemistä uusiksi jotta saa pidettyä yhtenäisenä.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Et sitten antanut yhtään linkkiä tuotantoympäristöön."

Kyseisiä kerneleitä on yleisesti tuotantoympäristöissä käytössä.

Tuotannossahan ne on tietysti käännettynä binäärimuotoon, että sorsistahan se tarkistetaan, tietysti.

"Perustele."

C on standardoitu
C mahdollistaa helposti vakaana pysyvän ABI:n
C on suorituskykyinen
C sopii laitteistonläheiseen ohjelmointiin
C:lle sopivia työkaluja ja systeemikoodia on sertifioitu
C sopii reaaliaikasovelluksiin

Ja sitten vielä se tärkeä juttu, nykyisin käytössä oleva unix arkkitehtuuri on tehty käsi kädessä C kielen kanssa, ja käyttöjärjestelmien ja tämän ohjelmointikielen "filosofia" vastaavat toisiaan. Toista kieltä käyttämällä tulee helposti kummallisuuksia, että ei ole niin unixmainen. Lopputulos on herkästi joku kummajainen.

"Mitkä työkalut ?"

Esimerkiksi työkaluja formaaliin verifiointiin. Vaikka tällainen: https://en.wikipedia.org/wiki/Frama-C

"Suorituskyky, mihin verrattuna ?"

Vaikka tulkattuihin kieliin. Tai kieliin jotka käyttävät garbage collectionia. Tai melkein mihin tahansa kun nuo C kielen kääntäjät ovat niin pitkään optimoituja.

"Mistä löytää nää serifikaatit ?"

Serfifioitujen tuotteiden valmistajat osaavat kertoa tarkemmin. Esim. QNX on IEC 62304 ja sitten lentokoneiden järjestelmissä on DO-178B sertifiointi. Se on itseasiassa vaatimus lentokoneiden tietokonejärjestelmille, että sellaisia päästetään ilmaan ja lentokoneisiin on tehty koodia C:llä.

DO-178B sertifiointi edellyttää myös sitä, että käytettävät työkalut kuten kääntäjä on perusteellisesti varmistettu oikeelliseksi.

'''''yksinkertaisuus''''': Mihin verrattuna ?

Verrattuna vaikka Adaan, joka olisi semmoinen toinen suorituskykyinen kieli mikä sopii reaaliaikatarpeisiin ja löytyy sertifioituja työkaluja.

Että voit toki esittää niitä vaihtoehtoja C:lle mutta jokseenkin varmasti et keksi mitään mikä olisi joka asiassa parempi, ja viimeistään kun vaatimuksena on yhdenmukaisuus unix arkkitehtuurin kanssa tarkoittaisi sitä, että korvaaminen toisella tarkoittaisi helposti kaiken mahdollisen koodin tekemistä uusiksi jotta saa pidettyä yhtenäisenä.
Sinä halveeraat ihmisten käsityskykyä. Tuommonen pilkanteko tuottaa ihan ansaittua palautetta.
Kommentoi
2
Ilmianna
Jaa
dtyjuyutkit kirjoitti:
Sinä halveeraat ihmisten käsityskykyä. Tuommonen pilkanteko tuottaa ihan ansaittua palautetta.
Miten se on minun halveeraamista jos joku on niin tyhmä, että kysyy linkkejä tuotantoympäristöihin?

Miksi pitää jankuttaa naurettavia kysymyksiä minulle jos itse ei kykene edes perusteisiin perehtyä?
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Miten se on minun halveeraamista jos joku on niin tyhmä, että kysyy linkkejä tuotantoympäristöihin?

Miksi pitää jankuttaa naurettavia kysymyksiä minulle jos itse ei kykene edes perusteisiin perehtyä?
Etkö sinä nyherö tajunnut, minähän vedätin sinua koko ajan.
Suomi24:sen suurin trolli sidotaan yhdelle palstalle, niin muut keskustelut saa olla rauhassa paskanjauhannaltasi.
Kommentoi
2
Ilmianna
Jaa
r67i758oi67tol kirjoitti:
Etkö sinä nyherö tajunnut, minähän vedätin sinua koko ajan.
Suomi24:sen suurin trolli sidotaan yhdelle palstalle, niin muut keskustelut saa olla rauhassa paskanjauhannaltasi.
"Etkö sinä nyherö tajunnut, minähän vedätin sinua koko ajan."

Taitaa olla ennemminkin niin, että et ymmärrä mitään ohjelmoinnista.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Etkö sinä nyherö tajunnut, minähän vedätin sinua koko ajan."

Taitaa olla ennemminkin niin, että et ymmärrä mitään ohjelmoinnista.
Ei tarvitsekkaan, minusta on mukava kusettaa sinun kaltaisia luusereita.
Kommentoi
1
Ilmianna
Jaa
M-Kar kirjoitti:
"Et sitten antanut yhtään linkkiä tuotantoympäristöön."

Kyseisiä kerneleitä on yleisesti tuotantoympäristöissä käytössä.

Tuotannossahan ne on tietysti käännettynä binäärimuotoon, että sorsistahan se tarkistetaan, tietysti.

"Perustele."

C on standardoitu
C mahdollistaa helposti vakaana pysyvän ABI:n
C on suorituskykyinen
C sopii laitteistonläheiseen ohjelmointiin
C:lle sopivia työkaluja ja systeemikoodia on sertifioitu
C sopii reaaliaikasovelluksiin

Ja sitten vielä se tärkeä juttu, nykyisin käytössä oleva unix arkkitehtuuri on tehty käsi kädessä C kielen kanssa, ja käyttöjärjestelmien ja tämän ohjelmointikielen "filosofia" vastaavat toisiaan. Toista kieltä käyttämällä tulee helposti kummallisuuksia, että ei ole niin unixmainen. Lopputulos on herkästi joku kummajainen.

"Mitkä työkalut ?"

Esimerkiksi työkaluja formaaliin verifiointiin. Vaikka tällainen: https://en.wikipedia.org/wiki/Frama-C

"Suorituskyky, mihin verrattuna ?"

Vaikka tulkattuihin kieliin. Tai kieliin jotka käyttävät garbage collectionia. Tai melkein mihin tahansa kun nuo C kielen kääntäjät ovat niin pitkään optimoituja.

"Mistä löytää nää serifikaatit ?"

Serfifioitujen tuotteiden valmistajat osaavat kertoa tarkemmin. Esim. QNX on IEC 62304 ja sitten lentokoneiden järjestelmissä on DO-178B sertifiointi. Se on itseasiassa vaatimus lentokoneiden tietokonejärjestelmille, että sellaisia päästetään ilmaan ja lentokoneisiin on tehty koodia C:llä.

DO-178B sertifiointi edellyttää myös sitä, että käytettävät työkalut kuten kääntäjä on perusteellisesti varmistettu oikeelliseksi.

'''''yksinkertaisuus''''': Mihin verrattuna ?

Verrattuna vaikka Adaan, joka olisi semmoinen toinen suorituskykyinen kieli mikä sopii reaaliaikatarpeisiin ja löytyy sertifioituja työkaluja.

Että voit toki esittää niitä vaihtoehtoja C:lle mutta jokseenkin varmasti et keksi mitään mikä olisi joka asiassa parempi, ja viimeistään kun vaatimuksena on yhdenmukaisuus unix arkkitehtuurin kanssa tarkoittaisi sitä, että korvaaminen toisella tarkoittaisi helposti kaiken mahdollisen koodin tekemistä uusiksi jotta saa pidettyä yhtenäisenä.
Objectpascal ei kaipaa standardeja; tästä on se hyöty, ettei sinun tarvitse maksaa standardiasiakirjasta.
standardithan ovat tekijänoikeuksien alaisia, eli ainoa laillinen tapa hankkia standardiasiakirja on maksaa siitä.
Objectpascalin valinta kieleksi C:n sijasta säästää siis selvää rahaa, kun standardiasiakirjasta ei tarvotse maksaa.

Objectpascal mahdollistaa helposti vakaana pysyvän ABI:n
Objectpascal on suorituskykyinen
Objectpascal sopii laitteistonläheiseen ohjelmointiin
Objectpascal:lle on sopivia työkaluja ja se soveltuu einomaisesti myös systeemikoodin kirjoittamiseen.
Mitään sertifiointeja ei tarvita, eikä sertifiointi oikeasti takaa mitään hyvää. Onpahan tiettyjen tahojen rahstusväline.

Objectpascal sopii reaaliaikasovelluksiin

Objectpascal on ennen kaikkea turvallisempi vaihtoehto.

Muistellaanpa vaikkapa Heartbleed -haavoittuvuutta, jollainen tuli julkisuuteen keväällä 2014 OpenSSL -kirjastosta.

Jos olisin itse koodannut OpenSSL -kirjaston Objectpascal -ohjelmointikielellä
ja se olisi käännetty Free Pascal -kääntäjällä useisiin eri käyttöjärjestelmiin,
niin Heartbleed -haavoittuvuutta ei olisi koskaan tapahtunut.

Näin koodattu kirjasto olisi suoritettavan koodin koolla mitattuna ollut samaa luokkaa
kuin C -kielellä koodattukin, mutta huomattavasti turvallisempi.

M-Karin päinvastaisia väitteitä ei kannata uskoa, mitään todenperäisyyttä näillä väitteillä ei ole.

C -kielen sekava ja kryptinen syntaksi vie ohjelmoijan aivokapasiteetista suuren osan, ja vain vähäinen määrä
jää jäljelle ratkaistavan asian koodaamiseen. Siksi C -kieli on virhealtis, ja vaikka sitä on historiallisesti
paljon käytettykin systeemikoodin kirjoittamiseen, C -kielellä ei ole mitään sellaista etua
Objectpascaliin verrattuna, joka tekisi siitä jotenkin paremman systeemikoodin kirjoittamisvälineen.

Mikrokontrollerin koodaus voi olla ainoa paikka, jossa Objectpascal ei ole paras kieli.
Mutta niissäkin Pascal on parempi valinta kuin C.

Ja miksi niissä pelkkä Pascal kaikin puolin kehittyneemmän Objectpascalin sijasta ?

Siksi, että mikrokontrollerissa saattaa olla esim. 1024 tavua RAM -muistia, halvimmissa tuotakin vähemmän.

Vaikka Objectpascal on kielenä sekä C:tä että pelkkää Pascalia kehittyneempi, niin
objektipohjaisuus lisää RAM -muistin tarvetta, ja jos mikrokontrollerissa on RAM -muistia
hyvin vähän, silloin sitä ei yleensä ole tarpeeksi objektipohjaiselle lähestymistavalle.

Objectpascal -kääntäjä (kuten esim. Free Pascal) kääntää myös pascalia ilman objekteja.

Eli kääntäjää ei tarvitse edes vaihtaa, vaikka objektit ja luokat jättäisikin käyttämättä,
jos jossain projektissa vaatimuksiin kuuluu minimaalisen pieni RAM -muistin käyttö.

M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures

Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä.

C -kieli on yksinkertaisesti ammattilaisellekin liian vaikeaa.
Tästä on hyvänä osoituksena se, että ammattilaisten, arvostettujen koodaajien jäljiltä
on luettavissa C -kielistä koodia, joissa on alkeellisia virheitä.

Jos sama projekti olisi koodattu Objectpascalilla, kyseisiä virheitä ei olisi tapahtunut.

En aio listata ko. virheitä tähän, sillä jos niin tekisin, joku ehkä kävisi korjaamassa nuo virheet välittömästi.

Silti vastaavia virheitä olisi lisääkin olemassa, mutta en vain ole tietoinen niistä.

C -kielen suunnittelija on tehnyt lukuisia virheitä.

Yksi niistä on idioottimainen if -käskyn syntaksi, josta puuttuu then.

Ilmeisesti tuo M-Karin joko tietämättömyyttään
tai tahallisessa harhaanjohtamistarkoituksessa (en tiedä, kummasta on kysymys)

puffaama Halstead complexity toimii juuri päinvastoin kuin on järkevää.

Hyvin yksinkertainen esimerkki:

C-Kieli:

if (a < b) {
min = a
} else { min = b};

Objectpascal:
if a < b
then min := a
else min := b;

M-Kar ilmeisesti tykkää mielestään todistella tuolla em.
Halstead complexity measures -systeemillä,
että em. C -koodi olisi jotenkin parempaa kuin vastaava Objectpascal -koodi.

then -sana tekee kuitenkin koodista helpommin ymmärrettävää.
Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole,
mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta.

Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C++, C#, Java, Javascript, Ada, Perl, PHP ja Python ?

Ja sikäli kuin tarvitaan suoraa ABI -yhteensopivuutta C -kielellä tehdyn toisen ohjelmamodulin kanssa,

Objectpascalissa on ratkaisu tähänkin:

Windows:
function demo(a,b:Integer):integer; cdecl; external 'systemmodule.dll';
function demo2(a,b:Integer):integer; stdcall; external 'systemmodule.dll';

Linux:
function de
Kommentoi
2
Ilmianna
Jaa
C_huono kirjoitti:
Objectpascal ei kaipaa standardeja; tästä on se hyöty, ettei sinun tarvitse maksaa standardiasiakirjasta.
standardithan ovat tekijänoikeuksien alaisia, eli ainoa laillinen tapa hankkia standardiasiakirja on maksaa siitä.
Objectpascalin valinta kieleksi C:n sijasta säästää siis selvää rahaa, kun standardiasiakirjasta ei tarvotse maksaa.

Objectpascal mahdollistaa helposti vakaana pysyvän ABI:n
Objectpascal on suorituskykyinen
Objectpascal sopii laitteistonläheiseen ohjelmointiin
Objectpascal:lle on sopivia työkaluja ja se soveltuu einomaisesti myös systeemikoodin kirjoittamiseen.
Mitään sertifiointeja ei tarvita, eikä sertifiointi oikeasti takaa mitään hyvää. Onpahan tiettyjen tahojen rahstusväline.

Objectpascal sopii reaaliaikasovelluksiin

Objectpascal on ennen kaikkea turvallisempi vaihtoehto.

Muistellaanpa vaikkapa Heartbleed -haavoittuvuutta, jollainen tuli julkisuuteen keväällä 2014 OpenSSL -kirjastosta.

Jos olisin itse koodannut OpenSSL -kirjaston Objectpascal -ohjelmointikielellä
ja se olisi käännetty Free Pascal -kääntäjällä useisiin eri käyttöjärjestelmiin,
niin Heartbleed -haavoittuvuutta ei olisi koskaan tapahtunut.

Näin koodattu kirjasto olisi suoritettavan koodin koolla mitattuna ollut samaa luokkaa
kuin C -kielellä koodattukin, mutta huomattavasti turvallisempi.

M-Karin päinvastaisia väitteitä ei kannata uskoa, mitään todenperäisyyttä näillä väitteillä ei ole.

C -kielen sekava ja kryptinen syntaksi vie ohjelmoijan aivokapasiteetista suuren osan, ja vain vähäinen määrä
jää jäljelle ratkaistavan asian koodaamiseen. Siksi C -kieli on virhealtis, ja vaikka sitä on historiallisesti
paljon käytettykin systeemikoodin kirjoittamiseen, C -kielellä ei ole mitään sellaista etua
Objectpascaliin verrattuna, joka tekisi siitä jotenkin paremman systeemikoodin kirjoittamisvälineen.

Mikrokontrollerin koodaus voi olla ainoa paikka, jossa Objectpascal ei ole paras kieli.
Mutta niissäkin Pascal on parempi valinta kuin C.

Ja miksi niissä pelkkä Pascal kaikin puolin kehittyneemmän Objectpascalin sijasta ?

Siksi, että mikrokontrollerissa saattaa olla esim. 1024 tavua RAM -muistia, halvimmissa tuotakin vähemmän.

Vaikka Objectpascal on kielenä sekä C:tä että pelkkää Pascalia kehittyneempi, niin
objektipohjaisuus lisää RAM -muistin tarvetta, ja jos mikrokontrollerissa on RAM -muistia
hyvin vähän, silloin sitä ei yleensä ole tarpeeksi objektipohjaiselle lähestymistavalle.

Objectpascal -kääntäjä (kuten esim. Free Pascal) kääntää myös pascalia ilman objekteja.

Eli kääntäjää ei tarvitse edes vaihtaa, vaikka objektit ja luokat jättäisikin käyttämättä,
jos jossain projektissa vaatimuksiin kuuluu minimaalisen pieni RAM -muistin käyttö.

M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures

Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä.

C -kieli on yksinkertaisesti ammattilaisellekin liian vaikeaa.
Tästä on hyvänä osoituksena se, että ammattilaisten, arvostettujen koodaajien jäljiltä
on luettavissa C -kielistä koodia, joissa on alkeellisia virheitä.

Jos sama projekti olisi koodattu Objectpascalilla, kyseisiä virheitä ei olisi tapahtunut.

En aio listata ko. virheitä tähän, sillä jos niin tekisin, joku ehkä kävisi korjaamassa nuo virheet välittömästi.

Silti vastaavia virheitä olisi lisääkin olemassa, mutta en vain ole tietoinen niistä.

C -kielen suunnittelija on tehnyt lukuisia virheitä.

Yksi niistä on idioottimainen if -käskyn syntaksi, josta puuttuu then.

Ilmeisesti tuo M-Karin joko tietämättömyyttään
tai tahallisessa harhaanjohtamistarkoituksessa (en tiedä, kummasta on kysymys)

puffaama Halstead complexity toimii juuri päinvastoin kuin on järkevää.

Hyvin yksinkertainen esimerkki:

C-Kieli:

if (a < b) {
min = a
} else { min = b};

Objectpascal:
if a < b
then min := a
else min := b;

M-Kar ilmeisesti tykkää mielestään todistella tuolla em.
Halstead complexity measures -systeemillä,
että em. C -koodi olisi jotenkin parempaa kuin vastaava Objectpascal -koodi.

then -sana tekee kuitenkin koodista helpommin ymmärrettävää.
Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole,
mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta.

Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C++, C#, Java, Javascript, Ada, Perl, PHP ja Python ?

Ja sikäli kuin tarvitaan suoraa ABI -yhteensopivuutta C -kielellä tehdyn toisen ohjelmamodulin kanssa,

Objectpascalissa on ratkaisu tähänkin:

Windows:
function demo(a,b:Integer):integer; cdecl; external 'systemmodule.dll';
function demo2(a,b:Integer):integer; stdcall; external 'systemmodule.dll';

Linux:
function de
"Objectpascal ei kaipaa standardeja; tästä on se hyöty, ettei sinun tarvitse maksaa standardiasiakirjasta."

Ei tarvitse nytkään maksaa. Sertifiointi on se mikä on kallista puuhaa.

"Objectpascal mahdollistaa helposti vakaana pysyvän ABI:n"

Vakaan ABI:n edellytys on vakaa API, ja vakaaseen API:n auttaa standardointi.

"Objectpascal on suorituskykyinen"

C on suorituskykyisempi ja kääntäjien optimoinnit on pidemmälle kehitetty. Object Pascalissahan oli lisäksi kaikennäköistä range checkiä yms. hidastetta.

"Objectpascal sopii laitteistonläheiseen ohjelmointiin."

Johtuen heikommasta suorituskyvystä, ei kannata käyttää. Onhan siinä sitten muitakin outoksia kuten calling convention puljaaminen tai sitten vaikka se, että miljoonien rivien sorsapuu on C:tä niin ei kannata sotkea sekaan mitään Object Pascalia. Tekee vain buildauksesta monimutkaisempaa.

"Objectpascal:lle on sopivia työkaluja"

No mitäs työkaluja on formaaliin verifiointiin?

"Mitään sertifiointeja ei tarvita"

Ilman sertifiointia ei lentokone saa lentää eikä softa voi ohjata röntgen kuvan ottamista tai vaikka keinomunuaista. Vaatimukset tulevat lainsäädännöstä.

"Objectpascal sopii reaaliaikasovelluksiin"

Kyllä. Object Pascal todellakin sopii reaaliaikasovelluksiin. Monet reaaliaikakohteet, kuten lentokoneen järjestelmät, vaan edellyttää myös sitä sertifiointia joten reaaliaikasovellukset joissa Object Pascalia voisi käyttää rajoittuisi teollisuusautomaatioon tai vaikka audiokäyttöön. Turvallisuuskriittiset reaaliaika kohteet ei Object Pascalille käy, sinne valitaan C, Ada ja nykyisin myös käytetään C++:sta subsettiä, että ei ole kaikki hilavitkuttimet mukana.

"Objectpascal on ennen kaikkea turvallisempi vaihtoehto."

Kuoleva ohjelmointikieli on taloudellinen riski, ja ohjelmointikieli itsessään ei sovi sinne turvallisuutta vaativiin kohteisiin kuten lentokoneeseen.

"Jos olisin itse koodannut OpenSSL -kirjaston Objectpascal -ohjelmointikielellä
ja se olisi käännetty Free Pascal -kääntäjällä useisiin eri käyttöjärjestelmiin,
niin Heartbleed -haavoittuvuutta ei olisi koskaan tapahtunut."

Object Pascalilla tehtyä OpenSSL kirjastoa ei olisi kelpuutettu käyttöjärjestelmiin. Turhaa kompeksisuutta tuoda erilaisia kieliä. Systeemiohjelmoijat siivoavat myös C++:aa pois, että olisi keskeiset komponentit puhdasta C:tä tai sh skriptiä.

Standardoinnin puute on myös tärkeä syy olla ottamatta Object Pascalia tuollaiseen. 90-luvulla Object Pascal oli johdettu vanhasta Borlandin Turbo Pascalin murteesta ja näin ollen siinä oli riski, että jonkun patentin takia torpataan koko projekti. Javan kanssahan sitä sitten riideltiin patenttien takia muutamaa vuotta myöhemmin.

Toinen vika Free Pascalissa oli lisensointi. Ei BSD järjestelmiin lisätä yhtään GPL koodia lisää saastuttamaan koodipuuta. Ainoat GPL palikat mitä BSD järjestelmissä käytettiin oli aikoinaan just joku GCC ja autotools ja kokoajan GPL koodia on vähennetty koodipohjasta.

Toisin sanoen, Object Pascalilla OpenSSL olisi jäänyt kelvottomaksi torsoksi jota ei olisi ihmiset käyttänyt ja sen tilalle olisi tehty oikeilla työkaluilla toinen kirjasto C:llä.

"Mikrokontrollerin koodaus voi olla ainoa paikka, jossa Objectpascal ei ole paras kieli.
Mutta niissäkin Pascal on parempi valinta kuin C.

Ja sitten kun sitä C:tä kuitenkin on niin tuo vaan lisää kompleksisuutta tuoda ylimääräisiä työkaluja.
Kommentoi
Ilmianna
Jaa
C_huono kirjoitti:
Objectpascal ei kaipaa standardeja; tästä on se hyöty, ettei sinun tarvitse maksaa standardiasiakirjasta.
standardithan ovat tekijänoikeuksien alaisia, eli ainoa laillinen tapa hankkia standardiasiakirja on maksaa siitä.
Objectpascalin valinta kieleksi C:n sijasta säästää siis selvää rahaa, kun standardiasiakirjasta ei tarvotse maksaa.

Objectpascal mahdollistaa helposti vakaana pysyvän ABI:n
Objectpascal on suorituskykyinen
Objectpascal sopii laitteistonläheiseen ohjelmointiin
Objectpascal:lle on sopivia työkaluja ja se soveltuu einomaisesti myös systeemikoodin kirjoittamiseen.
Mitään sertifiointeja ei tarvita, eikä sertifiointi oikeasti takaa mitään hyvää. Onpahan tiettyjen tahojen rahstusväline.

Objectpascal sopii reaaliaikasovelluksiin

Objectpascal on ennen kaikkea turvallisempi vaihtoehto.

Muistellaanpa vaikkapa Heartbleed -haavoittuvuutta, jollainen tuli julkisuuteen keväällä 2014 OpenSSL -kirjastosta.

Jos olisin itse koodannut OpenSSL -kirjaston Objectpascal -ohjelmointikielellä
ja se olisi käännetty Free Pascal -kääntäjällä useisiin eri käyttöjärjestelmiin,
niin Heartbleed -haavoittuvuutta ei olisi koskaan tapahtunut.

Näin koodattu kirjasto olisi suoritettavan koodin koolla mitattuna ollut samaa luokkaa
kuin C -kielellä koodattukin, mutta huomattavasti turvallisempi.

M-Karin päinvastaisia väitteitä ei kannata uskoa, mitään todenperäisyyttä näillä väitteillä ei ole.

C -kielen sekava ja kryptinen syntaksi vie ohjelmoijan aivokapasiteetista suuren osan, ja vain vähäinen määrä
jää jäljelle ratkaistavan asian koodaamiseen. Siksi C -kieli on virhealtis, ja vaikka sitä on historiallisesti
paljon käytettykin systeemikoodin kirjoittamiseen, C -kielellä ei ole mitään sellaista etua
Objectpascaliin verrattuna, joka tekisi siitä jotenkin paremman systeemikoodin kirjoittamisvälineen.

Mikrokontrollerin koodaus voi olla ainoa paikka, jossa Objectpascal ei ole paras kieli.
Mutta niissäkin Pascal on parempi valinta kuin C.

Ja miksi niissä pelkkä Pascal kaikin puolin kehittyneemmän Objectpascalin sijasta ?

Siksi, että mikrokontrollerissa saattaa olla esim. 1024 tavua RAM -muistia, halvimmissa tuotakin vähemmän.

Vaikka Objectpascal on kielenä sekä C:tä että pelkkää Pascalia kehittyneempi, niin
objektipohjaisuus lisää RAM -muistin tarvetta, ja jos mikrokontrollerissa on RAM -muistia
hyvin vähän, silloin sitä ei yleensä ole tarpeeksi objektipohjaiselle lähestymistavalle.

Objectpascal -kääntäjä (kuten esim. Free Pascal) kääntää myös pascalia ilman objekteja.

Eli kääntäjää ei tarvitse edes vaihtaa, vaikka objektit ja luokat jättäisikin käyttämättä,
jos jossain projektissa vaatimuksiin kuuluu minimaalisen pieni RAM -muistin käyttö.

M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures

Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä.

C -kieli on yksinkertaisesti ammattilaisellekin liian vaikeaa.
Tästä on hyvänä osoituksena se, että ammattilaisten, arvostettujen koodaajien jäljiltä
on luettavissa C -kielistä koodia, joissa on alkeellisia virheitä.

Jos sama projekti olisi koodattu Objectpascalilla, kyseisiä virheitä ei olisi tapahtunut.

En aio listata ko. virheitä tähän, sillä jos niin tekisin, joku ehkä kävisi korjaamassa nuo virheet välittömästi.

Silti vastaavia virheitä olisi lisääkin olemassa, mutta en vain ole tietoinen niistä.

C -kielen suunnittelija on tehnyt lukuisia virheitä.

Yksi niistä on idioottimainen if -käskyn syntaksi, josta puuttuu then.

Ilmeisesti tuo M-Karin joko tietämättömyyttään
tai tahallisessa harhaanjohtamistarkoituksessa (en tiedä, kummasta on kysymys)

puffaama Halstead complexity toimii juuri päinvastoin kuin on järkevää.

Hyvin yksinkertainen esimerkki:

C-Kieli:

if (a < b) {
min = a
} else { min = b};

Objectpascal:
if a < b
then min := a
else min := b;

M-Kar ilmeisesti tykkää mielestään todistella tuolla em.
Halstead complexity measures -systeemillä,
että em. C -koodi olisi jotenkin parempaa kuin vastaava Objectpascal -koodi.

then -sana tekee kuitenkin koodista helpommin ymmärrettävää.
Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole,
mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta.

Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C++, C#, Java, Javascript, Ada, Perl, PHP ja Python ?

Ja sikäli kuin tarvitaan suoraa ABI -yhteensopivuutta C -kielellä tehdyn toisen ohjelmamodulin kanssa,

Objectpascalissa on ratkaisu tähänkin:

Windows:
function demo(a,b:Integer):integer; cdecl; external 'systemmodule.dll';
function demo2(a,b:Integer):integer; stdcall; external 'systemmodule.dll';

Linux:
function de
"M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures

Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä."

Ei niin. En ole sellaista sanonutkaan.

Halstead complexity on kyllä ihan pätevä mittari, että se mittaa sitä koodin kompleksisuutta ja ilmaisukykyä.

Suoraan ei voi kahta kieltä näin mitata, koska eri työkaluja tehdään eri käyttötarkoituksiin ja omassa käyttötarkoituksessaan toinen kieli on helposti parempi kuin toinen.

Kritisoin joskus Delphiä siitä, että sellaista kohdetta ei ole mihin ei löytyisi nykyään sopivampaa työkalua. Tuo koskee myös Object Pascalia, että eri käyttötarkoituksiin löytyy kyllä sopivampia kieliä.

Työkaluhan valitaan käyttötarkoituksen mukaan ja kieli on myös työkalu.

"then -sana tekee kuitenkin koodista helpommin ymmärrettävää."

Näitä asioita on tutkittu. Ihmisaivot käsittelevät asioita symboleina ja havaitsevat ryhmittämistä. Se then -sana ei siellä ratkaise vaan ennemminkin se then -blokin sisennys. Se then -sana on siellä sitten vain kohinaa.

Mutta koska ihmisaivot käsittelevät asioita symboleina, tämän object pascal koodin:

if a < b
then min := a
else min := b;

voi sieventää C:lle näin:

min = a < b ? a : b;

Näistä kahdesta tuo minun kirjoittama C koodi on selvästi yksinkertaisempi.

"Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta."

Väärin meni. Se Halstead complexity mittaa kompleksisuutta kokonaisuudessaan. Se huomioi toteutuksen kuin myös sen työkalun.

"Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C++, C#, Java, Javascript, Ada, Perl, PHP ja Python ?"

C, C++, C#, Java, Javascript mahdollistavat tuon kirjoittamisen täysin samalla tavalla, eli:

min = a < b ? a : b;

PHP:llä ja Perlillä tulee kohinaa:

$min = $a < $b ? $a : $b;

Pythonissa vähän erikoinen järjestys:

min = a if a < b else b

Ada on kompleksinen:

' min := (if a < b
' then a
' else b);
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures

Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä."

Ei niin. En ole sellaista sanonutkaan.

Halstead complexity on kyllä ihan pätevä mittari, että se mittaa sitä koodin kompleksisuutta ja ilmaisukykyä.

Suoraan ei voi kahta kieltä näin mitata, koska eri työkaluja tehdään eri käyttötarkoituksiin ja omassa käyttötarkoituksessaan toinen kieli on helposti parempi kuin toinen.

Kritisoin joskus Delphiä siitä, että sellaista kohdetta ei ole mihin ei löytyisi nykyään sopivampaa työkalua. Tuo koskee myös Object Pascalia, että eri käyttötarkoituksiin löytyy kyllä sopivampia kieliä.

Työkaluhan valitaan käyttötarkoituksen mukaan ja kieli on myös työkalu.

"then -sana tekee kuitenkin koodista helpommin ymmärrettävää."

Näitä asioita on tutkittu. Ihmisaivot käsittelevät asioita symboleina ja havaitsevat ryhmittämistä. Se then -sana ei siellä ratkaise vaan ennemminkin se then -blokin sisennys. Se then -sana on siellä sitten vain kohinaa.

Mutta koska ihmisaivot käsittelevät asioita symboleina, tämän object pascal koodin:

if a < b
then min := a
else min := b;

voi sieventää C:lle näin:

min = a < b ? a : b;

Näistä kahdesta tuo minun kirjoittama C koodi on selvästi yksinkertaisempi.

"Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta."

Väärin meni. Se Halstead complexity mittaa kompleksisuutta kokonaisuudessaan. Se huomioi toteutuksen kuin myös sen työkalun.

"Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C++, C#, Java, Javascript, Ada, Perl, PHP ja Python ?"

C, C++, C#, Java, Javascript mahdollistavat tuon kirjoittamisen täysin samalla tavalla, eli:

min = a < b ? a : b;

PHP:llä ja Perlillä tulee kohinaa:

$min = $a < $b ? $a : $b;

Pythonissa vähän erikoinen järjestys:

min = a if a < b else b

Ada on kompleksinen:

' min := (if a < b
' then a
' else b);
Olisi kyllä kiva nähdä koodi joka olisi Object Pascalilla ylivertaisen yksinkertainen verrattuna mihin tahansa muuhun.

TAI, olisi edes ylivertaisen siisti verrattuna kyseisen käyttötarkoituksen muihin soveltuviin työkaluihin. Pitää huomioida vaatimukset mitä tulee lainsäädännöstä, lisensoinnista, työkaluista.

Nyt näkyi C-kielikin toimivan paremmin ja mielestäni C:llä tulee helpommin kompleksista koodia kuin monilla muilla välineillä. Se onkin tarkoitettu matalemmalle tasolle, että sillä tehdään niitä korkeamman tason toimintoja.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures

Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä."

Ei niin. En ole sellaista sanonutkaan.

Halstead complexity on kyllä ihan pätevä mittari, että se mittaa sitä koodin kompleksisuutta ja ilmaisukykyä.

Suoraan ei voi kahta kieltä näin mitata, koska eri työkaluja tehdään eri käyttötarkoituksiin ja omassa käyttötarkoituksessaan toinen kieli on helposti parempi kuin toinen.

Kritisoin joskus Delphiä siitä, että sellaista kohdetta ei ole mihin ei löytyisi nykyään sopivampaa työkalua. Tuo koskee myös Object Pascalia, että eri käyttötarkoituksiin löytyy kyllä sopivampia kieliä.

Työkaluhan valitaan käyttötarkoituksen mukaan ja kieli on myös työkalu.

"then -sana tekee kuitenkin koodista helpommin ymmärrettävää."

Näitä asioita on tutkittu. Ihmisaivot käsittelevät asioita symboleina ja havaitsevat ryhmittämistä. Se then -sana ei siellä ratkaise vaan ennemminkin se then -blokin sisennys. Se then -sana on siellä sitten vain kohinaa.

Mutta koska ihmisaivot käsittelevät asioita symboleina, tämän object pascal koodin:

if a < b
then min := a
else min := b;

voi sieventää C:lle näin:

min = a < b ? a : b;

Näistä kahdesta tuo minun kirjoittama C koodi on selvästi yksinkertaisempi.

"Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta."

Väärin meni. Se Halstead complexity mittaa kompleksisuutta kokonaisuudessaan. Se huomioi toteutuksen kuin myös sen työkalun.

"Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C++, C#, Java, Javascript, Ada, Perl, PHP ja Python ?"

C, C++, C#, Java, Javascript mahdollistavat tuon kirjoittamisen täysin samalla tavalla, eli:

min = a < b ? a : b;

PHP:llä ja Perlillä tulee kohinaa:

$min = $a < $b ? $a : $b;

Pythonissa vähän erikoinen järjestys:

min = a if a < b else b

Ada on kompleksinen:

' min := (if a < b
' then a
' else b);
-------------------------------------------------------------------------------------------------------------
PHP:llä ja Perlillä tulee kohinaa:

$min = $a < $b ? $a : $b;
-------------------------------------------------------------------------------------------------------------
Mitähän tämä kohina on ? (itseään korostamatta kiitos)
Kommentoi
2
Ilmianna
Jaa
Lyhyesti-kiitos kirjoitti:
-------------------------------------------------------------------------------------------------------------
PHP:llä ja Perlillä tulee kohinaa:

$min = $a < $b ? $a : $b;
-------------------------------------------------------------------------------------------------------------
Mitähän tämä kohina on ? (itseään korostamatta kiitos)
Vaikka nuo tarpeettomat $ merkit muuttujissa.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Vaikka nuo tarpeettomat $ merkit muuttujissa.
Katsoppa tuota kahta echo riviä. PHP sisältää pitkänmatkaa yli 10 000 käsitettä. Tämä mielestäsi tarpeeton merkki kertoo ohjelmoijalle että kyseessä on muuttuja, ei vakio, joka se olis ilman tuota tarpeetonta merkkiä.

OK, kyllä vakio voidaan tehdä C tai C++ mukaan, mutta kumpi on luettavampi, kummasta eroittaa heti ilman mitään epäilyjä mistä on kyse.

<?php
const min = 10;
$min = 0;
$a = 1;
$b = 2;
$min = $a < $b ? $a : $b;
echo $min;
echo min
?>
Kommentoi
2
Ilmianna
Jaa
Lyhyesti-kiitos kirjoitti:
Katsoppa tuota kahta echo riviä. PHP sisältää pitkänmatkaa yli 10 000 käsitettä. Tämä mielestäsi tarpeeton merkki kertoo ohjelmoijalle että kyseessä on muuttuja, ei vakio, joka se olis ilman tuota tarpeetonta merkkiä.

OK, kyllä vakio voidaan tehdä C tai C++ mukaan, mutta kumpi on luettavampi, kummasta eroittaa heti ilman mitään epäilyjä mistä on kyse.

<?php
const min = 10;
$min = 0;
$a = 1;
$b = 2;
$min = $a < $b ? $a : $b;
echo $min;
echo min
?>
"Katsoppa tuota kahta echo riviä. PHP sisältää pitkänmatkaa yli 10 000 käsitettä."

PHP onkin monissa asioissa aika pa5ka.

"Tämä mielestäsi tarpeeton merkki kertoo ohjelmoijalle että kyseessä on muuttuja, ei vakio, joka se olis ilman tuota tarpeetonta merkkiä."

IDE korostaa väreillä muuttujat, avainsanat ja jne.

Ja kuten näkyy niin muut kielet hoitavat tuon siistimmin.

"OK, kyllä vakio voidaan tehdä C tai C++ mukaan, mutta kumpi on luettavampi, kummasta eroittaa heti ilman mitään epäilyjä mistä on kyse."

Ei mitään eroa koska se näkyy nopeiten väristä tai muuten erilaisesta fontista.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Katsoppa tuota kahta echo riviä. PHP sisältää pitkänmatkaa yli 10 000 käsitettä."

PHP onkin monissa asioissa aika pa5ka.

"Tämä mielestäsi tarpeeton merkki kertoo ohjelmoijalle että kyseessä on muuttuja, ei vakio, joka se olis ilman tuota tarpeetonta merkkiä."

IDE korostaa väreillä muuttujat, avainsanat ja jne.

Ja kuten näkyy niin muut kielet hoitavat tuon siistimmin.

"OK, kyllä vakio voidaan tehdä C tai C++ mukaan, mutta kumpi on luettavampi, kummasta eroittaa heti ilman mitään epäilyjä mistä on kyse."

Ei mitään eroa koska se näkyy nopeiten väristä tai muuten erilaisesta fontista.
''''Ei mitään eroa koska se näkyy nopeiten väristä tai muuten erilaisesta fontista.
KommentoiIlmianna''''

Otas nyt omassa C tai C++ kehitys ympäristössäsi ja kerro millä tavalla väritys eroaa, kun (eka) on vakio, vaikka PII ja (toka ) tyyppiä char sisältäen mitä tahaansa.

Eli nuo alla on kaksi funktion paluuarvon asetusta. Osaatko sinä oikeasti edes C tai C++, puhumattakaan PHP kielestä.

return eka;
return toka;

Et viittis höpöttää jollet ole asiasta ollenkaan perillä. Ei nämä ihmiset täällä niele mitä tahaansa. mikä sinut ajaa tekemään tämmöistä kiusaa niille jotka tietävät. Aivan hiton rasittavaa kun kaveri joka ei tunne asiaa, kyseenalaitaa faktatietoa, saadakseen vääryydellä uskottavuutta omista kyvyistään.
Kommentoi
Ilmianna
Jaa
Lyhyesti-kiitos kirjoitti:
''''Ei mitään eroa koska se näkyy nopeiten väristä tai muuten erilaisesta fontista.
KommentoiIlmianna''''

Otas nyt omassa C tai C++ kehitys ympäristössäsi ja kerro millä tavalla väritys eroaa, kun (eka) on vakio, vaikka PII ja (toka ) tyyppiä char sisältäen mitä tahaansa.

Eli nuo alla on kaksi funktion paluuarvon asetusta. Osaatko sinä oikeasti edes C tai C++, puhumattakaan PHP kielestä.

return eka;
return toka;

Et viittis höpöttää jollet ole asiasta ollenkaan perillä. Ei nämä ihmiset täällä niele mitä tahaansa. mikä sinut ajaa tekemään tämmöistä kiusaa niille jotka tietävät. Aivan hiton rasittavaa kun kaveri joka ei tunne asiaa, kyseenalaitaa faktatietoa, saadakseen vääryydellä uskottavuutta omista kyvyistään.
"Otas nyt omassa C tai C++ kehitys ympäristössäsi ja kerro millä tavalla väritys eroaa, kun (eka) on vakio, vaikka PII ja (toka ) tyyppiä char sisältäen mitä tahaansa."

Vakiot kirjoitetaan ISOLLA, muuttujat camelCase, return kun on varattu sana niin se näkyy eri värillä.

Faktatietoa on se, että PHP:ssä tungetaan niitä $ merkkejä muuttujien eteen ja C:ssä ei tarvitse.

Siinä semmoinen juttu, että hyvin kirjoitettu koodi on itsedokumentoiva. Ei tarvitse erikseen dokumentoida mitä joku koodi tekee kun koodin voi tehdä niin luettavaksi, että se on itsessään dokumentaatio.

Toki korostan sitä, että kokonaisuus ratkaisee ja erilaisissa tilanteissa eri työkaluilla saadaan siistimpi lopputulos.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Otas nyt omassa C tai C++ kehitys ympäristössäsi ja kerro millä tavalla väritys eroaa, kun (eka) on vakio, vaikka PII ja (toka ) tyyppiä char sisältäen mitä tahaansa."

Vakiot kirjoitetaan ISOLLA, muuttujat camelCase, return kun on varattu sana niin se näkyy eri värillä.

Faktatietoa on se, että PHP:ssä tungetaan niitä $ merkkejä muuttujien eteen ja C:ssä ei tarvitse.

Siinä semmoinen juttu, että hyvin kirjoitettu koodi on itsedokumentoiva. Ei tarvitse erikseen dokumentoida mitä joku koodi tekee kun koodin voi tehdä niin luettavaksi, että se on itsessään dokumentaatio.

Toki korostan sitä, että kokonaisuus ratkaisee ja erilaisissa tilanteissa eri työkaluilla saadaan siistimpi lopputulos.
Vielä kehtasi vääntää päin persettä. Missä pirussa niin sanotaan että vakiot kirjotetaan isolla, elikä ei tietenkään siihen ole mitään syntaksi sääntöä, ohjelmoija tekee niin kuin haluaa. Luettavuuden vuoksi jollakin tavalla ohjelmoijan on hyvä leimata vakiot selvästi muuttujista eritavalla. mikään ei estä tekemästä sitä toisinkin päin.

Vaikioiden kirjoittaminen isolla on hyvän tavan mukainen sääntö, jota voi verrata vaikka sääntöön, älä ohjelmoi voileipä toisessa kädessä.

#define pii 3.14

Minkä virheilmoituksen sinun kehitysympäristö antaa yllä olevasta määrittelystä ?
Ei se anna virheilmoitusta, kun siinä ei ole virhettä, eikä myöskään tässä alla olevassa.

#define PII 3.14
Kommentoi
1
Ilmianna
Jaa
M-Kar kirjoitti:
"Objectpascal ei kaipaa standardeja; tästä on se hyöty, ettei sinun tarvitse maksaa standardiasiakirjasta."

Ei tarvitse nytkään maksaa. Sertifiointi on se mikä on kallista puuhaa.

"Objectpascal mahdollistaa helposti vakaana pysyvän ABI:n"

Vakaan ABI:n edellytys on vakaa API, ja vakaaseen API:n auttaa standardointi.

"Objectpascal on suorituskykyinen"

C on suorituskykyisempi ja kääntäjien optimoinnit on pidemmälle kehitetty. Object Pascalissahan oli lisäksi kaikennäköistä range checkiä yms. hidastetta.

"Objectpascal sopii laitteistonläheiseen ohjelmointiin."

Johtuen heikommasta suorituskyvystä, ei kannata käyttää. Onhan siinä sitten muitakin outoksia kuten calling convention puljaaminen tai sitten vaikka se, että miljoonien rivien sorsapuu on C:tä niin ei kannata sotkea sekaan mitään Object Pascalia. Tekee vain buildauksesta monimutkaisempaa.

"Objectpascal:lle on sopivia työkaluja"

No mitäs työkaluja on formaaliin verifiointiin?

"Mitään sertifiointeja ei tarvita"

Ilman sertifiointia ei lentokone saa lentää eikä softa voi ohjata röntgen kuvan ottamista tai vaikka keinomunuaista. Vaatimukset tulevat lainsäädännöstä.

"Objectpascal sopii reaaliaikasovelluksiin"

Kyllä. Object Pascal todellakin sopii reaaliaikasovelluksiin. Monet reaaliaikakohteet, kuten lentokoneen järjestelmät, vaan edellyttää myös sitä sertifiointia joten reaaliaikasovellukset joissa Object Pascalia voisi käyttää rajoittuisi teollisuusautomaatioon tai vaikka audiokäyttöön. Turvallisuuskriittiset reaaliaika kohteet ei Object Pascalille käy, sinne valitaan C, Ada ja nykyisin myös käytetään C++:sta subsettiä, että ei ole kaikki hilavitkuttimet mukana.

"Objectpascal on ennen kaikkea turvallisempi vaihtoehto."

Kuoleva ohjelmointikieli on taloudellinen riski, ja ohjelmointikieli itsessään ei sovi sinne turvallisuutta vaativiin kohteisiin kuten lentokoneeseen.

"Jos olisin itse koodannut OpenSSL -kirjaston Objectpascal -ohjelmointikielellä
ja se olisi käännetty Free Pascal -kääntäjällä useisiin eri käyttöjärjestelmiin,
niin Heartbleed -haavoittuvuutta ei olisi koskaan tapahtunut."

Object Pascalilla tehtyä OpenSSL kirjastoa ei olisi kelpuutettu käyttöjärjestelmiin. Turhaa kompeksisuutta tuoda erilaisia kieliä. Systeemiohjelmoijat siivoavat myös C++:aa pois, että olisi keskeiset komponentit puhdasta C:tä tai sh skriptiä.

Standardoinnin puute on myös tärkeä syy olla ottamatta Object Pascalia tuollaiseen. 90-luvulla Object Pascal oli johdettu vanhasta Borlandin Turbo Pascalin murteesta ja näin ollen siinä oli riski, että jonkun patentin takia torpataan koko projekti. Javan kanssahan sitä sitten riideltiin patenttien takia muutamaa vuotta myöhemmin.

Toinen vika Free Pascalissa oli lisensointi. Ei BSD järjestelmiin lisätä yhtään GPL koodia lisää saastuttamaan koodipuuta. Ainoat GPL palikat mitä BSD järjestelmissä käytettiin oli aikoinaan just joku GCC ja autotools ja kokoajan GPL koodia on vähennetty koodipohjasta.

Toisin sanoen, Object Pascalilla OpenSSL olisi jäänyt kelvottomaksi torsoksi jota ei olisi ihmiset käyttänyt ja sen tilalle olisi tehty oikeilla työkaluilla toinen kirjasto C:llä.

"Mikrokontrollerin koodaus voi olla ainoa paikka, jossa Objectpascal ei ole paras kieli.
Mutta niissäkin Pascal on parempi valinta kuin C.

Ja sitten kun sitä C:tä kuitenkin on niin tuo vaan lisää kompleksisuutta tuoda ylimääräisiä työkaluja.
"DO-178B sertifiointi edellyttää myös sitä, että käytettävät työkalut kuten kääntäjä on perusteellisesti varmistettu oikeelliseksi.

Object Pascal todellakin sopii reaaliaikasovelluksiin. Monet reaaliaikakohteet, kuten lentokoneen järjestelmät, vaan edellyttää myös sitä sertifiointia
joten reaaliaikasovellukset joissa Object Pascalia voisi käyttää rajoittuisi teollisuusautomaatioon ..."

Hmmm....

mikä estää sertifioimasta Objectpascal -kielellä tehtyä ohjelmaa,
joka on käännetty FreePascal -kääntäjällä siten, että se on kelvollinen lentokoneeseen ?

Ovatko muilla kielillä tehdyt lentokoneiden ohjelmat sitten turvallisia?

EIVÄT OLE !

Tai eivät ainakaan olleet kesäkuussa 2009.

googlettakaapa: Air France Flight 447

Viime kädessä toki lentäjän virhe,
mutta olisi epäoikeudenmukaista syyttää pelkästään lentäjää !

Lentokoneen tietotekniikkaa hyödyntävä hallintajärjestelmä
oli suorastaan vaarallisesti ohjelmoitu, ja on samalla malliesimerkki siitä,
että sertifiointi ei oikeasti hyödytä mitään
(muuta kuin sertifiointeja tekevien yritysten omistajien osinkotulojen maksimointia).

Vai väittääkö M-Kar, että Air France lensi lentojaan lentokoneella,
jonka lentotietojärjestelmien sertifiointi ei ollut voimassa ?

Kyseisen lennon lentotietojärjestelmä oli siis ohjelmoitu toimimaan kerrassaan
vaarallisella tavalla:

Kun konetta lennettiin oikein, sakkausvaroitin hälytti jatkuvasti
(kun pitot -noeusanturit antoivat jäätymisen takia väärää tietoa koneen nopeudesta).

Kun konetta lennettiin väärin:

"From there until the end of the flight, the angle of attack never dropped below 35 degrees."

eli koneen nokka osoitti väärin lennettäessä vähintään 35 astetta yläviistoon,

silloin sakkausvaroitin ei varoittanut.

Todella vaarallinen tapa ohjelmoida sakkausvaroitin, eli oli omiaan houkuttelemaan lentäjän
tekemään juuri se virhe, minkä lentäjä sitten tekikin, ja joka ohjasi koneen tuhoonsa.

Mutta, M-Karin mielestä siis muodollinen sertifikaatti on tärkeämpää kuin se,
että ohjelmoija olisi oikeasti ymmärtänyt, mitä ja miten on ohjelmoimassa.

Itse olisin toteuttanut asian toisin:

sakkausvaroitin varoittaa aina, kun kone on joko sakkausvaarassa tai jo sakkaustilanteessa!

Toki pitää löytyä nappi, jota painamalla sakkausvaroittimen varoitusäänen voi hiljentää,
mutta varoitin jatkaa varoittamalla muulla tavalla, siis sekä vilkkuvalolla että
ohjaustikkua ravistamalla, tämä tunnetaan englanniksi nimellä "stick shaker".

ELi siis varoitusÄÄNEN voi hiljentää, mutta itse varoitus jatkuu, kun siihen on aihetta.

Väärä syöte nopeusanturilta on toki hyvin ikävä tilanne,
mutta siihenkin varautumiseen olisi olemassa keinoja.

Mutta on ikävää, jos alalla päätösvalta on annettu M-Karin tapaisille yksilöille,
joita kiinnostaa eniten muodollinen sertifikaatti ja se, että se on kunnossa, mutta

sitten tosiasiallinen oikein toimivuus ei kiinnosta ketään.

Lennon 447 lentäjistä kokenein, eli kapteeni tuli lepovuorosta välittämättä paikalle,
ja ilmeisesti kokeneempana olisi pystynyt pelastamaan
vakavaan vaaratilanteeseen joutuneen lentokoneen,
mutta pelstusyrityksen onnistumisen esti muutama ikävä seikka:

1. Kapteeni saapui lepovuoron keskeyttäneenä liian myöhään takaisin ohjaamoon,
jolloin tilanteen korjaamiseen ei jäänyt riittävästi aikaa.
Kapteenin saapuessa siis kone oli jatkuvassa sakkaustilassa,
ja koneen korkeus putosi huimaa vauhtia kohti valtameren pintaa,
koska nokka osoitti vähintään 35 astetta yläviistoon.

2. Airbusin ohjaamon tekninen suunnittelu ei ole paras mahdollinen!
Boeingin koneissa kapteenin ja perämiehen ohjaimet on mekaanisesti kytketty toisiinsa.

Jos kone olisi ollut Boeing, kapteeni olisi tajunnut välittömästi,
että nokka osoittaa aivan liian ylös.

Mutta Airbusissa asia on (tai ainakin oli kesäkuussa 2009) toisin:
Molemmilla on elektronisesti toteutettu oma ohjaimensa, jolla voi antaa
komentoja lentotietojärjestelmälle.
Jos kapteeni ja perämies antavat eri komennon nokan suuntauksesta
(mikä on mahdollista kun mekaanista yhteenkytkentää ei ole),
mistä lentotietojärjestelmä tietää, kumman komentoa noudattaa ?

Kapteeni ei välttämättä tajunnut, että perämies teki tyhjäksi kapteenin yrityksen
pelastaa lentokoneensa vakavasta vaaratilanteesta !

Jälleen malliesimerkki siitä, mitä seuraa, kun joku muodollinen sertifikaatti on olevinaan
hyvin tärkeää, mutta ohjelman koodaaja ei tunnu ymmärtävän tosiasioita lentämisestä.

Jokaisen koodarin pitäisi ymmärtää ainakin perusasiat fysiikan laeista, joita jokainen
lentokone väkisinkin noudattaa.

Tämän lisäksi, jos koodaaja ei ymmärrä jotakin yksityiskohtaa, vastuullinen koodari
konsultoisi asiassa fyysikkoa, ammattilentäjää tai molempia.

Näin itse olisin toiminut, ja luonnollisesti käyttänyt Objectpascalia koodauksen
käytännön toteutuksessa.

Onko muuten M-Karin mukaan Javalla tuo DO-178B sertifiointi ?

JOS ON, niin se osoittaa kyseisen sertifioinnin lähinnä pelleilyksi.

Poikkeuksena ehkä se, jos jossain Java -toteutuksessa on muita Java -toteutuksia fiksummin
teh
Kommentoi
2
Ilmianna
Jaa
Lyhyesti-kiitos kirjoitti:
Vielä kehtasi vääntää päin persettä. Missä pirussa niin sanotaan että vakiot kirjotetaan isolla, elikä ei tietenkään siihen ole mitään syntaksi sääntöä, ohjelmoija tekee niin kuin haluaa. Luettavuuden vuoksi jollakin tavalla ohjelmoijan on hyvä leimata vakiot selvästi muuttujista eritavalla. mikään ei estä tekemästä sitä toisinkin päin.

Vaikioiden kirjoittaminen isolla on hyvän tavan mukainen sääntö, jota voi verrata vaikka sääntöön, älä ohjelmoi voileipä toisessa kädessä.

#define pii 3.14

Minkä virheilmoituksen sinun kehitysympäristö antaa yllä olevasta määrittelystä ?
Ei se anna virheilmoitusta, kun siinä ei ole virhettä, eikä myöskään tässä alla olevassa.

#define PII 3.14
"Vielä kehtasi vääntää päin persettä. Missä pirussa niin sanotaan että vakiot kirjotetaan isolla"

Varmaan kaikissa tyylioppaissa konsensus tästä.

"Minkä virheilmoituksen sinun kehitysympäristö antaa yllä olevasta määrittelystä ?"

Punakynä maalaa tekstit tai sitten jälkikäteen ajettuna lintteri, joku clang-tidy vaikka älähtää.

En minä ole sanonut, että kielen säännöt pakottaisi mutta ei tarvitsekkaan. Se kieli on vain edelleen työkalu millä muotoillaan omat ajatukset tietokoneen ymmärtämään muotoon.

"mikä estää sertifioimasta Objectpascal -kielellä tehtyä ohjelmaa,
joka on käännetty FreePascal -kääntäjällä siten, että se on kelvollinen lentokoneeseen ?"

Se sertifiointiprosessi on niin tiukka, että siihen kuuluu myös kääntäjä ja varmistetaan myös se, että kääntäjä tuottaa oikeaa koodia. Voihan kääntäjissäkin olla bugeja. Ja tietysti sertifiointiin kuuluu myös rauta.

"Ovatko muilla kielillä tehdyt lentokoneiden ohjelmat sitten turvallisia?"

Tällä hetkellä hyväksyttyjä on C, Ada ja riisuttu C++ missä käytetään vain tiettyjä osia kielestä.

"Kun konetta lennettiin oikein, sakkausvaroitin hälytti jatkuvasti
(kun pitot -noeusanturit antoivat jäätymisen takia väärää tietoa koneen nopeudesta)."

Eli sieltä ei löytytynyt nappia sakkausvaroituksen pois kytkemiseksi. Joko puuttui tai oli typerässä paikassa. Mokahan se mutta siellä ilmailupuolella on tiukat laatuprosessit siksi, että tuollaisia mokia kävisi vähän. Siihen prosessiin kuuluu myös korjata aiemmat mokat, että jatkossa ei pääsisi enää käymään.

"Mutta, M-Karin mielestä siis muodollinen sertifikaatti on tärkeämpää kuin se,
että ohjelmoija olisi oikeasti ymmärtänyt, mitä ja miten on ohjelmoimassa."

ObjectPascal ei tässä olisi pelastanut kun vika oli tehty ennen kuin koodia oli alettu kirjoittamaan.

"Onko muuten M-Karin mukaan Javalla tuo DO-178B sertifiointi ?"

Ei. Javassa on semmoinen ominaisuus kuin roskienkerääjä ja silloin kun roskienkerääjä pyörähtää ja vapauttaa muistia niin lentokoneita alkaisi putoilla. Se roskienkerääjä kun on suunniteltu tilanteissiin missä ei ole jatkuva reaaliaikavaatimus vaan tilanteisiin joissa kuormitus vaihtelee, että sitä ajellaan silloin kun ei olisi kuormaa.

Javasta ollaan kyllä tekemässä jotain tällaisiin tilanteisiin sopivaa, riisuttua versioita missä ollaan jollain konstilla pakotettu muistinhallinta toimimaan reaaliaikavaatimuksilla ja tässä voi olla myös oma rauta myös millä se temppu tehdään.

https://jcp.org/en/jsr/detail?id=302

Tätä on työstetty 11v jo, ei tosiaankaan ole valmis eikä nykyisellään kelpaa lentokoneisiin.

F-35 hävittäjä taisi olla ensimmäinen missä alettiin käyttämään riisuttua C++:aa ja tämähän saatiin pari vuotta sitten. C++ taas on vuodelta -83, että noissa turvallisuuskriittisissä järjestelmissä on aika pitkä sykli sille että softa on nuoltuna siihen kuntoon, että voi ottaa lentokoneen kriittisiin järjestelmiin.

Ada toki on yhtä vanha ja sitä on käytetty pitkään mutta siinä semmoinen ero, että se kieli alusta lähtien suunniteltu käytettäväksi jossain lentokoneiss tai ydinaseissa ja on ollut varmistettuna iäisyyden, että työkalut toimii oikein.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Vielä kehtasi vääntää päin persettä. Missä pirussa niin sanotaan että vakiot kirjotetaan isolla"

Varmaan kaikissa tyylioppaissa konsensus tästä.

"Minkä virheilmoituksen sinun kehitysympäristö antaa yllä olevasta määrittelystä ?"

Punakynä maalaa tekstit tai sitten jälkikäteen ajettuna lintteri, joku clang-tidy vaikka älähtää.

En minä ole sanonut, että kielen säännöt pakottaisi mutta ei tarvitsekkaan. Se kieli on vain edelleen työkalu millä muotoillaan omat ajatukset tietokoneen ymmärtämään muotoon.

"mikä estää sertifioimasta Objectpascal -kielellä tehtyä ohjelmaa,
joka on käännetty FreePascal -kääntäjällä siten, että se on kelvollinen lentokoneeseen ?"

Se sertifiointiprosessi on niin tiukka, että siihen kuuluu myös kääntäjä ja varmistetaan myös se, että kääntäjä tuottaa oikeaa koodia. Voihan kääntäjissäkin olla bugeja. Ja tietysti sertifiointiin kuuluu myös rauta.

"Ovatko muilla kielillä tehdyt lentokoneiden ohjelmat sitten turvallisia?"

Tällä hetkellä hyväksyttyjä on C, Ada ja riisuttu C++ missä käytetään vain tiettyjä osia kielestä.

"Kun konetta lennettiin oikein, sakkausvaroitin hälytti jatkuvasti
(kun pitot -noeusanturit antoivat jäätymisen takia väärää tietoa koneen nopeudesta)."

Eli sieltä ei löytytynyt nappia sakkausvaroituksen pois kytkemiseksi. Joko puuttui tai oli typerässä paikassa. Mokahan se mutta siellä ilmailupuolella on tiukat laatuprosessit siksi, että tuollaisia mokia kävisi vähän. Siihen prosessiin kuuluu myös korjata aiemmat mokat, että jatkossa ei pääsisi enää käymään.

"Mutta, M-Karin mielestä siis muodollinen sertifikaatti on tärkeämpää kuin se,
että ohjelmoija olisi oikeasti ymmärtänyt, mitä ja miten on ohjelmoimassa."

ObjectPascal ei tässä olisi pelastanut kun vika oli tehty ennen kuin koodia oli alettu kirjoittamaan.

"Onko muuten M-Karin mukaan Javalla tuo DO-178B sertifiointi ?"

Ei. Javassa on semmoinen ominaisuus kuin roskienkerääjä ja silloin kun roskienkerääjä pyörähtää ja vapauttaa muistia niin lentokoneita alkaisi putoilla. Se roskienkerääjä kun on suunniteltu tilanteissiin missä ei ole jatkuva reaaliaikavaatimus vaan tilanteisiin joissa kuormitus vaihtelee, että sitä ajellaan silloin kun ei olisi kuormaa.

Javasta ollaan kyllä tekemässä jotain tällaisiin tilanteisiin sopivaa, riisuttua versioita missä ollaan jollain konstilla pakotettu muistinhallinta toimimaan reaaliaikavaatimuksilla ja tässä voi olla myös oma rauta myös millä se temppu tehdään.

https://jcp.org/en/jsr/detail?id=302

Tätä on työstetty 11v jo, ei tosiaankaan ole valmis eikä nykyisellään kelpaa lentokoneisiin.

F-35 hävittäjä taisi olla ensimmäinen missä alettiin käyttämään riisuttua C++:aa ja tämähän saatiin pari vuotta sitten. C++ taas on vuodelta -83, että noissa turvallisuuskriittisissä järjestelmissä on aika pitkä sykli sille että softa on nuoltuna siihen kuntoon, että voi ottaa lentokoneen kriittisiin järjestelmiin.

Ada toki on yhtä vanha ja sitä on käytetty pitkään mutta siinä semmoinen ero, että se kieli alusta lähtien suunniteltu käytettäväksi jossain lentokoneiss tai ydinaseissa ja on ollut varmistettuna iäisyyden, että työkalut toimii oikein.
''''''''''Varmaan kaikissa tyylioppaissa konsensus tästä.'''''''''
Pidetään faktatieto sellaisena kun se on, minä en hyväksy mitään konsensusta tässä. Jos MUSTA on mustaa ja VALKOINEN on valkoista, siihen ei mitään konsensusta tarvita.

''''''Punakynä maalaa tekstit tai sitten jälkikäteen ajettuna lintteri, joku clang-tidy vaikka älähtää.''''''''
Sellaista punakynää ei ole.

''''En minä ole sanonut, että kielen säännöt pakottaisi mutta ei tarvitsekkaan''''''
Tämä on siis sinun mielipide, ei niiden jotka sitä käyttävät.

YHTEENVETO
Sinun mielestä kieli on hyvä, eikä muutoksia syntaksiin kaivata, koska joku kolmas osapuoli on tehnyt hyvästä ohjelmointi tavasta poikkeavien kohtien paikantajan.

C kieli, onko "toka" muuttuja vai vakio ? (vastaus löytyy jostakin lähdekoodista)
return eka;
return toka;

PHP kieli, onko "toka" muuttuja vai vakio ? (vastausta ei tarvitse hakea, se on vakio)
return $eka;
return toka;

Vain täysi ummikko voi sanoa $ -merkkiä PHP:ssä ylimääräiseksi. Tarkastellaan vielä C ja PHP kieliin sisältyvien käsitteiden määriä.

PHP Kielen käsitteitä
Classes . . . . . 537
Constants . . 1790
Functions . . .5076
Interfaces . . 24
Methods . . . 5510
Properties . 389
Variables . . .21

C Kielen käsitteitä
Classes . . . . . . . 3
Enumerations 1
Functions . . . . .417
Macros . . . . . . . 408
Types . . . . . . . . . 83

Ehkä tämä omalta osaltaan kertoo miksi kielen syntaksi on virhealtista koodattavaa. C++ kieli korjaa C kielen puutteita.

C++ Kielen käsitteitä
Classes . . . . . . . 483
Constants . . . . 275
Enumerations 34
Functions . . . . .777
Macros . . . . . . . 444
Methods . . . . . .2054
Types . . . . . . . . .262
Kommentoi
2
Ilmianna
Jaa
Lyhyesti-kiitos kirjoitti:
''''''''''Varmaan kaikissa tyylioppaissa konsensus tästä.'''''''''
Pidetään faktatieto sellaisena kun se on, minä en hyväksy mitään konsensusta tässä. Jos MUSTA on mustaa ja VALKOINEN on valkoista, siihen ei mitään konsensusta tarvita.

''''''Punakynä maalaa tekstit tai sitten jälkikäteen ajettuna lintteri, joku clang-tidy vaikka älähtää.''''''''
Sellaista punakynää ei ole.

''''En minä ole sanonut, että kielen säännöt pakottaisi mutta ei tarvitsekkaan''''''
Tämä on siis sinun mielipide, ei niiden jotka sitä käyttävät.

YHTEENVETO
Sinun mielestä kieli on hyvä, eikä muutoksia syntaksiin kaivata, koska joku kolmas osapuoli on tehnyt hyvästä ohjelmointi tavasta poikkeavien kohtien paikantajan.

C kieli, onko "toka" muuttuja vai vakio ? (vastaus löytyy jostakin lähdekoodista)
return eka;
return toka;

PHP kieli, onko "toka" muuttuja vai vakio ? (vastausta ei tarvitse hakea, se on vakio)
return $eka;
return toka;

Vain täysi ummikko voi sanoa $ -merkkiä PHP:ssä ylimääräiseksi. Tarkastellaan vielä C ja PHP kieliin sisältyvien käsitteiden määriä.

PHP Kielen käsitteitä
Classes . . . . . 537
Constants . . 1790
Functions . . .5076
Interfaces . . 24
Methods . . . 5510
Properties . 389
Variables . . .21

C Kielen käsitteitä
Classes . . . . . . . 3
Enumerations 1
Functions . . . . .417
Macros . . . . . . . 408
Types . . . . . . . . . 83

Ehkä tämä omalta osaltaan kertoo miksi kielen syntaksi on virhealtista koodattavaa. C++ kieli korjaa C kielen puutteita.

C++ Kielen käsitteitä
Classes . . . . . . . 483
Constants . . . . 275
Enumerations 34
Functions . . . . .777
Macros . . . . . . . 444
Methods . . . . . .2054
Types . . . . . . . . .262
"Jos MUSTA on mustaa ja VALKOINEN on valkoista, siihen ei mitään konsensusta tarvita."

Ei siihen tarvitse mitään lisämerkkejä näyttämään eroa kun vakiot tunnistaa ISOLLA kirjoitetusta.

"Sellaista punakynää ei ole."

Onhan. Hanki kunnon IDE.

"Sinun mielestä kieli on hyvä, eikä muutoksia syntaksiin kaivata, koska joku kolmas osapuoli on tehnyt hyvästä ohjelmointi tavasta poikkeavien kohtien paikantajan."

En ole tuollaista väittänyt.

Et tunnu hahmoittavan sitä, että on asioita joita kielen spesifikaatio pakottaa, muut työkalut pakottaa tai sitten tehdään asia jollain käytännöllä. Lopputulosta se ei muuta, että kumpi työkalu saa tehtyä tuon asian siistimmin ja tässä tapauksessa se oli C.

"C kieli, onko "toka" muuttuja vai vakio ? (vastaus löytyy jostakin lähdekoodista)

return eka;
return toka;

Tuossa tapauksessa molemmat ovat muutujia koska vakiot kirjoitetaan isolla.

"PHP kieli, onko "toka" muuttuja vai vakio ? (vastausta ei tarvitse hakea, se on vakio)"

return $eka;
return toka;

PHP ohjelmoinnissa myös normaali käytäntö kirjoittaa vakiot isolla. tuossa tapauksessa varmaan tulisi virheilmoitus kun muuttujan nimestä puuttuu $. Vakiohan olisi kirjoitettu TOKA

"Vain täysi ummikko voi sanoa $ -merkkiä PHP:ssä ylimääräiseksi. "

Moni muu kieli tekee saman tempun ilman $ merkkiä. Sinä vissiin haluat tunkea sen ObjectPascaliinkin?
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Jos MUSTA on mustaa ja VALKOINEN on valkoista, siihen ei mitään konsensusta tarvita."

Ei siihen tarvitse mitään lisämerkkejä näyttämään eroa kun vakiot tunnistaa ISOLLA kirjoitetusta.

"Sellaista punakynää ei ole."

Onhan. Hanki kunnon IDE.

"Sinun mielestä kieli on hyvä, eikä muutoksia syntaksiin kaivata, koska joku kolmas osapuoli on tehnyt hyvästä ohjelmointi tavasta poikkeavien kohtien paikantajan."

En ole tuollaista väittänyt.

Et tunnu hahmoittavan sitä, että on asioita joita kielen spesifikaatio pakottaa, muut työkalut pakottaa tai sitten tehdään asia jollain käytännöllä. Lopputulosta se ei muuta, että kumpi työkalu saa tehtyä tuon asian siistimmin ja tässä tapauksessa se oli C.

"C kieli, onko "toka" muuttuja vai vakio ? (vastaus löytyy jostakin lähdekoodista)

return eka;
return toka;

Tuossa tapauksessa molemmat ovat muutujia koska vakiot kirjoitetaan isolla.

"PHP kieli, onko "toka" muuttuja vai vakio ? (vastausta ei tarvitse hakea, se on vakio)"

return $eka;
return toka;

PHP ohjelmoinnissa myös normaali käytäntö kirjoittaa vakiot isolla. tuossa tapauksessa varmaan tulisi virheilmoitus kun muuttujan nimestä puuttuu $. Vakiohan olisi kirjoitettu TOKA

"Vain täysi ummikko voi sanoa $ -merkkiä PHP:ssä ylimääräiseksi. "

Moni muu kieli tekee saman tempun ilman $ merkkiä. Sinä vissiin haluat tunkea sen ObjectPascaliinkin?
No, minä luotan lukijoiden ymmärrykseen asian suhteen, ja päätän keskustelun omalta osaltani tähän.
Kommentoi
1
Ilmianna
Jaa
+Lisää kommentti
Eikö tuosta puutu Git?
2
Ilmianna
Jaa
Mitä sitä turhaan kehittelemään kun kaikki on aivan valmista jo.
Kommentoi
2
Ilmianna
Jaa
41 VASTAUSTA:
Totta tuokin. Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta. Sitten kun väitettiin keskeneräiseksi ohjelmia niin kysyin, että mitäs tästä maailmasta nyt sitten niinkuin oikeasti puuttuu niin en saanut siihenkään vastausta.

Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Totta tuokin. Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta. Sitten kun väitettiin keskeneräiseksi ohjelmia niin kysyin, että mitäs tästä maailmasta nyt sitten niinkuin oikeasti puuttuu niin en saanut siihenkään vastausta.

Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa.
Maailmasta puuttuu ääretön määrä liiketoimintasovelluksia. Jotkut tarpeet ovat toki paikattavissa räätälöitävillä yleisohjelmilla, mutta ei läheskään kaikki. Ja osa räätälöinneistäkin on ihan selkeästi ohjelmistokehittämistä, eikä pelkkää konffaamista.
Kommentoi
2
Ilmianna
Jaa
sfsfdfsdf kirjoitti:
Maailmasta puuttuu ääretön määrä liiketoimintasovelluksia. Jotkut tarpeet ovat toki paikattavissa räätälöitävillä yleisohjelmilla, mutta ei läheskään kaikki. Ja osa räätälöinneistäkin on ihan selkeästi ohjelmistokehittämistä, eikä pelkkää konffaamista.
"Maailmasta puuttuu ääretön määrä liiketoimintasovelluksia. "

Esim. mitä? Miltä toimialalta puuttuu sovellukset ja mitä?

On normaalia, että ensimmäisessä vaiheessa käytetään kynää ja paperia, sen jälkeen homma tehdään yleiskäyttöisillä toimistosovelluksilla ja lopuksi optimoidaan käyttötarpeisiin tehdyillä sovelluksilla.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Maailmasta puuttuu ääretön määrä liiketoimintasovelluksia. "

Esim. mitä? Miltä toimialalta puuttuu sovellukset ja mitä?

On normaalia, että ensimmäisessä vaiheessa käytetään kynää ja paperia, sen jälkeen homma tehdään yleiskäyttöisillä toimistosovelluksilla ja lopuksi optimoidaan käyttötarpeisiin tehdyillä sovelluksilla.
Ihan jokaiselta yritykseltä joka toimii jonkin prosessin mukaan "puuttuu" siihen prosessiin sovitettu sovellus.
Kommentoi
2
Ilmianna
Jaa
sdfafsdfsd kirjoitti:
Ihan jokaiselta yritykseltä joka toimii jonkin prosessin mukaan "puuttuu" siihen prosessiin sovitettu sovellus.
Esimerkiksi mitä?
Kommentoi
Ilmianna
Jaa
sdfafsdfsd kirjoitti:
Ihan jokaiselta yritykseltä joka toimii jonkin prosessin mukaan "puuttuu" siihen prosessiin sovitettu sovellus.
Tämä on täysin 100% totta. Nykyisessä työpaikassa (5v+) olen kehittänyt webissä toimivaa taloushallinnon softaa (prosesseja) ja koskaan tämä ei ole valmis. Uusia asiakkaita tulee, vaatimukset kasvaa, kuormat kasvaa, softa elää jatkuvasti. Open-source softaa käytetään 99% hyväksi ja myös Linux tuli tutuksi tämä työpaikan kautta.

Kävin eräs kerta nettideiteillä ja sanoin naiselle mitä teen työkseni, nainen kysyi että eikö se ole jo valmis? :'D hahaha! Joo niin se on, me vain nojaillaan tuoliin ja pyöritellään peukkuja, ei tod!
Kommentoi
2
Ilmianna
Jaa
Esimerkiksi nakkikioskilta "puuttuu" sovellus joka seuraa tilauksia ja optimoi sen mukaan rasvakeittimen käyttöaikoja.
Kommentoi
2
Ilmianna
Jaa
keps kirjoitti:
Tämä on täysin 100% totta. Nykyisessä työpaikassa (5v+) olen kehittänyt webissä toimivaa taloushallinnon softaa (prosesseja) ja koskaan tämä ei ole valmis. Uusia asiakkaita tulee, vaatimukset kasvaa, kuormat kasvaa, softa elää jatkuvasti. Open-source softaa käytetään 99% hyväksi ja myös Linux tuli tutuksi tämä työpaikan kautta.

Kävin eräs kerta nettideiteillä ja sanoin naiselle mitä teen työkseni, nainen kysyi että eikö se ole jo valmis? :'D hahaha! Joo niin se on, me vain nojaillaan tuoliin ja pyöritellään peukkuja, ei tod!
Kuormien ja asiakkaiden määrän kasvu ei olennaisesti ole ongelma jos infra on kunnossa. Että uutta serveriä vaan ylös.

Että organisaation tarjoamat palvelut ja tuotteet organisaation ulkopuolelle ja sisäiset palvelut organisaation sisälle ratkaisee että paljon kompleksisuutta, ja kompleksuus kertoo sitten siitä työmäärästä.

Aika monta palikkaa on tietysti valmista ja saatavilla että eihän näitä tyhjästä tarvitse tehdä. Hyvin usein kehittämisen sijasta konfiguroidaan valmiiksi tehty softa toimimaan haluamalla tavalla.
Kommentoi
Ilmianna
Jaa
sdfsfdf kirjoitti:
Esimerkiksi nakkikioskilta "puuttuu" sovellus joka seuraa tilauksia ja optimoi sen mukaan rasvakeittimen käyttöaikoja.
Rasvakeitin aitetaan päälle silloin kun on saapumassa asiakkaita. Vai onko ideoita miten asian voisi tehdä paremmin?
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Rasvakeitin aitetaan päälle silloin kun on saapumassa asiakkaita. Vai onko ideoita miten asian voisi tehdä paremmin?
Ruuhkassa voidaan optimoida paistojärjestystä niin että käyttöaste pysyy mahdollisimman korkeana ilman että öljy pääsee kuitenkaan jäähtymään liikaa eikä mikään tilaus veny halutun minuuttimäärän ylitse.
Kommentoi
2
Ilmianna
Jaa
sdfsdfsdfsdg kirjoitti:
Ruuhkassa voidaan optimoida paistojärjestystä niin että käyttöaste pysyy mahdollisimman korkeana ilman että öljy pääsee kuitenkaan jäähtymään liikaa eikä mikään tilaus veny halutun minuuttimäärän ylitse.
Mihin tässä tarvitsee sitä softaa kun nakkikiskalla näkee sen asiakasmäärän että voi sen mukaan kytkeä päälle tai pois.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Mihin tässä tarvitsee sitä softaa kun nakkikiskalla näkee sen asiakasmäärän että voi sen mukaan kytkeä päälle tai pois.
Mihin tietokoneitakaan ylipäätään tarvitaan kun ei niitä sata vuotta sittenkään tarvittu? Entäs sitten kun nakkikiska alkaa ottamaan tilauksia netin kautta? Mistä ne tilaajat silloin nähdään, että tuleekohan viiden minuutin sisällä kuinka paljon mitäkin tilauksia?

Sinäkö et siis ymmärrä mihin liiketoimintasovelluksia tarvitaan, tai miten IT:n avulla voidaan valvoa, raportoida ja optimoida liiketoimintaprosesseja? Vai oletko jonkin asteinen AS-persoona tai autisti jolla on ongelmia tällaisessa tavallisessa sosiaalisessa kanssakäymisessä ja jolla on pakkomielle jotenkin vängätä vastaan kaikessa?
Kommentoi
2
Ilmianna
Jaa
sdfgagfdsg kirjoitti:
Mihin tietokoneitakaan ylipäätään tarvitaan kun ei niitä sata vuotta sittenkään tarvittu? Entäs sitten kun nakkikiska alkaa ottamaan tilauksia netin kautta? Mistä ne tilaajat silloin nähdään, että tuleekohan viiden minuutin sisällä kuinka paljon mitäkin tilauksia?

Sinäkö et siis ymmärrä mihin liiketoimintasovelluksia tarvitaan, tai miten IT:n avulla voidaan valvoa, raportoida ja optimoida liiketoimintaprosesseja? Vai oletko jonkin asteinen AS-persoona tai autisti jolla on ongelmia tällaisessa tavallisessa sosiaalisessa kanssakäymisessä ja jolla on pakkomielle jotenkin vängätä vastaan kaikessa?
"Entäs sitten kun nakkikiska alkaa ottamaan tilauksia netin kautta?"

Sittenhän tuo nähdään tilauksista mitä on tehty. Ja netin kautta tilaukseen on softa. Rasvakeitin vaan päälle silloin kun on tiedossa aktiviteettia ja jos ei tilauksia tulossa eikä asiakkaita ole tulossa nakkikiskalle päin niin sitten napsauttaa sen rasvakeittimen pois päältä.

"Sinäkö et siis ymmärrä mihin liiketoimintasovelluksia tarvitaan, tai miten IT:n avulla voidaan valvoa, raportoida ja optimoida liiketoimintaprosesseja?"

Toki ymmärrän mutta sinä et osannut kertoa PUUTTUVAA liiketoimintasovellusta. Ruoan tilaamiseen netin kautta on jo softa.

"Vai oletko jonkin asteinen AS-persoona tai autisti jolla on ongelmia tällaisessa tavallisessa sosiaalisessa kanssakäymisessä ja jolla on pakkomielle jotenkin vängätä vastaan kaikessa?"

Sinullahan ne ongelmat näkyy olevan kun yksinkertaiseen kysymykseen ei saa vastausta.

Jatkuvasti joku jankkaa että ohjelmissa on muka vikoja ja sitten kun kysyy miten vian voi toistaa niin ei vastausta. Ja jos ohjelmat on muka keskeneräisiä tai joku ohjelma puuttuu niin ei oikein siihenkään saa vastausta.

Tuossa rasvakeittimessä nyt oli vähän jotain yritystä mutta kyllä se nettitilaus on jo olemassa ja se rasvakeitin lähtee pois siitä napista silloin kun ei ole aktiviiteettia tilauksissa eikä ihmisiä kävelemässä nakkikiskan ympäristössä tai sitä kohti.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Entäs sitten kun nakkikiska alkaa ottamaan tilauksia netin kautta?"

Sittenhän tuo nähdään tilauksista mitä on tehty. Ja netin kautta tilaukseen on softa. Rasvakeitin vaan päälle silloin kun on tiedossa aktiviteettia ja jos ei tilauksia tulossa eikä asiakkaita ole tulossa nakkikiskalle päin niin sitten napsauttaa sen rasvakeittimen pois päältä.

"Sinäkö et siis ymmärrä mihin liiketoimintasovelluksia tarvitaan, tai miten IT:n avulla voidaan valvoa, raportoida ja optimoida liiketoimintaprosesseja?"

Toki ymmärrän mutta sinä et osannut kertoa PUUTTUVAA liiketoimintasovellusta. Ruoan tilaamiseen netin kautta on jo softa.

"Vai oletko jonkin asteinen AS-persoona tai autisti jolla on ongelmia tällaisessa tavallisessa sosiaalisessa kanssakäymisessä ja jolla on pakkomielle jotenkin vängätä vastaan kaikessa?"

Sinullahan ne ongelmat näkyy olevan kun yksinkertaiseen kysymykseen ei saa vastausta.

Jatkuvasti joku jankkaa että ohjelmissa on muka vikoja ja sitten kun kysyy miten vian voi toistaa niin ei vastausta. Ja jos ohjelmat on muka keskeneräisiä tai joku ohjelma puuttuu niin ei oikein siihenkään saa vastausta.

Tuossa rasvakeittimessä nyt oli vähän jotain yritystä mutta kyllä se nettitilaus on jo olemassa ja se rasvakeitin lähtee pois siitä napista silloin kun ei ole aktiviiteettia tilauksissa eikä ihmisiä kävelemässä nakkikiskan ympäristössä tai sitä kohti.
Jos sinulla on 100 tilausta ranskalaisista, 80 nugetti-tilausta ja 20 kalapihviä, niin eipä tuo nyt täysin triviaalia ole miettiä missä järjestyksessä ne tilaukset ovat tulleet, kuinka paljon mitäkin tavaraa voidaan kerralla keittimeen laittaa ilman että lämmöt laskee liikaa, kuinka lisätyt tuotteet vaikuttavat jo keittimessä olevien paistoaikaan, miten varmistaa että yhden tilauksen tuotteet valmistuvat tietyn aikaikkunan sisällä että osa ei ole jo toimitettaessa kylmää.

Samoin öljyn käyttömäärää pitää pystyä seuraamaan, suunnitella suodatukset, vaihtovälit, seurata ja logittaa lämpötiloja. Eli jos sinä et ymmärrä, että jokaisen olemassa olevan liiketoiminnan prosessin voi mallintaa sovelluksella tai tietojärjestelmällä, ja suuri osa näistä on edelleen mallintamatta niin tämän paksummasta rautalangasta en osaa enkä jaksa asiaa vääntää. On katsos vähän muutakin hommaa tässä niiden puuttuvien liiketoimintasovellusten tekemisen kanssa.
Kommentoi
2
Ilmianna
Jaa
M-Kar kirjoitti:
"Entäs sitten kun nakkikiska alkaa ottamaan tilauksia netin kautta?"

Sittenhän tuo nähdään tilauksista mitä on tehty. Ja netin kautta tilaukseen on softa. Rasvakeitin vaan päälle silloin kun on tiedossa aktiviteettia ja jos ei tilauksia tulossa eikä asiakkaita ole tulossa nakkikiskalle päin niin sitten napsauttaa sen rasvakeittimen pois päältä.

"Sinäkö et siis ymmärrä mihin liiketoimintasovelluksia tarvitaan, tai miten IT:n avulla voidaan valvoa, raportoida ja optimoida liiketoimintaprosesseja?"

Toki ymmärrän mutta sinä et osannut kertoa PUUTTUVAA liiketoimintasovellusta. Ruoan tilaamiseen netin kautta on jo softa.

"Vai oletko jonkin asteinen AS-persoona tai autisti jolla on ongelmia tällaisessa tavallisessa sosiaalisessa kanssakäymisessä ja jolla on pakkomielle jotenkin vängätä vastaan kaikessa?"

Sinullahan ne ongelmat näkyy olevan kun yksinkertaiseen kysymykseen ei saa vastausta.

Jatkuvasti joku jankkaa että ohjelmissa on muka vikoja ja sitten kun kysyy miten vian voi toistaa niin ei vastausta. Ja jos ohjelmat on muka keskeneräisiä tai joku ohjelma puuttuu niin ei oikein siihenkään saa vastausta.

Tuossa rasvakeittimessä nyt oli vähän jotain yritystä mutta kyllä se nettitilaus on jo olemassa ja se rasvakeitin lähtee pois siitä napista silloin kun ei ole aktiviiteettia tilauksissa eikä ihmisiä kävelemässä nakkikiskan ympäristössä tai sitä kohti.
"Rasvakeitin vaan päälle silloin kun on tiedossa aktiviteettia ja jos ei tilauksia tulossa eikä asiakkaita ole tulossa nakkikiskalle päin niin sitten napsauttaa sen rasvakeittimen pois päältä."

Sinä et selkeästi ymmärrä koko liiketoiminta-aluetta. Ei ihmekään että et kykene hahmottamaan mistä tässä puhutaan. Liiketoimintasovelluksen sunnittelu alkaa siitä, että ymmärretään se prosessi jonka parissa toimitaan. Sinulta puuttuu nyt tämän sisäistäminen, mutta vouhotat silti vaahtopallo housuissa kuinka mitään sovellusta ei tarvita tai sellainen on jo.

Ja se, että ruoan tilaamiseen netin kautta on softa ei paljoa lohduta sellaista yritystä jolla ei sitä softaa vielä ole käytössä. Jonkun pitää se asentaa, konfiguroida ja integroida olemassa olevaan ICT infraan ja sovelluksiin joka ei puolestaan käytännössä eroa räätälöidyn ohjelmiston tekemisestä mitenkään muuten paitsi valmiina olevien komponenttien määrän ja hyödynnettävyyden pohjalta. Väitteesi on yhtälailla hölmö kuin että sanoisi webbikehityksen olevan täysin turhaa sillä Wordpress on jo olemassa. No, ei se tyhjä Wordpress-asennus ihan hirveästi pienyrittäjää vielä lämmitä, vaan jonkun pitää sinnekin se sisältö tehdä. Wordpress tai jokin toiminnanohjausjärjestelmä on ainoastaan se viitekehys jonka sisällä se kehitystyö tapahtuu. Ei se tee siitä kehitystyöstä yhtään sen vähänpätöisempää "puhtaaseen" koodaamiseen verrattuna.
Kommentoi
2
Ilmianna
Jaa
dfsdfsdfasf kirjoitti:
"Rasvakeitin vaan päälle silloin kun on tiedossa aktiviteettia ja jos ei tilauksia tulossa eikä asiakkaita ole tulossa nakkikiskalle päin niin sitten napsauttaa sen rasvakeittimen pois päältä."

Sinä et selkeästi ymmärrä koko liiketoiminta-aluetta. Ei ihmekään että et kykene hahmottamaan mistä tässä puhutaan. Liiketoimintasovelluksen sunnittelu alkaa siitä, että ymmärretään se prosessi jonka parissa toimitaan. Sinulta puuttuu nyt tämän sisäistäminen, mutta vouhotat silti vaahtopallo housuissa kuinka mitään sovellusta ei tarvita tai sellainen on jo.

Ja se, että ruoan tilaamiseen netin kautta on softa ei paljoa lohduta sellaista yritystä jolla ei sitä softaa vielä ole käytössä. Jonkun pitää se asentaa, konfiguroida ja integroida olemassa olevaan ICT infraan ja sovelluksiin joka ei puolestaan käytännössä eroa räätälöidyn ohjelmiston tekemisestä mitenkään muuten paitsi valmiina olevien komponenttien määrän ja hyödynnettävyyden pohjalta. Väitteesi on yhtälailla hölmö kuin että sanoisi webbikehityksen olevan täysin turhaa sillä Wordpress on jo olemassa. No, ei se tyhjä Wordpress-asennus ihan hirveästi pienyrittäjää vielä lämmitä, vaan jonkun pitää sinnekin se sisältö tehdä. Wordpress tai jokin toiminnanohjausjärjestelmä on ainoastaan se viitekehys jonka sisällä se kehitystyö tapahtuu. Ei se tee siitä kehitystyöstä yhtään sen vähänpätöisempää "puhtaaseen" koodaamiseen verrattuna.
"Jos sinulla on 100 tilausta ranskalaisista, 80 nugetti-tilausta ja 20 kalapihviä, niin eipä tuo nyt täysin triviaalia ole miettiä missä järjestyksessä ne tilaukset ovat tulleet, kuinka paljon mitäkin tavaraa voidaan kerralla keittimeen laittaa ilman että lämmöt laskee liikaa, kuinka lisätyt tuotteet vaikuttavat jo keittimessä olevien paistoaikaan, miten varmistaa että yhden tilauksen tuotteet valmistuvat tietyn aikaikkunan sisällä että osa ei ole jo toimitettaessa kylmää."

Eiköhän se keitin ole sit kokoajan päällä jos on jatkuvaa käyttöä.

Oletan nyt, että keittimessä on joko on/off tai säädetään aikaa tai joku rele mikä napsahtaa pois kun ollut tarpeeksi pitkään lämmöt tapissa ja on vaikka joku ylläpitolämpö ja nappi millä voi kuumentaa. Että mitkä ne keittimen ominaisuudet nyt sitten on? En ole ollut nakkikiskassa töissä että en tiedä rasvakeittimen käyttöliittymää.

Kun puhutaan siitä softasta niin sehän tehdään sen keittimen käyttöliittymän ehdoilla mitä se käyttäjä tekee tai muuten tässä on kyse muustakin kuin softasta.

"Samoin öljyn käyttömäärää pitää pystyä seuraamaan, suunnitella suodatukset, vaihtovälit, seurata ja logittaa lämpötiloja."

Tuohon nyt ei tarvitse välttämättä mitään erityistä softaa kun kirjanpidosta saadaan tilaukset niin siitä voidaan laskea paljon öljyä tarvitsee kuluttaa kuukautta kohti. Ymmärtääkseni se ei voi olla liian moneen kertaa käytettyä että tilausmäärästä selviää monta kertaa kuukaudessa pitää vaihtaa.

"Eli jos sinä et ymmärrä, että jokaisen olemassa olevan liiketoiminnan prosessin voi mallintaa sovelluksella tai tietojärjestelmällä"

Tiedän toki että voi mallintaa mutta sen sovellukseksi mallinnuksen pitää hyödyttää ja lopputuloksen pitää tuoda lisäarvoa siihen taulukkolaskentaohjelmaan nähden.

Katsos kun tässä on niitäkin juttuja, jos ylisuunnittelee jonkun liiketoimintaprosessin niin siitä tulee vähän jäykkä ja hankalammin muutettavissa ja toisekseen se voi tarvita omaksumista käyttäjältä mitä taas pitäisi välttää. Kaikki osaa käyttää vasaraa mutta jos joka työpaikassa on oma avaruusasema niin se tuo tarpeetonta käyttökynnystä.

"ja suuri osa näistä on edelleen mallintamatta"

Jos prosessia ei ole edes mallinnettu niin silloin ei tarvitse sovellustakaan. Ensiksi pitää homma olla mallinnettu taulukkolaskentaohjelmalla, että joka kuukausi vaikka tuo kirjanpidosta .csv:n ja laskee halutut asiat ja pyörittelee sillä ja jos sillä saa hommaa jotenkin parannettua (eli saisi joka kuukausi jossain säästöä) ilman että olennaisesti tarvitsee työntekijää kuormittaa niin sen manuaalisen nysvän voi korvata kätevällä sovelluksella.

Minä kyllä väittäisin että nakkikioskissa on prosessi mallinnettu, että keitin napsautetaan päälle kun on tiedossa, että sen pitää olla parissa minuutissa kuuma ja on tietty vaihtoväli sille öljylle ja kuuluu prosessiin ja prosessi voi olla vaikka seinällä muistiin kirjoitettuna mitä toimenpiteitä tehdään päivän päätteeksi.

Se että puuttuuko tästä jotain olennaista sovellusta, että millä tavalla sovellus tuo lisäarvoa niin et nyt osannut sellaista sanoa vaan arvailet, että jotain lämpötilaa voisi mitata mutta mallinnuskin sitten puuttuu. Että kerrohan nyt mistä niitä mallinnuksia revit mistä sovellukset muka puuttuu?

"Ja se, että ruoan tilaamiseen netin kautta on softa ei paljoa lohduta sellaista yritystä jolla ei sitä softaa vielä ole käytössä."

Saahan sen otettua käyttöön. Tekee vaan sopparin softan tarjoajan kanssa ja maksetaan vähän rahaa.

"Jonkun pitää se asentaa, konfiguroida ja integroida olemassa olevaan ICT infraan"

Softa on yleensä softatoimittajan palvelimella, SaaSsiahan nuo ruokatilaukset on. Siellä sitten webserviceä ja näitä konffauksia sitten tekee softan toimittaja kun ostaa sen tilausjärjestelmän.

"No, ei se tyhjä Wordpress-asennus ihan hirveästi pienyrittäjää vielä lämmitä, vaan jonkun pitää sinnekin se sisältö tehdä. Wordpress tai jokin toiminnanohjausjärjestelmä on ainoastaan se viitekehys jonka sisällä se kehitystyö tapahtuu. Ei se tee siitä kehitystyöstä yhtään sen vähänpätöisempää "puhtaaseen" koodaamiseen verrattuna. "

No ei tässä nyt mistään räätälöinnistä ole ollut kysekään vaan siitä että puuttuuko jotain softaa. Jos jossain on tarve jollekin liiketoimintasovellukselle, eli on mallinnettuna tarve ja olkoot se vaikka Wordpress niin sehän on tehty jo.

Niitä puuttuvia sovelluksia ei oikein ole. Siis aidosti puuttuvia. Arvaukset siitä, että jotain voidaan mitata ei vielä tee tarvetta sovellukselle vaan se että toiminta on mallinnettu ja tiedetään joku typerä, manuaalinen toistuva työvaihe (jotain kirjataan paperiin tai taulukkolaskimeen) jollain toimialalla (kaikki nakkikioskit vaikka) jonka softa voi korvata ja säästää sitten jonkun työaikaa tunnin päivässä vaikka.

Hyvä esimerkki sovellustarpeesta oli vaikka se taulukkolaskin silloin 70-luvulla, että ennen yrittäjät pyöritteli näitä ruutupaperilla ja aina kun muutti numeroa niin paperi laskettiin käsin uusiksi. Taulukkolaskin poisti sen manuaalisen vaiheen.
Kommentoi
Ilmianna
Jaa
"Mitä sitä turhaan kehittelemään kun kaikki on aivan valmista jo."

Jokatapauksessa tämä on pötypuhetta, enpä olisi töissä alalla jos kaikki olisi jo tehty tai pari naksun päässä palikoilla toteutettavissa =)
Kommentoi
1
Ilmianna
Jaa
M-Kar kirjoitti:
Totta tuokin. Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta. Sitten kun väitettiin keskeneräiseksi ohjelmia niin kysyin, että mitäs tästä maailmasta nyt sitten niinkuin oikeasti puuttuu niin en saanut siihenkään vastausta.

Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa.
'''''''''Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta''''''''''

Täällä ei ole ketään niin tyhmää että rupeaa sairaan mutuilijan lässytyksiä todistelemaan puoleen eikä toiseen.
Kommentoi
2
Ilmianna
Jaa
yjtfujkyfukyf kirjoitti:
'''''''''Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta''''''''''

Täällä ei ole ketään niin tyhmää että rupeaa sairaan mutuilijan lässytyksiä todistelemaan puoleen eikä toiseen.
Jos olisin väärässä niin se on helppo osoittaa koska kaikki mitä sanon, on todistettavissa oikeaksi tai vääräksi. Jos ei kykene todistamaan vääräksi niin havaintojen perusteella olisin oikeassa.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Jos olisin väärässä niin se on helppo osoittaa koska kaikki mitä sanon, on todistettavissa oikeaksi tai vääräksi. Jos ei kykene todistamaan vääräksi niin havaintojen perusteella olisin oikeassa.
''''''''''havaintojen perusteella olisin oikeassa''''''''
Minä muistan joskus kuulleeni armottomasta juoposta, hän myös teki havaintoja, ja oli tietysti aivan oikeassa omasta mielestään.

Tään juopon havainnot, oli pikku-ukkoja, joita hän välillä pyyhkäsi kädellään pöydän reunalta lattialle. Turha sinulle niin kuin tuolle armottomalle juopollekkaan oli mennä kertomaan että havainnot on vääriä.
Kommentoi
2
Ilmianna
Jaa
rset6yhtr7ur67yik7t kirjoitti:
''''''''''havaintojen perusteella olisin oikeassa''''''''
Minä muistan joskus kuulleeni armottomasta juoposta, hän myös teki havaintoja, ja oli tietysti aivan oikeassa omasta mielestään.

Tään juopon havainnot, oli pikku-ukkoja, joita hän välillä pyyhkäsi kädellään pöydän reunalta lattialle. Turha sinulle niin kuin tuolle armottomalle juopollekkaan oli mennä kertomaan että havainnot on vääriä.
"Turha sinulle niin kuin tuolle armottomalle juopollekkaan oli mennä kertomaan että havainnot on vääriä."

Se sinun juopposi katsos näki olemattomia asioita. Niin vissiin sinäkin kun näet olemattomia havaintoja.

Minä taas seuraan tätä ketjua mitä tässä on sanottu ja jos on jotain negaativista länkytystä ilman todistetta, tai väittämää ei ole mahdollista todistaa oikeaksi tai vääräksi niin ainoat havainnot ovat ne mitä jää jäljelle. Esimerkiksi se mitä minä sanon.
Kommentoi
Ilmianna
Jaa
rset6yhtr7ur67yik7t kirjoitti:
''''''''''havaintojen perusteella olisin oikeassa''''''''
Minä muistan joskus kuulleeni armottomasta juoposta, hän myös teki havaintoja, ja oli tietysti aivan oikeassa omasta mielestään.

Tään juopon havainnot, oli pikku-ukkoja, joita hän välillä pyyhkäsi kädellään pöydän reunalta lattialle. Turha sinulle niin kuin tuolle armottomalle juopollekkaan oli mennä kertomaan että havainnot on vääriä.
Väännetään asia varmuuden vuoksi rautalangasta...

Jos minä sanon jonkun mielipiteen, täysin vapaasti todistettavissa vääräksi tai oikeaksi, usein vieläpä kerron mihin asian perustan niin jos sinä alat siitä lässyttää ja alat esittämään jotain negatiivisia väittämiä esim. joistakin yrityksistä, tuotteista tai minusta etkä esitä mitään todistetta niin sehän tarkoittaa sitä, että sinun lässytyksesi epäonnistui kumoamana alkuperäistä väittämää ja se siis on kestänyt muiden ihmisten tarkastelun ja kritisoinnin voittajana.

Minun mielipide voi siis myös jäädä ainoaksi havainnoksi jos kukaan ei kykene esittämään vaihtoehtoisia mielipiteitä tai todistamaan väittämiä.

Tällä tavalla siitä asiasta tulee tietysti vähitellen se hyväksytty totuus, kuten kävi vaikka evoluutioteorialle. Kaikennäköiset hihhulit ovat yrittäneet kumota sitä ja lässyttäneet vastaan mutta epäonnistuneet.

Taidat vissiin olla sitä raamattu -väkeä kun asioita ei tarvitse mitenkään todistaa vaan voi uskoa höpönpöppöön?
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Turha sinulle niin kuin tuolle armottomalle juopollekkaan oli mennä kertomaan että havainnot on vääriä."

Se sinun juopposi katsos näki olemattomia asioita. Niin vissiin sinäkin kun näet olemattomia havaintoja.

Minä taas seuraan tätä ketjua mitä tässä on sanottu ja jos on jotain negaativista länkytystä ilman todistetta, tai väittämää ei ole mahdollista todistaa oikeaksi tai vääräksi niin ainoat havainnot ovat ne mitä jää jäljelle. Esimerkiksi se mitä minä sanon.
Noin se juoppukin sanoi
Kommentoi
2
Ilmianna
Jaa
t6jy6rfkuy kirjoitti:
Noin se juoppukin sanoi
Juurihan sanoit, että juoppo havaitsi olemattomia pikku-ukkoja.

Minä en havaitse olemattomia asioita.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Juurihan sanoit, että juoppo havaitsi olemattomia pikku-ukkoja.

Minä en havaitse olemattomia asioita.
Niin niin, juopponkaan mielestä ei pikku-ukot olleet olemattomia, ja sinun mielestä havainnot ei ole olemattomia, kummallisen paljon samakaltaisuutta teissä molemissa.
Kommentoi
2
Ilmianna
Jaa
t78ikt78o76to kirjoitti:
Niin niin, juopponkaan mielestä ei pikku-ukot olleet olemattomia, ja sinun mielestä havainnot ei ole olemattomia, kummallisen paljon samakaltaisuutta teissä molemissa.
"Niin niin, juopponkaan mielestä ei pikku-ukot olleet olemattomia, ja sinun mielestä havainnot ei ole olemattomia, kummallisen paljon samakaltaisuutta teissä molemissa."

Sinähän niitä vaihtoehtoisia mielipiteitä näit havaittavissa. Missä?
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Niin niin, juopponkaan mielestä ei pikku-ukot olleet olemattomia, ja sinun mielestä havainnot ei ole olemattomia, kummallisen paljon samakaltaisuutta teissä molemissa."

Sinähän niitä vaihtoehtoisia mielipiteitä näit havaittavissa. Missä?
Älähän nyt käännä asiaa päälaelleen, vain sinä sanoit tehneesi havaintoja joiden mukaan vain sinun hyväksymät mielipitee on oikeita. Samalla tavalla se juoppo teki niitä omia havaintoja, jotka ei oleet kenenkään muun mielestä oikeita.
Kommentoi
2
Ilmianna
Jaa
u9ioly89p8y9p kirjoitti:
Älähän nyt käännä asiaa päälaelleen, vain sinä sanoit tehneesi havaintoja joiden mukaan vain sinun hyväksymät mielipitee on oikeita. Samalla tavalla se juoppo teki niitä omia havaintoja, jotka ei oleet kenenkään muun mielestä oikeita.
"Älähän nyt käännä asiaa päälaelleen, vain sinä sanoit tehneesi havaintoja joiden mukaan vain sinun hyväksymät mielipitee on oikeita."

Tein havainnot mielipiteistä mitä löytyi. Oli kaksi havaintoa. Minun mielipiteeni sekä toinen "C ja C++ on huonoa" mikä osoittautui virheelliseksi.

Jäljelle jäi siis havainto joka oli minun mielipiteeni. Selvästikin se havainto löytyy kun itse juuri jankkaat minun mielipiteestäni.

On myös täysi syy pitää mielipiteeni olevan oikeassa kun sitä ei ole onnistuttu todistamaan vääräksi. Tämä minun mielipiteeni on siis se havainto joka ei ole mikään mielikuvituksen tuote.

"jotka ei oleet kenenkään muun mielestä oikeita."

Jos on olevinaan väärin niin pitäisi todistaa se. Jos ei onnistu vaikka virheellinen väite on helposti todistettavissa vääräksi niin silloinhan havaintojen perusteella näyttäisi pitävän paikkansa.

Epäonnistuneet yritykset kumota mielipidettäni ovat myös havaintoja sen puolesta, että olen oikeassa.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Älähän nyt käännä asiaa päälaelleen, vain sinä sanoit tehneesi havaintoja joiden mukaan vain sinun hyväksymät mielipitee on oikeita."

Tein havainnot mielipiteistä mitä löytyi. Oli kaksi havaintoa. Minun mielipiteeni sekä toinen "C ja C++ on huonoa" mikä osoittautui virheelliseksi.

Jäljelle jäi siis havainto joka oli minun mielipiteeni. Selvästikin se havainto löytyy kun itse juuri jankkaat minun mielipiteestäni.

On myös täysi syy pitää mielipiteeni olevan oikeassa kun sitä ei ole onnistuttu todistamaan vääräksi. Tämä minun mielipiteeni on siis se havainto joka ei ole mikään mielikuvituksen tuote.

"jotka ei oleet kenenkään muun mielestä oikeita."

Jos on olevinaan väärin niin pitäisi todistaa se. Jos ei onnistu vaikka virheellinen väite on helposti todistettavissa vääräksi niin silloinhan havaintojen perusteella näyttäisi pitävän paikkansa.

Epäonnistuneet yritykset kumota mielipidettäni ovat myös havaintoja sen puolesta, että olen oikeassa.
Taas teet niitä ihme havaintoja, ja pultsari huitoo pikku-ukkoja pöydän reunalta.
Kommentoi
2
Ilmianna
Jaa
t789o8796 kirjoitti:
Taas teet niitä ihme havaintoja, ja pultsari huitoo pikku-ukkoja pöydän reunalta.
Teithän sinäkin sen havainnon. Et muuten kirjoittaisi niistä mielipiteistä.

Minun mielipide löytyy, sinulta ei löydy.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Teithän sinäkin sen havainnon. Et muuten kirjoittaisi niistä mielipiteistä.

Minun mielipide löytyy, sinulta ei löydy.
Lueppa nyt ihan ajatuksen kanssa, mitä kirjoitit.
Kommentoi
2
Ilmianna
Jaa
ed65ur6iur67i kirjoitti:
Lueppa nyt ihan ajatuksen kanssa, mitä kirjoitit.
Luin. Tässä ketjussa on esitetty kaksi mielipidettä. Toinen ei kestänyt argumentointia ja toinen kesti.

Jäljelle jäi siis yksi mielipide jonka sinä havaitset (havainto) koska kirjoitat asiasta viestejä ja samoin minä (havainto).

Sitten puhut jostain uusista havainnoista, mistä? Kuka on ja mitä mieltä? Nämä sinun uudet havainnot on niitä juopon tonttuja koska kukaan muu ei niitä havaitse.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Luin. Tässä ketjussa on esitetty kaksi mielipidettä. Toinen ei kestänyt argumentointia ja toinen kesti.

Jäljelle jäi siis yksi mielipide jonka sinä havaitset (havainto) koska kirjoitat asiasta viestejä ja samoin minä (havainto).

Sitten puhut jostain uusista havainnoista, mistä? Kuka on ja mitä mieltä? Nämä sinun uudet havainnot on niitä juopon tonttuja koska kukaan muu ei niitä havaitse.
Viittasin "tässä ketjussa" noilla kahdella mielipiteellä ylemmässä ketjussa olevaa argumentointia C:n ja C++:n "huonoudesta".
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Viittasin "tässä ketjussa" noilla kahdella mielipiteellä ylemmässä ketjussa olevaa argumentointia C:n ja C++:n "huonoudesta".
Ei se riitä että lukee, pitää myös ymmärtää lukemansa, joten lueppa uudestaan
Kommentoi
2
Ilmianna
Jaa
t678o6968tttyo9 kirjoitti:
Ei se riitä että lukee, pitää myös ymmärtää lukemansa, joten lueppa uudestaan
Sitä ennen voisit nyt kertoa niistä muista mielipiteistä. Yrität kokoajan siirtää keskustelua pois siitä olennaisesta asiasta, että voidaan osoittaa että sinulla oli niitä juopon harhoja.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Sitä ennen voisit nyt kertoa niistä muista mielipiteistä. Yrität kokoajan siirtää keskustelua pois siitä olennaisesta asiasta, että voidaan osoittaa että sinulla oli niitä juopon harhoja.
No hyvä on, pyydä että joku, (ellei äiti jouda) lukee ne sinulle.
Kommentoi
2
Ilmianna
Jaa
e56u76r7i677rt5 kirjoitti:
No hyvä on, pyydä että joku, (ellei äiti jouda) lukee ne sinulle.
Ei kukaan muu ole havainnut mitään juopon harhoja, nehän oli vain sinulla.

Todistat juuri sitä kun et kykene osoittamaan tästä ketjusta niitä muita mielipiteitä C tai C++:sta, eli ei ole niitä siitä sinun keksimiäsi muita havaintoja.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Totta tuokin. Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta. Sitten kun väitettiin keskeneräiseksi ohjelmia niin kysyin, että mitäs tästä maailmasta nyt sitten niinkuin oikeasti puuttuu niin en saanut siihenkään vastausta.

Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa.
"Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa."

Niin. Mielestäsi siis OpenSSL:n vuoden 2014 alussa olleessa versiossakaan ei ollut mitään vikaa.

Sehän oli koodattu C:llä, kehumallasi systeemiohjelmointikielellä.

Mutta niin vaan iskivät rikolliset turva-aukkoon !

Vetoat tietysti siihen, että "virhe on jo korjattu".

1. Jos OpenSSL olisi koodattu Objectpascalilla, tuollaista virhettä ei olisi alunperinkään ollut olemassa. Se, että se ei jonkun linuxjakelun kokoajalle olisi kelvannut, kun se olisi ollut "väärällä välineellä koodattu" - siis se olisi uudelleenkirjoitettu C:llä (ja saatu aikaiseksi juuri sama turva-aukko, joka siitä sitten 2014 keväällä löytyikin).

2. Entä, kun C:llä, suurella ja mahtavalla systeemiohjelmointikielellä koodatusta OpenSSL:stä löytyy seuraava turva-aukko, ja rikolliset iskevät sitten siihen? Sinun mielestäsi, M-Kar, C on varmaan senkin jälkeen oikein hyvä systeemiohjelmointikieli, ei siis haittaa yhtään, että C -kielellä saadaan aikaiseksi massiivisia tietoturva-aukkoja?

On suuri vahinko, että linuxjakelujen johtajina on henkilöitä, joiden ajatustenjuoksu on yhtä pahasti pielessä kuin M-Karilla. (edellyttäen, että M-Karin edellä esittämät johtopäätökset ovat oikeita, ovatko ne ???)

Siis C -kieltä on vaan pakko käyttää, vaikka on tunnettua, että C -kielen typerä rakenne suorastaa houkuttelee koodaajia tekemään sellaisia virheitä, että syntyy juurikin sellaisia
tietoturva-aukkoja, joihin rikollisten on helppoa iskeä.

Ja samaan aikaan Objectpascalilla koodattuja systeemikirjastoja (jollainen esim. olisi Objectpascalilla koodattu versio SSL -salauskirjastosta, ilman ensimmäistäkään tietoturva-aukkoa) eivät siis linuxjakelujen johtajat halua hyväksyä osaksi jakeluaan.

JOS M-Kar on oikeassa tuossa, että "ei olisi hyväksytty", niin silloinhan linuxjakelujen johtajat puuhaavat varsinaista hölmöläisten touhua.
Kommentoi
2
Ilmianna
Jaa
linuxjakelut_sucks kirjoitti:
"Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa."

Niin. Mielestäsi siis OpenSSL:n vuoden 2014 alussa olleessa versiossakaan ei ollut mitään vikaa.

Sehän oli koodattu C:llä, kehumallasi systeemiohjelmointikielellä.

Mutta niin vaan iskivät rikolliset turva-aukkoon !

Vetoat tietysti siihen, että "virhe on jo korjattu".

1. Jos OpenSSL olisi koodattu Objectpascalilla, tuollaista virhettä ei olisi alunperinkään ollut olemassa. Se, että se ei jonkun linuxjakelun kokoajalle olisi kelvannut, kun se olisi ollut "väärällä välineellä koodattu" - siis se olisi uudelleenkirjoitettu C:llä (ja saatu aikaiseksi juuri sama turva-aukko, joka siitä sitten 2014 keväällä löytyikin).

2. Entä, kun C:llä, suurella ja mahtavalla systeemiohjelmointikielellä koodatusta OpenSSL:stä löytyy seuraava turva-aukko, ja rikolliset iskevät sitten siihen? Sinun mielestäsi, M-Kar, C on varmaan senkin jälkeen oikein hyvä systeemiohjelmointikieli, ei siis haittaa yhtään, että C -kielellä saadaan aikaiseksi massiivisia tietoturva-aukkoja?

On suuri vahinko, että linuxjakelujen johtajina on henkilöitä, joiden ajatustenjuoksu on yhtä pahasti pielessä kuin M-Karilla. (edellyttäen, että M-Karin edellä esittämät johtopäätökset ovat oikeita, ovatko ne ???)

Siis C -kieltä on vaan pakko käyttää, vaikka on tunnettua, että C -kielen typerä rakenne suorastaa houkuttelee koodaajia tekemään sellaisia virheitä, että syntyy juurikin sellaisia
tietoturva-aukkoja, joihin rikollisten on helppoa iskeä.

Ja samaan aikaan Objectpascalilla koodattuja systeemikirjastoja (jollainen esim. olisi Objectpascalilla koodattu versio SSL -salauskirjastosta, ilman ensimmäistäkään tietoturva-aukkoa) eivät siis linuxjakelujen johtajat halua hyväksyä osaksi jakeluaan.

JOS M-Kar on oikeassa tuossa, että "ei olisi hyväksytty", niin silloinhan linuxjakelujen johtajat puuhaavat varsinaista hölmöläisten touhua.
Toisaalta: jos M-Kar on tässä oikeassa, tämä herättää uuden kysymyksen...

Jos onnistun etsimään ja löytämään OpenSSL:stä uuden, julkisesti tuntemattoman tietoturva-aukon, mistä löydän eniten rahaa tarjoavan rikollisen, jolle myydä tiedot ko. tietoturva-aukosta ?

Ainahan voisi koodata Objectpascalilla korvaajan OpenSSL:lle, ja myydä sitä.

Kun sen koodaa alusta alkaen itse käyttämättä GPL -lisensioitua kirjastoa, silloinhan sen käyttölisenssejä voi myydä ja omistaa tekijänoikeudet edelleen itse.

Kertoisi vaan julkisesti, että jos tietoturvasi on sinulle oikeasti tärkeä, niin osta lisenssi ja asenna korvaaja linuxjakelun alkuperäisen OpenSSL:n korvaajaksi.

Jokainen voi itse valita, ostaako lisenssin vai jatkaako turvaallisuudeltaan heikon OpenSSL:n käyttöä.

Veikkaanpa, että jos jaksaisi tosissaan etsiä, niin OpenSSL:stä löytyy vielä monta tähän mennessä (ainakin suurelle yleisölle) tuntematonta tietoturva-aukkoa lisää.

Tosin, ainakin osa näistä tietoturva-aukoista voivat olla jo esim NSA:n tiedossa.

Eiköhän tuollainen valtiollisen tason toimija, jolla on jättibudjetti, voi palkata hyvät osaajat etsimään tietoturva-aukkoja, joita NSA voi sitten hyödyntää omiin tarkoituksiinsa.
Eiväthän he löytämiään aukkoja julkisesti kerro.
Veikkaanpa muuten, että NSA on tiennyt siitä samasta tietoturva-aukosta, joka OpenSSL:n osalta tuli julkisuuteen keväällä 2014, jo paljon aikaisemmin.

He vain ovat salaa hyödyntäneet ko. aukkoa omiin tarkoituksiinsa, ja siksi tieto ei ole sitä kautta levinnyt.

Miksiköhän muuten linuxjakelujen tekijät eivät halua laadukasta, Objectpascalilla koodattua ohjelmakoodia heikkolaatuisen ja turvattoman C:llä tehdyn koodin sijasta ? (edellyttäen, että M-Karin asiaa koskeva väite pitää paikkansa)

Muuttuisiko tilanne, jos joku etsisi useita turva-aukkoja linuxjakeluista ja myisi tiedot kustakin aukosta eniten tarjoavalle rikolliselle ?

Itse olen vakuuttunut siitä, että useimmista, ellei peräti kaikista sellaisista ohjelmista ja ohjelmakirjastoista, jotka on koodattu joko C:llä, C++:lla, tai näiden yhdistelmällä, löytyy tietoturva-aukkoja, kustakin yksi tai useampi.

Mutta jatkakaa vaan linux- ja GPL -lisenssifanaatikot sitä C:llä koodailua M-Karin ja tietoverkkomurtoja tekevien iloksi.
Kommentoi
2
Ilmianna
Jaa
linuxjakelut_sucks kirjoitti:
"Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa."

Niin. Mielestäsi siis OpenSSL:n vuoden 2014 alussa olleessa versiossakaan ei ollut mitään vikaa.

Sehän oli koodattu C:llä, kehumallasi systeemiohjelmointikielellä.

Mutta niin vaan iskivät rikolliset turva-aukkoon !

Vetoat tietysti siihen, että "virhe on jo korjattu".

1. Jos OpenSSL olisi koodattu Objectpascalilla, tuollaista virhettä ei olisi alunperinkään ollut olemassa. Se, että se ei jonkun linuxjakelun kokoajalle olisi kelvannut, kun se olisi ollut "väärällä välineellä koodattu" - siis se olisi uudelleenkirjoitettu C:llä (ja saatu aikaiseksi juuri sama turva-aukko, joka siitä sitten 2014 keväällä löytyikin).

2. Entä, kun C:llä, suurella ja mahtavalla systeemiohjelmointikielellä koodatusta OpenSSL:stä löytyy seuraava turva-aukko, ja rikolliset iskevät sitten siihen? Sinun mielestäsi, M-Kar, C on varmaan senkin jälkeen oikein hyvä systeemiohjelmointikieli, ei siis haittaa yhtään, että C -kielellä saadaan aikaiseksi massiivisia tietoturva-aukkoja?

On suuri vahinko, että linuxjakelujen johtajina on henkilöitä, joiden ajatustenjuoksu on yhtä pahasti pielessä kuin M-Karilla. (edellyttäen, että M-Karin edellä esittämät johtopäätökset ovat oikeita, ovatko ne ???)

Siis C -kieltä on vaan pakko käyttää, vaikka on tunnettua, että C -kielen typerä rakenne suorastaa houkuttelee koodaajia tekemään sellaisia virheitä, että syntyy juurikin sellaisia
tietoturva-aukkoja, joihin rikollisten on helppoa iskeä.

Ja samaan aikaan Objectpascalilla koodattuja systeemikirjastoja (jollainen esim. olisi Objectpascalilla koodattu versio SSL -salauskirjastosta, ilman ensimmäistäkään tietoturva-aukkoa) eivät siis linuxjakelujen johtajat halua hyväksyä osaksi jakeluaan.

JOS M-Kar on oikeassa tuossa, että "ei olisi hyväksytty", niin silloinhan linuxjakelujen johtajat puuhaavat varsinaista hölmöläisten touhua.
"1. Jos OpenSSL olisi koodattu Objectpascalilla, tuollaista virhettä ei olisi alunperinkään ollut olemassa. Se, että se ei jonkun linuxjakelun kokoajalle olisi kelvannut, kun se olisi ollut "väärällä välineellä koodattu" - siis se olisi uudelleenkirjoitettu C:llä (ja saatu aikaiseksi juuri sama turva-aukko, joka siitä sitten 2014 keväällä löytyikin)."

Kyllä se tarve on enemmän ollut BSD järjestelmissä, että ei oteta GPL koodia mukaan tai sitten suljetuissa järjestelmissä jotka hyödyntävät juurikin BSD koodia.

"2. Entä, kun C:llä, suurella ja mahtavalla systeemiohjelmointikielellä koodatusta OpenSSL:stä löytyy seuraava turva-aukko, ja rikolliset iskevät sitten siihen?"

Tuollaiset virheet löytyvät tavallisesti koodista joissa ei ole laatuprosesseja ollut olemassa kun tekeminen on aloitettu. Niiden käyttäminen jälkikäteen on hankalampaa.

"Sinun mielestäsi, M-Kar, C on varmaan senkin jälkeen oikein hyvä systeemiohjelmointikieli, ei siis haittaa yhtään, että C -kielellä saadaan aikaiseksi massiivisia tietoturva-aukkoja?"

Kyllä työkaluja voi käyttää väärin. Mutta onhan juurikin C-kiellä mahdollista tehdä ne huipputurvalliset sovellukset

"On suuri vahinko, että linuxjakelujen johtajina on henkilöitä, joiden ajatustenjuoksu on yhtä pahasti pielessä kuin M-Karilla. (edellyttäen, että M-Karin edellä esittämät johtopäätökset ovat oikeita, ovatko ne ???)"

Miten tämä nyt liittyy Linuxiin?

"Siis C -kieltä on vaan pakko käyttää, vaikka on tunnettua, että C -kielen typerä rakenne suorastaa houkuttelee koodaajia tekemään sellaisia virheitä, että syntyy juurikin sellaisia tietoturva-aukkoja, joihin rikollisten on helppoa iskeä."

Saat vapaasti kirjoittaa uuden kernelin ja systeemitason sovellukset uudella sertifioidulla työkalulla, aloittaa siis kaikki ihan alusta, kääntäjä mukaanlukien ja kääntäjät perusteellisesti testit.

Tällä hetkellä kiinnostukset ja resurssit tuollaiseen taitaa olla vain Googlella.

"JOS M-Kar on oikeassa tuossa, että "ei olisi hyväksytty", niin silloinhan linuxjakelujen johtajat puuhaavat varsinaista hölmöläisten touhua."

Ei tämä liity millään tavalla Linuxiin. Ei se minun vikani ole, että FreePascal on standardoimaton, sertifioimaton ja lisäksi vielä GPL koodia. Kyllä sitä käytetään sellaisia komponentteja mitkä on lisenssiyhteensopivia, harmonisia muun koodin kanssa ja jossa ei tule mitään typerää rajoitetta pitkällä aikavälillä.
Kommentoi
Ilmianna
Jaa
Linux_Hölmölä_alas kirjoitti:
Toisaalta: jos M-Kar on tässä oikeassa, tämä herättää uuden kysymyksen...

Jos onnistun etsimään ja löytämään OpenSSL:stä uuden, julkisesti tuntemattoman tietoturva-aukon, mistä löydän eniten rahaa tarjoavan rikollisen, jolle myydä tiedot ko. tietoturva-aukosta ?

Ainahan voisi koodata Objectpascalilla korvaajan OpenSSL:lle, ja myydä sitä.

Kun sen koodaa alusta alkaen itse käyttämättä GPL -lisensioitua kirjastoa, silloinhan sen käyttölisenssejä voi myydä ja omistaa tekijänoikeudet edelleen itse.

Kertoisi vaan julkisesti, että jos tietoturvasi on sinulle oikeasti tärkeä, niin osta lisenssi ja asenna korvaaja linuxjakelun alkuperäisen OpenSSL:n korvaajaksi.

Jokainen voi itse valita, ostaako lisenssin vai jatkaako turvaallisuudeltaan heikon OpenSSL:n käyttöä.

Veikkaanpa, että jos jaksaisi tosissaan etsiä, niin OpenSSL:stä löytyy vielä monta tähän mennessä (ainakin suurelle yleisölle) tuntematonta tietoturva-aukkoa lisää.

Tosin, ainakin osa näistä tietoturva-aukoista voivat olla jo esim NSA:n tiedossa.

Eiköhän tuollainen valtiollisen tason toimija, jolla on jättibudjetti, voi palkata hyvät osaajat etsimään tietoturva-aukkoja, joita NSA voi sitten hyödyntää omiin tarkoituksiinsa.
Eiväthän he löytämiään aukkoja julkisesti kerro.
Veikkaanpa muuten, että NSA on tiennyt siitä samasta tietoturva-aukosta, joka OpenSSL:n osalta tuli julkisuuteen keväällä 2014, jo paljon aikaisemmin.

He vain ovat salaa hyödyntäneet ko. aukkoa omiin tarkoituksiinsa, ja siksi tieto ei ole sitä kautta levinnyt.

Miksiköhän muuten linuxjakelujen tekijät eivät halua laadukasta, Objectpascalilla koodattua ohjelmakoodia heikkolaatuisen ja turvattoman C:llä tehdyn koodin sijasta ? (edellyttäen, että M-Karin asiaa koskeva väite pitää paikkansa)

Muuttuisiko tilanne, jos joku etsisi useita turva-aukkoja linuxjakeluista ja myisi tiedot kustakin aukosta eniten tarjoavalle rikolliselle ?

Itse olen vakuuttunut siitä, että useimmista, ellei peräti kaikista sellaisista ohjelmista ja ohjelmakirjastoista, jotka on koodattu joko C:llä, C++:lla, tai näiden yhdistelmällä, löytyy tietoturva-aukkoja, kustakin yksi tai useampi.

Mutta jatkakaa vaan linux- ja GPL -lisenssifanaatikot sitä C:llä koodailua M-Karin ja tietoverkkomurtoja tekevien iloksi.
"Jos onnistun etsimään ja löytämään OpenSSL:stä uuden, julkisesti tuntemattoman tietoturva-aukon, mistä löydän eniten rahaa tarjoavan rikollisen, jolle myydä tiedot ko. tietoturva-aukosta ?"

Miksi se rikolliselle pitäisi myydä kun varmaan löytyy muutama firma mikä maksaisi siitä.

"Ainahan voisi koodata Objectpascalilla korvaajan OpenSSL:lle, ja myydä sitä."

Ei kukaan ostaisi.

"Kun sen koodaa alusta alkaen itse käyttämättä GPL -lisensioitua kirjastoa, silloinhan sen käyttölisenssejä voi myydä ja omistaa tekijänoikeudet edelleen itse."

FreePascal kääntäjä on GPL lisensoitu. Tuo tarvisi FreePascalin lisäämistä käyttöjärjestelmän buildaukseen itsessään ja toisi GPL koodia sinne saastuttamaan.

Sinun tarvitsisi ensiksi tehdä uusi BSD lisensoitu kääntäjä ja saman tien kirjoittaa uusiksi kaikki userlandin palikat uusiksi BSD lisenssillä.

Mutta sitten herää mieleen että miksi? Miksi ei samantien tekisi tätä Go compilerilla joka on jo BSD lisensoitu?

"Veikkaanpa, että jos jaksaisi tosissaan etsiä, niin OpenSSL:stä löytyy vielä monta tähän mennessä (ainakin suurelle yleisölle) tuntematonta tietoturva-aukkoa lisää."

Niinhän niitä löytyi ja korjattiin myös. Siitä myös sitten tehtiin semmoinen turvallinen palikka myös: https://www.libressl.org/

Tosin, ainakin osa näistä tietoturva-aukoista voivat olla jo esim NSA:n tiedossa.

"Miksiköhän muuten linuxjakelujen tekijät eivät halua laadukasta, Objectpascalilla koodattua ohjelmakoodia heikkolaatuisen ja turvattoman C:llä tehdyn koodin sijasta ?"

Tuohan riippuu käyttöjärjestelmästä. Eri käyttöjärjestelmävalmistat vakioi eri tekniikkaan. Microsoft menee C#:n ja siellä sitten C++ on legacyä ja C on matalalla tasolla, Apple menee Swiftiin, ObjectiveC on legacyä ja C:tä matalalla tasolla. Red Hatissa C matalalla tasolla mutta rakentavat kaiken middlewaren Javalla. Oracle tekee samoin. Ubuntussa matalataso on C:tä ja muuten tätä tunnutaan käyttävän monilla kielillä. Debianissa sama juttu .

OpenBSD:ssä sitten päättivät siivota kaiken muun paitsi C:n ja sh skriptit pois.

Debianissa ja Ubuntussa vähän avoimempaa se vastaanotto erilaisille softapinoille ja hyväksyvät helpommin eri välineillä tehtyä koodia.

Semmoista ObjectPascal koodia on kovin vähän vain. Kukaan ei tee semmoista eikä ketään oikein kiinnosta. Parempiakin työkaluja on.

Voisin kuvitella että jos uudelleenkirjoitat matalan tason kompontit vaikka Go langilla siistimmin mitä nykyiset, 70-luvulta saakka kehityt palikat on ja saisit määriteltyä ABI yhteensopivuuden niin voisi jotain kiinnostaa.

Se tuskin kiinnostaa jos tuot vain ylimääräistä tekniikkaa sinne etkä esim. poista samalla C-kääntäjää userlandin käännöstä. Tuohan olisi kätevää kun kerneli käännettäisiin C:llä ja userland olisi sitten uusittu C:stä vapaaksi niin se voisi olla parannus, ehkä.

"Itse olen vakuuttunut siitä, että useimmista, ellei peräti kaikista sellaisista ohjelmista ja ohjelmakirjastoista, jotka on koodattu joko C:llä, C++:lla, tai näiden yhdistelmällä, löytyy tietoturva-aukkoja, kustakin yksi tai useampi."

Varmasti näin olikin 90-luvulla. Nythän nuo keskeiset komponentit ovat aika huolella nuoltu bugeista, että harvemmin löytyy. Esim. zlibistä löytyi edellisen kerran 12v sitten.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Kehitystyökaluja tarvitaan vielä ainakin toistaiseksi ilmeisesti vähintäänkin haittaohjelmien tuottamiseen.
2
Ilmianna
Jaa
udo apt-get install build-essential on ihan hyvä jos haluaa kääntää jonkin ohjelman lähdekoodista. Lisäksi täytyy asentaa tarvittavat kirjastot. C-kielestä ei tarvitse ymmärtää mitään. Jos osaa lukea README-tiedoston sisällön voi kokeilla vaikka kernelin kääntämistä. kernelillä on vähän riippuvuuksia - ncurses tarvitaan lisäksi. Lisäksi kun on git ja wget tai curl saa sitä koodia helposti ladattua netistä.

Isommassa kioskissa esim. Hesessä taitaa kaikki olla koneella. Ostin sieltä tänään kahvia ja termari täytetään kun huikkaa myyjälle, että se on loppu. Pullaa ei saa koska myydään vain suolaista ja rasvaista ruokaa.
Kommentoi
2
Ilmianna
Jaa
1 VASTAUS:
sudo apt-get install .... piti olla äh kun ei voi muokata jälkikäteen
Kommentoi
2
Ilmianna
Jaa
+Lisää kommentti

Vastaa alkuperäiseen viestiin

Asenna kehitystyökalut kerralla

Kehitystyökalut voidaan asentaa joko yksitellen tai kaikki kerralla, kuten tässä neuvotaan. Näin tehtynä se on paljon helpompaa.

sudo apt-get install build-essential

Tuon tuloksena asentuu seuraavat kehitystyökalut:

binutils
cpp
gcc-5-locales
g++-multilib
g++-5-multilib
gcc-5-doc
gcc-multilib
autoconf
automake
libtool
flex
bison
gdb
gcc-doc
gcc-5-multilib

Nyt ei GitHubilta ladatut käännettävätkään ole enään ongelma.

Linux Mint 18.1 Serena
Xfce 64-bit

5000 merkkiä jäljellä

Peruuta