Digitalisaatio - hyvät ja huonot puolet

Millä laitteella? Ainakin Androidissa ohjelman voi jättää taustalle siihen kohtaan kun käy sähköpostista hakemassa koodin.

oneplus 9pro, android 14. ohjelma on taustalla. mutta aina kun palaat siihen niin tämä kyseinen ohjelma päivittää näkymänsä. ärsyttävää jos haluat vaikka tilitapahtumia katsoa ja hyppäät toiseen appiin ja takaisin niin lataa aina uudestaan ja pomppaa sivun alkuun.
 
Ja taas löytyi ärsyttävä ominaisuus. Syötät s-mobiilissa email osoitteen. Appi sanoo että sähköpostiin lähti tarkastuskoodi. käy katsomassa koodi, palaa takaisin, sovellus lataa sisällön uudestaan joka tarkoittaa että palataan taas alkuun ja pyytää sähköpostiosoitteen. ja taas koodi kohtaan. onneksi koodi kelpasi eikä lähettänyt sitä uudestaan. Muuten olisi pitänyt käydä koneella lukemassa sähköposti...
Tuon tyyppinen toiminnallisuus todella ärsyttävää, ja tuntuu että viimevuosina yleistynyt, ihan tietoista kokemuksen pilaamista, selitys ilmeisesti "turvallisuus"

Millä laitteella? Ainakin Androidissa ohjelman voi jättää taustalle siihen kohtaan kun käy sähköpostista hakemassa koodin.
Mikä s-mobiilin versio sulla? (oletus että tuota aiempaa kommenoit)
 
Yksi tämmöinen paske joka tarvitsee sovelluksen ja nettisivujen käyttöä on Wilma. Itse sovelluksella voit ottaa vastaan viestejä ja nähdä koenumerot. Lomakkeet, anomukset, salasanan vaihto jne. vaativat nettisivujen käyttöä.
 
Xiaomi 13, Android 14, S-mobiili versiolla 2.30.0.

Tuon tilioteasian tunnistan, mutta en pidä sitä niin suurena ongelmana.
 
Lisenssi == lupa käyttää ohjelmaa laillisesti
Noi on laillisia. Käyttöehdot ei mene lain yli.

Toki yritysmaailmassa käyttöehdot painaa enemmän enkä noita käyttäisi vähänkään isommassa firmassa.

Ja joo, saahan noi aktivoitua KMS avulla, mutta koodi on helpompi ja täysin laillinen, eikä mitään piratismia.
 
  • Tykkää
Reactions: a-p
Mikä s-mobiilin versio sulla? (oletus että tuota aiempaa kommenoit)

?
S-mobiili versiolla 2.30.0.
Tuo taitaa olla viimeinen versio.

Varmistan vielä että ymmärsin kirjoituksesi vastaukseksi.

Eli sinulla voi se sähköposti ohjelman avata ja käydä kopsaamassa koodin ja palata s-mobiilin, ja pasteta sen sinne (tai muistista naputella), nimenomaan tuolla versiolla ?


Tuon tilioteasian tunnistan, mutta en pidä sitä niin suurena ongelmana.
Mikäs tämä tunnistus?
 
S-pankilla/kaupalla on näitäkin ongelmia, että ostat kaupasta jotain, niin nettipankissa voit ihastella kaupan nimessä lokkiskandeja. Unicoden kehityshän aloitettiin jo 40 vuotta sitten.

Tämä nyt ei ole mitenkään S-pankkiin liittyvä ongelma, vaan yleinen ongelma luottokorttimaksuissa. Niissä käytetään järjestelmätasolla lokkiskandeja, koska historialliset syyt. Pankin käyttöliittymä voi konvertoida tai olla konvertoimatta ne nykyaikaisiksi skandeiksi. Tässä on se ongelma, ettei ole tietoa, oliko alun perin tarkoitus käyttää skandeja vai haka- tai aaltosulkeita. Homma voi mennä pieleen kumpaankin suuntaan.
 
Noi on laillisia. Käyttöehdot ei mene lain yli.

Mikään laki ei tietääkseni sano, että esim. pakistanilainen opiskelija saa siirtää softasta halvan pakistaniin myydyn opiskelijalisenssinsä suomalaiselle ei-opiskelijalle.

Laki tietääkseni sanoo vain, että sen EUn alueelle myydyn normaalin "täyshintaisen" lisenssin saa myydä eteenpäin laillisesti EUn alueella.

Ja aktivointikoodi ei ole sama asia kuin lisenssi.

Osa noista voi olla laillisia, osa on laittomia. Sen varmistaminen, että mistä myytävä aktivointikoodi on alunperin peräisin on tuollaisesta ostamalla aika vaikeaa, ja sen selvittäminen, mitä lait ja käyttöehtosopimuksen sanoo juuri siitä lähteestä lisenssin siirtämisestä on työlästä.

Ja vaikka lisenssin saisi siirtää, mutta jos lisenssissä lukee, että sitä saa käyttää vain yliopisto- tai amk-opiskelija, niin jos sitä käyttää muu kuin tällainen opiskelija, sen käyttö on laitonta.

Että käytännössä tuollaisesta ostamalla on huomattava riski syyllistäyä piratismiin. Ja se, että siitä maksaa kolmannelle osapuolelle on mielestäni raskauttava tekijä, ei rikosta lieventävä tekijä.
 
Viimeksi muokattu:
Mikään laki ei tietääkseni sano, että esim. pakistanilainen opiskelija saa siirtää softasta halvan opiskelijalisenssinsä suomalaiselle ei-opiskelijalle.
Mikään laki ei kiellä tätä. Sulla on täysi oikeus käyttää sitä ja ainut mitä MS voi tehdä on mitätöidä lisensin, eikä tätäkään MS tee kovin usein.

Samaan tapaan kuin vaikka steamtili. Valve sanoo ettet saa siirtää, luovutyaa myydä, yms. Silti voit sen tehdä ja ostajalla on oikeus käyttää sitä tiliä, eikä joudu vastuuseen.

Lisäksi jos nämä lisensit MS oikesti kiinnostaa, niin keinoja kyllä olisi näiden toiminan estämiseen.
Aktivointikoodi ei ole sama asia kuin lisenssi.
Mutta sä käytät toisen lisnsiä/aktivointikoodia. Ja tämä on laillista. Muutenkin tämä on turhaa pilkun viilausta.
Osa noista voi olla laillisia, osa on laittomia. Sen varmistaminen, että mistä koodi on alunperin peräisin (eli että onko laillinen vai laiton) on tuollaisesta ostamalla aika vaikeaa.
Ei ole kuluttajan murhe. Jos noiden takana olisi jotain rikollista, niin ei noita myytäisi noin avoimesti eikä esim tämä käyttäjä olisi myynyt noita lisensejä vuosia.


Ja vaikka lisenssin saisi siirtää, mutta jos lisenssissä lukee, että sitä saa käyttää vain yliopisto- tai amk-opiskelija, niin jos sitä käyttää muu kuin tällainen opiskelija, sen käyttö on laitonta
Höpö höpö. Se rikkoo käyttöehtoja, mutta ei ole laitonta.

Että käytännössä tuollaisesta ostamalla on huomattava riski syyllistäyä piratismiin. Ja se, että siitä maksaa kolmannelle osapuolelle on mielestäni raskauttava tekijä, ei rikosta lieventävä tekijä
Edelleen toi ei ole piratismia. Softa on aito, koodit on aitoja.
ehkä jatkot tonne, sillä alkaa olla offtopicia.
 
