mboost-dp1
unknown
Det ser ud til at skyos.org er død, lige i øjeblikket. De vender nok snart tilbage :)
Og til dem der (altid) brokker sig over nyheder om små systemer, så husk at det er kategorien "OS - Andet" der skal fravælges...
Og til dem der (altid) brokker sig over nyheder om små systemer, så husk at det er kategorien "OS - Andet" der skal fravælges...
Hvad skyldes monstro årsagen til OpenDarwins nedtur? På papiret lyder det da spændende. MacOS er, trods det aldrig bliver mit primære OS, aldeles glimrende.
Men, som jeg forstår det, så var idéen med OpenDarwin at projekter skulle tages derfra og inkorporeres i MacOSX. Og så forstår jeg godt community'ets modvillighed for at deltage. Dermed kunne Apple tage kode fra projektet og sælge det til x antal kroner kommercielt? er det fair overfor de programmører der har lavet tilføjelser gratis?
Men, som jeg forstår det, så var idéen med OpenDarwin at projekter skulle tages derfra og inkorporeres i MacOSX. Og så forstår jeg godt community'ets modvillighed for at deltage. Dermed kunne Apple tage kode fra projektet og sælge det til x antal kroner kommercielt? er det fair overfor de programmører der har lavet tilføjelser gratis?
Grunden til de lukker er simpelt, manglende interesse - og fremtid af samme grund.
OpenDarwin baseres på Darwin som er platformen for OSX. Nu da Apple skifter til X86 og den gren af Darwin ikke kommer som opensource (for at undgå at al hardware kan køre OSX), vil OpenDarwin ikke nemt kunne komme til at køre på X86. Desuden findes der nok OS' som kører x86.
" er det fair overfor de programmører der har lavet tilføjelser gratis?"
Det blir da aldrig et problem. Apple kan ikke undgå licenserne. Hvis licensen ikke passer, kan de ikke bruge det. Det er også af den grund apple overhovedet har darwin ude som opensource, for det er de forpligtede til iht. de licenser som følger med softwaren som de har baseret deres eget OS på.
OpenDarwin baseres på Darwin som er platformen for OSX. Nu da Apple skifter til X86 og den gren af Darwin ikke kommer som opensource (for at undgå at al hardware kan køre OSX), vil OpenDarwin ikke nemt kunne komme til at køre på X86. Desuden findes der nok OS' som kører x86.
" er det fair overfor de programmører der har lavet tilføjelser gratis?"
Det blir da aldrig et problem. Apple kan ikke undgå licenserne. Hvis licensen ikke passer, kan de ikke bruge det. Det er også af den grund apple overhovedet har darwin ude som opensource, for det er de forpligtede til iht. de licenser som følger med softwaren som de har baseret deres eget OS på.
#2
Det er en del af problemet.
Hvad er det vigtigste ved MacOS, når folk bruger det? Det er ikke kun rå funktionalitet, det er desktoppen... Og OpenDarwin fik aldrig MacOS X's desktop, hvis jeg husker rigtigt.
Så ikke nok med at folk arbejde grais for Apple, Apple forhindre dem i praksis i at lave et alternativ til MacOS X, selvom licensen tillod det.
-----
#3
Der var skam engang hvor OpenDarwin kunne køre på x86 ;)
Det er en del af problemet.
Hvad er det vigtigste ved MacOS, når folk bruger det? Det er ikke kun rå funktionalitet, det er desktoppen... Og OpenDarwin fik aldrig MacOS X's desktop, hvis jeg husker rigtigt.
Så ikke nok med at folk arbejde grais for Apple, Apple forhindre dem i praksis i at lave et alternativ til MacOS X, selvom licensen tillod det.
-----
#3
Der var skam engang hvor OpenDarwin kunne køre på x86 ;)
Den retning OpenDarwin tog, var i forvejen en skandale. Så at lukke det ned, var vel forudsigeligt efterhånden.
Apples sympati for åbenhed, var åbenlyst et bedrag af format. Det blev tydeligt allerede, da de lukkede kernen til X86 versionen.
SkyOS har jeg aldrig fundet ud af ret meget om, siden jeg så deres distributionsform. Ufrit.
#3 Duckfighter
Tværtimod.
Vi kan aldrig få nok forskellige OS'er, ellers dør alsidigheden og innovationen lige så langsomt.
Apples sympati for åbenhed, var åbenlyst et bedrag af format. Det blev tydeligt allerede, da de lukkede kernen til X86 versionen.
SkyOS har jeg aldrig fundet ud af ret meget om, siden jeg så deres distributionsform. Ufrit.
#3 Duckfighter
Desuden findes der nok OS' som kører x86.
Tværtimod.
Vi kan aldrig få nok forskellige OS'er, ellers dør alsidigheden og innovationen lige så langsomt.
#6 Disky
Mener jeg personligt er irrelevant. So what om programmerne ikke kan køres på tværs af OS'er?. Er de baseret på en standard a'la POSSIX, er de som regel rimeligt porterbare. Tit drejer det sig blot, om en rekompilering. Så bliver det næppe lettere. Folk på platform R mangler program U, og så sætter de sig for at porte det over. Med tiden vil ting som .NET, når det bliver fundt funktionsdygtigt overalt, sikkert gøre dette endnu nemmere. Men alsidigheden må aldrig ofres, på grund af noget så trivielt som programmer. Det er ikke et problem, det er en arbejdsopgave som skal løses.
Læg mærke til at jeg skriver 'dør lige så langsomt'.
Hvad vi har set på Wintel platformet i mange år, var en meget faldende innovation både på software og hardware delen. Faktisk indtil godt op i 90'erne.
Nu ser dette ud til at ændre sig, i takt med at markedet bliver lidt mere alsidigt.
Intel tvinges til at tænke nyt på grund af AMD og omvendt for den sags skyld. Og Microsoft tvinges til at tænke nyt, på grund af Apple og omvendt. Sidstnævnte systemer, kan heller ikke køre hinandens programmer. Men dette udgører ikke noget reelt problem.
Alsidigheden er også en ulempe, nemlig fordi tingene er forskellige og de forskellige systemmer ikke kan køre hinandens programmer.
Mener jeg personligt er irrelevant. So what om programmerne ikke kan køres på tværs af OS'er?. Er de baseret på en standard a'la POSSIX, er de som regel rimeligt porterbare. Tit drejer det sig blot, om en rekompilering. Så bliver det næppe lettere. Folk på platform R mangler program U, og så sætter de sig for at porte det over. Med tiden vil ting som .NET, når det bliver fundt funktionsdygtigt overalt, sikkert gøre dette endnu nemmere. Men alsidigheden må aldrig ofres, på grund af noget så trivielt som programmer. Det er ikke et problem, det er en arbejdsopgave som skal løses.
At tro innovationen dør pga. er ikke korrekt.
Læg mærke til at jeg skriver 'dør lige så langsomt'.
Hvad vi har set på Wintel platformet i mange år, var en meget faldende innovation både på software og hardware delen. Faktisk indtil godt op i 90'erne.
Nu ser dette ud til at ændre sig, i takt med at markedet bliver lidt mere alsidigt.
Intel tvinges til at tænke nyt på grund af AMD og omvendt for den sags skyld. Og Microsoft tvinges til at tænke nyt, på grund af Apple og omvendt. Sidstnævnte systemer, kan heller ikke køre hinandens programmer. Men dette udgører ikke noget reelt problem.
#8
"Folk på platform R mangler program U, og så sætter de sig for at porte det over. Med tiden vil ting som .NET, når det bliver fundt funktionsdygtigt overalt, sikkert gøre dette endnu nemmere."
Hmm.. jaeh.. måske, men f.eks Java har eksisteret siden 1994, og jeg synes det er et fåtal af programmer, der har udnyttet Javas crossplatform muligheder.
"Folk på platform R mangler program U, og så sætter de sig for at porte det over. Med tiden vil ting som .NET, når det bliver fundt funktionsdygtigt overalt, sikkert gøre dette endnu nemmere."
Hmm.. jaeh.. måske, men f.eks Java har eksisteret siden 1994, og jeg synes det er et fåtal af programmer, der har udnyttet Javas crossplatform muligheder.
#8
Du har ikke helt ret i den første halvdel af dit indlæg (set derfra hvor jeg sidder).
Hvis vi taler om systemer som BeOS (Haiku & Zeta), SkyOS, og Syllable, så er alle systemerne i høj grad POSIX kompatible, men det betyder absolut ikke at man kan flytte programmerne, med minimale ændringer.
På netop disse platforme er der kun en begrænset brug af CLI software, da disse systemer er skabt som GUI OS'er. Og GUI'et er altså ikke X...
Hvis man vil flytte programmer mellem BeOS, SkyOS og Syllable, så skal GUI'et skrives forfra, og endnu mere problematisk bliver det hvis man forsøger at portere Linux/Windows software, for disse systemer kan ikke gøre brug af de muligheder der forefindes i de førnævnte små systemer.
For at tage FireFox som et eksempel, så er der voldsomme stabilitetsproblemer, på både SkyOS og BeOS, fordi store dele af browseren skal skrives om. Nogenlunde det samme er grunden til at vi ikke har FF.
At portere GUI software er et meget stort arbejde, og mange gange så er der ganske enkelt ikke mandskab til at omskrive så stor en del af koden, som det ofte er nødvendig.
Men at innovationen trives, dét er der ingen tvivl om :)
[edit]
I den første linje skrev jeg: "(set derfra hvor jeg sidder)"
Hvis man sidder et andet sted, og ser på *NIX systemer, der er POSIX kompatible, og har X ovenpå, så er der ikke den store tvivl om at du har ret. Med X, så kan man få QT og GTK(+), og med de tre ting, så er der ikke mange hindringer tilbage, da *NIX systemerne derudover er opbygget stortset end.
[/edit]
Du har ikke helt ret i den første halvdel af dit indlæg (set derfra hvor jeg sidder).
Hvis vi taler om systemer som BeOS (Haiku & Zeta), SkyOS, og Syllable, så er alle systemerne i høj grad POSIX kompatible, men det betyder absolut ikke at man kan flytte programmerne, med minimale ændringer.
På netop disse platforme er der kun en begrænset brug af CLI software, da disse systemer er skabt som GUI OS'er. Og GUI'et er altså ikke X...
Hvis man vil flytte programmer mellem BeOS, SkyOS og Syllable, så skal GUI'et skrives forfra, og endnu mere problematisk bliver det hvis man forsøger at portere Linux/Windows software, for disse systemer kan ikke gøre brug af de muligheder der forefindes i de førnævnte små systemer.
For at tage FireFox som et eksempel, så er der voldsomme stabilitetsproblemer, på både SkyOS og BeOS, fordi store dele af browseren skal skrives om. Nogenlunde det samme er grunden til at vi ikke har FF.
At portere GUI software er et meget stort arbejde, og mange gange så er der ganske enkelt ikke mandskab til at omskrive så stor en del af koden, som det ofte er nødvendig.
Men at innovationen trives, dét er der ingen tvivl om :)
[edit]
I den første linje skrev jeg: "(set derfra hvor jeg sidder)"
Hvis man sidder et andet sted, og ser på *NIX systemer, der er POSIX kompatible, og har X ovenpå, så er der ikke den store tvivl om at du har ret. Med X, så kan man få QT og GTK(+), og med de tre ting, så er der ikke mange hindringer tilbage, da *NIX systemerne derudover er opbygget stortset end.
[/edit]
#7
Jeg kan ikke se problemet i at det er svært at porte programmer. Et operativsystem bruger én webbrowser, et andet bruger en anden webbrowser, men fælles for dem er at de kan læse html-sider og browse rundt på internettet. Åbne standarder: Så længe alle programmer kan kommunikere på tværs (og på tværs af operativsystemer), så er der ingen problemer. Så vil jeg hilse alle nye operativsystemer velkommen.
HTML er et eksempel, hvor næsten alle kan være med. Det modsatte eksempel, efter min mening, er fildeling (altså på netværket a la SAMBA og NFS). SAMBA er svær at sætte op og få til at køre perfekt, når den skal spille sammen med en Microsoft Domain Controller, Linux klienter og Windows klienter af forskellige versioner. Desuden er det alt for kompliceret at implementere i et lille operativsystem. En åben standard ville gøre sig godt på det område.
Jeg kan ikke se problemet i at det er svært at porte programmer. Et operativsystem bruger én webbrowser, et andet bruger en anden webbrowser, men fælles for dem er at de kan læse html-sider og browse rundt på internettet. Åbne standarder: Så længe alle programmer kan kommunikere på tværs (og på tværs af operativsystemer), så er der ingen problemer. Så vil jeg hilse alle nye operativsystemer velkommen.
HTML er et eksempel, hvor næsten alle kan være med. Det modsatte eksempel, efter min mening, er fildeling (altså på netværket a la SAMBA og NFS). SAMBA er svær at sætte op og få til at køre perfekt, når den skal spille sammen med en Microsoft Domain Controller, Linux klienter og Windows klienter af forskellige versioner. Desuden er det alt for kompliceret at implementere i et lille operativsystem. En åben standard ville gøre sig godt på det område.
#9 Simm
Jeg tror personligt heller ikke på, at WORA* er andet end en idyllisk drøm desværre.
* Write Once - Run Anywhere.
Jeg tror fokus må holdes på at koden holdes så porterbar som muligt, vha nogle standarder på flere områder.
#10 BurningShadow
Jeg forsimplede min pointe lidt for meget. POSSIX hjælper på det, men garantere naturligvis ikke at det bliver piece of cake... :) Jeg efterlyser også flere standarder, som kan gøre portarbarheden på kryds af de frie OS'er nemmere og hurtigere.
Her er freedesktop.org et godt initiativ, omend GNU/Linux fokuseret, kan de andre sikkert hægte sig på, i alle ikke-X henseender.
Nej det udgører naturligvis en hurdle. Ikke nødvendigvis hvad jeg ville betegne som et problem, for jeg er ikke ubetinget glad for X.
I længden tror jeg løsningen må være en standard, som adskiller grafiklaget fra guikoden. Programmet kan så skrivet herimod, og vil virke ens på tvært af disse. Men det ved jeg jo så ikke, hvor glade disse er for... ;) Løsningen må jo så være, at gøre dette lag så tyndt og transparant som muligt?.
Hvor der er vije er der vej. Amiga folket er vist i samme båd, og er som jeg ser det ekstremt opsatte... hehe
Hvis det har tilstrækkelig med interesse, så kommer det med mandskabet helt af sig selv.
Det er den bedste måde at sikre innovation, at lade folk rende i vidt forskellige retninger, og så lade tiden vise hvilken vej som var mest farbar.
Jeg tror personligt heller ikke på, at WORA* er andet end en idyllisk drøm desværre.
* Write Once - Run Anywhere.
Jeg tror fokus må holdes på at koden holdes så porterbar som muligt, vha nogle standarder på flere områder.
#10 BurningShadow
Du har ikke helt ret i den første halvdel af dit indlæg (set derfra hvor jeg sidder).
Hvis vi taler om systemer som BeOS (Haiku & Zeta), SkyOS, og Syllable, så er alle systemerne i høj grad POSIX kompatible, men det betyder absolut ikke at man kan flytte programmerne, med minimale ændringer.
Jeg forsimplede min pointe lidt for meget. POSSIX hjælper på det, men garantere naturligvis ikke at det bliver piece of cake... :) Jeg efterlyser også flere standarder, som kan gøre portarbarheden på kryds af de frie OS'er nemmere og hurtigere.
Her er freedesktop.org et godt initiativ, omend GNU/Linux fokuseret, kan de andre sikkert hægte sig på, i alle ikke-X henseender.
På netop disse platforme er der kun en begrænset brug af CLI software, da disse systemer er skabt som GUI OS'er. Og GUI'et er altså ikke X...
Nej det udgører naturligvis en hurdle. Ikke nødvendigvis hvad jeg ville betegne som et problem, for jeg er ikke ubetinget glad for X.
Hvis man vil flytte programmer mellem BeOS, SkyOS og Syllable, så skal GUI'et skrives forfra, og endnu mere problematisk bliver det hvis man forsøger at portere Linux/Windows software, for disse systemer kan ikke gøre brug af de muligheder der forefindes i de førnævnte små systemer.
I længden tror jeg løsningen må være en standard, som adskiller grafiklaget fra guikoden. Programmet kan så skrivet herimod, og vil virke ens på tvært af disse. Men det ved jeg jo så ikke, hvor glade disse er for... ;) Løsningen må jo så være, at gøre dette lag så tyndt og transparant som muligt?.
For at tage FireFox som et eksempel, så er der voldsomme stabilitetsproblemer, på både SkyOS og BeOS, fordi store dele af browseren skal skrives om. Nogenlunde det samme er grunden til at vi ikke har FF.
Hvor der er vije er der vej. Amiga folket er vist i samme båd, og er som jeg ser det ekstremt opsatte... hehe
At portere GUI software er et meget stort arbejde, og mange gange så er der ganske enkelt ikke mandskab til at omskrive så stor en del af koden, som det ofte er nødvendig.
Hvis det har tilstrækkelig med interesse, så kommer det med mandskabet helt af sig selv.
Men at innovationen trives, dét er der ingen tvivl om :)
Det er den bedste måde at sikre innovation, at lade folk rende i vidt forskellige retninger, og så lade tiden vise hvilken vej som var mest farbar.
#12
"I længden tror jeg løsningen må være en standard, som adskiller grafiklaget fra guikoden. Programmet kan så skrivet herimod, og vil virke ens på tvært af disse. Men det ved jeg jo så ikke, hvor glade disse er for... ;) Løsningen må jo så være, at gøre dette lag så tyndt og transparant som muligt?."
Helt enig!
Dog er jeg bange for at motivationen kunne have været større... De vil alle beholde deres egne, har jeg en fornemmelse af. Og selvom der absolut ikke er krig (de rygter der tidligere har været på både OSNews og /. har været i stærk modstrid med virkeligheden), så betyder det dog heller heller ikke at de inviterer hinanden med til deres bryllupper ;)
Men hvis man gjorde det, og evt. lavede et fælles driver interface, så ville de stå stærkt.
"I længden tror jeg løsningen må være en standard, som adskiller grafiklaget fra guikoden. Programmet kan så skrivet herimod, og vil virke ens på tvært af disse. Men det ved jeg jo så ikke, hvor glade disse er for... ;) Løsningen må jo så være, at gøre dette lag så tyndt og transparant som muligt?."
Helt enig!
Dog er jeg bange for at motivationen kunne have været større... De vil alle beholde deres egne, har jeg en fornemmelse af. Og selvom der absolut ikke er krig (de rygter der tidligere har været på både OSNews og /. har været i stærk modstrid med virkeligheden), så betyder det dog heller heller ikke at de inviterer hinanden med til deres bryllupper ;)
Men hvis man gjorde det, og evt. lavede et fælles driver interface, så ville de stå stærkt.
#9
Javas cross platform muligheder udnyttes til dels i server apps,
udviklings vaerktøjer, spil til mobil og den slags.
Det store desktop marked (læs: Windows) har aldrig taget Java
til sig.
Det er der sikkert flere årsager til. Et par af dem er:
- performance af GUI apps skrevet i Java de første mange
år var dybt utilfredsstillende, idag har man så fået optimeret
meget og PC'ere er blevet de der 10-15 gange hurtige, men
mange udviklere husker med gru deres første erfaringer
- MS's modvilje mod Java, de lavede de en ukompatibel Java
som ikke blev opdateret og til sidst blev fjernet, de meget
omtalte hr. og fru Jensen henter ikke Java fra SUN og
installerer
Javas cross platform muligheder udnyttes til dels i server apps,
udviklings vaerktøjer, spil til mobil og den slags.
Det store desktop marked (læs: Windows) har aldrig taget Java
til sig.
Det er der sikkert flere årsager til. Et par af dem er:
- performance af GUI apps skrevet i Java de første mange
år var dybt utilfredsstillende, idag har man så fået optimeret
meget og PC'ere er blevet de der 10-15 gange hurtige, men
mange udviklere husker med gru deres første erfaringer
- MS's modvilje mod Java, de lavede de en ukompatibel Java
som ikke blev opdateret og til sidst blev fjernet, de meget
omtalte hr. og fru Jensen henter ikke Java fra SUN og
installerer
Skidrow:
At du tror Posix (jeg går ud fra det er det du mener) alene vil gøre at det er nemt at portere et program, viser at dit kendskab til software udvikling er minimalt. Hvilket du også har indrømmet her på sitet flere gange :)
GUI f.eks. er ikke noget du bare lige portere :-) Som andre jo også fint beskriver.
<ironi>
Men ligesom vi jo bare alle skal følge posix for at opnå porterbarhed ifølge dig, så kan vi jo slå 2 fluer med et smæk, hvis alle nu udvikler til Super OS V3.6, så kan alle køre alles programmer og så slipper vi helt for bøvlet med porterbarhed. Se det ville jo være smart ikke ?</ironi>
Hvis alle nu følger POSIX, så er valgfriheden jo røget sig en tur, og det er i sig selv blive en låst standard. Hvis porterbarhed kræver ALLE følger POSIX, så er vi jo netop låst på en måde der minder meget om det du normalt prædiker imod :)
Samt innovationen på dette områder forsvinder også, fordi alle bare skal følge denne standard :) Så du har ret i at innovationen dør hvis vi alle følger denne ene standard.
Helt enig, men hvorfor skal vi så alle følge POSIX ? Så forsvinder innovationen jo på dette område, fordi ingen gider lave noget der er bedre, eller anderledes. Selvfølgelig fortsætter udviklingen af posix, men ikke på samme konkurrerende måde som i dag.
Som andre siger, kunne vi jo bare alle sammen udvikle til Java, men det er i jo heller ikke tilfredse med, pga. den lille detalje at det i mange år ikke var åbent (er på vej). Denne lille detalje generer kun en lille flok mennesker, vi er rigtigt mange Java udviklere som ALDRIG har haft problemmer med dette.
<lettere overdrevet>
Så kort sagt, så skal vi alle følge en standard i sprog, en standard i design, et fast OS der bygger på posix, og vi skal vel også alle sammen bruge samme CPU, samme mængde ram og ellers alle være ens. Så bliver det meget meget nemmere at udvikle programmer og dele dem med naboen.
Er det virkeligt dette du ønsker ?
</lettere overdrevet>
Du siger godt nok alsidigheden aldrig må ofres, men det er jo netop det der sker hvis alle skal bruge den samme standard. :-)
p.s. Dette er trukket ud i det extreme, men det er for at understrege at let portering også har sin pris. Som du sjovt nok selv siger du ikke er ville til at betale.
At du tror Posix (jeg går ud fra det er det du mener) alene vil gøre at det er nemt at portere et program, viser at dit kendskab til software udvikling er minimalt. Hvilket du også har indrømmet her på sitet flere gange :)
GUI f.eks. er ikke noget du bare lige portere :-) Som andre jo også fint beskriver.
<ironi>
Men ligesom vi jo bare alle skal følge posix for at opnå porterbarhed ifølge dig, så kan vi jo slå 2 fluer med et smæk, hvis alle nu udvikler til Super OS V3.6, så kan alle køre alles programmer og så slipper vi helt for bøvlet med porterbarhed. Se det ville jo være smart ikke ?</ironi>
Hvis alle nu følger POSIX, så er valgfriheden jo røget sig en tur, og det er i sig selv blive en låst standard. Hvis porterbarhed kræver ALLE følger POSIX, så er vi jo netop låst på en måde der minder meget om det du normalt prædiker imod :)
Samt innovationen på dette områder forsvinder også, fordi alle bare skal følge denne standard :) Så du har ret i at innovationen dør hvis vi alle følger denne ene standard.
Intel tvinges til at tænke nyt på grund af AMD og omvendt for den sags skyld. Og Microsoft tvinges til at tænke nyt, på grund af Apple og omvendt. Sidstnævnte systemer, kan heller ikke køre hinandens programmer. Men dette udgører ikke noget reelt problem.
Helt enig, men hvorfor skal vi så alle følge POSIX ? Så forsvinder innovationen jo på dette område, fordi ingen gider lave noget der er bedre, eller anderledes. Selvfølgelig fortsætter udviklingen af posix, men ikke på samme konkurrerende måde som i dag.
Som andre siger, kunne vi jo bare alle sammen udvikle til Java, men det er i jo heller ikke tilfredse med, pga. den lille detalje at det i mange år ikke var åbent (er på vej). Denne lille detalje generer kun en lille flok mennesker, vi er rigtigt mange Java udviklere som ALDRIG har haft problemmer med dette.
<lettere overdrevet>
Så kort sagt, så skal vi alle følge en standard i sprog, en standard i design, et fast OS der bygger på posix, og vi skal vel også alle sammen bruge samme CPU, samme mængde ram og ellers alle være ens. Så bliver det meget meget nemmere at udvikle programmer og dele dem med naboen.
Er det virkeligt dette du ønsker ?
</lettere overdrevet>
Du siger godt nok alsidigheden aldrig må ofres, men det er jo netop det der sker hvis alle skal bruge den samme standard. :-)
p.s. Dette er trukket ud i det extreme, men det er for at understrege at let portering også har sin pris. Som du sjovt nok selv siger du ikke er ville til at betale.
#16 Disky
Jeg kom til at formulere migt forkert... :)
Istedet for at sige at posix er LØSNINGEN, så skulle jeg have udtrykt at posix er en del af løsningen. Generelt er standardER løsningen. Selvsagt kan en standard ikke helt klare opgaven, specielt når den standard vi taler om er meget grundlæggende og lowlevel.
Nej det er naturligvis rigtigt.
Nej det var ikke der jeg ville hen. Jeg diskutere hvordan programmer gøres lettere at flytte, fordi jeg er meget modstandarder af one OS fits all myten.
Se hvis man ser standarder som noget man bliver låst til, så er det jo at det går galt. Standarder er det fælles udgangspunkt, som man kan vende tilbage til. Den laveste fællesnævner, som alle kan følge og gøre gavn af. Standarder behøver absolut heller ikke at være låst fast, men kan vedligeholdes i en neutral forsamling. Lidt som HTML og CSS bliver det. Ovenpå standarder er der plads, til masser af innovation. Når det er sagt kan der da også sagtens udvikles nye ting, som man så standardiserer senere, når man ved at det bliver det man håbede på.
Alle nyudviklede ting gennemgår jo en modningsperiode, inden de bliver standardiserede. Det i sig selv er jo innovation. Vi får jo også med tiden, brug for nye standarder som kommer til og bliver standardiseret når de er modne til det. Innovation og standarder, er ikke en og samme snak. Men de behøver bestemt ikke, at være hinandens modstandere, hvis man ikke ønsker at de skal være det. Innovationen går nogle år forud for standardiseringen, er sådan jeg foretrækker at se på det.
Jamen jeg er kun glad for, hvis der dukker andre standarder op, som løser opgaven endnu bedre end posix. Og hvis blot det virkelig ER standarder, så er det kun godt. SKAL vi så allesammen, følge samme standard?. Næhh ikke nødvendigvis. Vi skal da helst selv, kunne se vores fordele af det.
Sproget er jo standardiseret. Men den fortolker som alle skriver op imod, er under restriktive vilkår. Det er den eneste ændring som er tiltrængt. Sun overrasker mig så, i at de faktisk har meldt ud at alt deres software skal være både gratis og fri og opensource software. Og deres nyeste CPU design, er licenseret under GPL, så alle er velkommen til at tage designet og udvikle videre på, under copyleft vilkår.
Nu er jeg ikke spåkone, og det præcise tal på, hvor mange det generer, vil jeg ikke gætte på. Men den restriktive natur, har alle dage gjort tingene mere besværlige end nødvendigt. Specielt installationsmæssigt. Et eksempel er at man ikke måtte videredistribuere JRE/JDK pakkerne, så ikke noget med blot at have dem i de sædvanlige pakkesystemer. Nej man skal trækkes igennem en side, og en gang juraævl.
Nu startede jeg med at konstantere, at jeg ønsker LANGT flere cpu arkitekturer. Så den del har jeg svaret på... ;) Jeg ønsker BESTEMT heller ikke samme OS. Specielt fordi jeg har set, hvilken form dette så ville tage. Både konstruktions og licensmæssigt. Hvor sidstnævnte detalje er kvalmende. Når jeg nævnte standarder, så var det for at kommenterer påstanden om at flere CPU arkitekturer, giver færre programmer osv. Og her siger jeg nej, ikke hvis man følger standarder. Flere arkitekturer er kun et problem, hvis man lader det blive det... ;)
Som sagt er alsidighed/innovation og brugen af standarder, ikke automatisk hinandens fjender. Men det er to forskellige tankegange, som kan konflikte hvis ikke man værdsætte begge dele.
Og min pointe er så at der findes rimelige kompromis'er, som gør begge dele mulige.
At du tror Posix (jeg går ud fra det er det du mener) alene vil gøre at det er nemt at portere et program, viser at dit kendskab til software udvikling er minimalt. Hvilket du også har indrømmet her på sitet flere gange :)
Jeg kom til at formulere migt forkert... :)
Istedet for at sige at posix er LØSNINGEN, så skulle jeg have udtrykt at posix er en del af løsningen. Generelt er standardER løsningen. Selvsagt kan en standard ikke helt klare opgaven, specielt når den standard vi taler om er meget grundlæggende og lowlevel.
GUI f.eks. er ikke noget du bare lige portere :-) Som andre jo også fint beskriver.
Nej det er naturligvis rigtigt.
<ironi>
Men ligesom vi jo bare alle skal følge posix for at opnå porterbarhed ifølge dig, så kan vi jo slå 2 fluer med et smæk, hvis alle nu udvikler til Super OS V3.6, så kan alle køre alles programmer og så slipper vi helt for bøvlet med porterbarhed. Se det ville jo være smart ikke ?</ironi>
Nej det var ikke der jeg ville hen. Jeg diskutere hvordan programmer gøres lettere at flytte, fordi jeg er meget modstandarder af one OS fits all myten.
Hvis alle nu følger POSIX, så er valgfriheden jo røget sig en tur, og det er i sig selv blive en låst standard. Hvis porterbarhed kræver ALLE følger POSIX, så er vi jo netop låst på en måde der minder meget om det du normalt prædiker imod :)
Se hvis man ser standarder som noget man bliver låst til, så er det jo at det går galt. Standarder er det fælles udgangspunkt, som man kan vende tilbage til. Den laveste fællesnævner, som alle kan følge og gøre gavn af. Standarder behøver absolut heller ikke at være låst fast, men kan vedligeholdes i en neutral forsamling. Lidt som HTML og CSS bliver det. Ovenpå standarder er der plads, til masser af innovation. Når det er sagt kan der da også sagtens udvikles nye ting, som man så standardiserer senere, når man ved at det bliver det man håbede på.
Samt innovationen på dette områder forsvinder også, fordi alle bare skal følge denne standard :) Så du har ret i at innovationen dør hvis vi alle følger denne ene standard.
Alle nyudviklede ting gennemgår jo en modningsperiode, inden de bliver standardiserede. Det i sig selv er jo innovation. Vi får jo også med tiden, brug for nye standarder som kommer til og bliver standardiseret når de er modne til det. Innovation og standarder, er ikke en og samme snak. Men de behøver bestemt ikke, at være hinandens modstandere, hvis man ikke ønsker at de skal være det. Innovationen går nogle år forud for standardiseringen, er sådan jeg foretrækker at se på det.
Helt enig, men hvorfor skal vi så alle følge POSIX ? Så forsvinder innovationen jo på dette område, fordi ingen gider lave noget der er bedre, eller anderledes. Selvfølgelig fortsætter udviklingen af posix, men ikke på samme konkurrerende måde som i dag.
Jamen jeg er kun glad for, hvis der dukker andre standarder op, som løser opgaven endnu bedre end posix. Og hvis blot det virkelig ER standarder, så er det kun godt. SKAL vi så allesammen, følge samme standard?. Næhh ikke nødvendigvis. Vi skal da helst selv, kunne se vores fordele af det.
Som andre siger, kunne vi jo bare alle sammen udvikle til Java, men det er i jo heller ikke tilfredse med, pga. den lille detalje at det i mange år ikke var åbent (er på vej).
Sproget er jo standardiseret. Men den fortolker som alle skriver op imod, er under restriktive vilkår. Det er den eneste ændring som er tiltrængt. Sun overrasker mig så, i at de faktisk har meldt ud at alt deres software skal være både gratis og fri og opensource software. Og deres nyeste CPU design, er licenseret under GPL, så alle er velkommen til at tage designet og udvikle videre på, under copyleft vilkår.
Denne lille detalje generer kun en lille flok mennesker, vi er rigtigt mange Java udviklere som ALDRIG har haft problemmer med dette.
Nu er jeg ikke spåkone, og det præcise tal på, hvor mange det generer, vil jeg ikke gætte på. Men den restriktive natur, har alle dage gjort tingene mere besværlige end nødvendigt. Specielt installationsmæssigt. Et eksempel er at man ikke måtte videredistribuere JRE/JDK pakkerne, så ikke noget med blot at have dem i de sædvanlige pakkesystemer. Nej man skal trækkes igennem en side, og en gang juraævl.
<lettere overdrevet>
Så kort sagt, så skal vi alle følge en standard i sprog, en standard i design, et fast OS der bygger på posix, og vi skal vel også alle sammen bruge samme CPU, samme mængde ram og ellers alle være ens. Så bliver det meget meget nemmere at udvikle programmer og dele dem med naboen.
Er det virkeligt dette du ønsker ?
</lettere overdrevet>
Nu startede jeg med at konstantere, at jeg ønsker LANGT flere cpu arkitekturer. Så den del har jeg svaret på... ;) Jeg ønsker BESTEMT heller ikke samme OS. Specielt fordi jeg har set, hvilken form dette så ville tage. Både konstruktions og licensmæssigt. Hvor sidstnævnte detalje er kvalmende. Når jeg nævnte standarder, så var det for at kommenterer påstanden om at flere CPU arkitekturer, giver færre programmer osv. Og her siger jeg nej, ikke hvis man følger standarder. Flere arkitekturer er kun et problem, hvis man lader det blive det... ;)
Du siger godt nok alsidigheden aldrig må ofres, men det er jo netop det der sker hvis alle skal bruge den samme standard. :-)
Som sagt er alsidighed/innovation og brugen af standarder, ikke automatisk hinandens fjender. Men det er to forskellige tankegange, som kan konflikte hvis ikke man værdsætte begge dele.
p.s. Dette er trukket ud i det extreme, men det er for at understrege at let portering også har sin pris. Som du sjovt nok selv siger du ikke er ville til at betale.
Og min pointe er så at der findes rimelige kompromis'er, som gør begge dele mulige.
Hør her man behøver ikke bruge de samme standarder når man udvikler portable programmer, man skal bare lære at tænke sig om istedet for nødvendigvis at bruge native libraries.
wxWidgets (LGPL): Se det er en idé man kan bruge til noget. wxWidgets er bare en form for wrapper der gør at samme kode kan compiles på mange platforme og stadig bruger native libraries.
GTK+ (LGPL): Native X11, men er blevet portet til Win32 og kører på Darwin. Kildekoden er åben og muligheden er derfor åben for mange andre platforme.
Hungrer man efter løsningen med kommerciel support så er der også dem fx. Qt. GTK+ og wxWidgets kan også bruges kommercielt, men laves der ændringer i deres kildekode (din kode kan sagtens være lukket) skal det offentliggøres.
Princippet gælder ikke kun GUI (og wxWidgets er da også langt mere end det).
Mht. GUI ser vi det allerede mere abstrakt ved XUL, XRC (wxWidgets) og Glade (*ix/Win/Darwin), hvor GUI ikke er en del af koden, men er defineret i XML og dynamisk loades run-time.
Der findes så perverst mange forskellige LGPL libraries til alt mellem himmel og jord, der endda er portet til mange systemer. Undskyldningen for at lave noget der ikke er portabelt kan kun være frygt, dovenskab eller en indbilsk tro på at performance kun opnås af de libraries der følger med systemet.
wxWidgets (LGPL): Se det er en idé man kan bruge til noget. wxWidgets er bare en form for wrapper der gør at samme kode kan compiles på mange platforme og stadig bruger native libraries.
GTK+ (LGPL): Native X11, men er blevet portet til Win32 og kører på Darwin. Kildekoden er åben og muligheden er derfor åben for mange andre platforme.
Hungrer man efter løsningen med kommerciel support så er der også dem fx. Qt. GTK+ og wxWidgets kan også bruges kommercielt, men laves der ændringer i deres kildekode (din kode kan sagtens være lukket) skal det offentliggøres.
Princippet gælder ikke kun GUI (og wxWidgets er da også langt mere end det).
Mht. GUI ser vi det allerede mere abstrakt ved XUL, XRC (wxWidgets) og Glade (*ix/Win/Darwin), hvor GUI ikke er en del af koden, men er defineret i XML og dynamisk loades run-time.
Der findes så perverst mange forskellige LGPL libraries til alt mellem himmel og jord, der endda er portet til mange systemer. Undskyldningen for at lave noget der ikke er portabelt kan kun være frygt, dovenskab eller en indbilsk tro på at performance kun opnås af de libraries der følger med systemet.
#19
Der kan være mange grunde til ikke at ville benytte sig af diverse libs. F.eks kan man være uenig med licensen.
http://www.oreillynet.com/pub/a/policy/2001/12/12/...
Og syntes du selv seriøst af wxWidgets er et fremragende lib? Det er ligeså roddet som MFC, som alle i dag er enige om er forfærdeligt.
Der kan være mange grunde til ikke at ville benytte sig af diverse libs. F.eks kan man være uenig med licensen.
http://www.oreillynet.com/pub/a/policy/2001/12/12/...
Og syntes du selv seriøst af wxWidgets er et fremragende lib? Det er ligeså roddet som MFC, som alle i dag er enige om er forfærdeligt.
#21
QT er ikke multithreaded, så der er grænser for hvor brugbart det er, udenfor Windows/Linux systemerne.
QT er ikke multithreaded, så der er grænser for hvor brugbart det er, udenfor Windows/Linux systemerne.
[url]#20[/url] Nu var essensen af mit indlæg jo ikke at man skulle bruge LGPL libs, men at man skulle bruge et fornuftigt portabelt library.
Jeg kunne kun smågrine lidt af deres "Why not LGPL?" i det link du postede.
Punkt 1:
Punkt 2:
Punkt 3:
Punkt 4:
Punkt 5:
Jeg ved ikke hvilken LGPL-hader der har skrevet det pis, men sjovt er det da.
http://www.gnu.org/licenses/lgpl.html
Jeg kunne kun smågrine lidt af deres "Why not LGPL?" i det link du postede.
Punkt 1:
The scope of the LGPL is too coarse-grained. The scope is furthermore open to interpretation. It is limited to some fuzzy notion of functional entities ("a collection of software functions and/or data prepared so as to be conveniently linked with application programs"). What if an LGPL-covered library is used by another library or a software component such as an embedded Web browser? [LGPL, section 0]Jeg mener nu ikke er der er noget der kan tolkes galt der. Du må bruge LGPL kode som du ønsker, men ændrer du i deres kode skal det offentliggøres under LGPL. Hvis der er mulighed for fejlfortolkning vil det ikke komme producenten til gode, kun brugeren.
Punkt 2:
The LGPL contains a provision for anybody, at any time, to convert the license irreversibly to GPL, effectively creating a the GPL-only fork of the converted code. [LGPL, section 3]Det forstår jeg ikke helt problematikken i? Medmindre de tænker som i Punkt 2.
Punkt 3:
The Free Software Foundation controls the license. They can release a new version of the license, which then will automatically apply to our software. Although we do not expect the Free Software Foundation of making changes that deviate from the spirit of the current versions, they could make clarifications that are contrary to our intentions. For example, they may clarify that the result of aspect-oriented weaving is subject to the terms of the LGPL, whereas we had intended that it is not. Another concern is who will be in charge of the Free Software Foundation 10 years from now, or what happens if the Free Software Foundation is discontinued? [LGPL, section 13]Hvordan er det forskelligt fra kommercielle licenser eller endda FreeBSD? Copyright indehaver kan altid ændre licens, men aldrig med tilbagevirkende kraft. Hvis man ønsker at udviklingen altid skal kunne forsætte er det da netop essentielt at koden er fri så andre kan overtage.
Punkt 4:
Patent issues and restrictions imposed by law are dealt with by the LGPL in the GPL's "my way or no way" style, namely that such restrictions automatically terminate all your rights to use the LGPL-covered software. [LGPL, section 11]Det eneste der bliver sagt i sektion 11 er at du ikke kan implementere patenteret kode i deres library, eller at du i såfald frasiger dig retten til at sagsøge.
Punkt 5:
Object files must be made available, when distributing executables. This may seem like a mere inconvenience, but it can impose a serious configuration management overhead, which can render the term impractical. [LGPL, section 6a]Punkt 5 er helt til grin. Kun et af underpunkterne a,b,c,d,e i sektion 6 skal opfyldes. Og 6c lyder:
Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.
Jeg ved ikke hvilken LGPL-hader der har skrevet det pis, men sjovt er det da.
http://www.gnu.org/licenses/lgpl.html
#23
Interessant, det er første gang jeg hører libqt-mt omtalt, men det er sket ofte at jeg har hørt folk brokke sig over at det ikke er multithreaded.
Og så ser det endda ud til at det har eksisteret i årevis :D
Interessant, det er første gang jeg hører libqt-mt omtalt, men det er sket ofte at jeg har hørt folk brokke sig over at det ikke er multithreaded.
Og så ser det endda ud til at det har eksisteret i årevis :D
#22
Det er trolltechs dokumentation nu ikke helt enig med dig i.
http://doc.trolltech.com/4.1/threads.html
http://doc.trolltech.com/3.3/threads.html
Helt tilbage i 2.3
http://doc.trolltech.com/2.3/threads.html
Tilgengæld er Qt kun tilgængeligt på X11/*nix, Windows og MacOS X.
Det er trolltechs dokumentation nu ikke helt enig med dig i.
http://doc.trolltech.com/4.1/threads.html
http://doc.trolltech.com/3.3/threads.html
Helt tilbage i 2.3
http://doc.trolltech.com/2.3/threads.html
Tilgengæld er Qt kun tilgængeligt på X11/*nix, Windows og MacOS X.
#27
Ja, de er sgu nogle båtnakker, når de ikke er enige med mig :)
Jeg har indimellem set et par uofficielle ports, dengang man kunne få adgang sourcen. Kan man stadig det, nu er ved det?
Ja, de er sgu nogle båtnakker, når de ikke er enige med mig :)
Jeg har indimellem set et par uofficielle ports, dengang man kunne få adgang sourcen. Kan man stadig det, nu er ved det?
[url]#28[/url] Ja, da.. Qt udgives også under GPL.
Qt/Windows Open Source Edition
Qt/X11 Open Source Edition
Qt/Mac Open Source Edition
Qt/Windows Open Source Edition
Qt/X11 Open Source Edition
Qt/Mac Open Source Edition
#28
Fra Qt 4.0 er både Windows,MacOSX og X11 udgaven under GPL, så ja kildekode er tilgængelig :)
http://www.trolltech.com/products/qt/downloads
EDIT:
To slow.
Fra Qt 4.0 er både Windows,MacOSX og X11 udgaven under GPL, så ja kildekode er tilgængelig :)
http://www.trolltech.com/products/qt/downloads
EDIT:
To slow.
#24
Hvis du gad finde ud af hvem forfatterne af artiklen er, ville du hurtigt indse af ingen af dem er GPL/LGPL hadere. Den ene af dem er Daniel Stenberg, som de fleste nok kender fra hans arbejde med CURL, så nogen GLP/LGPL hader er han trods alt ikke.
Den anden Bjørn Reese har så vidt jeg er orienteret senest arbejdet meget på GNOME libxslt, og igen næppe det helt store tegn på en GPL/LGPL hader. Men måske de arbejder undercover?
Det som de netop fremstiller er en problemstilling som man står overfor når man bruger GPL/LGPL. Og selve artiklen er blevet taget meget positivt imod, af såvel pro-GPL som anti-GPL folk. AT du måske ikke er enig med deres pointer er fint nok, men problemer som de beskriver er skam meget relevante, og de er ikke de eneste som har disse betænkligheder ved GPL/LGPL software. Og så kan det jo være at de ikke tænker så meget på brugeren når de tænker på licenser, men på udvikleren/producenten så er ret så ligeglad med at det kommer end-user til gode.
Og det er da meget problematisk at man kan lave en fork af LGPL software og frigive denne fork under GPL. Personligt er det rigeligt grund til at jeg aldrig ville kunne finde på at bruge LGPL.
Og hvis essesen med de indlæg ikke var at opfordre til at bruge GPL/LGP software, hvorfor skrev du så: "Der findes så perverst mange forskellige LGPL libraries til alt mellem himmel og jord, der endda er portet til mange systemer. Undskyldningen for at lave noget der ikke er portabelt kan kun være frygt, dovenskab eller en indbilsk tro på at performance kun opnås af de libraries der følger med systemet."
Hvis du gad finde ud af hvem forfatterne af artiklen er, ville du hurtigt indse af ingen af dem er GPL/LGPL hadere. Den ene af dem er Daniel Stenberg, som de fleste nok kender fra hans arbejde med CURL, så nogen GLP/LGPL hader er han trods alt ikke.
Den anden Bjørn Reese har så vidt jeg er orienteret senest arbejdet meget på GNOME libxslt, og igen næppe det helt store tegn på en GPL/LGPL hader. Men måske de arbejder undercover?
Det som de netop fremstiller er en problemstilling som man står overfor når man bruger GPL/LGPL. Og selve artiklen er blevet taget meget positivt imod, af såvel pro-GPL som anti-GPL folk. AT du måske ikke er enig med deres pointer er fint nok, men problemer som de beskriver er skam meget relevante, og de er ikke de eneste som har disse betænkligheder ved GPL/LGPL software. Og så kan det jo være at de ikke tænker så meget på brugeren når de tænker på licenser, men på udvikleren/producenten så er ret så ligeglad med at det kommer end-user til gode.
Og det er da meget problematisk at man kan lave en fork af LGPL software og frigive denne fork under GPL. Personligt er det rigeligt grund til at jeg aldrig ville kunne finde på at bruge LGPL.
Og hvis essesen med de indlæg ikke var at opfordre til at bruge GPL/LGP software, hvorfor skrev du så: "Der findes så perverst mange forskellige LGPL libraries til alt mellem himmel og jord, der endda er portet til mange systemer. Undskyldningen for at lave noget der ikke er portabelt kan kun være frygt, dovenskab eller en indbilsk tro på at performance kun opnås af de libraries der følger med systemet."
[url]#32[/url] Det er jo fuldstændig fejlagtigt det de skriver eller også fremlægger de en problemstilling der er ved alle andre licenser, nemlig at copyright indehaver kan ændre licens. En ting der med LPGL modsat proprietære formater ikke vil betyde at det oprindelige projekt under LGPL stagnerer. Fordelen ved LGPL modsat alle lukkede licenser er jo netop at hvis producenten slår hånden af dig så har du stadig koden og retten til at ændre den eller hyre andre til at udvikle på den.
Jeg valgte termet hader, fordi de fremlægger fejlagtige oplysninger og endda udelader oplysninger der modbeviser deres falske problemstilling. Der er et eller andet galt i den tekst, måske har de slet ikke haft fat i en LGPL licens da de skrev det?
Essensen skrives først. En introduktion til indlægget.
Selv hvis nu jeg var FSF præst og skrev at man skulle bruge portable libraries MEN KUN GPL libraries. Så ville du jo sagtens som PRO ELITE MY CODE IS MY OWN kunne ræsonere dig frem til en pointe du kunne overføre på din egen lukkede tankegang. Nemlig brugen af portable libraries... det kan da ikke være rigtigt at jeg skal lære folk at tænke akademisk.
Jeg valgte termet hader, fordi de fremlægger fejlagtige oplysninger og endda udelader oplysninger der modbeviser deres falske problemstilling. Der er et eller andet galt i den tekst, måske har de slet ikke haft fat i en LGPL licens da de skrev det?
Essensen skrives først. En introduktion til indlægget.
Hør her man behøver ikke bruge de samme standarder når man udvikler portable programmer, man skal bare lære at tænke sig om istedet for nødvendigvis at bruge native libraries.Det sidste afsnit er skrevet fordi vi er på et nørdesite hvor folk gør det selv og fordi LGPL er langt mere fri for brug af lukkede applikationer end din kilde på O'Reilly påstår.
Selv hvis nu jeg var FSF præst og skrev at man skulle bruge portable libraries MEN KUN GPL libraries. Så ville du jo sagtens som PRO ELITE MY CODE IS MY OWN kunne ræsonere dig frem til en pointe du kunne overføre på din egen lukkede tankegang. Nemlig brugen af portable libraries... det kan da ikke være rigtigt at jeg skal lære folk at tænke akademisk.
#32
Jeg tror lidt at du misforstår deres vinkel. Det virker mest af alt på mig som om du tror de er utilfredse med licensen i bruger øjenmed. De er de netop ikke, det er som udviklerne/copyrigth holderne artiklen er skrevet. Så det er klart at copyrigth holderen kan skifte licens, dog ikke med tilbage virkende kraft. Og dette betyder at hvis man udgiver under LGPL så kan folk tage din kode og udgive under GPL hvis de ønsker.
Så nej jeg kan ikke se fejl i artiklen i henhold til det der er skrevet.
Og apropos at tænke akademisk, hvad vil du bruge din konklussion til hvis du allerede har skrevet essensen i introduktionen?
Yderligere er da pænt af dig og kalde mig "PRO ELITE MY CODE IS MY OWN" og endda bruge tid på at lære mig at tænke akademisk. Fordi i min verden der har introduktionen altid været der man afgrænser problemstillingen og senere i konklussionen så kan man ligesom lukke det hele af med den evt endelige anbefaling. Men det glæder mig da at jeg fik lært dette.
Yderligere så vidste jeg godt nok ikke at bare fordi man ikke er meget for GPL, at man så pr def var den store tilhænger af closed source. F.eks troede jeg at jeg godt kunne have mine forbehold overfor FSF/GPL, men alligevel syntes de på mange måder gør et godt stykke arbejde. Endda selvom jeg kun vil udgive under BSD hvis der skulle udgives noget opensource fra min side.
Jeg tror lidt at du misforstår deres vinkel. Det virker mest af alt på mig som om du tror de er utilfredse med licensen i bruger øjenmed. De er de netop ikke, det er som udviklerne/copyrigth holderne artiklen er skrevet. Så det er klart at copyrigth holderen kan skifte licens, dog ikke med tilbage virkende kraft. Og dette betyder at hvis man udgiver under LGPL så kan folk tage din kode og udgive under GPL hvis de ønsker.
Så nej jeg kan ikke se fejl i artiklen i henhold til det der er skrevet.
Og apropos at tænke akademisk, hvad vil du bruge din konklussion til hvis du allerede har skrevet essensen i introduktionen?
Yderligere er da pænt af dig og kalde mig "PRO ELITE MY CODE IS MY OWN" og endda bruge tid på at lære mig at tænke akademisk. Fordi i min verden der har introduktionen altid været der man afgrænser problemstillingen og senere i konklussionen så kan man ligesom lukke det hele af med den evt endelige anbefaling. Men det glæder mig da at jeg fik lært dette.
Yderligere så vidste jeg godt nok ikke at bare fordi man ikke er meget for GPL, at man så pr def var den store tilhænger af closed source. F.eks troede jeg at jeg godt kunne have mine forbehold overfor FSF/GPL, men alligevel syntes de på mange måder gør et godt stykke arbejde. Endda selvom jeg kun vil udgive under BSD hvis der skulle udgives noget opensource fra min side.
[url]#34[/url] Jeg har aldrig snakket om brugernes vinkel.
Du skriver det somom de kan bestemme over din kode der bruger librariet (hvilket du selvfølgelig ikke gør). Det er meget vigtig at pointere at det kun er librariets kode og den kode du har udbygget librariet med der kan gøres til GPL. Dette vil stadig betyde at din kode kan bruges under LGPL, men at den blot OGSÅ kan bruges under GPL.
Du skriver det somom de kan bestemme over din kode der bruger librariet (hvilket du selvfølgelig ikke gør). Det er meget vigtig at pointere at det kun er librariets kode og den kode du har udbygget librariet med der kan gøres til GPL. Dette vil stadig betyde at din kode kan bruges under LGPL, men at den blot OGSÅ kan bruges under GPL.
Yderligere er da pænt af dig og kalde mig..Det var dog ufatteligt svært at skrive noget til dig du ikke misforstår. Læs det sidste afsnit et par gange mere og overvej om jeg virkelig er FSF-præst og om du virkelig er min modsætning eller om det er et tænkt eksempel.
Og apropos at tænke akademisk, hvad vil du bruge din konklussion til hvis du allerede har skrevet essensen i introduktionen?Det er faktisk meget normalt (ikke akademisk) at fremhæve essensen ved at placere den først. Se fx. teksten under overskriften i en avisartikel. Det er ikke akademisk at placere en konklussion sidst (medmindre DSN har ændret definitionen over-night). Det jeg skriver er ikke en rapport under udarbejdelse, hvor jeg først kan drage en konklussion til sidst.
#35
Nu tror jeg lidt jeg har set hvor det er at vi ikke er enige om permissen, nemlig at jeg snakker GPL/LGPL generelt som licens. (Og at man pga modstand af denne ikke vil støtte den). Og du mener mere konkret at der er snakke om disse libs, og brugen af dem i projekter. Det er nok der vi går skævt af hinanden.
Men hvad angår porteringen af LGPL til GPL kode angår, vil du ikke mene at det er problematisk at du udgiver noget under LGPL for så blot at se nogle GPL folk tage din udgivelse og lave en port af denne under GPL? Det er hvertfald sådan jeg læser LGPL licensen, og jeg har set mange andre som læser den sådan. Men hvis du kan finde en advokat med forstand på licenser som vil sige noget modsat er jeg da åben for at lytte.
Og yderligere, når du bruger 4 linier på at "lære mig at tænke akademisk" og skriver med store bogstaver "PRO ELITE...", så forventer du ikke det bliver tage ilde op? At skrive med stort har nu altid været at råbe af folk, og generelt virker PRO ELITE som noget man gerne skriver til folk, for at ironisere overfor dem. Yderligere er din "belæring" af mig skrevet på en ganske nedværdigende måde, og derudover ganske forkert. Så hvis det ikke er ment sådan, så fair nok.
Nu tror jeg lidt jeg har set hvor det er at vi ikke er enige om permissen, nemlig at jeg snakker GPL/LGPL generelt som licens. (Og at man pga modstand af denne ikke vil støtte den). Og du mener mere konkret at der er snakke om disse libs, og brugen af dem i projekter. Det er nok der vi går skævt af hinanden.
Men hvad angår porteringen af LGPL til GPL kode angår, vil du ikke mene at det er problematisk at du udgiver noget under LGPL for så blot at se nogle GPL folk tage din udgivelse og lave en port af denne under GPL? Det er hvertfald sådan jeg læser LGPL licensen, og jeg har set mange andre som læser den sådan. Men hvis du kan finde en advokat med forstand på licenser som vil sige noget modsat er jeg da åben for at lytte.
Og yderligere, når du bruger 4 linier på at "lære mig at tænke akademisk" og skriver med store bogstaver "PRO ELITE...", så forventer du ikke det bliver tage ilde op? At skrive med stort har nu altid været at råbe af folk, og generelt virker PRO ELITE som noget man gerne skriver til folk, for at ironisere overfor dem. Yderligere er din "belæring" af mig skrevet på en ganske nedværdigende måde, og derudover ganske forkert. Så hvis det ikke er ment sådan, så fair nok.
[url]#36[/url] Du har ret. Du snakker for udviklerne af LGPL programmer, men jeg snakker om udviklere der bruger LGPL libraries.
Jo, selvfølgelig er der en problematik for udvikleren af librariet ved at bruge LGPL. Det faktum at man kan lave LGPL til GPL, lave rettelser i koden og ikke skulle udgive den under LGPL. Det er da rigtig nok klart en ulempe for udvikleren. Det kunne da også være at jeg lige skulle nærlæse den artikel igen. Der er godt nok stadig nogle fejl som omkring sektion 6, men når de snakker for folk der bruger LGPL licensen på deres egne produkter giver det pludselig mere mening.
Jeg må jo nok trække alle mine frustrationer over at du ikke forstod mig tilbage, jeg forstod heller ikke dig ;)
Det jeg skrev med stort var også for at ironisere. Ikke ironisere dig, men ironisere yderpolerne i licensdebatten.
Det var denne sætning i [url]#20[/url] der fik mig på galt spor.
Jo, selvfølgelig er der en problematik for udvikleren af librariet ved at bruge LGPL. Det faktum at man kan lave LGPL til GPL, lave rettelser i koden og ikke skulle udgive den under LGPL. Det er da rigtig nok klart en ulempe for udvikleren. Det kunne da også være at jeg lige skulle nærlæse den artikel igen. Der er godt nok stadig nogle fejl som omkring sektion 6, men når de snakker for folk der bruger LGPL licensen på deres egne produkter giver det pludselig mere mening.
Jeg må jo nok trække alle mine frustrationer over at du ikke forstod mig tilbage, jeg forstod heller ikke dig ;)
Det jeg skrev med stort var også for at ironisere. Ikke ironisere dig, men ironisere yderpolerne i licensdebatten.
Det var denne sætning i [url]#20[/url] der fik mig på galt spor.
Der kan være mange grunde til ikke at ville benytte sig af diverse libs. F.eks kan man være uenig med licensen.
#37.
Glimragende, så blev vi jo næsten enige i sidste ende :) Og hvad angår artiklen så syntes jeg du skulle give den et extra kig, og finder du en fejl skal du endelig lade folkene det at vide. Hvis du gerne vil have kontakt oplysninger på dem, så send en PM.
Og utroligt så uenige man kan være, specielt når permissen ikke er ens :)
Og ja den sætning kan fint forståes på den måde, men det var nu mere ment som om, hvis man var modstander af den type licens, så var det ikke sikkert at man ønskede at støtte den ved at bruge libs licenseret under den.
Glimragende, så blev vi jo næsten enige i sidste ende :) Og hvad angår artiklen så syntes jeg du skulle give den et extra kig, og finder du en fejl skal du endelig lade folkene det at vide. Hvis du gerne vil have kontakt oplysninger på dem, så send en PM.
Og utroligt så uenige man kan være, specielt når permissen ikke er ens :)
Og ja den sætning kan fint forståes på den måde, men det var nu mere ment som om, hvis man var modstander af den type licens, så var det ikke sikkert at man ønskede at støtte den ved at bruge libs licenseret under den.
jeg kan ikke se noget problem fra udvikleren af lgpl librariets side.. han udgiver et stykke arbejde under en licens, hans arbejde kan dog konverteres til en licens hvor folk der ikke har lyst til at dele, ikke kan spise.. DOG er det originale jo STADIG licenseret under LGPL, fra den originale forfatter..
desuden er dette jo også gjort af meget klare årsager.. hvis du laver derived works af GPL, bliver det hele GPL, så hvis jeg nu laver et encryption library og udgiver i LGPL, men så en anden tager mit library, tilføjer en anden algoritme, ved brug af et GPL library, bliver produktet til GPL, ganske simpelt.. sådan gør ffmpeg for eksempel...
desuden er dette jo også gjort af meget klare årsager.. hvis du laver derived works af GPL, bliver det hele GPL, så hvis jeg nu laver et encryption library og udgiver i LGPL, men så en anden tager mit library, tilføjer en anden algoritme, ved brug af et GPL library, bliver produktet til GPL, ganske simpelt.. sådan gør ffmpeg for eksempel...
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund