Ruby compiler til .NET

#48

Først siger du at MS.NET er ligeså hurtigt som Native C++, men nu siger du at det er langsomt?

#50

Og da leverandøren i form af, at være den eneste med kildekoden, er den eneste som kan løse ens problem. Så bliver det ret kritisk, hvis de ikke er deres ansvar ordentligt bevidst. Derfor er det et alvorligt minus, som alt for få anerkender alvorligheden af.

Enig! Jeg har en gang brændt fingrene på en købt DLL uden kildekode. Firmaet forsvandt ud i den blå luft efter et par år! Heldigvis kan man i dag købe sig til kildekoden de fleste steder (har selv gjort det hos www.dynaforms.com) eller også findes det som open source.

#45 Acro. Du er selvstændig. Hvordan har du sikret dine kunder en forsat drift i tilfælde af en konkurs? Har du deponeret din kode hos tredjepart eller har du en overtagelsesaftale af koden med dine kunder?

#39: jeg forstår ikke lige hvad du mener med den sidste linje der?

#49:
kilde: mine egne tests, og nej, jeg har ikke smækket dem på nettet, og nej, det bliver ikke mere rigtigt eller forkert hvis jeg laver et site der dokumenterer det.

#51:
hvor sagde jeg at ms.net er lige så hurtigt som nativt c++ ?

"Det er MEGET trist, at de finder på den slags."

Det er det da netop ikke. De bruger det native API, for at forbedre performance, hvilket også er en stor del af grunden til at .net performer bedre end java på windows..

"Hvilket kun gør det endnu mere spøjst.
Først laver de en standard, og så er de selv de første til at forplumre den... Ohh well... ;)"

Nej de er da ej? Alle libraries som følger med default har intet som helst med standarten at gøre. De er libraries som følger med, for at man ikke selv skal igang med at lave et komplet framework.

"Og da leverandøren i form af, at være den eneste med kildekoden, er den eneste som kan løse ens problem. Så bliver det ret kritisk, hvis de ikke er deres ansvar ordentligt bevidst. Derfor er det et alvorligt minus, som alt for få anerkender alvorligheden af."

Snakker vi generelt eller microsoft? Du mener altså ikke at microsoft har tænkt sig at supportere, og løse evt. problemer i .net?

"Og hvad hindre Microsoft i at inkludere GTK#, QT# og andre?. Intet, absolut intet. "

Næh, men hvorfor skulle de ha en interesse i at gøre det?

"De bør ikke binde sig til libraries, medmindre disse bredt kan implementeres, i alle implementationer uden problemmer."

Aha... Det princip giver sku hurtigt meget store problemer generelt for software-udvikling. Lad os håbe det ikke er noget der spreder sig ud på nettet fra foraet!

#53: Du bør så lige forstå at Microsofts Runtime reserverer en del ram til din applikation når det afvikles. Det er IKKE ensbetydende med at applikationen gør brug af dem. Derudover er det så smart lavet at hvis du begynder at ramme imod loftet så frigiver runtimen dele af den reserverede ram og giver dem tilbage til operativsystemet - reserveringen har med andre ord ikke den store konsekvens andet end at den i langt de fleste tilfælde optimerer afviklingen af .NET applikationerne eftersom det ville være dyrt konstant at skulle udvide allokeringen af hukommelsen i den virtuelle maskine.

Så hvis dine såkaldte "tests" er baseret på at sidde og glo på allokeret ram i Taskmanageren så er de ikke meget værd :)

#54 duckfighter

Har du nogle links til nogle tests, der viser at .NET er hurtigere end Java på Windows? Dem jeg kan Google mig frem til viser nemlig at de er cirka lige hurtige. I visse tests har .NET en fordel, og i andre har Java en fordel, men forskellen er meget lille...

offtopic:
Duckfighter, 2 opfordringer til dig - kig på dine indlæg inden du trykker gem - de kan godt virke usammenhængende.
Svar på de spørgsmål der bliver stillet dig i en tråd du deltager i.

#50 sKIDROw:
Du forstår tydeligvis ikke, hvad jeg mener, eller hvordan det fungerer.

Hvis jeg vil lave en implementering af .NET, der anvender et specielt library, så kan jeg sagtens gøre det, men det ændrer ikke standarden. Jeg sparer bare mig selv for noget arbejde ved at kunne genbruge funktionerne til den implementering, der fortolker MSIL. Om Microsoft.NET bruger Windows API'et er hamrende irrelevant. Det er da en selvfølge, at Microsoft.NET henvendt til Windows-platformen skal integrere sig i Windows, og det ændrer jo ikke på .NET-applikationerne. De er stadig lige portable, krydskompatible og hvad man ellers kan finde på at kalde dem.