Viimeksi muokattu:
Tämä nyt ei ole mitenkään S-pankkiin liittyvä ongelma, vaan yleinen ongelma luottokorttimaksuissa. Niissä käytetään järjestelmätasolla lokkiskandeja, koska historialliset syyt. Pankin käyttöliittymä voi konvertoida tai olla konvertoimatta ne nykyaikaisiksi skandeiksi. Tässä on se ongelma, ettei ole tietoa, oliko alun perin tarkoitus käyttää skandeja vai haka- tai aaltosulkeita. Homma voi mennä pieleen kumpaankin suuntaan.
Siis lokkiskandit ilmenevät kun tehdään virheellisiä koodisivumuunnoksia. Tarkoittaa käytännössä, että saman ryhmän kaupalla ja pankilla on epäyhteensopivat koodisivut bäkkärissä. Kyllä koodisivutkin saa toimimaan "oikein" juuri tällaisessa tilanteessa kun sama taho kontrolloi transaktion molempia osapuolia. Mistä tahansa koodisivusta on triviaalia muuttaa webbinäkymään, kun sivustot ovat nykyisin unicodea ja unicode sisältää kaikki koodisivun merkit.

edit: Olet siinä oikeassa, että yleisessä tapauksessa tuo on vaikea ongelma kun eri tahoilta voi tulla miten vaan koodattuna nuo merkkijonot. Kuitenkin joidenkin kauppojen rivit näkyvät nettipankissa "oikein" eli ääkkösillä. On se minusta aika onneton tilanne jos omat järjestelmät eivät puhu samaa kieltä.
 
Viimeksi muokattu:
Eli sinulla voi se sähköposti ohjelman avata ja käydä kopsaamassa koodin ja palata s-mobiilin, ja pasteta sen sinne (tai muistista naputella), nimenomaan tuolla versiolla ?

Silloin kun mulla s-mobiili toimi niin ei siitä pystynyt vaihtaa pois mihinkään toiseen sovellukseen, ilman että sisäänkirjautuminen meni vanhaksi. Sama juttu mobilepay. Ei tarvinnut kuin pariksi sekunniksi poistua niin joutuu uudestaan kirjautumaan. Ja se nimenomaan tapahtui vain näillä kahdella sovelluksella joilla voi liikutella rahaa, niin olettaisin että se on ihan tarkoituksella. Jännä että jollain se sitten ei tee tuota.
Sinänsä, saisi se nyt sentään minuutin verran pysyä sisällä just jos haluaa kaivaa jotain jostain toisesta sovelluksesta.

Nyt kun kokeilin niin mobilepay pysyi sisällä ainakin hetken verran. Silti noissa sovelluksissa on käyttökokemuksessa parantamisen varaa. Olen melko hiljattain yrittänyt syöttää etukäteen mobilepayhin maksua, no se vanhenee ja pyyhkiytyy pois jos tiedot vaan syöttää etukäteen maksamatta. Sitten yritin kopioida myyjän puhelinnumeron torista jossa sen voisi nopeasti syöttää siihen mobilepayhin maksaessa. Sekään ei toimi koska tietyn ajan jälkeen myös leikepöytä pyyhkiytyy.
Sitäkin olen vähän miettinyt miksi kännykässä leikepöydältä tiedon liittäminen aina tyhjentää sen leikepöydän, muutamaan kertaan olisin tarvinnut liittää saman asian moneen kertaan. Sen sijaan sitä joutuu kaivaa edestakaisin.



S-pankilla/kaupalla on näitäkin ongelmia, että ostat kaupasta jotain, niin nettipankissa voit ihastella kaupan nimessä lokkiskandeja. Unicoden kehityshän aloitettiin jo 40 vuotta sitten.

Mä katsoin kerran sattumalta katevarauksia. Siellä oli kohteena SIPOO-SODERKULLA. En ole välttämättä koskaan käynyt koko Sipoossa. Ihmettelin tuota jonkin aikaa. Lopulta oivalsin että kyse oli kuitenkin Turun keskustan Lidlistä. Kun se maksu oli toteutettu, se oli oikein. Varmasti jos noita katselisi enemmän niin näkisi tuollaista enemmän.
1725556942560.png


Noi kaupan nimet ovat vähän mitä sattuu. Sama keskustan Lidl useimmiten esiintyy kahdella eri nimellä. Siinä voi olla variaationa yhteenkirjoitettuna tai ei, ääkkösillä tai ei(ei tuo mutta muut kaupat), tai jotain numeroita. Ja vuosien myötä se koko ajan vaihtuu. Sama pätee muihinkin kauppoihin, sen näkee parhaiten kun käy samoissa kaupoissa usein. Mä tykkään käyttää sitä verkkopankista löytyvää kulujenseurantaa ja jossain vaiheessa opin että noi voi kaikki yhdistää. Tällöin ne eri variaatiot saa samaan läjään.

Mä olettaisin että noi nimet kuitenkin tulee siitä maksun vastaanottajan päässä olevasta systeemistä, ei maksajan pankin systeemeistä. Toki niiden täytyy myös kommunikoida keskenään oikein. Kuitenkin tosiaan jos niitä katsoo tarpeeksi niin ne ovat sinnepäin ja ajan myötä voivat hieman muuttua.



Koska mulla on ääkkösiä nimessä niin mä olen milloin missäkin törmännyt niiden rikkoutumiseen. Toisinaan hyvin omituisesti, ei kunnolla pysty päättelemään miten tarkalleen ne on menneet rikki. Toisinaan hyvin tavanomaiset koodaus X näytetään koodauksen Y mukaisesti. Esim. Åbo Akademin kirjastossa olen varauksessa nähnyt sotkua mun nimessäni. Tuollaisessa paikassa luulisi ääkkösten olevan luonnostaan kunnossa. Ulkomailta tulevat postilähetykset usein ovat osoitettu miten sattuu.

Mä vähän odotan että joku kerta mä saan uuden ajokortin, passin tai muun tälläisen vähän tärkeän jutun käteeni, ja siinä on mun nimeni väärin. UTF on sinänsä ihan kiva keksintö, mutta kun ehkä puolet järjestelmistä ei ole UTF niin eiköhän nämä ongelmat jatku vielä muutaman vuosikymmenen vähintään.
 
Mä vähän odotan että joku kerta mä saan uuden ajokortin, passin tai muun tälläisen vähän tärkeän jutun käteeni, ja siinä on mun nimeni väärin. UTF on sinänsä ihan kiva keksintö, mutta kun ehkä puolet järjestelmistä ei ole UTF niin eiköhän nämä ongelmat jatku vielä muutaman vuosikymmenen vähintään.
Kyseessä on Unicode tai UCS tai UTF-1/8/16/32. UTF ei ole mikään validi lyhenne.

Unicode kyllä on varsin laajalle levinnyt. Käytännössä kaikki pääkäyttikset ovat jo vuosia tukeneet sitä. Esim. Windowsit vuodesta 1993 (pl. 95/98/ME). Netissä myös "UTF-8 is the dominant encoding for the World Wide Web (and internet technologies), accounting for 98.3% of all web pages, 99.1% of the top 100,000 pages, and up to 100% for many languages, as of 2024.[9] Virtually all countries and languages have 95% or more use of UTF-8 encodings on the web."

Erinäiset legacy-järjestelmät ovat jääneet jumiin koodisivuihin. Jenkeissähän ongelmaa vähentää paljon se, että vanha ASCII on käytännössä osa Unicodea myös.
 
Sitäkin olen vähän miettinyt miksi kännykässä leikepöydältä tiedon liittäminen aina tyhjentää sen leikepöydän, muutamaan kertaan olisin tarvinnut liittää saman asian moneen kertaan. Sen sijaan sitä joutuu kaivaa edestakaisin.
Tuo on täysin puhelinvalmistajan päätös. Samsungilla on päinvastoin leikepöydälle historia jossa säilyy jopa puhelimen uudelleenkäynnistyksen yli parisenkymmentä edellistä asiaa.
 
