Tuttu ongelma, nyt siihen puuttuu arvovaltainen taho. Standardointi kusee.
http://news.softpedia.com/news/Linus-Torvalds-Says-Linux-Binary-Packages-Are-Terrible-Valve-Might-Save-the-Desktop-458087.shtml
http://news.softpedia.com/news/Linus-Torvalds-Says-Linux-Binary-Packages-Are-Terrible-Valve-Might-Save-the-Desktop-458087.shtml
Vastaukset 17
Vanhimmat
http://www.mbnet.fi/artikkeli/tietokoneet/linus_torvalds_valve_saattaa_pelastaa_linuxin_tyopoydilla
Samaa suomexi.
Ei minkäänlaista ongelmaa.
Linus on itse tässä asiassa pihalla kuin lumiukko ja kuvittelee, että eri merkkisille käyttöjärjestelmien tarvitsisi käyttää samoja asennuspaketteja.
Joku varmasti on pihalla.
"ja kuvittelee, että eri merkkisille käyttöjärjestelmien tarvitsisi käyttää samoja asennuspaketteja"
Joo kyse olis samanlaisesta "vaatimuksesta" jos standardisoinnin nimissä vaadittas että skodan osien pitää sopia myös Mercedes-benz:iin ?
Niin. Tai Mac OS:n ohjelmien asennuspakettien pitäis toimia Windowsissa.
Tässä ei oikeasti ole minkäänlaista ongelmaa. Linus mainitsi Valven pelit ja käytännössä ainoat kuluttajapuolelle suunnatut Linuxia käyttävät käyttöjärjestelmät ovat Android ja Ubuntu. Android ei Valvea kiinnosta koska Ubuntussa on parhaat grafiikkaominaisuudet kaikista käyttöjärjestelmistä ja Valve tietää myös sen, että Googlella ja laitevalmistajilla on aika vahva ote sovellusten jakelussa.
Joten, Steamin peleille alustat ovat tällä hetkellä käytännössä:
Mac OS 10.7
Mac OS 10.8
Mac OS 10.9
Ubuntu 12.04 LTS 32-bit
Ubuntu 12.04 LTS 64-bit
Ubuntu 14.04 LTS 32-bit
Ubuntu 14.04 LTS 64-bit
Windows Vista SP2 32-bit
Windows Vista SP2 64-bit
Windows 7 SP1 32-bit
Windows 7 SP1 64-bit
Windows 8 32-bit
Windows 8 64-bit
Windows 8.1 update 1 32-bit
Windows 8.1 update 1 64-bit
Asennuspaketteja tulee todellakin enemmän kuin yksi!
"Linus on itse tässä asiassa pihalla kuin lumiukko ja kuvittelee, että eri merkkisille käyttöjärjestelmien tarvitsisi käyttää samoja asennuspaketteja."
Linus meinaa että Linuxeihin on useita eri asennuspaketteja .deb ja .rpm jne...
Ei me mitään windows taikka mac paketteja haluta toimivaksi...
Windowsilla onkin omia ohjelma- "paketteja" aika hintelästi ja niidenkin päivitykset paskoo, saas nähä kuinka illalla käy.
Se winkussa onkin ongelma, että siihen voit tehdä laaduttomia paketteja ja kukaan ei mukise, vaikka tuhoaisi tietokoneen.
Linuxiin vastaavasti vaaditaan vain laadukasta koodausta....
Ubuntuun laitetaan .deb paketteja.
Androidiin laitetaan .apk paketteja
Mac OS:n laitetaan .dmg paketteja
Red Hat Enterpriseen laitetaan .rpm paketteja
Windowsiin laitetaan .msi paketteja
Linusin mukaan näille pitäisi olla joku standardi että sama paketti kävisi kaikkiin.
Totuus on että Linus on tässä asiassa oikeasti pihalla. Jos ohjelmistokehittäjä haluaa että ohjelma toimii sellaisenaan näissä kaikissa niin se tekee sen softan vaikka Javascriptillä, ja käyttäjä käynnistää/asentaa pelin tekemällä pikakuvakkeen linkillä tyyliin http://www.peli.fi ja tadaa, täysin sama softa toimii joka paikassa.
Kannattaa muistaa se, että Linus on mm. valittanut tälläistä C :sta: http://harmful.cat-v.org/software/c /linus
Pointti tässä on se, että Linus elää jossain tietokoneraudan ja sovellusrajapintojen välissä eikä ymmärrä sitä, että C on sovellusohjelmointikieli. Ei sillä mitään kerneliä tehdä.
Normaalistihan se homma menee niin, että kun halutaan lisätä siirrettävyyttä niin lisätään abstraktiokerrosta jonka alapuolella sitten säädetään juttuja eri tekniikoille. Aikaisemman viestin Steam alustoille löytyy myös yhtenevä paketointimekanismi kaikille työpöytäympäristöille ja se olisi tietystikin .jar paketointi. Ei tarvitse kuin Javan ja sama peli toimii sellaisenaan samasta paketista. Kokeilkaa vaikka Minecraftilla.
Joten, mikä helvett1 tässä nyt on muka se ongelma?
Olishan se hyvä juttu, jos kaikkiin linuxseihin kävisi yksi ja ainoa paketti, että ei tarvis arpoa toimiiko. Eikä siten tarvis pelleillä javojen sun muun ylimääräisen kanssa, eli ohjelman asennus kertalaakista ja sillä selvä.
Missä se Linus sanoo että pitäisi windowsin pazka.msi toimia Linuxissa?
Samalla tavalla yksi ja sama paketti pitäisi käydä riippumatta siitä onko siellä käyttöjärjestelmässä Linuxia vai ei.
Eri käyttöjärjestelmävalmistajilla vaan on omat lokaalit standardit paketoinnille ja se on riippuvainen käyttöjärjestelmästä, ei Linuxista tai mistään muustakaan. Jos tämä ei käy, pitää nostaa abstraktiotasoa ja laittaa jotain siihen väliin. Java hoitaa esimerkiksi homman hyvin työpöytäympäristöissä, ei tarvitse kuin Java tuki ja yksi ja sama .jar paketti toimii riippumatta siitä onko Windows vai Ubuntu vai mikä hitto. Android, iOS, Windows RT jne. ei tietenkään sovi koska Java JRE tarvitsee ikkunoinnilla varustetun työpöytäympäristön. Valmiina Java on Red Hat Enterprisessä ja Ubuntussa, Windowsista ja Mac OS:stä se puuttuu ja tarvitsee asentaa.
Siinä kun se sanoo että saman paketin pitäisi toimia vaikka Red Hat Enterprisessä ja Ubuntussa.
Sillä ei ole väliä onko se käyttöjärjestelmä Windows, Ubuntu, Mac OS, Suse, Android tai mikä tahansa. Jokaisella on se oma paketointi. Linus nyt hölmönään kuvittelee, että jos käyttöjärjestelmässä on hänen tekemä kerneli että se muka vaikuttaisi millään tavalla mihinkään muuhun. Se on lähinnä Linusin egoon liittyvä ongelma.
Ai sinäkö kuvittelet että virus.exe ohjelman pitäisi toimi myös Linuxissa? Ei kait Linus noin ajattele???
"Joten, mikä helvett1 tässä nyt on muka se ongelma? "
Se että sinä et ole keksinyt tai saanut aikaiseksi mitään merkittävää.
Ajatuksena tässä taitaakin olla se, että "käyttöjärjestelmä" olisi Linux. EI Ubuntu, Debian, Fedora, Arch Linux tai jokin muu vastaava. Eli, että olisi Linux-käyttöjärjesteömä työpöydälle, joissa kaikissa olisi sama pakettienhallinta. M-Kar haluaa vain taas tahallaan ymmärtää asian väärin ja esittää, kuin mitään ongelmaa ei olisikaan. Suuren osan mielestä se on ongelma, kun linuxeja käytetään mitä milloinkin, mutta itse tehtyä ohjelmaa vaikkapa C:llä kirjoitettuna ei saa toimimaan useassa jakelussa ongelmitta, vaan täytyy opetella useita eri pakettienhallintoja. Eri versiot kirjastoista aiheuttavat sitten vielä suuremman ongelman, mutta jo yhtenäinen pakettiformaatti auttaisi, jos ohjelman voisi kääntää vain joka järjestelmälle samalla ohjelmalla..
"Ajatuksena tässä taitaakin olla se, että "käyttöjärjestelmä" olisi Linux."
Sellaista käyttöjärjestelmää ei ole. Linus Torvaldsin ego vaan voi olla liian suuri ja se haluaisi nimetä suurimman osan maailman käyttöjärjestelmistä olevan "Linux". Sama ongelma vaivaa erästä Richard Stallmania joka väittää käyttöjärjestelmien olevan nimeltään "GNU".
Molemmat ovat pihalla. Käyttävät nimittäin ns. GPL lisenssiä ohjelmistoissaan ja tämä lisenssi on sellainen, että ohjelmia voi hyödyntää eri käyttöjärjestelmissä ja muissa tuotteissa.
"Suuren osan mielestä se on ongelma, kun linuxeja käytetään mitä milloinkin, mutta itse tehtyä ohjelmaa vaikkapa C:llä kirjoitettuna ei saa toimimaan useassa jakelussa ongelmitta, vaan täytyy opetella useita eri pakettienhallintoja."
Ja sitten kun käytetään Mac OS:ia niin Ubuntulle tehdyt C-kieliset ohjelmat sitten alkavatkin yks kaks toimimaan?
Kannattaa nyt ymmärtää ne käsitteet:
-API, eli sovellusrajapinta mille ohjelma _kirjoitetaan_. Esim. GTK 2, Java 6 API jne.
-ABI, eli sovelluksen binäärirajapinta. Ohjelma käännetään ABI:lle. ABI:t voivat olla käyttöjärjestelmäkohtaisia ja rajapinnasta riippuen myös käyttöjärjestelmäversiokohtaisia.
-Kerneli, eli se ohjelmapalikka siellä sovellusrajapintojen ja raudan välissä, esim. Linux.
-Paketointijärjestelmä, sisältää koneiston millä ohjelma asentuu järjestelmään yhdestä tiedostosta. Yleensä käyttöjärjestelmäkohtainen.
-Käyttöjärjestelmä, sisältää sen kernelin, sovellusrajapinnat, paketointijärjestelmän ja kaikkea muutakin kivaa.
"kun linuxeja käytetään mitä milloinkin"
Normaalisti IT-ympäristöt vakioidaan, ja että siellä on sama käyttöjärjestelmä ja sama versiokin vielä käyttöjärjestelmästä käytössä.
"mutta itse tehtyä ohjelmaa vaikkapa C:llä kirjoitettuna ei saa toimimaan useassa jakelussa ongelmitta, vaan täytyy opetella useita eri pakettienhallintoja."
Buildijärjestelmät on keksitty. Esim. GNU Autotools. Helpottaa sitä porttaamista.