Microsoft.NET må gerne binde sig til libraries, ligesom Mono gerne må. Det er kun selve standarden (.NET). Det kan være fuldkommen ligegyldigt for brugeren, om Mono anvender Gtk for at vise noget grafisk. Det er bare essentielt, at både Microsoft.NET og Mono kan vise noget grafisk. Måden de gør det på er irrelevant, når de lever op til standarden. Det er jo netop idéen med standarder.

Hvorfor tror du, at Microsoft har ladet .NET standardisere, hvis de ikke vil lade det være kompatibelt andre platforme? De vil da meget gerne lade det være kompatibelt, når de bare bevarer kontrollen.

#51 elacris:
Hvis DONG går konkurs, så overtager du da ikke rørnetværket fra forsyningen og til din husstand. Hvis Nokia går konkurs, så kan min telefon ikke softwareopdateres. Jeg forstår ikke de underlige krav indenfor softwarebranchen; det er fuldkommen unikt at stille den slags krav. Hvor mange andre virksomheder sikrer dig på den måde?

Når det er sagt, så har alle kunder retten til at anvende præsentationsdelen af CMS-løsningerne, hvis de dropper deres abonnement. De kan altså frit lade webstedet køre, selvom de ikke kan anvende værktøjet til at opdatere det. Det annoncerer vi ikke med på nuværende tidspunkt, men det kommer snart. Derudover er kildekodedeponering o. lign. ting, der kan indgå i en SLA, men selvom det er tilbudt flere kunder, så har ingen haft interesse i det endnu. De kunder, der har et særligt behov og får specialudvikling, ejer selv deres software i forvejen.

#54 duckfighter

Det er det da netop ikke. De bruger det native API, for at forbedre performance, hvilket også er en stor del af grunden til at .net performer bedre end java på windows..

Og hvor dette udelukkende giver performance, uden at skabe et lockin?. Go ahead... ;) Altså API aware delen, skal være i fortolkerlaget, og ikke i den bytekode kopilerede del.

Nej de er da ej? Alle libraries som følger med default har intet som helst med standarten at gøre. De er libraries som følger med, for at man ikke selv skal igang med at lave et komplet framework.

Hvilket er hele problemmet. Du har en standard, og så har du alt det uspecificerede, som hver implementør kan tilføje ovenpå. Og jeg siger så: Så at få specificeret alle tilføjelserne, og gør dem en (optionel) del af standarden.

Snakker vi generelt eller microsoft? Du mener altså ikke at microsoft har tænkt sig at supportere, og løse evt. problemer i .net?

Generelt talt. Men vil Microsoft holde op med at supportere .NET framework'et?. Næppe. Vil det sige at Microsoft vil supportere det, i det niveau og i den retning brugerne måtte ønske?. Who knows.. ;) Vil det sige at det kan inkludere ting, du ikke er glad for?. Nemt. Hvad kan du gøre, i et lukket system?. Nada!.

Næh, men hvorfor skulle de ha en interesse i at gøre det?

Hvorfor dog ikke om jeg må spørge?.

Aha... Det princip giver sku hurtigt meget store problemer generelt for software-udvikling. Lad os håbe det ikke er noget der spreder sig ud på nettet fra foraet!

Hvilket problem er det, hvis jeg må spørge?. Det kunne da have være relevant, at du havde redegjort for så kontroversiel en udtalelse. Vi må jo blot sørge for, at alt bliver (re)implementerbart af alle. Så kan jeg da ikke, få øje på noget problem. Og med hensyn til at sprede sig fra dette forum, så er jeg ikke ene om det syn. Og jeg diskutere ikke kun på newz. Lægger naturligvis heller ikke bånd på mig selv, ud af nogens påstande om skadevirkninger. Specielt skadevirkninger, man ikke gør rede for.

#58 Acro

Du forstår tydeligvis ikke, hvad jeg mener, eller hvordan det fungerer.

Enten det eller også er jeg ikke enig med jer i, hvordan det fungerer i praksis eller hvordan det BURDE fungerer.

Hvis jeg vil lave en implementering af .NET, der anvender et specielt library, så kan jeg sagtens gøre det, men det ændrer ikke standarden.

Nej det er det jeg mener er et problem.

Alle tilføjelserne, bør hurtigst muligt standardiseres. Måske ikke i standarden i sig selv, Men gerne sideløbende. QT# og GTK# er mig bekendt standardiseret, så mangler vi blot at de andre som laver tilføjelser INKLUSIV Microsoft få ALLE disse standardiseret på ligefod.

Jeg sparer bare mig selv for noget arbejde ved at kunne genbruge funktionerne til den implementering, der fortolker MSIL. Om Microsoft.NET bruger Windows API'et er hamrende irrelevant. Det er da en selvfølge, at Microsoft.NET henvendt til Windows-platformen skal integrere sig i Windows, og det ændrer jo ikke på .NET-applikationerne. De er stadig lige portable, krydskompatible og hvad man ellers kan finde på at kalde dem.

Sålænge API brugen er holdt til fortolker delen, og ikke lægger ude i bytekoden, så behøver det heller ikke være et problem.