Tuo on täysin puhelinvalmistajan päätös. Samsungilla on päinvastoin leikepöydälle historia jossa säilyy jopa puhelimen uudelleenkäynnistyksen yli parisenkymmentä edellistä asiaa.
Riippuu softasta (tuossa ehkä viittaat näppisoftaan), saa ne vaikka pilveen synkattua. Joissain ohjelmissa jos kopsaa leikepäydälle niin se poistaa sen määräajan sisään, pieni "yksityisyys suoja". Joissain ohelmissa(näppis) saa sitten kiinittää asioita "leikepäydälle", eniten käytetyille frraseille näppärä. Synkroinointi myös näppärä, jos sen tiedostaan ja esim täysin yksityiset laitteet. Siinä ehkä kohtuu kompromissi jos se toimii vain kiinnitetyille.

Ne ohjelmat on syvältä joissa estetty kopioiminen, ja liittäminen, taustalla usein tietoturva ajatus. jos estetään liittäminen, luodaan jopa oma näppis, niin ehkä sillä yritetään estää koneellinen käyttö.
 
Riippuu softasta (tuossa ehkä viittaat näppisoftaan), saa ne vaikka pilveen synkattua. Joissain ohjelmissa jos kopsaa leikepäydälle niin se poistaa sen määräajan sisään, pieni "yksityisyys suoja". Joissain ohelmissa(näppis) saa sitten kiinittää asioita "leikepäydälle", eniten käytetyille frraseille näppärä. Synkroinointi myös näppärä, jos sen tiedostaan ja esim täysin yksityiset laitteet. Siinä ehkä kohtuu kompromissi jos se toimii vain kiinnitetyille.

Ne ohjelmat on syvältä joissa estetty kopioiminen, ja liittäminen, taustalla usein tietoturva ajatus. jos estetään liittäminen, luodaan jopa oma näppis, niin ehkä sillä yritetään estää koneellinen käyttö.
Aivan juu. Ymmärrän tietoturvasyistä sen miksi screenshotit estetty joissain sovelluksissa mutta ärsyttää silloin kun haluisi itse ottaa jostain kuvan.
 
Aivan juu. Ymmärrän tietoturvasyistä sen miksi screenshotit estetty joissain sovelluksissa mutta ärsyttää silloin kun haluisi itse ottaa jostain kuvan.
Itse juuri tällä viikolla koitin tehdä erääseen töissä käytettävään mobiilisovellukseen käyttöohjetta ja yllättäen sovelluksen tekijä oli blokannut screenshotit sovelluksesta. No, ei tuo ihan hirveän iso este sinänsä ollut, toisella kännykällä valokuvia toisen kännykän ruudusta ja perään vähän kuvankäsittelyä niin lopputulos oli hyvinkin lähellä sitä että olisi ottanut screenshotteja suoraan. Kyllähän tuo "turhaa" työtä teetti ehkä 5min per kuva mutta kyllähän tuo hieman ärsytti nysvätä parin välivaiheen kautta.

No, tulipahan todettua että GIMPin perspective tool ja pari muuta toimintoa tekee ihmeitä ja lopputulos oli kyllä niin lähellä oikeaa screenshottia että jos ei olisi tiennyt että oli tehty kuvamanipulointia käyttäen, en olisi itsekään lopputulosta erottanut aidosta. Ja tosiaan tuo oli about 5min/kuva, jos olisi vielä jokusen minuutin lisää jaksanut turata noiden kanssa niin olisi viimeisetkin parin pikselin virheet saanut korjattua eikä paljaalla silmällä enää olisi voinut erottaa tuota kameralla otettua "screenshottia" aidosta.
 
Huvittavasti poissuljetaan käytännössä koko 90-luku kuitenkin. Ei noita NT-pohjaisia (joka tässä lienee oli se erottava tekijä?) "kukaan" käyttänyt tuolloin..

Niinpä.

Windows XP tuli vasta vuonna 2001, ja vasta sen myötä NT-pohjaisia windowseja alettiin tosissaan asentaa kuluttajakoneisiin.

Alunperinhän 2000sta piti tulla se ensimmäinen "kuluttajakelponen NT-pohjaimen" mutta pelien toimivuus sillä vielä liian huonoa ja taisi muistivaatimuksetkin olla vielä vähän runsaanlaisesti vuoden 2000 halpiskoneisiin joten sitten julkaistiin sen rinnalle kuluttajille vielä 98n cripplattu versio Windows Me, joka ei siis tuonut juuri mitään hyödyllisiä parannuksia 98iin verrattuna mutta poisti joitain 98n hyödyllisiä ominaisuuksia.
 
En muista juuri missään olleen windows 2000. Windows ME oli vielä harvinaisempi. Taisi tarjota aika vähän windows 95/98 päälle mitään. XP tulikin sitten rytinällä ja oli verrataen pitkään käytössä, en ihmettelisi jos vieläkin jollain/jossain.
 
Tuo merkistökeskustelu on siinä mielessä ihan ketjun aiheen mukaista, että se tosiaan on paikoitellen yksi digitalisaation miinussarakkeessa näyttäytyvistä asioista vielä tällä hetkellä.

Monet "pomminkestävät" pankkijärjestelmät ja niiden väliset integraatiot on kuitenkin alunperin rakennettu sellaiseen aikaan ja sellasilla menetelmillä, ettei niitä ole saatu (tai ei ole kannattanut) järkikustannuksilla päivitettyä vastaamaan tätä nykyistä "digiloikkaa". Mm. pankkitapahtumien osalta on keskitytty siihen, että summa ja aikaleima on ok ja että tapahtuman nimikirjauksen osalta riittää että se on kuosissaan jollakin tietyllä merkistöllä, eikä ole niinkään välitetty siitä, että joskus tulevaisuudessa joku pahoittaa mielensä siitä, ettei mobiilisovelluksen näyttämässä transaktiossa oleva nimi vastaa haluttua kirjoitusasua sillä tiliotteella, joka on jossakin toisaalla kaiveltu kannasta käyttäen jotain ihan eri merkistöä.

Tämä ei kuitenkaan ole minkään yksittäisen pankin omien viritysten ongelma, vaan laajempi ja hiljalleen korjautuva tilanne, jonka kanssa pystyy elämään. Ja mistäs sitä tietää, vaikka EU laittaisi ensi vuonna tulille jonkin vekkulin direktiivin, joka määrää kaikki toimijat laittamaan tämän kuntoon jollakin 12kk siirtymäajalla. Se voi maksaa muutaman miljardin, mutta onpahan sitten lokit kunnossa. :D
 
Tuo merkistökeskustelu on siinä mielessä ihan ketjun aiheen mukaista, että se tosiaan on paikoitellen yksi digitalisaation miinussarakkeessa näyttäytyvistä asioista vielä tällä hetkellä.

Monet "pomminkestävät" pankkijärjestelmät ja niiden väliset integraatiot on kuitenkin alunperin rakennettu sellaiseen aikaan ja sellasilla menetelmillä, ettei niitä ole saatu (tai ei ole kannattanut) järkikustannuksilla päivitettyä vastaamaan tätä nykyistä "digiloikkaa". Mm. pankkitapahtumien osalta on keskitytty siihen, että summa ja aikaleima on ok ja että tapahtuman nimikirjauksen osalta riittää että se on kuosissaan jollakin tietyllä merkistöllä, eikä ole niinkään välitetty siitä, että joskus tulevaisuudessa joku pahoittaa mielensä siitä, ettei mobiilisovelluksen näyttämässä transaktiossa oleva nimi vastaa haluttua kirjoitusasua sillä tiliotteella, joka on jossakin toisaalla kaiveltu kannasta käyttäen jotain ihan eri merkistöä.

Tämä ei kuitenkaan ole minkään yksittäisen pankin omien viritysten ongelma, vaan laajempi ja hiljalleen korjautuva tilanne, jonka kanssa pystyy elämään. Ja mistäs sitä tietää, vaikka EU laittaisi ensi vuonna tulille jonkin vekkulin direktiivin, joka määrää kaikki toimijat laittamaan tämän kuntoon jollakin 12kk siirtymäajalla. Se voi maksaa muutaman miljardin, mutta onpahan sitten lokit kunnossa. :D
Pankeissahan edelleen käytetään päivittäisessä työssä jotain 80-lukulaisia jonkin emuloinnin kautta pyöriviä DOS-sovelluksia (ei mitään hiiritukea, täysin tekstipohjaista). "If it works" jne.
 
