Digitalisaatio - hyvät ja huonot puolet

[JCSH]

Koska 99,9% käyttäjistä ei halua tai osaa käyttää mitään telnetiä saati koodata omaa käyttöliittymäänsä robotti-imuriinsa jos ei halua antaa sille ohjeita komentoriviltä kun olemassaoleva älylaite riittää.

Miksi yksikään kaupallinen toimija käyttäisi tällaisen marginaaliryhmän paapomiseen arvokasta tuotekehitysaikaa?

Tosin kyllähän nuo valmistajat aika usein lisäävät niitä rajapintoja, joiden kautta laitteita voi kontrolloida ilman sitä valmistajan omaa softaa. Esim. Philips Hue:ssa on oma rajapintansa, jonka kautta voi tehdä oman kontrollisoftan.
Toki noiden tavoitteena on enemmänkin mahdollistaa muut kaupalliset toteutukset, ei niinkään että joku kotikoodari tekee itse.

*edit*
Niin ja kyse ei ole mistään kivikautisista telnet-yhteydestä, vaan muistaakseni https REST API.

 

[Drinkkeri]

Tosin kyllähän nuo valmistajat aika usein lisäävät niitä rajapintoja, joiden kautta laitteita voi kontrolloida ilman sitä valmistajan omaa softaa. Esim. Philips Hue:ssa on oma rajapintansa, jonka kautta voi tehdä oman kontrollisoftan.
Toki noiden tavoitteena on enemmänkin mahdollistaa muut kaupalliset toteutukset, ei niinkään että joku kotikoodari tekee itse.

*edit*
Niin ja kyse ei ole mistään kivikautisista telnet-yhteydestä, vaan muistaakseni https REST API.

Mitään tällaista järkevää ratkaisua tuskin haettiin

 

[Francis Ford Mondeo]

Tosin kyllähän nuo valmistajat aika usein lisäävät niitä rajapintoja, joiden kautta laitteita voi kontrolloida ilman sitä valmistajan omaa softaa. Esim. Philips Hue:ssa on oma rajapintansa, jonka kautta voi tehdä oman kontrollisoftan.
Toki noiden tavoitteena on enemmänkin mahdollistaa muut kaupalliset toteutukset, ei niinkään että joku kotikoodari tekee itse.

*edit*
Niin ja kyse ei ole mistään kivikautisista telnet-yhteydestä, vaan muistaakseni https REST API.

Jeps, esimerkiksi Bosch tarjoaa Home Connect API:n kautta mahdollisuuden ohjata jos jonkinlaisia laitteita REST-kutsuilla: Developer Portal

 

[Kopsa]

Nyt on ruvennut spotify harmittamaan kovasti. Aina kun otan BL napit kotelosta ja laitan korviin, niin Spotify soi. Samoin kun yhdistyy autoon niin spotify soi. Olen googlettanut ongelmaa. Spotifyn asetuksista kaikki autoplayhin viittaava offilla, tausta ajo kielletty yms. Ja Spotify soi ja soi!!

 

[Paapaa]

Nyt on ruvennut spotify harmittamaan kovasti. Aina kun otan BL napit kotelosta ja laitan korviin, niin Spotify soi. Samoin kun yhdistyy autoon niin spotify soi. Olen googlettanut ongelmaa. Spotifyn asetuksista kaikki autoplayhin viittaava offilla, tausta ajo kielletty yms. Ja Spotify soi ja soi!!

Laittakaas noi Spotify-huolenne oikeaan ketjuun:

Spotify - Nyt ja tulevaisuudessa

Jeps. Elikkä ketju Spotifylle. Missä mennään, mikä mättää, mitä hyvää? Itselläni jostain syystä kieltäytyy Spotify soittamasta mitään kappaletta. "Tämä kappale ei ole saatavana". Olen rebootannut Spotifyn ja koneen, mutta ei vaikutusta. Onko yleinenkin ongelma tällähetkellä?

bbs.io-tech.fi

Täällä puhutaan yleisesti digitalisaatiosta, ei Spotifyn tai auton audiosoftan bugeista.

 

[Trespasser]

Mitä "älytoimintoja" teillä on, ja missä kodinkoneissa? Minulla ei tule mieleen yhtään omaa kodinkonetta, joissa olisi joku sovelluksella toimiva älytoiminto. Eikä kyllä taida olla tulossakaan.

Itellä kodinkoneista pesukone ja kuivausrumpu joiden älytoimintoja käytän. Pääasiassa jonkun spesiaalin lyhytohjelman käynnistys sovelluksesta mitä ei suoraan koneen napeissa ole ja tärkeimpänä ilmoitukset kelloon/puhelimeen, kun ohjelma on valmis. Ilman ilmoituksia unohtaisin pyykit koneeseen vähintään joka toinen pesukerta. Sit tietty valot, auton lämmitys ja muut pienemmät jutut.

 

[Sompi]

Koska 99,9% käyttäjistä ei halua tai osaa käyttää mitään telnetiä saati koodata omaa käyttöliittymäänsä robotti-imuriinsa jos ei halua antaa sille ohjeita komentoriviltä kun olemassaoleva älylaite riittää.

Miksi yksikään kaupallinen toimija käyttäisi tällaisen marginaaliryhmän paapomiseen arvokasta tuotekehitysaikaa?

Mikään ei estä sitä valmistajaa myös perustamasta tekemästä omaa käyttöliittymänsä, joka käyttäisi sitä matalamman tason telnet-protokollaa. Sen itse protokollan voisi sitten kuitenkin dokumentoida ja antaa muidenkin tehdä siihen omia käyttöliittymiä ja ohjelmia.

Niin ja kyse ei ole mistään kivikautisista telnet-yhteydestä, vaan muistaakseni https REST API.

Osaisitko määritellä, mikä on REST API?

Mikä mielestäsi tekee telnet-yhteydestä "kivikautisen"?

 

[Paapaa]

Osaisitko määritellä, mikä on REST API?

Osaisitko googlettaa? Olen varma, että kaveri, joka kirjoittelee omat TCP/IP-pinot, osaa myös googlettaa jos niinkin yleiset termit kuin REST(ful) tai API eivät ole tuttuja.

 

[Sompi]

Osaisitko googlettaa? Olen varma, että kaveri, joka kirjoittelee omat TCP/IP-pinot, osaa myös googlettaa jos niinkin yleiset termit kuin REST(ful) tai API eivät ole tuttuja.

Kyllä minä tiedän mikä on REST API.

Meinaan vain sitä, että tuossa on ristiriita, jos mikään telnet-protokolla ei kelpaa koska "telnet on kivikautinen", mutta kuitenkin sitten halutaan REST API.

 

[Vaateri]

Mikään ei estä sitä valmistajaa myös perustamasta tekemästä omaa käyttöliittymänsä, joka käyttäisi sitä matalamman tason telnet-protokollaa.

Mikään ei estä mutta mikään ei myöskään kannusta.

Voisitko kuvailla kuinka hyödyntäisit jonkin vapaavalintaisen kodinkoneen telnet-yhteyttä omassa käytössäsi?

 

[Drinkkeri]

Mikään ei estä sitä valmistajaa myös perustamasta tekemästä omaa käyttöliittymänsä, joka käyttäisi sitä matalamman tason telnet-protokollaa. Sen itse protokollan voisi sitten kuitenkin dokumentoida ja antaa muidenkin tehdä siihen omia käyttöliittymiä ja ohjelmia.


Osaisitko määritellä, mikä on REST API?

Mikä mielestäsi tekee telnet-yhteydestä "kivikautisen"?

Telnet ei tietoturvan kannalta ole nykyaikaa edes purkkapatenttina päälleliimatulla salauslisälleellä eikä sitä pitäisi käyttää missään internetiin kytketyssä laitteessa. Tästä syystä laitevalmistajat käyttävät modernimpia API:ja

 

[Paapaa]