Microsoft.NET må gerne binde sig til libraries, ligesom Mono gerne må.

De ekstra libraries som Mono bruger, som ikke er inkluderet i Microsfts .NET, kunne Microsoft implementere imorgen HVIS DE VILLE. Det ville ikke være dem forbudt, og det ville ikke være besværligt for dem. Heri lægger der en stor forskel.

Det er kun selve standarden (.NET). Det kan være fuldkommen ligegyldigt for brugeren, om Mono anvender Gtk for at vise noget grafisk. Det er bare essentielt, at både Microsoft.NET og Mono kan vise noget grafisk. Måden de gør det på er irrelevant, når de lever op til standarden. Det er jo netop idéen med standarder.

Hvis du koder til Microsofts grafiske library, og andre kun kan supportere GTK# eller lignende, vil programmet så stadig fungere gnidningsløst blot med et andet udseende?. Så er det irrelevant, ellers er det højest relevant.

Hvorfor tror du, at Microsoft har ladet .NET standardisere, hvis de ikke vil lade det være kompatibelt andre platforme? De vil da meget gerne lade det være kompatibelt, når de bare bevarer kontrollen.

Der er mange teorier om, hvorfor de gør som de gør. Jeg har opgivet helt at konkludere noget. Vil man kende et ddækkende svar, må man nok spassere lidt runde inde bagved murene, hvor ingen almindelige dødelige har adgang. De vil gerne være kompatible, sålænge de bevarer kontrollen?... Hmmm...
Lad os spille et spil kort. Jeg lover dig at jeg ikke vil snyde, hvis blot jeg må bestemme reglerne... Æhhh?. Det oprigtige for dem at gøre, ville naturligvis være at overføre den komplette kontrol til standardiseringsorganisationen. Og så være et medlem med stemmeret, i en forsamling af flere medlemmer, som beslutter retningen.

#51 elacris:
Hvis DONG går konkurs, så overtager du da ikke rørnetværket fra forsyningen og til din husstand. Hvis Nokia går konkurs, så kan min telefon ikke softwareopdateres. Jeg forstår ikke de underlige krav indenfor softwarebranchen; det er fuldkommen unikt at stille den slags krav. Hvor mange andre virksomheder sikrer dig på den måde?.

Underlige eksempler.
Det er uhyre relevant, når vi i dit tilfælde som jeg husker, taler om CMS løsninger, som virksomheder kan have baseret større websites på. Dine kunders sider er baseret på en stor procentdel CMS, og de sidste procentdele af deres egen indhold. En CMS leverandør som går ned, lig med en trediedel website som fungerer. Min mobiltelefon derimod, fungerer, og jeg ejer den selvom Nokia/SE/Samsung skulle dø. Hvis DONG skulle dø, ejer du den komplette installation derhjemme, og en ny leverandør kan fri levere til dette setup.

Når det er sagt, så har alle kunder retten til at anvende præsentationsdelen af CMS-løsningerne, hvis de dropper deres abonnement. De kan altså frit lade webstedet køre, selvom de ikke kan anvende værktøjet til at opdatere det. Det annoncerer vi ikke med på nuværende tidspunkt, men det kommer snart.

Vel et skridt i den rigtige retning om ikke andet.

Derudover er kildekodedeponering o. lign. ting, der kan indgå i en SLA, men selvom det er tilbudt flere kunder, så har ingen haft interesse i det endnu. De kunder, der har et særligt behov og får specialudvikling, ejer selv deres software i forvejen.

Kodedeponering og tilbud om at få denne, i tilfælde af konsurs er ligeomkring intet værd i praksis. Når et konkursbo skal gøres op, og en kreditor med mange penge til gode, ser at aktiv som kunne indbringe ham penge, så tror jeg desværre ikke dette tilbud er det blæk værd det er skrevet med.

Skidrow.

Jeg forstår ikke hvorfor en hjemmeside holder op med at fungere hvis en udbyder går ned. Den vil vel virke lige så godt som din telefon der ikke kan opdateres?

Du må gerne svare tilbage i en PM da jeg skal på FEEERIE! :D

#59 sKIDROw:

Enten det eller også er jeg ikke enig med jer i, hvordan det fungerer i praksis eller hvordan det BURDE fungerer.

Det skyldes (tror jeg), at du ikke har noget begreb om softwareudvikling.

Nej det er det jeg mener er et problem.

Alle tilføjelserne, bør hurtigst muligt standardiseres. Måske ikke i standarden i sig selv, Men gerne sideløbende. QT# og GTK# er mig bekendt standardiseret, så mangler vi blot at de andre som laver tilføjelser INKLUSIV Microsoft få ALLE disse standardiseret på ligefod.