mun mielestäni ainakin nordean ja osuuspankin sivut meni huonoiksi uudistuksen jälkeen. OP on käyttökelpoinen vaikka huono, mutta Nordea oli niin sietämätöntä kuraa, että lopetin tilin. Osaan toki sanoa vain aasiakas kokemuksen, enkä tiedä onko huonous design vai tekniikkapuolella vai molemmissa.
...
Nordean kehittäjät siis voittivat asiakaskokemuksen tuhoamistaistelun, vaikka kaikkeni yritin puolustaa itseäni ja etsiä pakoreittejä hyvään asiakaskokemukseen.
Tietääkö joku, miksi Nordean piti väenväkisin korvata oikein hyvin toiminut Solo tällä uudella Netbank-kötöstyksellä? En osaa nimetä yhtään elementtiä, joka toimisi Netbankissa paremmin kuin Solossa. Kaikki on hidasta ja kankeaa. Osittain Netbank on käyttäjälle suorastaan vaarallinen: sillä on esim. helppo jättää laskuja vahvistamatta huomaamatta eikä se ymmärrä summien syötössä desimaalipistettä (12.79 -> 79€).

Miten laadunvalvonta on voinut pettää näin pahasti, että ilmeisen huono Netbank on pakotettu kaikille?
 
Pankeissahan edelleen käytetään päivittäisessä työssä jotain 80-lukulaisia jonkin emuloinnin kautta pyöriviä DOS-sovelluksia (ei mitään hiiritukea, täysin tekstipohjaista). "If it works" jne.

Höpöhöpö. Kaikki tekstipohjainen ei tarkoita DOSia.

OS/2:lla oli jossain vaiheessa nichensä pankkimaailmassa. Lisäksi käytännössä kaikissa PC-maailmaa järeämmissä järjestelmissä on käytetty hyvin paljon tekstipohjaisia käyttöliittymiä.

Ja edelleen uusissakin windowseissa on tuki komentoriviohjelmille, joilla ei ole mitään tekemistä minkään DOS-emulaation kanssa.
 
Tietääkö joku, miksi Nordean piti väenväkisin korvata oikein hyvin toiminut Solo tällä uudella Netbank-kötöstyksellä? En osaa nimetä yhtään elementtiä, joka toimisi Netbankissa paremmin kuin Solossa. Kaikki on hidasta ja kankeaa.

Uusi huomattavasti parempi kuin vanha. Vanha ei ollut responsiivinen ja monelta osin saavutettava. Uusi kummassakin suhteessa paljon parempi. Uusi on käyttökokemukseltaan paljon lähempänä myös mobiilisovellusta jolloin niiden käyttäminen ristiin on monelle helpompaa. Vanha oli kaikella tavalla vanhentunut ja luultavasti hankala ylläpitää ja kehittää uusia ominaisuuksia. Ulkonäkö omasta mielestäni uudessa parempi mutta on toki subjektiivista. Vanha oli raikas tuulahdus 90-luvun webbidesignista joten en ihmettele että brändäyksen takia myös haluttiin siirtyä 2000-luvulle.

Osittain Netbank on käyttäjälle suorastaan vaarallinen: sillä on esim. helppo jättää laskuja vahvistamatta huomaamatta eikä se ymmärrä summien syötössä desimaalipistettä (12.79 -> 79€).

Miten laadunvalvonta on voinut pettää näin pahasti, että ilmeisen huono Netbank on pakotettu kaikille?

Kyllähän voi käyttää pilkkua tai pistettä desimaalierottimena. Juuri testasin ja kumpikin toimivat. Verkkopankki konvertoi erikoismerkit pilkuksi ja esim. "k" tai "m" kertovat summan 1000:lla tai 1000000:lla vastaavasti.

Millä tavalla sinulla jää laskut vahvistamatta? Ei ole koskaan käynyt itselleni noin.

Laadunvalvonta näyttää pelaavan hyvin. Sekä webbi- että kännysovellusta on ilo käyttää ja kaikki asiat hoituvat niillä helposti.

Jos tulee jatkoja, niin johonkin toiseen ketjuun. Tämä ei liity digitalisaatioon.
 
Tietääkö joku, miksi Nordean piti väenväkisin korvata oikein hyvin toiminut Solo tällä uudella Netbank-kötöstyksellä? En osaa nimetä yhtään elementtiä, joka toimisi Netbankissa paremmin kuin Solossa. Kaikki on hidasta ja kankeaa. Osittain Netbank on käyttäjälle suorastaan vaarallinen: sillä on esim. helppo jättää laskuja vahvistamatta huomaamatta eikä se ymmärrä summien syötössä desimaalipistettä (12.79 -> 79€).

Miten laadunvalvonta on voinut pettää näin pahasti, että ilmeisen huono Netbank on pakotettu kaikille?

Eiköhän se ole sama kuin muussakin, että käyttöliittymä ja toiminnot pitää yksinkertaistaa mobiilisovelluksen tasolle. Tuo on kyllä vanhaan verrattuna hävyttömän hidas selaimella käytettäessä. Lisäksi tilitapahtumia pääsee kätevästi tarkastelemaan vain viime vuoden puolelle saakka ja muita pieniä älyttömyyksiä. Ehkä tässä vaan luodaan uusia mahdollisuuksia esitellä vanhoja ominaisuuksia sitten uusina.
 
Missäs pankeissa moisia on käytössä ja kuka niitä siellä käyttää?
Pankkiirit. Sen tarkemmin en pankkia kerro NDA:sta johtuen.
Höpöhöpö. Kaikki tekstipohjainen ei tarkoita DOSia.

OS/2:lla oli jossain vaiheessa nichensä pankkimaailmassa. Lisäksi käytännössä kaikissa PC-maailmaa järeämmissä järjestelmissä on käytetty hyvin paljon tekstipohjaisia käyttöliittymiä.

Ja edelleen uusissakin windowseissa on tuki komentoriviohjelmille, joilla ei ole mitään tekemistä minkään DOS-emulaation kanssa.
Oli mitä oli niin 80-luvulta on sovelluksen copyright-merkintä ja minkäänlaista hiiritukea ei ole vaan mennään täysin tekstipohjaisesti näppäimistöllä.
 
OS/2:lla oli jossain vaiheessa nichensä pankkimaailmassa. Lisäksi käytännössä kaikissa PC-maailmaa järeämmissä järjestelmissä on käytetty hyvin paljon tekstipohjaisia käyttöliittymiä.
Niin oli, ja OS/2 oli erinomaisen robusti käyttöjärjestelmä (vähän NT:n tapaan). Se oli ehkä vähän oikukas saada asennettua mutta kun laitteet olivat sellaiset, joita käyttis oikeasti tuki, niin se ei pahemmin kaatuillut. Se lienee harvoja PC-käyttiksiä, jotka ovat käyttäneet tehokkaasti hyväksi Intelin prosessorien kehäsuojauksia (ring model). Laiteajurit eivät periaatteessa pystyneet kaatamaan kerneliä.

Tekstipohjaisilla käyttöliittymillä on paikkansa, kun pitää tehdä tarkoin speksattuja, verraten yksinkertaisia asioita, luotettavasti. Niiden toteuttaminen on kevyttä eikä vaadi miljoonaa riviä bugista koodia arvaamaan mihin käyttäjä ehkä täppäsi sormella vai täppäsikö.

On oma digitalisaatio-ongelmansa, kun rautaympäristöt, joille on toteutettu laajojakin tietojärjestelmiä lahoavat alta. Softa tekisi edelleen juuri sitä, mitä varten se on hankittu mutta milläpä ajat, kun mistään ei saa enää uutta rautaa.