Meinaan vain sitä, että tuossa on ristiriita, jos mikään telnet-protokolla ei kelpaa koska "telnet on kivikautinen", mutta kuitenkin sitten halutaan REST API.

Telnet on paljon vanhempi protokolla kuin HTTP tai HTTPS. Jos nykyään haluaa luoda avoimen API:n jota voi käyttää internetin yli, niin saa olla melkoinen aivovamma, että valitsee Telnetin tuohon tarkoitukseen. En tiedä, miksi tuosta edes keskustellaan. Miksei sitten vaikka kirjekyyhkyistä.

 

[Sompi]

Telnet on paljon vanhempi protokolla kuin HTTP tai HTTPS. Jos nykyään haluaa luoda avoimen API:n jota voi käyttää internetin yli, niin saa olla melkoinen aivovamma, että valitsee Telnetin tuohon tarkoitukseen. En tiedä, miksi tuosta edes keskustellaan. Miksei sitten vaikka kirjekyyhkyistä.

HTTP on telnet-protokolla.

Joku REST API on kuitenkin järjettömän monimutkainen, raskas ja tehoton tuollaiseen tarkoitukseen. Jos ajatellaan vaikka jotain valojen etäohjausta, niin REST APIlla tehtynä se protokolla voisi näyttää esimerkiksi tältä:

GET /valot/1/action?switch=on HTTP/1.1
Host: valo.iot.paska
Connection: keep-alive

(huomaa tässä kaksi rivinvaihtoa!)

Ja ilman tuota keep-alivea joka ikistä pyyntöä varten pitäisi vieläpä tehdä uusi yhteys.
Jokaisessa palvelimen antamassa vastauksessakin pitäisi sitten olla omat headerinsa varsinaisen vastauksen lisäksi.

Kun taas vapaalla telnetillä vastaava pyyntö voisi olla vaikkapa seuraavanlainen:

ACTION LIGHT1 SWITCH ON

Ja mitään HTTP:n keepalive-hömppääkään ei tarvittaisi, jotta yhteys pysyy päällä. Palvelin voisi vastata simppelisti yhdellä rivillä.

Niin en kyllä edelleenkään ymmärrä, mitä pahaa siinä telnetissä on.

 

[Francis Ford Mondeo]

Aloittaja on näköjään kategorisesti lukkiutunut teknologioihin, mitkä olivat valideja viimeksi vuosituhannen vaihteessa. Syitä en jaksa lähteä edes arvailemaan.

En ymmärrä miksi jostain REST-kutsujen tekemisestä pitää tehdä ongelma, kun melkeimpä millä tahansa nykyaikaisella frameworkilla kielestä riippumatta homma on sujuvaa ja simppeliä. Tosin tästäkin varmaan saadaan ongelma, kun ei onnistu jollain kuopasta kaivetulla legacy-natiivikoodilla.

 

[PCB]

Itellä kodinkoneista pesukone ja kuivausrumpu joiden älytoimintoja käytän. Pääasiassa jonkun spesiaalin lyhytohjelman käynnistys sovelluksesta mitä ei suoraan koneen napeissa ole ja tärkeimpänä ilmoitukset kelloon/puhelimeen, kun ohjelma on valmis. Ilman ilmoituksia unohtaisin pyykit koneeseen vähintään joka toinen pesukerta. Sit tietty valot, auton lämmitys ja muut pienemmät jutut.

Eli onko se lyhytohjelma kuitenkin siellä pesukoneessa, mutta haluat käynnistää sen sovelluksella, koska pesukoneessa joutuisit seikkailemaan valikossa? Jos noin, niin minusta kyllä hyvä esimerkki siitä, miten joku toiminto paskotaan pilalle.

Tuo lopetusilmoitus kännykkään/kelloon taas ihan hyvä ominaisuus. Itse laitan aina puhumalla ajastimen Applen kelloon ja menee 3-4 sekuntia, mutta tuossa säästyy sekin vaiva. Miinuspuolena sitten se, että pesukone on verkossa.

 

[hkultala]

Niin en kyllä edelleenkään ymmärrä, mitä pahaa siinä telnetissä on.

Se, että telnet-protokollalla salasanat kulkevat verkon yli salaamattomina, jolloin ne on helppo salakuunnella.

Tätä ei pitäisi olla vaikeaa ymmärtää.

 

[Sompi]

Se, että telnet-protokollalla salasanat kulkevat verkon yli salaamattomina, jolloin ne on helppo salakuunnella.

Tätä ei pitäisi olla vaikeaa ymmärtää.

Miten se sitten eroaa REST APIsta?

 

[Tonnin Seteli]

Eli onko se lyhytohjelma kuitenkin siellä pesukoneessa, mutta haluat käynnistää sen sovelluksella, koska pesukoneessa joutuisit seikkailemaan valikossa? Jos noin, niin minusta kyllä hyvä esimerkki siitä, miten joku toiminto paskotaan pilalle.

En pidä tätäkään(tarkemman tilannekuvan puuttuessa) välttämättä pahana vaikka olisi toki ihanteellista että voisi kerran tallentaa konfiguraatiomuutokset sovelluksella ja sen jälkeen käynnistää omaan käyttöönsä sopivat ohjelmat pesukoneen paneelista.

ikävä ja normaalisti vallitseva tilanne pesukoneissa on, että tarjolla on turha, huono, paska, paskempi ja paskin pesuohjelma plus pari jotenkuten toimivaa. Siinä sitten valitaan kurkkukivun, ilmavaivojen ja lihassäryn väliltä(en nyt kehtaa ruttoon ja koleraan tällaista pikkuriesaa verrata) miellyttävintä vaihtoehtoa. Tällöin rikkinäinenkin sovellusohjaus on parannus lähtötilanteeseen.

 

[hkultala]

Miten se sitten eroaa REST APIsta?

Siten että RESTiä voi ajaa (ja yleensä ajetaan) HTTPS-yhteyden yli, jolloin ne salasanat eivät kulje salaamattomana, eikä niitä ole helppo salakuunnella.

 

[Sompi]

Siten että RESTiä voi ajaa (ja yleensä ajetaan) HTTPS-yhteyden yli, jolloin ne salasanat eivät kulje salaamattomana, eikä niitä ole helppo salakuunnella.

Miten se sitten eroaa salatusta telnetistä, kun se HTTP on edelleenkin vain yksi telnet-protokolla muiden joukossa?

Jotain kodin sähkölaitteiden etäohjausta kuitenkin todennäköisesti käytetään lähiverkossa, joten sen olisi hyvä olla mahdollista myös salaamattomana. TLS-protokollan implementointi lisää jo oman asiakasohjelman kehitykseen vaadittavaa työmäärää melkoisesti.

 

[PCB]

ikävä ja normaalisti vallitseva tilanne pesukoneissa on, että tarjolla on turha, huono, paska, paskempi ja paskin pesuohjelma plus pari jotenkuten toimivaa. Siinä sitten valitaan kurkkukivun, ilmavaivojen ja lihassäryn väliltä(en nyt kehtaa ruttoon ja koleraan tällaista pikkuriesaa verrata) miellyttävintä vaihtoehtoa. Tällöin rikkinäinenkin sovellusohjaus on parannus lähtötilanteeseen.

Menee vähän ohi aiheenkin, mutta meillä pesukoneessa on 20 ohjelmaa, jotka valitaan suoraan kiekkoa pyörittämällä. Lisäksi ohjelmia voi varioida lisäparametreillä lyhyt, esipesu, ja liotus. Lisäksi linkousvaihtoehtoja 6 kpl ja vielä pari muuta parametriä. Noista tulee niin iso määrä vaihtoehtoja, että itse en millään osaa keksiä mitään mitä voisin tarvita. Toki erilaisissa koneissa erilainen määrä ohjelmia ja pesijöillä tarpeita. Koko säätö toimii pyöritettävän valintakiekon ja 2 napin voimalla, lisäksi starttinappi, luukku ja virtanappi. Omasta mielestäni täydellinen, siis aivan täydellinen käyttöliittymä.

 