Du viser her tydeligt, at du ikke ved, hvad det handler om. Lad mig forklare det på en anden måde så. JPG er en standard. Billedformatet kan åbnes på mange forskellige måder i mange forskellige fremvisere, men resultatet er det samme. Windows Billed- og faxfremviser er ét program, der kan åbne JPG-formatet, og hvis dette program anvender en del af Windows API'et for at åbne filen, så er det ligegyldigt. Det ændrer ikke standarden, og det tilføjer ikke til standarden, men det implementerer standarden. Det er da logisk, at et program skal anvende nogle funktioner i operativsystemet. Der er ingen grund til at opfinde den dybe tallerken to gange. Microsoft.NET svarer til Windows Billed- og faxfremviser (eller en hvilken som helst anden), og .NET svarer til JPG.

Hvis du koder til Microsofts grafiske library, og andre kun kan supportere GTK# eller lignende, vil programmet så stadig fungere gnidningsløst blot med et andet udseende?. Så er det irrelevant, ellers er det højest relevant.

Det er jo netop derfor, at man har WinForms i .NET, og at man har andre muligheder for design. WinForms anvender i nogen udstrækning GTK, og det var det, jeg hentød til. Man bør aldrig bruge GTK#, da du så ikke har et kompatibelt program, selvom GTK# er kompatibelt. Når .NET indeholder et en designflade, så bør denne bruges, så man bevarer idéen i at have en standard.

Vil man kende et ddækkende svar, må man nok spassere lidt runde inde bagved murene, hvor ingen almindelige dødelige har adgang.

Nu har du nok lidt for høje tanker om de, der har deres liv inde bag murene. De er helt bestemt almindelige dødelige.

Lad os spille et spil kort. Jeg lover dig at jeg ikke vil snyde, hvis blot jeg må bestemme reglerne... Æhhh?. Det oprigtige for dem at gøre, ville naturligvis være at overføre den komplette kontrol til standardiseringsorganisationen. Og så være et medlem med stemmeret, i en forsamling af flere medlemmer, som beslutter retningen.

Det er muligt, at Sun pt. har en masse muligheder for, at man kan deltage i arbejdet omkring den videre udvikling af Java, men hvem har det endelige ord? Microsoft lytter naturligvis også til deres partnere, communitiet og mange andre. Det er der talrige eksempler på, og hvis man følger med i mange af deres blogs, vil man se, at der faktisk sker ret mange ændringer som følge af dette.

Det er uhyre relevant, når vi i dit tilfælde som jeg husker, taler om CMS løsninger, som virksomheder kan have baseret større websites på. Dine kunders sider er baseret på en stor procentdel CMS, og de sidste procentdele af deres egen indhold. En CMS leverandør som går ned, lig med en trediedel website som fungerer. Min mobiltelefon derimod, fungerer, og jeg ejer den selvom Nokia/SE/Samsung skulle dø. Hvis DONG skulle dø, ejer du den komplette installation derhjemme, og en ny leverandør kan fri levere til dette setup.

Din mobiltelefon virker, hvis Nokia går konkurs, men det gør din CMS-løsning også, hvis denne udbyder går konkurs. Du har ikke mulighed for at videreudvikle på din telefon, og du har det ikke umiddelbart på din CMS-løsning. Forskellen er den samme. Et ordentligt CMS bør dog have en masse muligheder for udvidelse, så det ikke er nødvendigt med selve kildekoden til kernen. Hvis det ikke er tilfældet, så er systemet simpelthen ikke fleksibelt nok.

Kodedeponering og tilbud om at få denne, i tilfælde af konsurs er ligeomkring intet værd i praksis. Når et konkursbo skal gøres op, og en kreditor med mange penge til gode, ser at aktiv som kunne indbringe ham penge, så tror jeg desværre ikke dette tilbud er det blæk værd det er skrevet med.

Det fungerer fint i praksis. Nu lader man jo ikke kildekoden ligge hos virksomheden selv, da det naturligvis vil medføre den proces, som du skitserer. De allerfleste betaler en uvildig advokat, der har en kontrakt på at skulle udlevere den i forbindelse med en konkurs.

#47: "Jeg oplever at mit program er gennemsnit 5-10% langsommere og under visse opgaver bruger 25% mere CPU under .NET."

Det er nok højest sandsynligt et spørgsmål om optimering af dit program :) Acro har et link til en glimrende artikel på MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwinforms/html/stickout.asp), som viser en løsningsmodel ved hjælp af Win32 API'et og lidt kreativ tænkning :D

#61 Acro

Det skyldes (tror jeg), at du ikke har noget begreb om softwareudvikling.

Vil jeg ikke lægge skjul på. Er dog ved at læse på C, men mine Hello World! programmer, er vist stadig v1.2.. :D

Du viser her tydeligt, at du ikke ved, hvad det handler om. Lad mig forklare det på en anden måde så. JPG er en standard. Billedformatet kan åbnes på mange forskellige måder i mange forskellige fremvisere, men resultatet er det samme. Windows Billed- og faxfremviser er ét program, der kan åbne JPG-formatet, og hvis dette program anvender en del af Windows API'et for at åbne filen, så er det ligegyldigt. Det ændrer ikke standarden, og det tilføjer ikke til standarden, men det implementerer standarden. Det er da logisk, at et program skal anvende nogle funktioner i operativsystemet. Der er ingen grund til at opfinde den dybe tallerken to gange. Microsoft.NET svarer til Windows Billed- og faxfremviser (eller en hvilken som helst anden), og .NET svarer til JPG.

Som sagt det vigtigste er, at fragmentering og lockins undgås. Så den fremstilling kan jeg godt leve med.

Det er jo netop derfor, at man har WinForms i .NET, og at man har andre muligheder for design. WinForms anvender i nogen udstrækning GTK, og det var det, jeg hentød til. Man bør aldrig bruge GTK#, da du så ikke har et kompatibelt program, selvom GTK# er kompatibelt. Når .NET indeholder et en designflade, så bør denne bruges, så man bevarer idéen i at have en standard.

I så fald bør GTK ol naturligvis, tilskrives via af WinForms. Standardisering frem for alt.

Nu har du nok lidt for høje tanker om de, der har deres liv inde bag murene. De er helt bestemt almindelige dødelige.

Det var naturligvis ikke pointen. Kan du spankulere ind af hoveddøren, og vade ind og kigge og snakke med koderne?. Jeg tvivler... ;)

Det er muligt, at Sun pt. har en masse muligheder for, at man kan deltage i arbejdet omkring den videre udvikling af Java, men hvem har det endelige ord? Microsoft lytter naturligvis også til deres partnere, communitiet og mange andre. Det er der talrige eksempler på, og hvis man følger med i mange af deres blogs, vil man se, at der faktisk sker ret mange ændringer som følge af dette.

Jeg fremhævede så ikke Sun. Over en standard bør ingen part have det endelige ord, det bør vare en forsamling. Hvis man vil have det endelige ord, og bevare kontrollen er det fint nok. Så lad vær med at kalde det en standard... ;)

Din mobiltelefon virker, hvis Nokia går konkurs, men det gør din CMS-løsning også, hvis denne udbyder går konkurs.

Hvis det er noget du fysisk har, og selv kan hoste ja. Ellers ikke. Ikke alle lader end hoste det selv.

Du har ikke mulighed for at videreudvikle på din telefon, og du har det ikke umiddelbart på din CMS-løsning.

De CMS løsninger jeg har roddet med, har da heldigvis være scriptbaserede. Og derved fuldt modificerbare, som det altid bør være. Hvis nogle CMS udviklere, kompilerer deres scipts eller what ever, er det et problem. Altså med mindre koden er lægger der sideløbende.

Forskellen er den samme. Et ordentligt CMS bør dog have en masse muligheder for udvidelse, så det ikke er nødvendigt med selve kildekoden til kernen. Hvis det ikke er tilfældet, så er systemet simpelthen ikke fleksibelt nok.

Fleksibilitet undskylder naturligvis aldrig, at nægte kunderne deres helt igennem legitime ret, til at have koden til de ting de bruger. Men derfor er fleksibilitet nu stadig en god ting, som der bør sigtes imod.

Det fungerer fint i praksis. Nu lader man jo ikke kildekoden ligge hos virksomheden selv, da det naturligvis vil medføre den proces, som du skitserer. De allerfleste betaler en uvildig advokat, der har en kontrakt på at skulle udlevere den i forbindelse med en konkurs.

Lyder som en mulig løsning. Men tror nu alligevel, man skal være varsom med at stole på den slags aftaler, i den slags situationer.

Lyder som en mulig løsning.

Som Acro siger: det bruges ude i den virkelige verden. Jeg ved personligt, at det er udbredt ved leverence af industrielle scada-systemer. Det er så samtidig systemer, der er egnede til den slags: typisk afleveres systemet først efter en lang acceptance-test og derefter er patches noget der (forhåbenlig sker sjældent), hvilket letter bøvlet med at opdatere deponeret kildekode.

#64 Pally

[@uote]Som Acro siger: det bruges ude i den virkelige verden. [/quote]

Hvad det så end dækker over?.
Jeg er mest nysgerrig over, om det er afprøvet i praksis.

Jeg ved personligt, at det er udbredt ved leverence af industrielle scada-systemer. Det er så samtidig systemer, der er egnede til den slags: typisk afleveres systemet først efter en lang acceptance-test og derefter er patches noget der (forhåbenlig sker sjældent), hvilket letter bøvlet med at opdatere deponeret kildekode.

Tjahh... Virker nu stadig, som et klamt hack til en defekt model.

#63 sKIDROw:

Det var naturligvis ikke pointen. Kan du spankulere ind af hoveddøren, og vade ind og kigge og snakke med koderne?. Jeg tvivler... ;)

Det har jeg heller intet behov for. Microsoft er i deres gode ret til at lave deres implementering fuldkommen lukket, og specifikationerne til standarden er tilgængelige, så jeg kan bygge min egen implementering, hvis det er mit ønske. Jeg har aldrig stødt på et problem, hvor jeg havde en fordel af at kunne kigge i koden. God dokumentation og gode værktøjer gør det overflødigt, og jeg ville sandsynligvis ikke få meget ud af at kigge i koden. De fleste fortalere for åben kildekode har typisk intet begreb om hvor stor en opgave, det er. Det er givetvis en fordel på sigt, men det kommer meget an på opgaven, om det er en rentabel fordel.

Jeg fremhævede så ikke Sun. Over en standard bør ingen part have det endelige ord, det bør vare en forsamling. Hvis man vil have det endelige ord, og bevare kontrollen er det fint nok. Så lad vær med at kalde det en standard... ;)

Du ville altså hellere have, at .NET var lukket, fremfor at Microsoft bestemmer den videre udvikling? Der er ingen grund til at have mistillid til, at Microsoft vil drive .NET langt, og at de naturligvis lytter til alle, der har indflydelse og interesse i .NET-verdenen. Alt andet ville da være dumt, når de nu gerne vil promovere deres platform og skabe succes bag den.

Hvis jeg prutter hver eneste gang, jeg skriver et indlæg på newz.dk, så er det også en standard. Læs eventuelt March to Your Own Standard.

De CMS løsninger jeg har roddet med, har da heldigvis være scriptbaserede. Og derved fuldt modificerbare, som det altid bør være. Hvis nogle CMS udviklere, kompilerer deres scipts eller what ever, er det et problem. Altså med mindre koden er lægger der sideløbende.

Det er ikke en god løsning, at et system er scriptbaseret. Du har brug for meget mere viden om systemet, hvis du skal rette i kilden, end hvis du vil skrive et modul op imod et API. Det bør aldrig være nødvendigt at rette i kilden. Hvis det er det, så er systemet simpelthen ikke godt nok gennemtænkt, men jeg må indrømme, at jeg heller ikke er stødt på mange CMS'er - properitære som frie, der har været ordentlige. Hvis du retter i et scriptbaseret system, så kan du sjældent opdatere det uden at skulle rette en gang til. Det er en besværlig proces, der kun medfører ulemper.

Fleksibilitet undskylder naturligvis aldrig, at nægte kunderne deres helt igennem legitime ret, til at have koden til de ting de bruger. Men derfor er fleksibilitet nu stadig en god ting, som der bør sigtes imod.

Det er ikke kundens legitime ret. At det er din holdning, det er ganske fair, men lovgivningen siger ikke, at kunden skal have retten til kildekoden. Lovgivningen sikrer både forbruger og producent, og det er en god ting, så kan man nemlig selv vælge, hvor man helst vil handle. At kalde det en legitim ret er useriøst, når det er for at fremme din egen holdning.

#66 Acro

Det har jeg heller intet behov for.

Hvilket jeg stadig ikke mener, ændre på noget som helst.

Microsoft er i deres gode ret til at lave deres implementering fuldkommen lukket, og specifikationerne til standarden er tilgængelige, så jeg kan bygge min egen implementering, hvis det er mit ønske.

Intet bør holdes lukket. Hverken specifikationer eller implementationer. Selvom jeg ikke giver meget, for den gode ret til at holde software lukket. Så er det nu heller ikke, fordi jeg vil forbyde noget. Men det er da en tendens, som må overflødiggøres.

Jeg har aldrig stødt på et problem, hvor jeg havde en fordel af at kunne kigge i koden. God dokumentation og gode værktøjer gør det overflødigt, og jeg ville sandsynligvis ikke få meget ud af at kigge i koden.

Stadig en dårlig undskyldning, for ikke at holde den tilgængelig alligevel. Nogen kan have glæde af den, enten af de grunde du nævner, eller for at lære af den.

De fleste fortalere for åben kildekode har typisk intet begreb om hvor stor en opgave, det er. Det er givetvis en fordel på sigt, men det kommer meget an på opgaven, om det er en rentabel fordel.

Det var da noget af det værste sludder jeg har hørt. Alle prominente fortalere fra FSF og OSI, er selv dygtige hackere. Selv Eben Moglen, FSFs chef jurist, har hacker bagrund. Har arbejdet for IBM, med at udvikle programmeringssprog. At pointen så er så klar, så selv folk som ikke udvikler kan forstå det, er så en anden snak. Men OSI og FSF, blev startet af kodere.

Du ville altså hellere have, at .NET var lukket, fremfor at Microsoft bestemmer den videre udvikling?

Har jeg ikke sagt. At have Microsoft til at styre .NET, er vel et lesser evil, end hvis det var lukket. Men det betyder stadig ikke, at det er optimalt.

Der er ingen grund til at have mistillid til, at Microsoft vil drive .NET langt, og at de naturligvis lytter til alle, der har indflydelse og interesse i .NET-verdenen. Alt andet ville da være dumt, når de nu gerne vil promovere deres platform og skabe succes bag den.

Det lyder jo godt alt sammen. Men der vil altid være konfliktende interesser. Og så er det skidt, hvis det er dem selv, som har det sidste ord.

Det er ikke en god løsning, at et system er scriptbaseret. Du har brug for meget mere viden om systemet, hvis du skal rette i kilden, end hvis du vil skrive et modul op imod et API.

De PHP baserede CMS systemer jeg har set, har haft tonsvis af udviddelser. Så den terskel, er tydeligvis mindre, end du vil gøre den til. Scriptopbygningen giver gennemsigtighed, og gennemsigtighed er altid godt.

Det bør aldrig være nødvendigt at rette i kilden. Hvis det er det, så er systemet simpelthen ikke godt nok gennemtænkt

Selv hvis folk ikke følte behovet, skal de da sandelig stadig have lov til det.

men jeg må indrømme, at jeg heller ikke er stødt på mange CMS'er - properitære som frie, der har været ordentlige. Hvis du retter i et scriptbaseret system, så kan du sjældent opdatere det uden at skulle rette en gang til. Det er en besværlig proces, der kun medfører ulemper.

Nej sådan er det jo. Om det medfører ulemper, må være op til den enkelte. Ingen undskyldning for at stoppe, de som ønsker at tage den vej.

Det er ikke kundens legitime ret. At det er din holdning, det er ganske fair, men lovgivningen siger ikke, at kunden skal have retten til kildekoden.

Når jeg taler om det, som folks helt ignnem legitime ret, så er det ikke en ret i juridisk forstand. Men i moralsk forstand. Koden bør være en del af en handel.

Lovgivningen sikrer både forbruger og producent, og det er en god ting, så kan man nemlig selv vælge, hvor man helst vil handle.

Lovgivningen i dag, sikre hovedsageligt producent, og giver nogle meget få indrømmelser til forbrugeren. Nogle der bliver færre og færre af, for hver justering de laver. Så her giver du loven, lagt mere credit end den fortjener på det punkt. Desværre.

At kalde det en legitim ret er useriøst, når det er for at fremme din egen holdning.

Ordet legitim kan misforstås, så jeg fremstår som at påstå, at det er en juridisk ret. Det er det eneste, jeg kan se forkert i min formulering. Jeg ser det stadig om en ret, som alle naturligvis bør have. Desuden er det, som du nok har fundet ud af efterhånden, langt mere end MIN holdning.

Skidrow:
Jeg må altså give Acro ret.

Det er tydeligt du ikke kender til software branchen.

Som jeg ser det er dine meninger om disse ting idiologisk og har ikke nødvendigvis den fjerneste ting med virkelighedens verden at gøre.

Den langt største del af udviklere rundt om i verdenen har intet imod at noget er lukket, at noget er properitært.
At Microsoft kobler sig op imod deres eget API giver jo fuldt ud mening, det er ligesom deres. Hvorfor pokker skulle de kræve at brugerne installete QT eller GTK for at kunne bruge det. Det giver brugerne en langt bedre brugeroplevelse at tingene starter hurtigere, ikke kræver extra ting installeret samt det ligner resten af systemmet.
Det er jo blandt andet derfor Java+Swing har fået en del tæv da det netop ikke har samme look&feel som resten af ens system.

Jeg er selv software udvikler og har arbejdet prof. med det i >10 år, både på closed source projekter, open source projekter, til web, til applikationer, til embeddede systemmer. Og det har ALDRIG været et problem at nogle ting man anvender er lukket, aldrig nogensinde.
Faktisk har open source tingene givet større problemmer, pga. ikke eksisterende support, elendig dokumentation, projektet bare dør (kan også ske med en closed source har bare ikke oplevet det).

Rent idiologisk er open source og 100% åbne standarder og alt lukket i teorien en god ting, det er bare ikke holdbart i virkelighedens verden.
Husk software branchen der kører med lukkede systemmer og properitære ting er LANGT størrere end open source er. Og begge dele kan udemærket eksistere samtidigt.
Da at begrænse den ene del af det absolut INTET har med friheden til at vælge at gøre. Friheden til dette er nemlig at jeg som udvikler, min arbejdsgiver som firma osv. SELV kan vælge om de vil bruge open eller closed source. At fjerne et af disse valg er og bliver en begrænsning.
Ligesom du selv har et valg om du vil bruge software der ikke opfylder din idiologi. Hvis du ikke har dette valg er din frihed blevet begrænset. (hvilket er noget OSS folkene ikke kan/vil indse)

#68 Disky

Jeg må altså give Acro ret.

Det er tydeligt du ikke kender til software branchen.

Det han skrev var at jeg ikke havde begreb om softwareudvikling, hviket jo er derfor jeg har købt bøger. Så det har han så evigt ret i... :D

Jeg har så heller ikke begreb om softwarebranchen, men det ønsker jeg bestemt heller ikke... ;)

Som jeg ser det er dine meninger om disse ting idiologisk og har ikke nødvendigvis den fjerneste ting med virkelighedens verden at gøre.

Igen glosen virklighedens verden?... :D
Lidt et tåget begreb.

Den langt største del af udviklere rundt om i verdenen har intet imod at noget er lukket, at noget er properitært.

Det tror da pokker, hvis de aldrig har været vant til andet?.. ;) At kineserne ikke modsætter sig censur, betyder heller ikke at det er i god ting... :)

At Microsoft kobler sig op imod deres eget API giver jo fuldt ud mening, det er ligesom deres. Hvorfor pokker skulle de kræve at brugerne installete QT eller GTK for at kunne bruge det. Det giver brugerne en langt bedre brugeroplevelse at tingene starter hurtigere, ikke kræver extra ting installeret samt det ligner resten af systemmet.

Her måtte jeg trække i land tidligere. Og derfor min skelnen. Hvis ovenstående gøres, så det ikke medfører lockins, så er jeg den varmeste tilhænger. Men hvis dette medfører at en byteocode skrevet mod MS .NET, ikke kan køres på nogle andre implementationer, så er ryger idéen jo med at bytecode kompilere... ;) OG mener da heller ikke, at Microsoft skulle benytte QT eller GTK. Pointerede blot, at de havde lov til det.

Det er jo blandt andet derfor Java+Swing har fået en del tæv da det netop ikke har samme look&feel som resten af ens system.

Konsistens er altid godt. Derfor er det bekymrende, hvis standarder fragmenterer. Noget af min oprindelige frygt, er så blevet afkræftet. OG det burdee mindre senere indlæg også afspejle.

Jeg er selv software udvikler og har arbejdet prof. med det i >10 år, både på closed source projekter, open source projekter, til web, til applikationer, til embeddede systemmer. Og det har ALDRIG været et problem at nogle ting man anvender er lukket, aldrig nogensinde.

Det er da kun godt hvis du ikke har haft gener af det.

Faktisk har open source tingene givet større problemmer, pga. ikke eksisterende support, elendig dokumentation, projektet bare dør (kan også ske med en closed source har bare ikke oplevet det).

Manglende support og elendig dokumentation, syntes jeg i lige så høj grad præger de proprietære produkter, som du ikke betaler en kejserlig formue for.

Rent idiologisk er open source og 100% åbne standarder og alt lukket i teorien en god ting, det er bare ikke holdbart i virkelighedens verden.

Ved ikke helt hvordan du ville have formuleret dig, men forstår ikke helt ovenstående.

Husk software branchen der kører med lukkede systemmer og properitære ting er LANGT størrere end open source er. Og begge dele kan udemærket eksistere samtidigt.

Større er nok afhængigt af, hvor du vælger at måle. Pengemæssigt naturligvis ja. Da fri og opensource ikke handler om penge, men da heller ikke udelukker det. Hvor vidt de KUNNE sameksistere, skal jeg ikke kunne udelukke. Hvis begge lejre ønskede dette så måske. Men når der bliver gjort ting, som konflikter med den anden, så fungerer det jo bare ikke. Patenter er et punkt, DRM et andet, lukkede standarder/lockins et tredie.

Da at begrænse den ene del af det absolut INTET har med friheden til at vælge at gøre.

Nej men det er jo det som sker i dag?.
Mange af de love, som lejfler for den proprietære side, er stærkt hæmmende for fri og opensource udviklingen.
Og så er det jeg stræber efter, jo også langt mere end friheden til at vælge. Valget mellem flere proprietære softwarepakker, er jo som at vælge mellem at bo i Kina eller Nordkorea... :D

Friheden til dette er nemlig at jeg som udvikler, min arbejdsgiver som firma osv. SELV kan vælge om de vil bruge open eller closed source. At fjerne et af disse valg er og bliver en begrænsning.

Se DU har altid valget, det har jeg også. Hvis DU vælger at sælge under et sæt betingelser, og jeg vil have andre betingelser, så har vi ingen handel. Hvis flere så (fra)vælger som jeg, så har du stadig dit valg. Men ikke nogen forretning. Det er der ingen tvang i, det er rent og skær markedsmekanismer.. ;)

Ligesom du selv har et valg om du vil bruge software der ikke opfylder din idiologi. Hvis du ikke har dette valg er din frihed blevet begrænset. (hvilket er noget OSS folkene ikke kan/vil indse)

Se nu er der ikke nogen af os der siger: "Du må ikke bruge det der, fordi det er ikke frit/åbent..." Det kan dog gøre mig lidt irriteret, hvis dit valg af en komponent X, hindre mig i at kommunikere med dig med komponent Y... ;) Men vi kan godt finde på at sige: "Jeg syntes du burde overveje, ikke at bruge den slags software på grund af...." Derfor har du og vil altid have dit frie valg til at gøre det alligevel da... ;)