Eiköhän se ole sama kuin muussakin, että käyttöliittymä ja toiminnot pitää yksinkertaistaa mobiilisovelluksen tasolle. Tuo on kyllä vanhaan verrattuna hävyttömän hidas selaimella käytettäessä. Lisäksi tilitapahtumia pääsee kätevästi tarkastelemaan vain viime vuoden puolelle saakka ja muita pieniä älyttömyyksiä. Ehkä tässä vaan luodaan uusia mahdollisuuksia esitellä vanhoja ominaisuuksia sitten uusina.
Sama mielikuva on tullut, että on väkisin yritetty pakottaa mobiilisovellusta myös työpöydälle. Mm. tilankäyttö työpöydällä on holtitonta, joskin se on vähän parantunut.

Kiitos, että muistutit tilitapahtumien selailusta. Argh. :rage:
Jos tilillä on harvakseltaan tapahtumia, se vain tyhmänä kertoo, että ei tapahtumia xx-kuussa, ei sitä, milloin tilillä on ollut tapahtumia.
 
Tietääkö joku, miksi Nordean piti väenväkisin korvata oikein hyvin toiminut Solo tällä uudella Netbank-kötöstyksellä? En osaa nimetä yhtään elementtiä, joka toimisi Netbankissa paremmin kuin Solossa. Kaikki on hidasta ja kankeaa. Osittain Netbank on käyttäjälle suorastaan vaarallinen: sillä on esim. helppo jättää laskuja vahvistamatta huomaamatta eikä se ymmärrä summien syötössä desimaalipistettä (12.79 -> 79€).

Miten laadunvalvonta on voinut pettää näin pahasti, että ilmeisen huono Netbank on pakotettu kaikille?
Tukee ajatusta mikä osakevälitys ja säilytyspalveluita heiltä ostaneena syntyi. Nordea on sellanen markalla markan tavara- pankki. Verrattain edullista oli kaikki mutta oli kyllä paskaakin.
 
Huvittavasti poissuljetaan käytännössä koko 90-luku kuitenkin. Ei noita NT-pohjaisia (joka tässä lienee oli se erottava tekijä?) "kukaan" käyttänyt tuolloin..
Kannattaa nyt erottaa yritys- ja kuluttajakäyttö. Jos kuluttajalla on 9x-laite kotona eikä välttämättä kiinni internetissä tai korkeintaan modeemilla pari tuntia viikossa, sen laitteen verkostovaikutus on aika pieni. 90-luvulla meille tuli kouluun atk-luokat ja työasemat yhdistävä palvelin oli NT-pohjainen alusta asti ja tiedostot ntfs-levyllä wide-koodattuina. Kun koulussa vaihdettiin 9x-työasemat 2k:ksi joskus vuosituhannen vaihteessa, mikään ei muuttunut säilöttävän datan muodossa. YMMV. NT 3.x-palvelimia en ole nähnyt käytössä, mutta kyllä NT 4.0 oli jo kohtalaisen yleinen. Myös OS/2 näkyi käytössä mm. oikeusministeriössä, mutta siinäkin on eri merkistöt (esim. 850) kuin Windows-koneissa (win-1252), joten merkistöasiat piti tiedostaa ihan eri tavalla.

Toinen aspekti on se, miten oman systeemin merkistö vaikutti muuhun maailmaan. Esim. ysärillä jos teit kotisivut, tiedostot ladattiin yleensä ftp:llä palvelimelle ja palvelimella oli "unix-merkistö". Jos siirsit ääkkösellisiä tiedostoja soneran/saunalahden servulle, tuli tod.näk. 404:ää vastaan. Eli koodisivujen vaikutus oli eristetty ja palvelimet toimivat eri merkistöllä (joka ei siinä kohtaa tod.näk. ollut unicode, mutta kuitenkin erillinen työaseman vastaavasta). Samoin jos menit nettisivulle, urleissa ja domain-nimissä ei ollut ok käyttää 8-bittisiä laajennettuja merkkejä. Webbisivujen sisällön merkistön pystyi määrittämään tagilla, joskin ysärillä netti oli aika villi länsi eikä itseoppineilla webbiguruilla ollut hajua webbistandardeista. Nyt jos 2024 kokeilisit surffata nettiä windows 9x -koneella ja siihen vaan saisi modernin webbiselaimen niin sillä koneen merkistöllä ei ole niin väliä kun selain eristää nämä asiat toisistaan ja renderöi sivut webbistandardien mukaisesti.

En yrittänyt kiistää sitä että muitakin merkistöjä oli ja edelleen on paljon vaivana, mutta näitä asioita on tiedostettu oikeasti jo yli neljä vuosikymmentä ja niissä järjestelmissä, joilla on tulevaisuuden kannalta merkitystä, on jo todella pitkään pyritty korjaamaan tilanne. Peruskäyttäjällä on tosi harvoissa paikoissa vastassa koodisivuja. Oikeastaan cmd.exe ja windowsilla käytetyt sd/usb-mediat fat-formatoinnilla ja zip-tiedostot on ainoita, mitä heti tulee mieleen.
 
Höpöhöpö. Kaikki tekstipohjainen ei tarkoita DOSia.

OS/2:lla oli jossain vaiheessa nichensä pankkimaailmassa. Lisäksi käytännössä kaikissa PC-maailmaa järeämmissä järjestelmissä on käytetty hyvin paljon tekstipohjaisia käyttöliittymiä.

Ja edelleen uusissakin windowseissa on tuki komentoriviohjelmille, joilla ei ole mitään tekemistä minkään DOS-emulaation kanssa.
Käräjäoikeuksissa ajettiin myös OS/2:n päällä terminaalisoftaa, jolla käsiteltiin väestötietoja, rikosasioita yms. Näistä on kyllä aikaa sitten jo vaihdettu graafisiin ympäristöihin ja nuo softat varmasti olivat ihan paikallaan kun aiemmin verkkoyhteydet eivät olleet hirveän nopeita. Tietoturvan kannalta saattoi myös olla oikein hyvä valinta ottaen huomioon miten paljon selaintekniikoissa on ollut aukkoja ja käyttäjillä puutetta tietoturvaosaamisessa. Tuolloinhan sisäverkkojakin oli vielä token ring -tekniikalla. Näistä pakko sanoa, että todella harmikin, että ovat poistuneet, kun tuolla on VTKK:lla varmaan ollut aikoinaan paljonkin talon sisäisiä innovaatioita käyttöliittymäsuunnittelussa, joista ei ole julkaistu minnekään isommin.

Viimeisiä komentorivisoftia mitä olen nähnyt toimistopuolella oli matkatoimiston käyttöliittymä matka-asioiden hoitoon. Näissäkin 2010-luvun puolella workflow vaihtui itsepalveluksi webbiselaimen kautta. Aiemmin marssittiin matkatoimistoon ja siellä sihteeri näppäili hyvin kryptisiä koodeja systeemiin. Muistan että esim. lentokenttien tiedot pystyi näppärästi syöttämään lyhytkoodina. Klientti oli ihan joku windows-ohjelma, mutta tiedot menivät terminaalin kautta jonnekin etäkoneelle.
 
Jopa FAT-tiedostojärjestelmän tukemat ”pitkät tiedostonimet” on alusta asti koodattu 16-bittisellä merkistöllä. En tiedä, onko tämä mikään standardi unicode-koodaus, mutta huomattava parannus vanhoihin 8-bittisiin merkistöihin nähden. Kokonaan toinen asia sitten on, kuinka hyvin ohjelmistot tukivat näitä merkistöjä.
 
Vieläköhän Askolla (vai olikohan Vepsäläisellä?) ja Gigantilla on tekstipohjaiset systeemit käytössä? Ei mitään käsitystä, minkä käyttöjärjestelmän päällä niitä ajet(aan/tiin) kylläkään :think:
 
