Gå til innhold

Silverlight 4 snart tilgjengelig for Linux


Anbefalte innlegg

Videoannonse
Annonse

Frode, vi har noen glupe nakker i vår By Horten, som har satt opp streaming av komunestyrets møter i silverlight. Noe som er helt ubrukelig for folk.

 

Folk lurer på hvorfor maskinene deres blir tregere og tregere. Ja, det er fordi de må installere så mye dr*t på sine MS maskiner for å se på ting som kunne vært kjørt på åpne standarer. Eller en lukket standard som Flash som finnes til så og si alle platformer.

Lenke til kommentar

Klare nå å laste mer av Eurosport player, men den klarer ikke å vise noe innhold enda. Får en melding om at det benyttes Silverlight 4 og at det ikke er fult ut støttet enda. Men det går i alle fall fremover :) Så får vi se hva som kommer først i mål av fullgod Silverlight støtte og html5.

Lenke til kommentar

Crowly: Du bruker Firefox ell Chrome? Er kun de to som er støttet så vidt jeg skjønner...

 

Det skal og nevnes at Silverlight (eller ihvertfall en versjon av) benyttes i Windows Phone 7 (Metro-grensesnittet er basert på Silverlight). Så god støtte for Silverlight i Mono kan gjøre det lettere (i fremtiden) for utviklere på Mac og Linux for å utvikle apps til WP7.

Lenke til kommentar

Mono og Moonlight er bare med på å rakke Linux ned til annenrangs programvare. Både fordi det aldri vil være i front av utviklingen av hverken Silverlight eller .NET, men også fordi det legitimerer ufrie formater i bruk på nettet. Internett bør være fritt og bruke åpne standarder. Et lukket og proprietært Internett vil ødelegge Internettet. Jo mer man legitimerer bruk av ufrie formater på nett jo mer vil disse formatene brukes av tilbydere og dermed tvinge ennå flere til å ta i bruk disse ufrie teknologiene. Det er en ond sirkel man bør få kuttet så raskt som mulig.

 

Det er nettopp slike betraktninger som ligger bak Googles avgjørelse om å fjerne H.264-støtten fra Chrome.

 

La flammekrigen begynne! :p

  • Liker 1
Lenke til kommentar

HTML5 er bare en av mange åpne løsninger. Totalt sett bør alle behov kunne dekkes av åpne løsninger. Enten eksisterende løsninger eller kommende løsninger.

 

Flash og Silverlight bør for alles beste dø ut.

 

Stikkordet her er vel "kommende". All den tid løsningene enda ikke har kommet og dermed ikke er i bruk, er det flott at Silverlight også er tilgjengelig på andre platformer enn Windows.

 

Jeg har ikke noe problem med å tro at Flash og Silverlight dør den dagen det kommer åpne løsningner som er tilnærmet like gode.

Lenke til kommentar

La flammekrigen begynne! :p

..., men faktum er dessverre at html5 ikke dekker alle behov man har for nettet slik at løsninger som flash og sliverlight kommer til å eksistere i samspill med andre åpne teknologier.

 

Hvilke behov er det web-plattformen ikke dekker? Et sånt "faktum" bør det gå glatt å konkretisere.

Ja, vertfall Flash, kommer til å ha en stor rolle for Internett-innhold i lang tid fremover, men "historiske faktum" og "personlig smak", er det som slår meg som grunnen - ikke den moderne web-plattformens mangler.

Lenke til kommentar

3 argumenter jeg kommer på nå her, men finnes nok mange fler.

 

Avanserte applikasjoner som kjøres på klienten.

DRM og generell rettighetsstyring

Sikkerhet

 

- DRM: Er mye meninger om det er en "mangel" eller en "bonus", men det er vertfall en oppfattet mangel for endel ja.

 

- "... og generell rettighetsstyring". Du formulerer det som et utspring av DRM-punktet, men nevner det som et eget tredje punkt. Tenker du det som et bredere bruksområde av hva man vanligvis forbinder med DRM-funksjonalitet, så må det regnes under det samme. Tenker du det som noe helt generelt på utviklings-nivå, så er det vare tøv, og vertfall milevis unna noe konkret.

 

- Sikkerhet: Tøv og svada.

 

 

Det konkrete er altså DRM. Hvis det er det du mener påstanden din står på, så OK...

Lenke til kommentar

Hvilke behov er det web-plattformen ikke dekker? Et sånt "faktum" bør det gå glatt å konkretisere.

Ja, vertfall Flash, kommer til å ha en stor rolle for Internett-innhold i lang tid fremover, men "historiske faktum" og "personlig smak", er det som slår meg som grunnen - ikke den moderne web-plattformens mangler.

 

Tilgang til mikrofon og webcam er noe som nevnes av en del. "Kommende" er et passende ord for HTML5-støtten, såvidt jeg har forstått.

Lenke til kommentar