[JCSH]

Miten se sitten eroaa salatusta telnetistä, kun se HTTP on edelleenkin vain yksi telnet-protokolla muiden joukossa?

Jotain kodin sähkölaitteiden etäohjausta kuitenkin todennäköisesti käytetään lähiverkossa, joten sen olisi hyvä olla mahdollista myös salaamattomana. TLS-protokollan implementointi lisää jo oman asiakasohjelman kehitykseen vaadittavaa työmäärää melkoisesti.

Juuh okei, tottakai se devaaja lähtee toteuttamaan omaa TLS-protokollaa, sen sijaan että vain käyttäisi valmiita toteutuksia jotka löytyy tyyliin jokaiselle tarvittavalle plattikselle.

Tässä nyt mennään sun osalta taas niin ankarasti parodiahorisontin yli, että et sä voi olla tosissasi.

 

[Vaateri]

HTTP on edelleenkin vain yksi telnet-protokolla muiden joukossa?

Tykkäät selkeästi käyttää näitä hämmennyksiä, joten kysytään nyt, että mitä tarkalleen ottaen tarkoitat tällä?

 

[Xanthe_]

Koettakaas välillä TCP protokollaa tämän UDP protokollan jälkeen kun teillä ny nuo viestit mee perille.

 

[Trespasser]

Eli onko se lyhytohjelma kuitenkin siellä pesukoneessa, mutta haluat käynnistää sen sovelluksella, koska pesukoneessa joutuisit seikkailemaan valikossa? Jos noin, niin minusta kyllä hyvä esimerkki siitä, miten joku toiminto paskotaan pilalle.

Tuo lopetusilmoitus kännykkään/kelloon taas ihan hyvä ominaisuus. Itse laitan aina puhumalla ajastimen Applen kelloon ja menee 3-4 sekuntia, mutta tuossa säästyy sekin vaiva. Miinuspuolena sitten se, että pesukone on verkossa.

Ohjelma ei ole pesukoneessa, vaan koneessa on toiminto missä voi ladata puhelimelta ihan kiitettävän määrän erikoisohjelmia mitkä ei vaan tollaseen perus helppokäyttöiseen "ohjelmarullaan" mahdu. Normaalisti käytetyt ohjelmat säätöineen löytyy suoraan ja helposti, eli sovellusta ei ole pakko käyttää. Yks esimerkki erityisen nopean pesun lisäks mitä käytän sovelluksella on rummun pikapuhdistus. Fyysisessä valitsimessa on rummun puhdistus normaalina eli pitkäkestoisena, mut ei sitä aina huvita odotella pitkiä aikoja.

Mä olin todella skeptinen alkuun näiden suhteen, koska olin etenkin pesukoneissa vankalla "vähemmän nappeja ja digiä = parempi" linjalla. Yllätyin kuitenkin siitä, miten paljon noita digijuttuja päädyin käyttämään lopulta.

Edit: Ja tosiaan, tulee myös otettua kaikki ekohippeily pois. Reilu huuhtelu riittävän lämpimässä ja kunnon pyörittely niin lähtee jarruraidat kalsareista. Nää tosin saa napeistakin painelemalla pois.

 

[Francis Ford Mondeo]

Miten se sitten eroaa salatusta telnetistä, kun se HTTP on edelleenkin vain yksi telnet-protokolla muiden joukossa?

Jotain kodin sähkölaitteiden etäohjausta kuitenkin todennäköisesti käytetään lähiverkossa, joten sen olisi hyvä olla mahdollista myös salaamattomana. TLS-protokollan implementointi lisää jo oman asiakasohjelman kehitykseen vaadittavaa työmäärää melkoisesti.

Sisäverkko nyt ei ole enää ollut mikään argumentti sen suhteen, että yhteyden salauksen voisi skipata - kun puhutaan kaupallisista toteutuksista. TLS-protokollankin pyörittelyyn löytyy lukuisista eri ohjelmointikehyksistä valmiit palikat. Toisaalta jos kategorisesti haluat välttää näitä niin väännä sitten pitkästä tavarasta, mutta turha itkeä ylämäessä.

Tässä parinkymmenen vuoden sovelluskehitysuran aikana on tullut useammankin kerran nähtyä näitä jääräpäisiä velhoja, jotka vastarannankiiskeyttään vastustavat kategorisesti kaikkea oman pienen periaatekuplan ulkopuolelta. Jokainen vääntäkööt siellä kierrätysraudalla pyörivässä Linux-sisäverkossaan juuri sellaiset ratkaisut kun haluaa. Mutta on älyllisesti epärehellistä lähteä tyrkyttämään näitä tuhanteen kertaan murrettuja ja deprekoituja teknologisia ratkaisuja muille - saati kaupalliseen toteutukseen. Ei kukaan vakavasti otettava taho ala kaupallistamaan ja tuotteistamaan, saati ylläpitämään vuosikymmeniä vanhoja teknologiaratkaisuja vaikkapa kuluttajasovellutuksiin jonkun muutaman legacy-pakkomielteen omaavan kotikolvaajan vuoksi.

Jostain kumman syystä kun pitäisi saada aikaan skaalautuvaa, vikasietoista, ylläpidettävää, tietoturvallista ja toimivaa toteutusta, niin nämä joka kodin tiedemiesten korttitalot tuppaavat kaatumaan. Omaa teknistä rajoitteisuutta voi toki perustella milloin milläkin, syvässä päässä vaikkapa salaliittoteorioilla.

 

[Sompi]

Mitä oikein yrität tuolla vihaisella purkauksellasi hakea?

Mistä löytyy "valmiit palikat" TLS-protokollan toteuttamiseen?

 

[love_doctor]

Eli onko se lyhytohjelma kuitenkin siellä pesukoneessa, mutta haluat käynnistää sen sovelluksella, koska pesukoneessa joutuisit seikkailemaan valikossa? Jos noin, niin minusta kyllä hyvä esimerkki siitä, miten joku toiminto paskotaan pilalle.

Kuulostaa tosiaan siltä, että valikkosysteemi on melkeinpä taannuttanut käyttömukavuutta. Aiempi pesukoneeni oli perinteisempi, tosin 2010-luvulla ostettu. Siinä kuitenkin oli ajastusta yms. ilman verkkoon kytkemistä. Säädöt osuivat yllättävän hyvin kohdille omiin käyttötapoihin ja vasta jälkikäteen osasi arvostaa. Toki laitteessa olisi voinut olla muistipaikkoja omille konfiguraatioille vielä.

Hyvä vastaava esimerkki on mikroaaltouunit, joihin on tuotu valikkoihin tuhottomasti reseptivaihtoehtoja, ehkä jenkkilästä lähtöisin. Kaikkein paskin ikinä käyttämäni mikro oli jenkkilässä sellainen, jossa ei saanut valittua manuaalisesti tehoa tai aikaa mitenkään vaan ruokareseptit oli koodattu numeroilla ja ruokapakkauksesta piti kai katsoa, mikä sen ruuan reseptinumero on. No, eipä löytynyt, niin siinä sitten jännäilee käsi mikron ovella, koska kärähtää poroksi. Muistaakseni tuossa ei edes ollut numeronäyttöä vaan reseptit piti selata nuolinapeilla valikosta ja ruudulla näkyi jollain 60x30 pikselin näytöllä alkeellinen pikselöitynyt kuva reseptin ruuasta.

Tuo lopetusilmoitus kännykkään/kelloon taas ihan hyvä ominaisuus. Itse laitan aina puhumalla ajastimen Applen kelloon ja menee 3-4 sekuntia, mutta tuossa säästyy sekin vaiva. Miinuspuolena sitten se, että pesukone on verkossa.

Tuo on varsin kätevä, samoin ajastus. Yleensä ajastusten käyttöliittymä on perinteisissä laitteissa melko kankea. Esim. tuhottomasti napsuttelua, että saa minuutit kohdalleen tai hallittavuus luokkaa se, että töpselin saa repiä seinästä, jos haluaa ajastaakin toisella tavalla. Aiemmassa perinteiseen tapaan rakennetussa pesukoneessa oli digitaalinen piippaus, josta tiesi ohjelman valmistuneen. Tässä oli vaan se ärsyttävä piirre, että piippauksen jälkeen ei luukkua saanut auki vaan piti odottaa pari minuuttia. Usein siinä ajassa unohtui sitten tyhjentää kone. Piippaus olisi saanut tulla siinä kohtaa kun luukun lukko aukeaa. Mutta näkisin että nämä kaikki ovat ennemmin suunnittelun kukkasia.

 

[love_doctor]

Sisäverkko nyt ei ole enää ollut mikään argumentti sen suhteen, että yhteyden salauksen voisi skipata - kun puhutaan kaupallisista toteutuksista. TLS-protokollankin pyörittelyyn löytyy lukuisista eri ohjelmointikehyksistä valmiit palikat. Toisaalta jos kategorisesti haluat välttää näitä niin väännä sitten pitkästä tavarasta, mutta turha itkeä ylämäessä.

Alkaa myös IPv6 olla pian tätä päivää. Nyt vielä Telia tarjoaa 6rd-verkkoa, mutta muilla pääoperaattoreilla on natiivi IPv6. IPv6-penetraatio kasvanee suhteellisesti vielä ensi vuoden alussa, kun kupariverkkoja suljetaan.

Ainakin teoriassa IPv6 tekee nattaamiset turhiksi. Moni varmaan käyttänee silti IPv6-siirtymän jälkeenkin sitä tukematonta reititintä tai nattia "palomuurina" kotiverkossa. Ehkä jopa tuplanattausta (4g-mokkulassa ja modeemi kiinni usb:llä reitittimeen, jossa oma nat). Ja päälle vielä operaattorin cgnat. Kuitenkin niillä, joilla IPv6 tulee toimimaan "oikein", on vähän isompia ongelmia, jos kotona on salaamaton verkko.

Osaisitko googlettaa? Olen varma, että kaveri, joka kirjoittelee omat TCP/IP-pinot, osaa myös googlettaa jos niinkin yleiset termit kuin REST(ful) tai API eivät ole tuttuja.

Periaatteessa Sompi on siinä ihan oikeassa, että HTTP(S)+REST on hieman raskas ja kömpelö API moneen hommaan. Harva on oikeasti lukenut tuon väitöskirjan nimeltä 'Architectural Styles and the Design of Network-based Software Architectures' ja käyttää REST-nimeä omasta RPC-protokollasta, joka toimii HTTP:n päällä ja käyttää HTTP:n verbeistä yhtä tai kahta, vähän miten sattuu - jopa virhekoodit voivat tulla HTTP-statuksella 200 ja koodi on luettava JSON-datasta. Resurssiprotokolla HTTP:llä on vähän idioottimainen kerros RPC:n päällä, jos halutaan tehdä RPC:tä. Sitä tietysti käytetään kun sitä on helpompi debugata ja dokumentoida kuin omia binääriprotokollia. MQTT on toinen mikä voisi olla lähempänä sitä mitä Sompi haluaa telnetillä. MQTT toimii salauksella tai ilman.

 

[Paapaa]

Periaatteessa Sompi on siinä ihan oikeassa

No eikä ole oikeassa tässä kontekstissa. Telnet-tuella ei ole mitään tarvetta eikä siinä ole mitään järkeä. MQTT (tai vaikka AMQP) on moderni protokolla, kuten vaikkapa HTTPS. Jos halutaan tukea avoimia protokollia, kannattaa valita sellaisia joita myös käytetään. Jämähtäminen jokaisessa kuviteltavissa olevassa asiassa 1970-luvulle kertoo jotain mitä en tähän viitsi edes kirjoittaa.

 

[leffo]

Niin en kyllä edelleenkään ymmärrä, mitä pahaa siinä telnetissä on.

Voi jee. No leivänpaahtimissa ja puhelimissa ei ole sitä. Täten se on käytettävyydeltään umpipaska. Sen sijaan selain löytyy kaikkialta.

 

[JCSH]

Periaatteessa Sompi on siinä ihan oikeassa, että HTTP(S)+REST on hieman raskas ja kömpelö API moneen hommaan. Harva on oikeasti lukenut tuon väitöskirjan nimeltä 'Architectural Styles and the Design of Network-based Software Architectures' ja käyttää REST-nimeä omasta RPC-protokollasta, joka toimii HTTP:n päällä ja käyttää HTTP:n verbeistä yhtä tai kahta, vähän miten sattuu - jopa virhekoodit voivat tulla HTTP-statuksella 200 ja koodi on luettava JSON-datasta. Resurssiprotokolla HTTP:llä on vähän idioottimainen kerros RPC:n päällä, jos halutaan tehdä RPC:tä. Sitä tietysti käytetään kun sitä on helpompi debugata ja dokumentoida kuin omia binääriprotokollia. MQTT on toinen mikä voisi olla lähempänä sitä mitä Sompi haluaa telnetillä. MQTT toimii salauksella tai ilman.

Tässä oli kyse yhdestä aika selvästä asiasta ja se oli kodin älylaitteiden hallinta rajapinnan kautta. Tuohon se HTTPS:n kautta toimiva REST on täysin toimiva ratkaisu ja helvetisti kätevämpi kuin mikään Sompin haluama telnet viritys. Kyseessä on kuitenkin sen verta matalan käyttöasteen toiminto, että yksi hailee jos HTTPS on ”hieman raskas”. Paljon tärkeämpää on se, että se HTTPS tarjoaa hyvät olemassa olevat työkalut ja laajan tuen, tehden siitä rajapinnan päälle toteuttamisesta erittäin nopeaa ja helppoa.
Toki voi olla jotain erikoistapauksia, joissa tarvitaan jotain muuta toteutusta. Esim. Huessa taitaa olla joku erillinen API siihen, jos haluaa tehdä nopeaa valojen automaatiota (esim. musiikin tahtiin).

 

[hkultala]

Miten se sitten eroaa salatusta telnetistä, kun se HTTP on edelleenkin vain yksi telnet-protokolla muiden joukossa?

Ei ole olemassa mitään yleisesti tuettua "salattua telnetiä". Sinulta menee nyt telnet ja TCP pahasti sekaisin.

ssh ei ole telnet, http/https ei ole telnet. Kaikki näistä toimivat TCPn päällä, kuten myös telnet.

Ja jos halutaan yksinkertaista ja nopeaa kontrolliprotokollaa eikä piitata tietoturvasta, joku UDP-pohjainen on paljon järkevämpi kuin mikään TCP-pohjainen.

Telnetissä on myös sellainen ongelma, että tilallista telnet-yhteyttä käyttävä palvelinsofta on hankalampi tehdä sellaiseksi että sitä voi käskyttää monesta eri paikasta.

 

[penttip]

En tiedä tuleeko tästä nyt bannia, mutta kun Sompi on tällekin foorumille jonkun kotisivunsa linkin postannut, niin todettakoon että kyseessä ei näyttäisi olevan mikään trolli vaan vakavasti näitä ajatuksia ajava persoona. Minkäänlaisen rakentavan kritiikin vastaanottaminen ei taida olla vahvuus.

 

[Sompi]

Edelleenkin se HTTP on yksi monista telnet-protokollista, ja REST API jonkun HTTP:n yli on ihan yltiöraskas ja turhan monimutkainen viritelmä jonkun kodinkoneen etäohjaukseen. Binääriprotokollaa nyt varsinkaan ei ole mitään järkeä käyttää, jos sen protokollan on tarkoitus olla helposti lähestyttävä, jolloin se on etu, että asioita voi ennen oman asiakasohjelman tekoa testata telnet-asiakasohjelmalla. Sitä protokollaa voi ajaa TLS:n päällä, mutta kuten tässä ketjussa on aiemminkin todettu, kaikenlainen pakotus on vastenmielistä ja niin on myös salauksen pakotus niin, ettei käyttäjä saa sitä pois päältä.

Täällä tuntuu hyvin monella olevan ihan perusasiat hukassa. Ilmeisesti eräät ihannoivat kaikkea mahdollisimman monimutkaista ja vihaavat kaikkea, jonka mieltävät jotenkin "vanhanaikaiseksi". ASCII-protokollia vastustetaan koska "telnet on vanha", mutta kuitenkin sitten ristiriitaisesti tarjotaan HTTP:ta käyttävää REST APIa ratkaisuksi kaikkeen.

Alkaa myös IPv6 olla pian tätä päivää. Nyt vielä Telia tarjoaa 6rd-verkkoa, mutta muilla pääoperaattoreilla on natiivi IPv6. IPv6-penetraatio kasvanee suhteellisesti vielä ensi vuoden alussa, kun kupariverkkoja suljetaan.

En nyt ihan saa kiinni, miten lankapuhelinverkon sulkeminen tähän vaikuttaa. IP on muutaman levelin sitä fyysistä linkkiä korkeamman tason protokolla.

Ainakin teoriassa IPv6 tekee nattaamiset turhiksi. Moni varmaan käyttänee silti IPv6-siirtymän jälkeenkin sitä tukematonta reititintä tai nattia "palomuurina" kotiverkossa. Ehkä jopa tuplanattausta (4g-mokkulassa ja modeemi kiinni usb:llä reitittimeen, jossa oma nat). Ja päälle vielä operaattorin cgnat. Kuitenkin niillä, joilla IPv6 tulee toimimaan "oikein", on vähän isompia ongelmia, jos kotona on salaamaton verkko.

IPv6:ssa on ihan samanlainen verkkomaskilogiikka kuin IPv4:ssäkin, ainoastaan maskin merkintätapa eroaa. Privaattiverkkoja voi tehdä aivan samalla tavalla IPv6:llakin ja varmasti niitä tehdäänkin. IPv6 vähentää nattaamisen tarvetta vain sitä kautta, että julkisia IP-osoitteita ei tarvitse enää säästellä, mutta nattaamiselle on kyllä monia muitakin perusteita olemassa. Esimerkiksi IP-verkon kautta etäohjattavien kodinkoneiden nyt ainakin kannattaa olla NATin takana, tai vielä mielummin kokonaan omassa verkossaan, josta ei mikään paketti reitity ulos.

Ei ole olemassa mitään yleisesti tuettua "salattua telnetiä". Sinulta menee nyt telnet ja TCP pahasti sekaisin.

ssh ei ole telnet, http/https ei ole telnet. Kaikki näistä toimivan TCPn päällä, kuten myös telnet.

Mnkä tahansa protokollan voi salata laittamalla sen salausprotokollan hyötykuormaksi.

Ei mitään HTTPS-protokollaakaan ole olemassa, vaan se on lyhenne HTTP/TLS:stä.

Millä tavoin muka sotken telnetin ja TCP:n?

Ja jos halutaan yksinkertaista ja nopeaa kontrolliprotokollaa eikä piitata tietoturvasta, joku UDP-pohjainen on paljon järkevämpi kuin mikään TCP-pohjainen.

UDP:ssä on se ongelma, että paketit eivät välttämättä mene perille, eikä lähettäjä tiedä siitä mitään.

Telnetissä on myös sellainen ongelma, että tilallista telnet-yhteyttä käyttävä palvelinsofta on hankalampi tehdä sellaiseksi että sitä voi käskyttää monesta eri paikasta.

Siinä ei ole mitään vaikeaa. Ja jos se nyt tosiaan on ylivoimaista sellainen tehdä, niin silloin siitä omasta protokollasta voi tehdä samalla tavalla tilattoman kuin HTTP-protokollakin vakiona ilman keep-alivea on, eli joka pyynnön jälkeen soketti kiinni. Ei se HTTP:n monimutkaisuuden tunkeminen siihen protokollaan hyödytä tuossa mitään.

Paljon tärkeämpää on se, että se HTTPS tarjoaa hyvät olemassa olevat työkalut ja laajan tuen, tehden siitä rajapinnan päälle toteuttamisesta erittäin nopeaa ja helppoa.

Toteutuksen pitäisi onnistua myös ilman mitään raskaita rajapintoja. Varsinkin marginaalissa oleville käyttöjärjestelmille noita rajapintoja voi olla muutenkin hankala löytää.

 

[Vaateri]

Edelleenkin se HTTP on yksi monista telnet-protokollista,

Kysyn nyt vielä kerran ja sitten saa jäädä: Mitä ovat nämä mystiset telnet-protokollat ja kuinka/kuka ne on sellaisiksi määritellyt?

 

[Sompi]

En tiedä tuleeko tästä nyt bannia, mutta kun Sompi on tällekin foorumille jonkun kotisivunsa linkin postannut, niin todettakoon että kyseessä ei näyttäisi olevan mikään trolli vaan vakavasti näitä ajatuksia ajava persoona. Minkäänlaisen rakentavan kritiikin vastaanottaminen ei taida olla vahvuus.

Täällä näyttää tietyillä ihmisillä olevan erioikeus toisista käyttäjistä keskustelemiseen. En tiedä, kuulutko sinä niihin. Säännöthän sen kieltävät. En kyllä koe henkilöönmenevää keskustelua ja olkiukkoilua rakentavana kritiikkinä.

Tämän ketjun perusteella monella täällä näyttää olevan suoranainen pakkomielle asioiden monimutkaistamiseen. Sitä pidetään pahana asiana, jos joku protokolla on niin yksinkertainen, että sen voi toteuttaa itse. Sitä ei sanota suoraan, vaan se verhoillaan kaikenlaisen "nykyaika"-pöhisemisen taakse. Nämä kyseiset ihmiset eivät varmastikaan itse tee ikinä mitään omia toteutuksia mistään protokollista, vaan ainoastaan ostavat kaupasta valmista ja kuluttavat. Eri mieltä olevia kohtaan sitten hyökätään olkiukoilla.

Jopa binääriprotokollia pidetään näköjään suositeltavana siksi, että se nähdään pahana asiana, jos protokollaa pystyy opiskelemaan kokeilemalla asioita tavallisella telnet-asiakasohjelmalla ennen varsinaisen dedikoidun asiakasohjelman tekemistä. Salausta halutaan PAKOTTAA, vaikka sekin lisää monimutkaisuutta sekä nostaa itse tekemisen kynnystä eikä monessa käyttötapauksessa ole edes tarpeellinen.

Kaikenlaisia uusia pöhinäsanoja sisältäviä juttuja halutaan pakottaa kaikki käyttämään, ja jos jossain esiintyy joku vanha sana, niin se halutaan kieltää, vaikka se pöhinäjuttukin toimisi sen päällä. Hyvänä esimerkkinä tuo, miten ensin ratkaisuksi kaikkeen tarjottiin REST APIa, mutta kun huomattiin että sekinhän on telnet-asiakasohjelmalla debugattava tekstiprotokolla, niin ratkaisu vaihtuikin binääriprotokolliin, koska ne ovat vaikeammin debugattavissa.

Juuri tällaisen vammaisen pöhinäpaskan takia tekniikan kehitys menee koko ajan enemmän ja enemmän päin helvettiä ja loppukäyttäjän mahdollisuuksia rajoittavampaan suuntaan - ja tämän viestiketjun otsikon mukaiseen suuntaan.

Edelleenkin kyllä kiinnostaisi sellaiset ohjelmointikirjastot, joilla pystyisi toteuttamaan helposti TLS-protokollan kättelyineen kaikkineen. Eräs oma projekti tarvitsisi sellaista.

 

[Drinkkeri]

Täällä näyttää tietyillä ihmisillä olevan erioikeus toisista käyttäjistä keskustelemiseen. En tiedä, kuulutko sinä niihin. Säännöthän sen kieltävät. En kyllä koe henkilöönmenevää keskustelua ja olkiukkoilua rakentavana kritiikkinä.

Tämän ketjun perusteella monella täällä näyttää olevan suoranainen pakkomielle asioiden monimutkaistamiseen. Sitä pidetään pahana asiana, jos joku protokolla on niin yksinkertainen, että sen voi toteuttaa itse. Sitä ei sanota suoraan, vaan se verhoillaan kaikenlaisen "nykyaika"-pöhisemisen taakse. Nämä kyseiset ihmiset eivät varmastikaan itse tee ikinä mitään omia toteutuksia mistään protokollista, vaan ainoastaan ostavat kaupasta valmista ja kuluttavat. Eri mieltä olevia kohtaan sitten hyökätään olkiukoilla.

Jopa binääriprotokollia pidetään näköjään suositeltavana siksi, että se nähdään pahana asiana, jos protokollaa pystyy opiskelemaan kokeilemalla asioita tavallisella telnet-asiakasohjelmalla ennen varsinaisen dedikoidun asiakasohjelman tekemistä. Salausta halutaan PAKOTTAA, vaikka sekin lisää monimutkaisuutta sekä nostaa itse tekemisen kynnystä eikä monessa käyttötapauksessa ole edes tarpeellinen.

Kaikenlaisia uusia pöhinäsanoja sisältäviä juttuja halutaan pakottaa kaikki käyttämään, ja jos jossain esiintyy joku vanha sana, niin se halutaan kieltää, vaikka se pöhinäjuttukin toimisi sen päällä. Hyvänä esimerkkinä tuo, miten ensin ratkaisuksi kaikkeen tarjottiin REST APIa, mutta kun huomattiin että sekinhän on telnet-asiakasohjelmalla debugattava tekstiprotokolla, niin ratkaisu vaihtuikin binääriprotokolliin, koska ne ovat vaikeammin debugattavissa.

Juuri tällaisen vammaisen pöhinäpaskan takia tekniikan kehitys menee koko ajan enemmän ja enemmän päin helvettiä ja loppukäyttäjän mahdollisuuksia rajoittavampaan suuntaan.

Edelleenkin kyllä kiinnostaisi sellaiset ohjelmointikirjastot, joilla pystyisi toteuttamaan helposti TLS-protokollan kättelyineen kaikkineen. Eräs oma projekti tarvitsisi sellaista.

Siinä on, vissiin se open source hakukone ei löytänyt sulle tätä wolfSSL – Embedded SSL/TLS Library

 

[JCSH]

Edelleenkin se HTTP on yksi monista telnet-protokollista, ja REST API jonkun HTTP:n yli on ihan yltiöraskas ja turhan monimutkainen viritelmä jonkun kodinkoneen etäohjaukseen. Binääriprotokollaa nyt varsinkaan ei ole mitään järkeä käyttää, jos sen protokollan on tarkoitus olla helposti lähestyttävä, jolloin se on etu, että asioita voi ennen oman asiakasohjelman tekoa testata telnet-asiakasohjelmalla. Sitä protokollaa voi ajaa TLS:n päällä, mutta kuten tässä ketjussa on aiemminkin todettu, kaikenlainen pakotus on vastenmielistä ja niin on myös salauksen pakotus niin, ettei käyttäjä saa sitä pois päältä.

…

Toteutuksen pitäisi onnistua myös ilman mitään raskaita rajapintoja. Varsinkin marginaalissa oleville käyttöjärjestelmille noita rajapintoja voi olla muutenkin hankala löytää.

Ei tarvi, koska ketään ei kiinnosta mitkään ”marginaalissa olevat käyttöjärjestelmät”. Ei ole mitään järkeä tehdää hommaa vaikeaksi 99,99999%:lle devaajista vain sen takia, että jotku viisi 80-luvulle juuttunutta hakkeria voivat käyttää omaa suosikkiaan.
HTTPS on vallan mainio ja toimiva ratkaisu tuollaiseen, ”yltiöraskaus” tai ”monimutkaisuus” eivät merkkaa tuossa tippaakaan, kerta se tarvittava kaista on niin minimaalinen, että tuo ”raskaus” ei merkkaa pätkääkään ja ”monimutkaisuus” ei myöskään merkkaa, kerta on valmiit rajapinnat ja kirjastot tuon HTTPS protokollan hanskaamiseen.

Salauksen pakottaminen on yritysten kannalta erittäin hyvä juttu. On hemmetin typerää, että nykyaikana salaamattomat protokollat ovat vieläkin niin yleisiä kuin ovat. Niiden vastustamiselle ei todellakaan ole mitään järkipohjaisia syitä.
Lisäksi mikään täysjärkinen yritys ei ota sitä riskiä, että jättäisi tuotteisiinsa tuollaisia massiivisia tietoturva-aukkoja, ihan jo pelkästään siitä seuraavan negatiivisen julkisuuden takia.

 

[Timo 2]

Edelleenkin se HTTP on yksi monista telnet-protokollista, ja REST API jonkun HTTP:n yli on ihan yltiöraskas ja turhan monimutkainen viritelmä jonkun kodinkoneen etäohjaukseen. Binääriprotokollaa nyt varsinkaan ei ole mitään järkeä käyttää, jos sen protokollan on tarkoitus olla helposti lähestyttävä, jolloin se on etu, että asioita voi ennen oman asiakasohjelman tekoa testata telnet-asiakasohjelmalla. Sitä protokollaa voi ajaa TLS:n päällä, mutta kuten tässä ketjussa on aiemminkin todettu, kaikenlainen pakotus on vastenmielistä ja niin on myös salauksen pakotus niin, ettei käyttäjä saa sitä pois päältä.

Itse en aihetta tarkkaan tunne, mutta uutisissa on ollut paljon juttua kaapatuista kodinkoneista, niin eikö salauksen pois jättö lisäisi kaapattujen kodinkoneiden määrää ja täten olisi silkkaa idiotismia? Vai oliko tässä tarkoitus saada bottiarmeijan ostohintaa alas lisäämällä tarjontaa?

 

[Sompi]

Yleisesti ottaen englanninkielisessä osassa internettiä ei ole tällaista vihamielisyyttä itse tekemistä kohtaan. Kyseessä on melko suomalainen ilmiö.

Eipä tosiaankaan tarvitse ihmetellä, miksi Nokia oli ja meni ja uutta ei enää tule.

 

[Timo 2]

Eipä tosiaankaan tarvitse ihmetellä, miksi Nokia oli ja meni ja uutta ei enää tule

Nokia kaatui kun ei ymmärretty softan merkitystä, eikä kosketusnäytön hyötyjä.
Tällä sun sun saamalla kritiikillä ei ole mitään tekemistä nokian kaatumisen kanssa.

 

[JCSH]

Yleisesti ottaen englanninkielisessä osassa internettiä ei ole tällaista vihamielisyyttä itse tekemistä kohtaan.

Ei tässä ole kyse mistään vihamielisyydestä ”itse tekemistä” kohtaan. Vaan tässä on kyse siitä, että sä haluat vaikeuttaa kaikkien muiden elämää vain jotta sun omat idiosynkraattiset halut saataisiin katettua.

 

[jyppi]

Kyllä mun mielestä valoja pitäs voida ohjata reikäkortilla.

Nokia kaatui kun ei ymmärretty softan merkitystä, eikä kosketusnäytön hyötyjä.
Tällä sun sun saamalla kritiikillä ei ole mitään tekemistä nokian kaatumisen kanssa.

Vielä tarkemmin, Nokia juurikin jumiutui niihin vanhentuneisiin teknologioihin, toimintatapoihin- ja malleihin. Kuten Sompikin. Esimerkiksi toimivaa älypuhelinta kosketusnäytöllä tarjottiin jo 2003 Nokialle, mutta ei kelvannut.

 