Vieläköhän Askolla (vai olikohan Vepsäläisellä?) ja Gigantilla on tekstipohjaiset systeemit käytössä? Ei mitään käsitystä, minkä käyttöjärjestelmän päällä niitä ajet(aan/tiin) kylläkään :think:
Ostin sohvapöydän talvella Askolta ja olihan se tuolloin vielä käytössä. Omissa töissä tullut hieman vastaava joskus vastaan tuoteinventaarion modernisointiprojektissa ja tuolloin kyseessä oli IBM AS/400 järjestelmä.
 
Jopa FAT-tiedostojärjestelmän tukemat ”pitkät tiedostonimet” on alusta asti koodattu 16-bittisellä merkistöllä. En tiedä, onko tämä mikään standardi unicode-koodaus, mutta huomattava parannus vanhoihin 8-bittisiin merkistöihin nähden. Kokonaan toinen asia sitten on, kuinka hyvin ohjelmistot tukivat näitä merkistöjä.
Alkuaikoina kai uskottiin, että 65536 code pointia tms. riittää kaikille vähän kuten 640 kB muistia. Sen takia Windowissa ja Javassakin oli UCS-2 -tyylinen (en)koodaus. Sittemmin merkkejä keksittiin lisää ja kävi niin että aiempi 16-bittinen tarviikin välillä 32 bittiä loppujen merkkien koodaamiseen. Tämä aiheuttaa sen että 16-bittinen koodaus ei enää tuekaan helppoa indeksointia ja tuhlaa myös tilaa varsinkin länsimaalaisten kielten kanssa ihan turhaan. Sittemmin UTF-8 on yleistynyt myös Windowsissa ja Javassakin tuli UTF-8 API:n oletukseksi reilu 2 vuotta sitten.

Linuxissa voi FATia käyttää UTF-8:lla. Ei välttis toimi Windowsin kanssa kivasti yhteen, mutta jos käyttää pelkkää Linuxia, niin poistaa joitain FATin ongelmakohtia.
 
Sittemmin UTF-8 on yleistynyt myös Windowsissa ja Javassakin tuli UTF-8 API:n oletukseksi reilu 2 vuotta sitten.

Linuxissa voi FATia käyttää UTF-8:lla. Ei välttis toimi Windowsin kanssa kivasti yhteen, mutta jos käyttää pelkkää Linuxia, niin poistaa joitain FATin ongelmakohtia.
Onko tämä UTF-8 se paske, joka (lopullisesti) rikkoo ikiaikaisen 1 tavu = 1 merkki -oletuksen ohjelmoinnissa? Tämähän tekee merkkijonojen käsittelystä vaikeaa ja voipa olla, että jokunen aikojen saatossa tehty koodinpätkä menee särki. Miten edes allokoit taulukon vaikka 6-merkkiselle stringille?

Ei kai länsi-europpalaisten kielten kanssa ole järkeä käyttää muuta kuin ISO-Latin1:stä?
 
UTF-8 on sangen elegantti ratkaisu vaikeaan ongelmaan, kaukana paskeesta. Sen sijaan ikiwanhat ISO-koodisivut ovat osa ongelmaa, eivät ratkaisua.

UTF-8'ssa merkkijonolla on erikseen merkkimäärä ja tilanvaraus. Näistä tilanvaraus on yleensä merkityksellisempi ja siksi tavallisimmat merkkijonokäsittelyt, kuten strlen, strncpy, strcat jne, ihan C-tasolla toimivat UTF-8'lla luonnostaan oikein. Renderointi ei tietty voi enää olettaa, että jokainen tavu on oma merkkinsä, vaan merkkimäärä <= tilanvaraus. Yhteen merkkiin menee tilanteesta riippuen 1-7 tavua. Siltikin vaikka UTF-8 merkkijonon renderoisi yksittäisen tavun lohkoina, ainoastaan nämä useamman tavun merkit renderoituvat väärin. Normi ASCII payload toimii suorilta, koska se on validia utf-8'aa. Kenenkään ei omaa custom renderointikoodia muutenkaan kirjoittaa.

Merkkijonojen järjestäminen tai upccase/lowcase toimivat about hyvin ihan normi C-kirjaston funkkareilla niin kauan kuin käsitellään länsimaisia merkkejä. Yleisessä tapauksessa vertailuja varten pitää muodostaa collate-key, jota käytetään vertailuun.

Ja sitten jos käytät jotain korkeamman tason kieltä, niin mistään tällaisesta nysvaamisesta ei tarvitse välittää ollenkaan.

Jos jotain tekstilohkoa pitää jatkuvasti iteroida renderoituva merkki kerrallaan, voidaan kyseinen pätkä tietty tallentaa 32-bittisenä unicode code pointteina. Ja sitten (de)serialisoida sisältö UTF-8'ksi esimerkiksi tallennusta varten.
 
UTF-8 on sangen elegantti ratkaisu vaikeaan ongelmaan, kaukana paskeesta. Sen sijaan ikiwanhat ISO-koodisivut ovat osa ongelmaa, eivät ratkaisua.
Eleganttius ottaa merkittävää osumaa, jos/kun olemassaolevaa koodia menee rikki.

UTF-8'ssa merkkijonolla on erikseen merkkimäärä ja tilanvaraus.
Legacy-koodit eivät tiedä tällaisesta mitään vaan ne on kirjoitettu oletuksella 1 tavu = 1 merkki. On vähän vaikeaa arvioida miten paljon tämän oletuksen särkyminen rikkoo koodia. Eihän esim. alimerkkijonoihin pääse enää käsiksi suoraan indeksoimalla (esim. tekstirivillä 5 saraketta vakiopaikoissa ja halutaan poimia 4. sarakkeessa oleva numero ja konvertoida se liukuluvuksi). Hyvin tavallinen tehtävä, kun luetaan tekstitiedostosta dataa sisään. Toki voi pitäytyä ASCII-merkistössä mutta entäs kun 2. sarakkeessa lukeekin "Hyvinkää"?

...siksi tavallisimmat merkkijonokäsittelyt, kuten strlen, strncpy, strcat jne, ihan C-tasolla toimivat UTF-8'lla luonnostaan oikein.
Ihanko varmasti, jos käytetään jotain binääriä (esim. vanha kirjasto), jossa nämä kutsut on inline-optimoitu suoraan assembleriksi? Enää näin ei voi tehdä, jolloin suorituskyky kärsii.

Merkkijonojen järjestäminen tai upccase/lowcase toimivat about hyvin ihan normi C-kirjaston funkkareilla niin kauan kuin käsitellään länsimaisia merkkejä. Yleisessä tapauksessa vertailuja varten pitää muodostaa collate-key, jota käytetään vertailuun.
Ehkä toimii, jos todella kutsutaan jotain funktiota mutta monet merkkijonofunktiot on tehty inline-assemblerina. Ei taida toimia, jos on koodattu jokin toiminnallisuus itse käsin.

Ja sitten jos käytät jotain korkeamman tason kieltä, niin mistään tällaisesta nysvaamisesta ei tarvitse välittää ollenkaan.
C, Fortran?
 
Legacy-koodit eivät tiedä tällaisesta mitään vaan ne on kirjoitettu oletuksella 1 tavu = 1 merkki. On vähän vaikeaa arvioida miten paljon tämän oletuksen särkyminen rikkoo koodia. Eihän esim. alimerkkijonoihin pääse enää käsiksi suoraan indeksoimalla (esim. tekstirivillä 5 saraketta vakiopaikoissa ja halutaan poimia 4. sarakkeessa oleva numero ja konvertoida se liukuluvuksi). Hyvin tavallinen tehtävä, kun luetaan tekstitiedostosta dataa sisään. Toki voi pitäytyä ASCII-merkistössä mutta entäs kun 2. sarakkeessa lukeekin "Hyvinkää"?

Ihanko varmasti, jos käytetään jotain binääriä (esim. vanha kirjasto), jossa nämä kutsut on inline-optimoitu suoraan assembleriksi? Enää näin ei voi tehdä, jolloin suorituskyky kärsii.