Mono og Moonlight er bare med på å rakke Linux ned til annenrangs programvare. Både fordi det aldri vil være i front av utviklingen av hverken Silverlight eller .NET, men også fordi det legitimerer ufrie formater i bruk på nettet. Internett bør være fritt og bruke åpne standarder. Et lukket og proprietært Internett vil ødelegge Internettet. Jo mer man legitimerer bruk av ufrie formater på nett jo mer vil disse formatene brukes av tilbydere og dermed tvinge ennå flere til å ta i bruk disse ufrie teknologiene. Det er en ond sirkel man bør få kuttet så raskt som mulig.

 

Det er nettopp slike betraktninger som ligger bak Googles avgjørelse om å fjerne H.264-støtten fra Chrome.

 

La flammekrigen begynne! :p

 

Mono og Moonlight er nå open-source såvidt jeg husker, og C# er jo en åpen standard (ECMA godkjent eller noe mener jeg, ikke helt sikker dog).

 

Personlig synes jeg C# er det mest geniale programmeringsspråket jeg har vært borte i, og er glad jeg har mulighet til å lage programmer med .NET plattformen i operativsystemet som passer meg best, slik at jeg ikke er låst til Windows.

 

Skal sies at Mono forsåvidt er eneste alternativet hittil som støtter utvikling for alle desktop plattformene, pluss Android, iOS og WP7. Er visst snakk om at de skal legge til støtte for WebOS og mener jeg, noe som muliggjør rask app-utvikling for disse plattformene hvis programmereren tenker langsiktig og lager en grunn-kjerne i programmet.

 

Men jo, enig i at Silverlight bør dø ut... Hvis de da ikke legger vekt på å bruke Silverlight som en fancy UI-løsning for desktop, slik de bruker Silverlight som UI i WP7.

Lenke til kommentar

Tilgang til mikrofon og webcam er noe som nevnes av en del. "Kommende" er et passende ord for HTML5-støtten, såvidt jeg har forstått.

 

Mikrofon og webcam er i grunnen et kurant punkt ja. Det er spesifikasjoner for dette under arbeid ja, som har de første implementeringene på plass. "Kommende" passer greit.

 

Så er jo en da "interessant" observasjon (mest i forhold denne artikkelen) at mikrofon og webcam-støtte er noe som også er "kommende" for Moonlight...

Lenke til kommentar

Silverlight/Moonlight ser jeg lite nytte av, og er vel strengt tatt brukt til streaming av video fra noen nettsider, og det finnes bedre alternativer.

 

Mono brukes faktisk i en del programvare, blant annet F-spot og Banshee som finnes i en del distribusjoner, uten at jeg er begeistret for dette. Men jeg anser C# med .NET som "the lesser of two evils" sammenlignet med java med swing/awt, men ingen av disse er frie, og de frie implementasjonene kommer bare diltende etter. .NET er faktisk ryddigere enn swing/awt, og mer kompliserte GUI i swing er et mareritt å få til på alle plattformer og alle skjermoppløsninger. Begge alternativene har store konsekvenser for ytelse/ressursbruk, stabilitet og respons, og java med swing/awt gjør det spesielt dårlig på sistnevnte. Uansett så mener jeg at begge alternativene er prinsipielt feil metodikk for løsning av kryssplattform-problemene.

 

Men det finnes da gode alternativer:

Bruk av rammeverkene Qt eller GTK direkte, som finnes for en rekke programmeringsspråk, og vil ha god ytelse og stabilitet. Begge disse krever at bibliotekene er installert i operativsystemet, i likhet med .NET og swing. Noen fordeler med Qt er at i Qt 4 vil programmene i stor grad kunne passe inn i temaet til operativsystemet, er objektorientert for den som foretrekker det og er ellers et rammeverk med veldig mye funksjonalitet. Noen fordeler med GTK er at det kan brukes direkte i C, kan ved riktig bruk skalere godt med ulike skjermoppløsninger og er veldig kompakt.

 

En tredje type løsning er varianten som Lazarus (fritt kryssplattform-IDE som ligner på Delphi) har valgt, nemlig å kompilere til de ulike rammeverkene i stedet for et felles. Folk tror da gjerne at de har et minste felles multiplum fra alle disse rammeverkene, men det stemmer ikke. Komponentene i LCL(bibliteket til Lazarus) er i all hovedsak implementert native i Windows/Windows CE, GTK, Qt og Carbon, i tillegg til at Cocoa jobbes med. I disse er LCL implementert ferdig med en håndfull unntak, og alle disse komponentene er bygd opp native i hvert enkelt rammeverk. Mellomlaget til LCL eksisterer alså bare under design, og kompilerer til et program som bruker f.eks. Qt native.

 

Personlig ser jeg få scenario der det er hensiktsmessig å bruke enten C# med .NET eller java med swing/awt, med unntak av applets for java. Straks et prosjekt kommer over et visst nivå av kompleksitet så overskygges fordelene av de store ulempene. Og spesielt for java sine bibliotek så går det mye tid med på å finne bibliotek med ønsket funksjonalitet, og som regel mye tid og kode på å få disse til å jobbe sammen. Jeg mener ikke å rakke ned på noens ferdigheter eller favorittspråk her, men hvis vi ser realistisk på det så brukes disse to plattformene til mye mer enn de er best egnet for. Alt til sitt bruk.

 