[tjkoo]

En tiedä tuleeko tästä nyt bannia, mutta kun Sompi on tällekin foorumille jonkun kotisivunsa linkin postannut, niin todettakoon että kyseessä ei näyttäisi olevan mikään trolli vaan vakavasti näitä ajatuksia ajava persoona. Minkäänlaisen rakentavan kritiikin vastaanottaminen ei taida olla vahvuus.

Ei varmastikaan ole trolli, ja kyllä minä ymmärrän AP:n ajatuksen tuosta telnet-hommasta, olen tehnyt niitä itsekin joissain tapauksissa 90-luvulta alkaen.

Vielä tänäkin päivänä on käytössä eräs viritys joka SMS viestin saatuaan ottaa (sisäverkon sisällä) rehellisen telnet yhteyden, kysyy arvoja ja quittaa. Joskus aikoinaan kaikki vastasivat portteihin, ja jos oli syöttää validia kysymystä niin ei siellä mitään tunnistautumisia kyselty. Tai jos kyseltiin, niin sen pystyi syöttämään, mutta ei se ollut millään tavalla salattua.

Se että onko se tätä päivää, niin ei.. Riippuen toki palvelusta, jos joku saa lukea keittiön lämpötilasi niin kukaan ei varmaan kuole, mutta jos joku pääsee ohjaamaan esim. kameroitasi tai saunaasi niin ei ehkä hyvä.

Tuo aiemmin mainittu API-rajapinta (REST) toimii siis kaikista yksinkertaisimmin niin, että teet komentorivillä wgetillä kutsun 'wget --token=232325fefwef http://palvelu.fi/setvaloOLKKARI=0'. Se ei muuta telnetistä oikeastaan kuin tuon autentikoinnin ja kirjastoja on saatavilla, java/python/yleisimmät pari riviä koodia niin voi olla jopa helpompaa. Listeneri sinne palvelinpuolelle on ehkä jopa helpompi toteuttaa vs. telnet.

Yleisesti ottaen kannattaa se kotiverkkokin pitää turvallisena, ei mene kauaa kun joku kaveri tai lapsen yökyläkaveri kysyy WLAN-salasanaa "Merjan pitäis saa netti toimimaan että se voi vastaa äidille ku sillei oo saldoo, mikä se passu on", ja hankalampi niistä laitteista on haittaohjelmia skannata

Itsellänihän ei toki ole mitään salattavaa tai jaossa edes kotiverkossa.

 

[Tonnin Seteli]

Yleisesti ottaen englanninkielisessä osassa internettiä ei ole tällaista vihamielisyyttä itse tekemistä kohtaan. Kyseessä on melko suomalainen ilmiö.

Liekö tämä kulttuurianalyysi kenenkään otannalla vilpittömästi tehtävissä tai osa aihetta. Voisin kuitenkin sanoa, että sikäli kun "englanninkielisellä osalla internettiä" tarkoitetaan yhdysvaltalaista foorumikulttuuria, siellä ei ole keskeisessä osassa keskustelu. Kova viha kylläkin herkästi siellä leimahtaa jos joku kyseenalaistaa sitä hegemoniaa ja pöhinää. Siitä kriittisyydestä kun tunnistaa ulkopuolisen vaikka olisikin pirulainen osannut kieltä hyvin, ja siellä ei suvaitsevaisuus ole kovassa huudossa. Erittäin kriittisellä vähemmistönäkemyksellä kun menee kokeilemaan oikeasti, voi tulla nenille. Ei sen jälkeen vaikuta pelkästään suomalaiselta piirteeltä.

 

[love_doctor]

HTTPS on vallan mainio ja toimiva ratkaisu tuollaiseen, ”yltiöraskaus” tai ”monimutkaisuus” eivät merkkaa tuossa tippaakaan, kerta se tarvittava kaista on niin minimaalinen, että tuo ”raskaus” ei merkkaa pätkääkään ja ”monimutkaisuus” ei myöskään merkkaa, kerta on valmiit rajapinnat ja kirjastot tuon HTTPS protokollan hanskaamiseen.

HTTPS:n on kyllä sen verran raskas, että jos puhe on vaikka IoT-laitteista, ihan normaalisti työpöydällä ja servereissä käytetyt SSL/TLS-kirjastot esim. eivät välttämättä käy vaan on juuri noita wolfSSL/mbedtls-tyylisiä kevytratkaisuja.

Toinen mitä tarkoitin raskaudella on speksin pituus - jos haluat vaan viestiä /valo/1/päälle ja saada jonkun statuskoodin, HTTP:n speksi on pitkä kuin nälkävuosi. Siinä käytössä ei tarvi tukea jollekin 4 teratavun datan lähettämiselle chunkeissa tai HTTP/2:lle ja HTTP/3:lle (jotka olisi työläs poistaa siitä täysverisestä kirjastosta). Jos viestit ovat pari tavua pitkiä, 5+ eri protokollatason kompressioformaatin tukea ei tarvita. HTTPS:llä myös kaikki serttien ylläpidot niin että palvelin on node-laitteella on lisää vaivaa. Auditointi tuo vielä oman osuutensa tähän.

IoT-laitteelle sopisi paljon paremmin joku kevyt protokolla. Lisäksi MQTT:ssä on hyödyllisiä ominaisuuksia kuten viestin lähetys myöhemmin jos laite nukkuu. Useinhan noissa IoT-laitteissa on ihan omat protokollat ja HTTP(S) on vaan se avoin API jollain API-avaimella sinne valmistajan suljettuun pilvipalveluun. Ironisesti valmistajalla voisi hyvinkin olla vaikka joku salaamaton telnet pesukoneelta sinne AWS:ään - ei voi tietää.

En nyt ihan saa kiinni, miten lankapuhelinverkon sulkeminen tähän vaikuttaa. IP on muutaman levelin sitä fyysistä linkkiä korkeamman tason protokolla.

DSL-verkkoihin ei operaatorit ole välttämättä tuoneet natiivia IPv6:sta ja näiden verkkojen osalta päivityspolku on lopettaa koko tekniikka kokonaan. Näin operaattori voi keskittyä modernimpien tekniikoiden ylläpitoon.

Esimerkiksi IP-verkon kautta etäohjattavien kodinkoneiden nyt ainakin kannattaa olla NATin takana, tai vielä mielummin kokonaan omassa verkossaan, josta ei mikään paketti reitity ulos.

Tällainen reitittymiseen liittyvä käyttöoikeus on melkoisen ongelmallinen. Eikä se edes toimisi, jos vaikka kotona laitteet on kiinteässä verkossa ja kaukosäätimet (puhelin, kello) mobiiliverkossa. Jos tähän tekee jotain porttien avaamista ja uudelleenohjausta, edelleen vaaditaan autentikointi. Eikä tämä poista sitä ongelmaa, miten se palvelu edes löytyy jos IP on dynaaminen.

Telnet-tuella ei ole mitään tarvetta eikä siinä ole mitään järkeä. MQTT (tai vaikka AMQP) on moderni protokolla, kuten vaikkapa HTTPS. Jos halutaan tukea avoimia protokollia, kannattaa valita sellaisia joita myös käytetään. Jämähtäminen jokaisessa kuviteltavissa olevassa asiassa 1970-luvulle kertoo jotain mitä en tähän viitsi edes kirjoittaa.

Niin, järkevää on käyttää nykyiseen toimintaympäristöön soveltuvia protokollia ja valmiita tekniikoita. En ottanut tätä telnet-ajatusta vastaan niin konkreettisesti, kun en näe että se ratkaisisi tässä mitään oleellista. Mietin vaan, mitä telnettimäisempää voisi olla jos ei halua HTTP(S):ää. Minusta telnet on väärä ratkaisu nykyään aika moneen paikkaan. Jos on tarpeeksi yksinkertainen laite kuten vaikkapa kotireititin, voi olla monin tavoin parempi joku dedikoitu sarjalinkki, jossa ei ole samanlaisia tietoturvariskejä verkon yli.

 