Ehkä toimii, jos todella kutsutaan jotain funktiota mutta monet merkkijonofunktiot on tehty inline-assemblerina. Ei taida toimia, jos on koodattu jokin toiminnallisuus itse käsin.

Legacy-ohjelma, joka ei tiedä UTF-8'sta mitään, näkee nuo enkoodatut pätkät tilanvarauksensa mukaisina hivenen pitempinä pätkinä. Pääsääntöisesti tuo ei haittaa mitään. Esimerkiksi tuota tekstitiedostoa (vaikka CSV) parsiessa etsit jonkinlaisia column-markereita, joilla jaat tekstin sarakkeiksi. Nuo löytyvät ihan samalla tavalla kuin ennenkin. Se "hyvinkää" parsiutuu sieltä ihan oikein. strlen() palauttaa sille oikean tilanvarauksen mukaisen arvon, jolla voi tarvittaessa varata oikean määrän muistia. Ja vaikka strncpy kopioi sen varattuun bufferiin oikein, vaikka sovellus ei ole ikinä unicodesta kuullutkaan. Ja ei haittaa, vaikka kaikki nuo olisi inlinetetty binääriin, se strlen on edelleen ihan sama toteutus.

Sitten jos sulla on vaikka legacy tekstieditori, niin toki sillä saa generoitua rikkinäisiä utf-8 payloadeja: menet vaikka lisäämään välilyönnin keskelle tuollaista enkoodattua blobia. Mutta niiden esimerkiksi deletoiminen tai copy-paste toimii ihan oikein. Tällainen käyttötapaus sopii hyvin tilanteeseen, jossa tiedoston payload on pääasiassa ASCII, mutta voi sisältää pieniä määriä muita merkkejä.
 
Unicode on tarpeellinen tapauksissa, joissa saman dokumentin on pystyttävä näyttämään eri kirjoitusjärjestelmien merkkejä, siis esimerkiksi sekä koodisivulta IBM850 että japanilaisten kirjoitusjärjestelmästä löytyviä merkkejä.

Hyöty unicodesta tulee jo ihan siitä, että jokaisen tiedoston mukana ei tarvitse erikseen olla jossain toisaalla metatietona, millä koodisivulla se on kirjoitettu. Ääkköset ja muutkin yli 128'n olevat merkit menevät heti pieleen, jos tietoa siirtäessä lähettäjä ja vastaanottaja käyttävät eri koodisivua. UTF-8 pystyy esittämään kerralla kaikki unicode-speksin määrittelemät merkit, ei pelkkää 256-merkin subsettia. No, meille Suomessa on tuttua jo kymmenien vuosien takaa, että ääkköset voivat mennä pieleen, mutta käytännössä nämä paikat ovat koko ajan vähentyneet. Ja tässä unicode on ratkaisu, ei ongelma. Ongelma ovat nuo toisistaan irralliset 8-bittiset merkistöt.

Ja näinä päivinä tietty ihan mikä teksti vaan voi sisältää vaikka hymiöitä.
 
Hyöty unicodesta tulee jo ihan siitä, että jokaisen tiedoston mukana ei tarvitse erikseen olla jossain toisaalla metatietona, millä koodisivulla se on kirjoitettu. Ääkköset ja muutkin yli 128'n olevat merkit menevät heti pieleen, jos tietoa siirtäessä lähettäjä ja vastaanottaja käyttävät eri koodisivua. UTF-8 pystyy esittämään kerralla kaikki unicode-speksin määrittelemät merkit, ei pelkkää 256-merkin subsettia. No, meille Suomessa on tuttua jo kymmenien vuosien takaa, että ääkköset voivat mennä pieleen, mutta käytännössä nämä paikat ovat koko ajan vähentyneet. Ja tässä unicode on ratkaisu, ei ongelma. Ongelma ovat nuo toisistaan irralliset 8-bittiset merkistöt.

Ja näinä päivinä tietty ihan mikä teksti vaan voi sisältää vaikka hymiöitä.

Puhumattakaan siitä, että noin 2/3 maailmasta käyttää jotain muita aakkosia kuin latinalaisia.
 
Viimeksi muokattu:
Hämmentävää lukea, että joku haikailee suppeita merkistöjä, jotka eivät siis kykene kattamaan edes kaikkia länsieurooppalaisten kielien tarvitsemia merkkejä, puhumattakaan muusta maailmasta. Se, että ohjelmoija on paska eikä kykene toimimaan UTF-8:n kanssa ja on saanut oppinsa 80-luvulla ei ole mikään peruste luopua siitä ja palata johonkin puutteellisen Latin-1:een. Devaaja on hyvä ja siirtyy 2000-luvulle. UTF-8-enkoodaus on todella toimiva ratkaisu, eikä ihme että se on saavuttanut laajan tuen.

Mutta miten ihmeessä tämä nyt sitten liittyy digitalisaatioon? En tiedä. Taas jotain ihme vänkäämistä uusista ja vanhoista protokollista, mikä varmaan kuuluisi jonnekin muualle. EDIT: No ehkä niin, että merkistöongelmat olivat ihan oikea ja paha ongelma digitalisaation alkuvaiheessa: nimet olivat väärin, vieraskieliset sanat oli väärin, piti muuttaa kirjaimia vääriksi ja sen jälkeen samalla sanalla olikin useita kirjoitusasuja ja haku ei toiminut oikein, sama sana näkyi eri tavalla eri käyttäjille jne. UTF-8 ja tietenkin Unicode ovat tuoneet tähän todella hyvän ja toimivan ratkaisun. EI nyt jumalauta kukaan tervejärkinen voi kaivata jotain vanhoja merkistöjä :facepalm:
 
Viimeksi muokattu:
Legacy-koodit eivät tiedä tällaisesta mitään vaan ne on kirjoitettu oletuksella 1 tavu = 1 merkki. On vähän vaikeaa arvioida miten paljon tämän oletuksen särkyminen rikkoo koodia. Eihän esim. alimerkkijonoihin pääse enää käsiksi suoraan indeksoimalla (esim. tekstirivillä 5 saraketta vakiopaikoissa ja halutaan poimia 4. sarakkeessa oleva numero ja konvertoida se liukuluvuksi). Hyvin tavallinen tehtävä, kun luetaan tekstitiedostosta dataa sisään. Toki voi pitäytyä ASCII-merkistössä mutta entäs kun 2. sarakkeessa lukeekin "Hyvinkää"?

Tai jos siinä lukeekin 北京 tai 東京都. Puhumattakaan جِدَّة‎ tai תל אביב. Sitten on toki myös Αθήνα ja Hà Nội.
Suht nopeasti huomataan, että tuollaisia yksinkertaistuksia sisältävät legacy-koodit kuuluvat sinne roskakoriin kaksinumeroisten vuosilukujen ja 32 bittisten aikaleimojen kanssa.
 
Viimeksi muokattu:
Eleganttius ottaa merkittävää osumaa, jos/kun olemassaolevaa koodia menee rikki.

Legacy-koodit eivät tiedä tällaisesta mitään vaan ne on kirjoitettu oletuksella 1 tavu = 1 merkki. On vähän vaikeaa arvioida miten paljon tämän oletuksen särkyminen rikkoo koodia. Eihän esim. alimerkkijonoihin pääse enää käsiksi suoraan indeksoimalla (esim. tekstirivillä 5 saraketta vakiopaikoissa ja halutaan poimia 4. sarakkeessa oleva numero ja konvertoida se liukuluvuksi). Hyvin tavallinen tehtävä, kun luetaan tekstitiedostosta dataa sisään. Toki voi pitäytyä ASCII-merkistössä mutta entäs kun 2. sarakkeessa lukeekin "Hyvinkää"?