Edit: Det er også frustrerende at .NET i seg selv ikke er bakoverkompatibelt under kjøretid. Det skal ikke mange programmene til før det er nødvendig med 3-4 ulike versjoner av .NET framework inne, og flere av disse trenger gjerne et par service packs også.

Endret av efikkan
Lenke til kommentar

Silverlight/Moonlight ser jeg lite nytte av, og er vel strengt tatt brukt til streaming av video fra noen nettsider, og det finnes bedre alternativer.

 

Mono brukes faktisk i en del programvare, blant annet F-spot og Banshee som finnes i en del distribusjoner, uten at jeg er begeistret for dette. Men jeg anser C# med .NET som "the lesser of two evils" sammenlignet med java med swing/awt, men ingen av disse er frie, og de frie implementasjonene kommer bare diltende etter. .NET er faktisk ryddigere enn swing/awt, og mer kompliserte GUI i swing er et mareritt å få til på alle plattformer og alle skjermoppløsninger. Begge alternativene har store konsekvenser for ytelse/ressursbruk, stabilitet og respons, og java med swing/awt gjør det spesielt dårlig på sistnevnte. Uansett så mener jeg at begge alternativene er prinsipielt feil metodikk for løsning av kryssplattform-problemene.

 

Men det finnes da gode alternativer:

Bruk av rammeverkene Qt eller GTK direkte, som finnes for en rekke programmeringsspråk, og vil ha god ytelse og stabilitet. Begge disse krever at bibliotekene er installert i operativsystemet, i likhet med .NET og swing. Noen fordeler med Qt er at i Qt 4 vil programmene i stor grad kunne passe inn i temaet til operativsystemet, er objektorientert for den som foretrekker det og er ellers et rammeverk med veldig mye funksjonalitet. Noen fordeler med GTK er at det kan brukes direkte i C, kan ved riktig bruk skalere godt med ulike skjermoppløsninger og er veldig kompakt.

 

En tredje type løsning er varianten som Lazarus (fritt kryssplattform-IDE som ligner på Delphi) har valgt, nemlig å kompilere til de ulike rammeverkene i stedet for et felles. Folk tror da gjerne at de har et minste felles multiplum fra alle disse rammeverkene, men det stemmer ikke. Komponentene i LCL(bibliteket til Lazarus) er i all hovedsak implementert native i Windows/Windows CE, GTK, Qt og Carbon, i tillegg til at Cocoa jobbes med. I disse er LCL implementert ferdig med en håndfull unntak, og alle disse komponentene er bygd opp native i hvert enkelt rammeverk. Mellomlaget til LCL eksisterer alså bare under design, og kompilerer til et program som bruker f.eks. Qt native.

 

Personlig ser jeg få scenario der det er hensiktsmessig å bruke enten C# med .NET eller java med swing/awt, med unntak av applets for java. Straks et prosjekt kommer over et visst nivå av kompleksitet så overskygges fordelene av de store ulempene. Og spesielt for java sine bibliotek så går det mye tid med på å finne bibliotek med ønsket funksjonalitet, og som regel mye tid og kode på å få disse til å jobbe sammen. Jeg mener ikke å rakke ned på noens ferdigheter eller favorittspråk her, men hvis vi ser realistisk på det så brukes disse to plattformene til mye mer enn de er best egnet for. Alt til sitt bruk.

 

Edit: Det er også frustrerende at .NET i seg selv ikke er bakoverkompatibelt under kjøretid. Det skal ikke mange programmene til før det er nødvendig med 3-4 ulike versjoner av .NET framework inne, og flere av disse trenger gjerne et par service packs også.

 

Jeg må bare spørre, da det er mange som har denne holdningen og jeg skjønner den ikke helt, hva er det som er så galt med .NET? Eller, jeg er smertelig klar over at .NET er ett mareritt pga de forskjellige versjonene og slikt på Windows, her er det rett og slett dårlig jobb av Windows-utviklerene mener jeg. Men Mono og C# i seg selv ser jeg ingenting i veien med.

 

Sånn jeg ser det, blir C# veldig likt Python i måten det fungerer på, bare at Mono da selvfølgelig har muligheten til å compilere C# og fungere som en JIT... Mono benytter jo også GTK som standard for bygging av grafiske grensesnitt. Når det gjelder ytelse så ja, det kan være tregere enn C++, men for det meste er forskjellene små, dog C#/Mono programmer gjerne bruker litt lenger tid på å starte opp...

 

Lagde nettopp en app til Ovi Suite med Qt og C++, og selv om jeg ser at Qt er ett fantastisk rammeverk, så endte jeg opp med å skrive programmet på nytt da C# som språk er mye lettere å jobbe med og lar meg utvikle programmer raskere... og selvfølgelig fordi Nokia valgte å satse på Windows Phone 7 hvor, ironisk nok, kun .NET-plattformen fungerer :p

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...