[Sompi]

Nokia kaatui kun ei ymmärretty softan merkitystä, eikä kosketusnäytön hyötyjä.
Tällä sun sun saamalla kritiikillä ei ole mitään tekemistä nokian kaatumisen kanssa.

Viestini pääpaino olikin tuossa "uuden Nokian" syntymisen mahdollisuuteen. Kun kulttuuri Suomessa on sellaista, että aktiviisesti haitataan kaikenlaista itse tekemistä, niin kehitysmaaksi tullaan ja sellaisena sitten pysytäänkin.

Käsitykseni mukaan Nokialla kyllä oli myös paljon sellaista keskijohtoa, joka halusi pakottaa kaikille omia juttujaan vähän samaan tyyliin kuin tälläkin foorumilla moni pöhisijä haluaa tehdä.

Ei tarvi, koska ketään ei kiinnosta mitkään ”marginaalissa olevat käyttöjärjestelmät”.

Tässä juuri kiteytyy se vittumainen asenne. Eli koska sinua itseäsi ei kiinnosta muut kuin virran mukana kulkeminen, valmiit tuotteet ja niiden kuluttaminen, niin kaikkien muidenkin elämä pitää tehdä mahdollisimman hankalaksi ja estää kaikenlainen itse tekeminen.

Itse en aihetta tarkkaan tunne, mutta uutisissa on ollut paljon juttua kaapatuista kodinkoneista, niin eikö salauksen pois jättö lisäisi kaapattujen kodinkoneiden määrää ja täten olisi silkkaa idiotismia? Vai oliko tässä tarkoitus saada bottiarmeijan ostohintaa alas lisäämällä tarjontaa?

Eiköhän se kaappaus tyypillisesti tapahdu pikemminkin jonkun takaoven tai hallintaohjelmassa olevan aukon kautta. Tietysti salauksen pois jättö voi helpottaa myös pahan hakkerin työtä, ja senpä takia se salaus pitääkin pitää päällä ulkoverkon kautta tietoa lähetettäessä. Pakottaa sitä ei kuitenkaan pidä.

Salaus tekee myös protokollan reverse-engineeraamisesta käytännössä mahdotonta. Salaamattoman protokollan toiminnan voi yleensä suhteellisen helposti saada selville, vaikka kyse olisi dokumentoimattomasta protokollasta. Salatun protokollan tapauksessa pitäisi sitten jo purkaa asiakasohjelma osiin disassemblerilla ja vaikeustaso nousee melkoisesti. Lähtökohtaisesti tietysti sen protokollan pitäisi kuitenkin olla dokumentoitu.

Tuo aiemmin mainittu API-rajapinta (REST) toimii siis kaikista yksinkertaisimmin niin, että teet komentorivillä wgetillä kutsun 'wget --token=232325fefwef http://palvelu.fi/setvaloOLKKARI=0'. Se ei muuta telnetistä oikeastaan kuin tuon autentikoinnin ja kirjastoja on saatavilla, java/python/yleisimmät pari riviä koodia niin voi olla jopa helpompaa. Listeneri sinne palvelinpuolelle on ehkä jopa helpompi toteuttaa vs. telnet.

REST APIn protokollassa on jo aika paljon enemmän sääntöjä kuin telnetissä.

Totta kai se toimii helposti komentoriviltä wget-ohjelmaa käyttäen, mutta wgetissä sitten taas onkin jo melkoinen määrä koodia. Kukaan ei ihan hetkessä koodaa omaa wgettiä, ei vaikka siihen toteuttaisi vain HTTP:n.

DSL-verkkoihin ei operaatorit ole välttämättä tuoneet natiivia IPv6:sta ja näiden verkkojen osalta päivityspolku on lopettaa koko tekniikka kokonaan. Näin operaattori voi keskittyä modernimpien tekniikoiden ylläpitoon.

Tuo on ihan suomalaisten internet-operaattorien evotusta eikä varsinaisesti liity mitenkään siihen, mitä lankapuhelinverkolla voi tehdä.

Nuo MQTT ja AMQP vaikuttavat kyllä melkoisen monimutkaisilta protokollilta mihinkään kodinkoneiden ohjaukseen. Jälkimmäinen ainakin on vieläpä binääriprotokolla. Googlella on hankala löytää tietoa oikein kummastakaan, mutta speksit taitavat ainakin olla aika pitkät. Hakemalla löytyy enimmäkseen vain IoT-pöhinää.

Vaikuttaa siltä, että yksinkertainen telnet-pohjainen protokolla ei kelpaa, koska se olisi liian helppoa ja toimivaa.

 

[JCSH]

Tässä juuri kiteytyy se vittumainen asenne. Eli koska sinua itseäsi ei kiinnosta muut kuin virran mukana kulkeminen, valmiit tuotteet ja niiden kuluttaminen, niin kaikkien muidenkin elämä pitää tehdä mahdollisimman hankalaksi ja estää kaikenlainen itse tekeminen.

Sä tässä haluat tehdä kaikkien muiden paitsi itsesi elämän hankalaksi. Sä haluat, että firmat käyttäisivät helvetisti aikaa ja rahaa siihen, että toteuttaisivat juurikin ne sun haluamat rajapinnat, joita ylivoimainen enemmistö niistä devaajista ei kaipaa.
Valtaosalle devaajista se HTTPS rajapinta kelpaa vallan mainiosti, kerta se on erittäin helppo ja nopea käyttöinen moderneilla frameworkeillä. Tarvitaan muutama hassu rivi koodia niiden HTTPS requestien tekemiseen ja parsimiseen. Lopputuloksena sen rajapintaa käyttävät clientin koodaaminen on erittäin helppoa ja nopeaa.
Devaajat saavat helpot rajapinnat, käyttäjät saavat halpoja softia ja laitevalmistaja parantaa asemiaan markkinoilla.

Mutta sulle tuo ei jostain ihmeen syystä kelpaa. Sen sijaan ajat sitä, että firmat käyttäisivät miljoonia huonojen rajapintojen toteuttamiseen, joka nostaa niiden tuotteiden hintoja, vain jotta sä saat niihin sun harrasteprojekteihin mieluisesi rajapinnat.

Jos haluat ”tehdä itse” niin ok, siitä vaan. Ota kolvi käteen ja ala rakentaan sitä itsetehtyä älyjääkaappia. Mihin sä noita laitevalmistajien rajapintoja kaipaat?

 

[Sompi]

Tarvitaan muutama hassu rivi koodia niiden HTTPS requestien tekemiseen ja parsimiseen.

Hah.

Onko tässä REST APIn pakottamisessa motiivina se, että protokollan pitää olla sellainen, että sitä pystyy käpistelemään JavaScriptin fetch-APIlla? Ja kun mitään muuta kuin sitä JavaScriptiä ei osata eikä viitsitä opetella, niin halutaan sitten pakottaa kaikki muutkin käyttämään sitä.

Ihan millä tahansa konekielelle käännettävällä kielellä tuollaisen tekeminen on nimittäin aika monta tuhatta riviä koodia, jos ajatellaan, että yhdelle riville tulee yksi lauseke. JavaScript ja muut skriptikielet ovat tietysti asia erikseen, mutta niillä ei kovin tehokkaaseen lopputulokseen ikinä päästäkään.

JavaScript on vielä siitäkin hyvin huono kieli, että mitään ohjelmoijan itse päättämää sisältöä ei saa sokettien yli menemään, vaan ainoat mahdollisuudet ovat käyttää fetch-APIn kautta HTTP-protokollan tarjoamia metodeja ja sitten webSocket-apin kautta käyttää websoketteja. Tuki uusille jutuille vaihtelee selaimittain.