Ihanko varmasti, jos käytetään jotain binääriä (esim. vanha kirjasto), jossa nämä kutsut on inline-optimoitu suoraan assembleriksi? Enää näin ei voi tehdä, jolloin suorituskyky kärsii.

Ehkä toimii, jos todella kutsutaan jotain funktiota mutta monet merkkijonofunktiot on tehty inline-assemblerina. Ei taida toimia, jos on koodattu jokin toiminnallisuus itse käsin.

Vanhaa koodia menee jatkuvasti rikki, kun vaatimukset muuttuvat. Esim. merkistöistä jos luet lisää, huomaat että se "vanha" ei ollut 8 bittiä vaan ASCII oli 7 bittiä ja kahdeksas saattoi olla esimerkiksi virheenkorjaukseen pariteetti. 8-bittiset merkistöt kyllä rikkoivat yhteensopivuutta myös jos oletus oli että merkit ovat 7-bittisiä ja esim. kirjaimet ovat väleillä a-z ja A-Z. Ääkköset kun eivät kuulu noihin väleihin. 128 merkkiin on aika paha sovittaa montaakaan kieltä, kun mukana on ohjausmerkkejäkin.

Oikeastaan toit aika hyvin esille parikin virhekäsitystä - C-tyylinen tapa koodata merkkijonot 0-loppuisiksi ilman pituustietoa on tehoton ja tietoturvaongelmille altis paskakoodaus. Samoin tekstin käsittely inline assyllä. Tietoturvasyistä tällainen pitäisi lopettaa kuten myös näitä tekevät koodarit. Toinen pointti on että kovinkaan usein tekstiin ei sovelleta merkkikohtaisella indeksoinnilla hajasaantia vaan teksti käydään läpi kokonaisuutena tai jollain muulla tavalla (esim. rivinvaihdot), jotka kuitenkin vaativat läpikäyntiä. Vaihtelevanpituiset merkit tuovat miinuspuolia, mutta myös etuja. Merkkijonoja kannattaisi C-tyylin sijaan käsitellä aina pituustiedolla, koska vaikka siinä on hieman enemmän kirjanpitoa, strlen-tyylinen nopeutuu O(n)-ajallisesta O(1)-aikaiseksi ja monet oikeasti raskaat operaatiot voi optimoida menemään vektoreilla tai muuten kevyemmällä muistikuormalla, kun ei tarvitse lukea jonoa haarautumisen päättämiseksi.

Digitalisaation kannalta on hyvä jos merkistöt ovat monikäyttöisiä. Se että joku MUMPSin 1960-luvun 8-bittinen paskakoodi toimii vielä 2230 ilman tarvetta muokata jotain 8-bittistä assyä on enemmän joku (kaulaparta)koodarien eroottinen fantasia.
 
Offtopic seis ja keskittykää ketjun aiheeseen, kiitos.
Kun katson ylläolevaa kommentointia, niin minusta alkaa näyttää siltä, että pakkodigitalisaation ydinongelma ei ehkä olekaan analogisen pakottaminen digitaaliseksi vaan yleisemmin kaiken vanhan pakottaminen uudeksi, hinnasta ja seurauksista piittaamatta. Legacy on kirosana ja paskaa riippumatta siitä onko kyse pahvikortistosta, analogisesta radiosta vai VAXille tehdystä, Linuxille portatusta tietokannasta. Pelkkä digitalisaatio ei olekaan riittävää, vaan pitää olla uudenaikaista digitalisaatiota. Lähinnä tällaisesta asennoitumisesta tulee mieleen Maon kulttuurivallankumous, jossa vanha historia tuhottiin aktiivisesti ja yritettiin korvata uudella, kommunistisella tulevaisuudella.

Porukka ilkkuu sille, että uusien maailmanstandardien pakottaminen kaikkeen särkee toimivia tietojärjestelmiä, eikä haitoilla ja kustannuksilla ole väliä. Esim. tällainen, uudenaikaisesti koodattu kartta on tosi hyödyllinen eurooppalaiselle:
Screenshot at 2024-09-11 20-39-01.png
 
...pakkodigitalisaation ydinongelma ei ehkä olekaan analogisen pakottaminen digitaaliseksi vaan yleisemmin kaiken vanhan pakottaminen uudeksi, hinnasta ja seurauksista piittaamatta.
Väärin, ei kukaan ole haluamassa "kaiken vanhan pakottamista uudeksi, hinnasta ja seurauksista piittaamatta". Kyse on siitä, että halutaan vanhentuneiden menetelmien korvaamista tehokkaammilla, nopeammilla, käytettävämmillä ja modulaarisemmilla.

Aina uusi ei tietenkään ole kaikessa parempi, mutta kehitys kehittyy, eikä yleensä kuitenkaan mennä kokonaisuutena taaksepäin, vaikka ei kertalaakista priimaa tulisikaan.

Legacy on kirosana ja paskaa riippumatta siitä onko kyse pahvikortistosta, analogisesta radiosta vai VAXille tehdystä, Linuxille portatusta tietokannasta.
Niin no, lähtökohtaisesti legacy nimenomaan on paskaa, jos ei kyse ole jostakin sellaisesta asiasta, jota ei nykypäivänä ole mahdollista korvata paremmalla. Paikallaan jumittamisen ei pidä olla itseisarvo, eikä varsinkaan jos takana on vain muutosvastarintaa, tai yksittäisten dinosaurusten vanhoillisia ajatusmalleja.
 
Väärin, ei kukaan ole haluamassa "kaiken vanhan pakottamista uudeksi, hinnasta ja seurauksista piittaamatta". Kyse on siitä, että halutaan vanhentuneiden menetelmien korvaamista tehokkaammilla, nopeammilla, käytettävämmillä ja modulaarisemmilla.
Tuolta se käyttäjälle monesti näyttää että pääasia että vaan uudistetaan. Sen lisäksi kun ne uuden järjestelmän opettelut tulee muiden töiden päälle eikä muita töitä korvaavasti. Hyödytkin jää kysymysmerkiksi käyttäjälle kun pääsääntöisesti käyttöliittymät nykyisin huononee, mikä taas tekee valtavia kustannuksia kun kukaan ei osaa käyttää, ja päivityksessä valikot sotketaan tms.

Ainakin itsellä on ollu ainakin 15 vuotta väsymys turhanpäiväiseen opetteluun erityisesti tietotekniikan kanssa...joskus teininä vielä jaksoi.
 
....

Porukka ilkkuu sille, että uusien maailmanstandardien pakottaminen kaikkeen särkee toimivia tietojärjestelmiä, eikä haitoilla ja kustannuksilla ole väliä. Esim. tällainen, uudenaikaisesti koodattu kartta on tosi hyödyllinen eurooppalaiselle:
Screenshot at 2024-09-11 20-39-01.png

Nyt ei tuo karttajuttu avaudu, png kuvatiedosto, otsikkoon liittyen haikailetko paperisia.
Digitaaliset kartat ovat olle vuosikausia ihan muuta kuin pikselikuvatiedostoja.


Mutta pitää kuitenkin olla metatieto siitä, että se on unicodea - ja myös siitä, mitä unicoden tyyppiä ja versiota se on. Mikään ei siis ole muuttunut.
....
Ymmärsin että moderointi nimenomaan kielsi merkistö keskustelun

Offtopic seis ja keskittykää ketjun aiheeseen, kiitos.
 
Nyt ei tuo karttajuttu avaudu, png kuvatiedosto, otsikkoon liittyen haikailetko paperisia.
Digitaaliset kartat ovat olle vuosikausia ihan muuta kuin pikselikuvatiedostoja.
Veikkaan että tuossa oli pointti että nuo paikkojen nimet on paikallisilla koukeroilla eikä latinalaisilla aakkosilla. Eli merkistöjuttua tämäkin.
 

Statistiikka

Viestiketjuista
275 300
Viestejä
4 741 956
Jäsenet
77 314
Uusin jäsen
Lukrula

Hinta.fi

Back
Ylös Bottom