Joo tämä on totta. Sama Linuxissa että moni ohjelma käyttää saman alkuperän khtml/webkit-komponentteja, mutta se ei ole sama mikä chromiumissa. Kuitenkin tuo yhteinen pohja tekee näistä isomman monokulttuurin, kun niillä on jotain yhteisiä piirteitä, mitä Geckossa ja vastaavissa ei ole.
Kokeilitko Slackwaren (32-bittisellä) Seamonkeyllä? Muistelen että kyseessä voi olla testaus sillä. Seamonkey on hieman jäljessä muista kun sivulla lukee uusimmassa versiossa muutoksissa: "SeaMonkey 2.53.19 uses the same backend as Firefox and contains the relevant Firefox 60.8 security fixes. Additional important security fixes up to Current Firefox 115.14 and Thunderbird 115.14 ESR plus many enhancements have been backported". Firefox 60.8 on julkaistu 2019-03-18 ja tuo 115.14 2024-08-06. Eli tuo selain käyttänee 5,5 vuotta vanhaa engineä, johon on poimittu käsin 5v sen jälkeen julkaistuja tietoturvakorjauksia, muttei ihan uusimpia viimeisen 3 kuukauden aikana julkaistuja. Se ei välttämättä renderöi samalla tavalla kuin nuo uusimmat selaimet. Nythän mennään jo Firefox-versiossa 132.
Itse taas olen sitä mieltä, että sinä teet tulkinnasta vähän omia kärjistyksiä. Jos siinä sanotaan että "wide variety of user agents", niin kyllä se antaa mun mielestä enemmän sijaa laveampaan tulkintaan.
En voi kuin oudoksua tätäkin valitusta. Itse en fb:tä käytä ollenkaan (koska syyt) mutta kyseessä on kuitenkin yritys jonka tulee tuottaa omistajilleen voittoa.
Nykyäänhän suurin osa selaimista on suunnilleen Chrome eri kuorissa. Mutta itsehän mainitsit että VAIN noilla mainitsemillasi neljällä selaimella toimii mutta toimiikin kuitenkin muillakin Chromen sukulaisilla. Ihan hirveän montaa nykyaikaista ja ajantasalla olevaa selainta ei varmaan ole millä facebook ei toimisi ainakin suunnilleen oikein, ellei sitten jotain erikoisempia virityksiä lasketa. Joku Seamonkey esimerkiksi alkaa olla jo vähän mainstream-selainten ulkopuolella. Kyllä FB haluaa että mahdollisimman moni heidän palveluaan käyttää joten tahallaan eivät mene rikkomaan tukea yleisimmin käytetyille selaimille.
Tämä ei ole kyllä totta. Esim. Wikipediasta: "SeaMonkeyn selainkomponentti käyttää samaa renderöintiohjelmistoa kuin Firefox, joten SeaMonkey tukee kaikkia samoja WWW-standardeja kuin Firefox."
Kyllähän tuo CloudFlaren "Verify you are human" -tarkistus toimii kaikilla yleisimmillä selaimilla (Chrome/Chromium-pohjaiset, Firefox ja Safari), joiden markkinaosuus on yhteensä jotain yli 95%. Joku SeaMonkey edelleenkin on marginaaliselain joka pohjautuu johonkin kivikautiseen engineen joten ei kannata ihmetellä jos sellaisen kanssa on ongelmia. Se on ihan oma vikasi että käytät tuollaisia ei-tuettuja selaimia.
Tavallinen tallaaja tuskin käyttää mitään 0.02% markkinaosuudella olevaa selainta kuten SeaMonkey vaan todennäköisemmin Chromea, Edgeä, Firefoxia tai Safaria, ehkäpä jopa jotain Bravea, Operaa tai Vivaldia. Noiden selaimien kanssa tuskin tulee ongelmia CloudFlaren sun muiden vastaavien kanssa. CloudFlare ihan syystäkin blokkailee kaikenlaisia outoja useragent-stringejä käyttäviä selaimia, kaikenlaisissa DDOS-skripteissä kun useragenttina on yleensä jotain ihan randomia niin niiden suodattaminen kannattaa.
Toimiipas. Viimeisen 20-25 vuoden ajan on puhuttu selainten turvallisuudesta. Ja netin käytössä on viime pelissä kyse turvallisuudesta maailman liikkuessa tähän aikaan.
Itse olen käyttänyt linuxia about 20v daily driverinä eikä kertaakaan ole tuollaista ongelmaa tullut vastaan Firefoxilla, Chromella, Operalla tai Vivaldilla, joten kyllä se ongelma jossain muualla on kuin linux-käyttäjien syrjimisessä. Tai ehkä nuo selaimet vaan osaavat tuon useragentin määritellä oikein, toisin kuin käyttämäsi meriapina.
Itsekin olen Linuxia käyttänyt pääasiassa reilut 20 vuotta ja yleisesti voi sanoa, että selaimet ovat toimineet ihan ok. Ennen vanhaan oli noita ongelmia, kun jotkut videot vaativat binäärisiä Windows-koodekkeja (puhutaan jostain ajasta 2000-2007 tjsp). Joku C#/VB/ASP-skripti ei suoriutunut Linuxissa ymmärrettävästä syystä. Joissain flash-applikaatioissa oli ongelmia, esim. kova kaatuilu. Muistaakseni web-kameran jako ei toiminut Omeglen tapaisissa jossain vaiheessa Flashin kautta, mutta Flashin loppuaikoina sitten toimikin (NPAPI sitten alkoikin poistua 2013 alkaen). Joku ehkä muistaa näistä.
Firefox näyttäisi ilmoittavan olevansa "Mozilla/5.0 (X11; Linux x86_64; rv:133.0)" ja ei ole ollut ongelmia Cloudflaren kanssa, eli ehkä kyse on jostain muusta?
Ymmärrän kyllä tuohtumisesi. Ei marginaaliselaimen käyttö ole mikään syy estää pääsyä sivustoille. Tuntuu, että keskustelijoilta menee koko pointti ohi, kun aletaan haukkumaan selainta ja selaimen käyttäjää siitä että markkina-asemaansa väärinkäyttävät firmat perseilee.
Ota nyt huomioon, että kyse on marginaalikäyttiksestä ja marginaaliselaimesta sillä käyttiksellä. Esim. suosittu Arch Linux ei tarjoa pakettia lainkaan Seamonkeylle. Se pitää itse kääntää lähdekoodista. Linuxia käyttää pari prosenttia webin käyttäjistä ja Seamonkeytä taas pari prosenttia Linux-käyttäjistä. Kyse on todella harvinaisesta selaimesta. Tuolta marginaalista löytyy iso joukko selaimia, jotka eivät ole "riittäviä" nykyaikaisen webin selaamiseen. Muistaakseni dillo-selaimesta esimerkiksi puuttui https-tuki pitkään. Jos selain ei tue kryptattua yhteyttä, haluat siis että koko internetin pitää tarvittaessa toimia selkokielisenä? Kuulostaa aika huonolta esim. verkkopankkien osalta.
Ei se ole edelleenkään se pointti tässä, onko selain hyvä vai ei, tai renderöityykö se sivu siihen "oikein". Ei sillä ole mitään merkitystä. Kuten kirjoitin, en odota, että sivustojen pitäisi erikseen tukea näitä selaimia. Riittää, ettei niiden käyttöä estetä. Se, että toimiiko se sivu sitten siinä selaimessa, on eri asia.
Sinä olet tässä ihan toisen käyttäjän mutuilun varassa. Tuosta toimimattomuudesta ei ole tehty mitään tarkkaa analyysiä. Se voi johtua ihan vaan jostain yksittäisestä bugista selaimessa ja olla täysin tuon selaimen ja sen nykyisen version vika.
Ei mihinkään kieleen ole tullut mitään uutta, jota ei voisi jo toteuttaa vuoden 1945 Plankalkülillä. Toisto, valinta ja sekvenssi riittävät, mutta tuo on ihan turhaa saivartelua. Uutta on sen jälkeen kiihtyvällä vauhdilla kehitetty 80 vuotta ja kaiken uuden vastustaminen on vähän myöhäistä tässä kohtaa kehitystä. Olisi kannattanut syntyä 1800-luvulla, jos olisi halunnut 2. maailmansodan aikaan vaikuttaa ensimmäisten symbolisten ohjelmointikielten kehitykseen.
Niin mistä rajapinnoista on kyse? Firefoxiin tuli esim. versiossa 25 tuki Web Audio API:lle. Tämä on siis standarditapa käsitellä audiota. Sitä ennen Firefoxilla oli oma ei-standardi tapa käsitellä audiota. Ymmärrätkö tahallaan väärin mistä on kyse. Web Audio API toimii kaikilla selaimilla ja aiemmin jokaiselle tarvi oman, mahdollisesti erilaisen API:n. Kyse on taas yli 10 vuotta vanhasta standardista, joten tuki lienee tässä kohtaa kaikissa selaimissa. Ehkä ei Seamonkeyssä, mutta noissa mitä 99% ihmisistä käyttää.
Niin no koita nyt tehdä itsellesi ensin selväksi, mitä niistä API-versioista kannatat. Normaalisti kun porukka käyttää noita kirjastojen kautta, se kirjasto voi toteuttaa polyfillit niin, että sekä uusi että vanha API ovat samaan aikaan tuettuja. Onhan tässä selkeä etu. Se standardi-API on toiminut 2013 asti, mutta jos haluat tukea myös vuosien 2011-12 Firefoxia, onnistuu sen kirjaston kautta samalla kun uudemmat ovat tuettuja.
Totta. Olen kuitenkin törmännyt vastaaviin ongelmiin ajantasaisen Firefox ESR:n kanssa, kun jokin sivusto on nyt vain päättänyt ettei niille pääse kuin "uusimmilla" selainversioilla. ESR on LTS, eli ei sitä uusinta uutta bugeineen, mutta tietoturvapäivitykset pitäisi olla kunnossa.
Se on selaimen ongelma tukeeko se näitä rajapintoja tai muita kilkkeitä. En vaadi, että sivustojen pitäisi tarjota salaamatonta http:tä tai ottaa Lynxin käyttäjät huomioon. Kunhan niitä ei etukäteen estetä.
Mielestäni viranomaissivuja pitäisi todella voida lukea vaikka OS/2 Warpin selaimella. Kuten tässäkin ketjussa joku kirjoitti, Trafin sivut ovat nykyään täynnä JS-valikkoja, ettei hakukoneetkaan osaa indeksoida niitä. Se on kansalaisten tiedonsaannin kannalta melko surkeaa toimintaa. Varsinainen asiointi tietysti vaatii salattua yhteyttä.
Joo, tämä on iso epäkohta, koska tuo ESR on monessa paikassa käytössä ja käyttäjillä ei ole mahdollisuutta välttämättä tehdä asialle mitään.
On se ideana ihan ok, mutta tuossa on se ongelma, että noihin implementaatioihin voi liittyä rajoitteita, jotka kuitenkin tekevät asian mahdottomaksi käytännössä, koska niin monta teknologiapinon tasoa on mennyt uusiksi. Haluat ehkä, että OS/2:lle olisi teoriassa mahdollista toteuttaa selain, joka toimisi, mutta jotta ylipäänsä pääsisi siihen pisteeseen, on monta alemman tason ongelmaa ratkottavana.
Tuo on asiakkaan pään ongelma, ei sivuston ylläpitäjän. Ajurit löytyy kyllä yleisimpiin Ethernet-verkkokortteihin.
Salaus on tässä se isoin ongelma. Asia jäi mietityttämään, joten kokeilin piruuttani avata Finlexiä OS/2 Warpin mukana tulleella Netscape 2.02 selaimella ja sain vain virhekoodin 1010. Kokeilin myös Netscape 4.61:lla ja se ilmoitti ettei ole yhteensopivia salausalgoritmeja.
Eikö nuo nyt olisi mitä otollisimpia väärennetyn informaation syöttökohteita mitm-hyökkäyksille?
Voi olla. Pidän kuitenkin riskiä kovin teoreettisena. Tuomarin pitäisi huolehtia siitä, että käyttää https-yhteyttä.
Ihan hyvää pohdintaa ja tässä lienee yleinen paradigman muutos. Joitain vuosia sittenhän https oli niin harvinaista herkkua, että jossain kauppasivuillakin kaikki muut vaiheet oli ilman, paitsi se maksuvaihe ja siitäkin ihan kriittinen viimeinen osuus. Veikkaan että nykyään voi olla ihan sekin, että osa kehittäjistä ei ymmärrä oikein tuota yhteysmuodon vaihtelua, frameworkit voi edellyttää http/2 + tls-komboa eri tavoin ja arvostetaan yksityisyyttä enemmän, joten asia on yksinkertaisempi näin. Ja asiakaskoneilta odotetaan suht. uutta selainohjelmistoa. Tätä helpottaa se, että selaimet ja käyttikset päivittävät itseään automaattisestikin. Ei salaus varmastikaan ole pakollinen tällaisiin.
Maailma on paljon muuttunut, mutta vielä kun roaming on paikoin kallista, tuo salaus oletuksena on ihan mukava niille, jotka surffaavat kahviloissa, lentokentillä yms. wifin varassa. Vpn-firmat tietysti ovat eri mieltä, mutta moni loppukäyttäjä arvostaa, kun liikenne toimii käyttäjää kunnioittavalla tavalla lähtökohtaisesti. Ja kyllähän operaattoreitakin voi kiinnostaa liiketaloudellisista syistä seuloa, mitä liikennettä asiakkaat tuottavat. Joissain maissa poliisit ovat vähän yliaktiivisia jne.
Pidän salauksen yleistymistä lähtökohtaisesti ihan hyvänä asiana. Sen automaattista uudelleenohjausta voisi kuitenkin enemmän harkita tapauskohtaisesti.
Se on pakko tehdä noin, koska yksi palvelin (tai ehkä pitäisi puhua IP-osoitteen omaavasta palvelusta) voi tarjota useamman eri sivuston sisältöä asiakkaalle. Eli TCP:n lähde- ja kohdetiedot eivät noissa tapauksisa riitä yksilöimään sitä miltä sivustolta asiakas haluaa dataa ladata.
superpark.fi
Näyttäisi olevanVerkkokauppa Vantaa - SuperPark Finland
kertokaas onko sivusto oikeasti niin paskasti toteutettu että mobiililaitteella ei voi valita suomea koska keksi-ilmoitus peitä valinnan? oikeasta yläkulmasta kun avaa valikon niin kielevalinta tulee vasemmalle alas.
Kyllä se minulla ainakin tietää, jos painaa tuosta painikkeesta joka on hotellin esittelytekstin alla. Yläpalkissa olevasta napista painettaessa ei tiedä eikä kyllä pitäisikään tietää, kun se nappi on aina näkyvillä niin olisi epäloogista jos välillä sitä painettaessa tietoja täytettäisiin automaattisesti ja välillä ei (jos vaikka painat etusivulla oltaessa).Taas yksi hyvä esimerkki kehnosta UI/UX-suunnittelusta:
Mene esim. Tampereen Sokos Hotelli Tornin varaussivulle ja paina "Varaa huone", niin systeemi ei tiedä että mihin kaupunkiin ja mihin hotellin mahdollisesti haluaisit varata huoneen. Pikkujuttu tavallaan, mutta sen lisäksi että hinta näyttää tuossa ketjussa olevan yleensä kilpailijoita kalliimpi, niin ainakin minua tällaiset typeryydet vituttavat siinä määrin, että varaan hotellin jo lähtökohtaisesti mieluummin sieltä missä varausjärjestelmä toimii vähemmän urposti.
Jaa nyt tuokin on sitten rikottu. Joskus aikanaan kun duunikeikoilla majoituin paljon hotelleissa niin tuo vielä toimi ainakin tuon valitun hotellin osalta mutta firman sopparihintojen saaminen nettivarauksella vaati kaikenlaisia kikkoja niin rupesin suosiolla varaamaan puhelimitse jos Sokos-hotelliin olin aikomassa mennä kun niin oli paljon helpompi.Taas yksi hyvä esimerkki kehnosta UI/UX-suunnittelusta:
Mene esim. Tampereen Sokos Hotelli Tornin varaussivulle ja paina "Varaa huone", niin systeemi ei tiedä että mihin kaupunkiin ja mihin hotellin mahdollisesti haluaisit varata huoneen. Pikkujuttu tavallaan, mutta sen lisäksi että hinta näyttää tuossa ketjussa olevan yleensä kilpailijoita kalliimpi, niin ainakin minua tällaiset typeryydet vituttavat siinä määrin, että varaan hotellin jo lähtökohtaisesti mieluummin sieltä missä varausjärjestelmä toimii vähemmän urposti.
Pointti oli, että jos menet hotellin sivulle (kliks) ja klikkaat yläpalkin kirkuvan punaisesta painikkeesta "Varaa huone", niin aina tulee tuo sama "valitse hotelli" -virheilmoitus , vaikka olisit minkä S-ketjun hotellin sivulla. Tuon pitäisi tietenkin toimia niin, että se tietää suoraan minkä hotellin sivulla käyttäjä jo on, eikä niin että asiakkaan pitää etukäteen tietää, ettei vahingossakaan klikkaa sitä selvästi silmiin pomppaavaa "Varaa huone" -linkkiä, vaan että pitäisi sen sijaan kaivella sivun muusta sisällöstä joku erillinen linkki. En ymmärrä logiikkaa, jossa asiakas ei haluaisi varata huonetta siitä hotellista, jonka esittelysivua on katsomassa. Edelleenkin, paskaa käyttöliittymäsuunnittelua, kuten koko S-hotellien varausjärjestelmä muutenkin.
Olen miettinyt samaa jo kolmatta vuosikymmentä. Toki enimmäkseen kysymys on mainospaskasta, jota yleensä ei jaksa katsoa vaikka joskus on pakko. Ylipäänsä laiskuus suunnittelussa lienee muutenkin ongelma. Monenkohan ydinvoimalan tai ison kivihiilipannun voima maailmassa menee koiran perseeseen pelkästään sillä, että maailman jokaisessa webbiselainta pyörittävässä koneessa jauhetaan turhaa paskaa? Ongelmahan korostuu siinä, että kaikilla ei ole suhteellisen suorituskykyistä rautaa vaan kaikenlaisia 10 vuoden ikäisiä tai vanhempiakin matopurkkeja jotka ovat bloattisivun edessä polvillaan ja vetävät jokusen hehkulampun verran turhaa tehoa koko sen tökkimisen hidastaman asiointitapahtuman ajan.
Joo ja jos TLS:ää joutuu käyttämään jossakin embedded-laitteessa josta puuttuu rautakiihdytys, niin vielä surkeammaksi menee. Se kättelyoperaatio on aivan järkyttävän raskas ja vetää kyykkyyn kaikki kevyemmät raudat. Kättely saattaa vielä toistua jos yhteys pysyy auki.
Itse en ole tuota sivujen raskautta aiemmin huomannut, nyt ehkä viimeisen puolen vuoden aikana on tuntunut moni sivusto tulevan paljon raskaammaksi adblockin kanssakin. Vielä vuosi sitten ei koneen tuuletin lähtenyt puhisemaan käytännössä koskaan netissä surffailessa, nykyään tuntuu että joka kolmannella sivulla rupeaa tuuletin puhkumaan enemmän tai vähemmän vaikka mainoksetkin on blokattu.
Ei tarvitse rautalangasta vääntää, ymmärsin kyllä heti mistä on kyse ja ymmärrän myös näkökulmasi. Olen vain eri mieltä siitä, että tuo olisi huonoa käyttöliittymäsuunnittelua, koska yläpalkki ja sen painikkeet ovat staattisia elementtejä ilman sidosta itse sivuihin niin minusta olisi hölmöä, että sen painaminen hakisi dynaamisesti juuri sen hotellin tiedot lomakkeeseen mitä sillä hetkellä katsot. Eihän se tarkoita, että käyttäjä haluaa automaattisesti juuri sen hotellin varata mikä sattuu sillä hetkellä olemaan auki. Tätä vartenhan hotellin esittelysivulla on se oma nappinsa juuri sen hotellin varaamiseen. Ongelma tässä on mielestäni siinä, että yläpalkin nappi vie huomion liiaksi eikä hotellin omaa varausnappia meinaa edes huomata.Pointti oli, että jos menet hotellin sivulle (kliks) ja klikkaat yläpalkin kirkuvan punaisesta painikkeesta "Varaa huone", niin aina tulee tuo sama "valitse hotelli" -virheilmoitus , vaikka olisit minkä S-ketjun hotellin sivulla. Tuon pitäisi tietenkin toimia niin, että se tietää suoraan minkä hotellin sivulla käyttäjä jo on, eikä niin että asiakkaan pitää etukäteen tietää, ettei vahingossakaan klikkaa sitä selvästi silmiin pomppaavaa "Varaa huone" -linkkiä, vaan että pitäisi sen sijaan kaivella sivun muusta sisällöstä joku erillinen linkki. En ymmärrä logiikkaa, jossa asiakas ei haluaisi varata huonetta siitä hotellista, jonka esittelysivua on katsomassa. Edelleenkin, paskaa käyttöliittymäsuunnittelua, kuten koko S-hotellien varausjärjestelmä muutenkin.
Sama rautalangasta:
Riippuu tosiaan raudasta jota käyttää, ja olen vaihtelevasti käyttänyt pitkään kaikenlaista vauhtia hyvästä aika astmaiseen muuliin. Ihan viime aikoina ja noin lyhyellä tarkastelyvälillä en ole aiemmasta kehityksestä poikkeavaa muutosta havainnut.
Käsitän että havaintoaineisto kohdistuu yhteen laitteistoon. Onko lokaalin ongelman mahdollisuus suljettu pois? Ettei laite ole saanut sopivasti fyysistä saastaa ilmateihinsä tai haitallista bios/firmispäivitystä, ilmennyt piilevä laitevika?
Tässä varmaan parempi kysymys on miksi ei voisi tulla valmiiksi todennäköisesti oikea(oma oletukseni, ei tutkimusnäyttöä) vaihtoehto?
Tuo tuulettimen käytös on tosiaan tuosta yhdestä koneesta mutta saman sivujen raskaammaksi muuttumisen olen huomannut muillakin laitteilla. Joillakin sivuilla näkee ihan CPUn käyttö -käppyrästä että nyt kuormitetaan konetta reippaasti. Kuitenkin muita ohjelmia käytettäessä koneen CPU-kuorma ja tuulettimen käytös on pysynyt samana joten kyllä tuo aika selkeästi joihinkin nettisivuihin viittaa.
Eipä siinä mitään varsinaista syytä ole, miksi se ei noin voisi toimia. Se, että rikkoisiko tuollainen toiminta (missä sama painike tekee periaatteessa hieman eri asioita) sitten vaikka consistency and standards -heuristiikkaa niin en osaa sanoa. Mutta eipä varmaan kun tässä ero on kuitenkin niin pieni (yhden kohdan automaattinen täyttö lomakkeessa). Tämä on näitä asioita missä taas toinen käyttäjä kokisi tuon toimintamallin "vääräksi" kun sen tietyn hotellin varaamiseksi suoraan on se oma painikkeensa kuitenkin, niin tuossa tulisi taas tälle käyttäjälle yksi ylimääräinen vaihe lisää kun pitäisi joko navigoida pois hotellisivulta tai tyhjentää lomake ensin käsin.
Silloin käyttöliittymä on suunniteltu huonosti, jos se ei ole käyttäjälle intuitiivinen/looginen. Se on ihan sama onko vika väreissä, painikkeiden sijoittelussa, tai missä tahansa.
Kyllähän webbisivut voivat olla aika raskaita nykyään. Itsellä on ollut esim. 500 megan kaapelinetti, 5950X ja 64 gigaa muistia sekä PCIe 4.0 SSD siitä saakka kun noita 5000-sarjan Ryzeneitä alkoi saada. Pitkään tuntunut varsin nopealta kaikkeen hommaan, mutta juuri netin kanssa ekana ilmennyt tällä laitteistolla nykimistä. Siis tarkoitan, että tietenkin uusi rauta vaikkapa kääntää koodia tai koodaa videota nopeammin ja siitä ei ole epäselvyyttä, mutta sillä ei lopulta ole UX:n kannalta merkitystä, montako sekuntia kestää ekstraa, kun nuo on odottamista joka tapauksessa vaativia toimintoja. Netin käytössä taas huomaa haitallista käyttökokemusta nykimistä. Mulla on myös zramia käytössä ja swapin kanssa muistia luokkaa 100 gigaa. Silti pari kertaa Gnome infonnut että OOM killeri tappanut jotain selainprosesseja.
Nettikehityksessähän on lähtökohtaisesti metriikoita, joilla mitataan sivun paremmuutta. Esim. erilaiset lagit osoitteen syöttämisen jälkeen. Se taas on ongelmallinen metriikka, koska nuo ajat on vakioitu kunkin aikakauden koneille ja koneiden nopeus kasvaa jatkuvasti. Kaikki selain/js-enginet nopeutuvat optimointien ansiosta. Esim. Pythonistakin oli juuri uutinen, että 3-30% saatii lisää nopeutta. Samoin nettiliittymien noin yleisesti ottaen. Eli sivukoodille sallitaan joka vuosi enemmän ja enemmän hitautta. Tässä oli hyvä esimerkki parin päivän takaa, kun todettiin että ohjelmistorobotti käsittelee vain 2000 hakemusta päivässä. c10k-ongelma on tänä vuonna 26 vuotta vanha ongelma. c10k siis käsitteli haasteita kun 1999 haluttiin palvella 10 000 yhteyttä samaan aikaan, esim. joka sekunti. Nyt 2025 ollaan 60*60*24*5 kertaa hitaampia, jos ei huomioida raudan kehittymistä mitenkään. Jos huomioitaisiin, tuohon kertoimen 432 000 perään voisi kertoa vielä esimerkiksi 100 000 laskentatehon erosta. Ohjelmistoalalla puhutaan 100x-koodareista, mutta tuossa esimerkissä oikeampi termi olisi 4*10^11x-koodari.
Yleistäen/käjistäen se taitaa nimenomaan olla se kodin raskain juttu minkä mukaan/takia se laite pitää päivittää tehokkaampaa.
www.finnkino.fi
/img-s3.ilcdn.fi/5525bf9a198bd6e3ba35c71318109f1153e12d5b0497b889d1d582950c49d726.jpg)
www.iltalehti.fi
