mboost-dp1
unknown
#49 SmackedFly
Det er jeg mere i tvivl om. Modulerne loadet jo ind i kernen og bliver et med kernen. Uden at jeg dog kender mere til hvordan det sker, end du muligvis gør det... ;)
Det er ihvertfald det mest synlige problem for os alle. Der er netop også derfor, jeg mener vi bør sige nej til binary only moduler.
Nej de bliver ikke loadet ind i kernen. De fleste linker dog til GLIBC, som er LGPL'ed.
Jeg ser en stor forskel på de to scenarier. Men med en revideret GPL licens, vil disse ting forhåbentligt blive mere klare. Idéen om at det ligefrem skulle gå helt ud i applikationslaget, syntes jeg nu er sjov... hehe Men det er nu, resultatet taget i betragning, ikke en vej jeg mener er gangbar. Det bør være folk selv, som siger "nej tak - min frihed er for vigtig".
Det er vist et meget stort definationsspørgsmål. Kerne moduler er baseret på interfaces, dvs. hvis du bygger non-gpl moduler oven på så bør de ikke bryde med noget licensmæssigt.
Det er jeg mere i tvivl om. Modulerne loadet jo ind i kernen og bliver et med kernen. Uden at jeg dog kender mere til hvordan det sker, end du muligvis gør det... ;)
såvidt jeg ved er det eneste problem med binære moduler at de er stortset umulige at debugge, til stor gene for udviklerne.
Det er ihvertfald det mest synlige problem for os alle. Der er netop også derfor, jeg mener vi bør sige nej til binary only moduler.
Hvis kernens interfaces tvinger modulerne til at gå GPL, medfører den naturlige IPC der foregår imellem processer (og som er en naturlig del af det at ekserkvere et app) så også GPL brud?
Nej de bliver ikke loadet ind i kernen. De fleste linker dog til GLIBC, som er LGPL'ed.
Jeg må indrømme at jeg ligepludselig ikke er så sikker, men jeg håber det ikke.
Jeg ser en stor forskel på de to scenarier. Men med en revideret GPL licens, vil disse ting forhåbentligt blive mere klare. Idéen om at det ligefrem skulle gå helt ud i applikationslaget, syntes jeg nu er sjov... hehe Men det er nu, resultatet taget i betragning, ikke en vej jeg mener er gangbar. Det bør være folk selv, som siger "nej tak - min frihed er for vigtig".
AFAIK er det et fortolkningsspørgsmål om et binært modul bryder GPL eller ej - dog er modulet jo ikke afhængigt af kernen (ubrugelig uden, men ikke afhængig af).
#52 Deternal
Tjahh det bliver jo trodsalt loadet ind i den kørende kerne. Tror desværre blot kernel hackerne, ser velvilligt igennem fingre med det.
Hvornår er noget så afhængigt, hvis det ikke bliver afhængigt af ikke at kunne fungere uden?... :P Lyder selvmodsigende for mig.
AFAIK er det et fortolkningsspørgsmål om et binært modul bryder GPL eller ej
Tjahh det bliver jo trodsalt loadet ind i den kørende kerne. Tror desværre blot kernel hackerne, ser velvilligt igennem fingre med det.
dog er modulet jo ikke afhængigt af kernen (ubrugelig uden, men ikke afhængig af).
Hvornår er noget så afhængigt, hvis det ikke bliver afhængigt af ikke at kunne fungere uden?... :P Lyder selvmodsigende for mig.
#53: I så fald er al linux software jo afhængigt af kernen - så sun bryder gpl fordi java kører på linux? næppe. Men linux version af java er stadig rimeligt ubrugelig uden kernen.
Det er vel snarere sådan at kernen loader modulet end modulet der loader kernen.
Hvis du tager k3b, så kræver det en scsi generic driver, vcdxbuil mv. - hvis de ting er GPL, så er k3b nødt til at være det, fordi k3b er afhængigt af de libs for at køre.
Håber du forstår den subtile forskel.
Det er vel snarere sådan at kernen loader modulet end modulet der loader kernen.
Hvis du tager k3b, så kræver det en scsi generic driver, vcdxbuil mv. - hvis de ting er GPL, så er k3b nødt til at være det, fordi k3b er afhængigt af de libs for at køre.
Håber du forstår den subtile forskel.
#54 Deternal
Ja men de linker ikke direkte.
Men det ville nu være rart, om GPL'en havde reddet os fra ufri Java. Men nej det må Sun selv rette op på.
Faktisk ikke.
Linux emuleringen på FreeBSD, skulle vist sagtens kunne klare det... ;) Ellers ville de jo slet ikke have adgang til Java. Derfor kan det kun gå for langsomt med at få fri Java.
Ja det er det jeg siger er det ikke?
Det ved jeg nu ikke om den SKAL være, men K3B ER GPL licenseret. Ikke på grund af de ting, men på grund af KDE bibliotekerne og QT.
Mjahhh det er jo en masse gætteri, sålænge ingen af os er programmøre. Mindes jeg ikke at du er?.
I så fald er al linux software jo afhængigt af kernen - så sun bryder gpl fordi java kører på linux?
Ja men de linker ikke direkte.
Men det ville nu være rart, om GPL'en havde reddet os fra ufri Java. Men nej det må Sun selv rette op på.
næppe. Men linux version af java er stadig rimeligt ubrugelig uden kernen.
Faktisk ikke.
Linux emuleringen på FreeBSD, skulle vist sagtens kunne klare det... ;) Ellers ville de jo slet ikke have adgang til Java. Derfor kan det kun gå for langsomt med at få fri Java.
Det er vel snarere sådan at kernen loader modulet end modulet der loader kernen.
Ja det er det jeg siger er det ikke?
Hvis du tager k3b, så kræver det en scsi generic driver, vcdxbuil mv. - hvis de ting er GPL, så er k3b nødt til at være det, fordi k3b er afhængigt af de libs for at køre.
Det ved jeg nu ikke om den SKAL være, men K3B ER GPL licenseret. Ikke på grund af de ting, men på grund af KDE bibliotekerne og QT.
Håber du forstår den subtile forskel.
Mjahhh det er jo en masse gætteri, sålænge ingen af os er programmøre. Mindes jeg ikke at du er?.
Det er ikke gætterier - er ret overbevist om at FreeBSD og Linux driverne har samme versionering fordi de blot er compilet med lidt forskellige options.
Mht. linkingen, så er ovenfor beskrevne jo en af grundene til at mange libs er under lgpl, netop for at der kan linkes til dem eller de kan loades af en app uden at app'en skal være gpl.
Mht. linkingen, så er ovenfor beskrevne jo en af grundene til at mange libs er under lgpl, netop for at der kan linkes til dem eller de kan loades af en app uden at app'en skal være gpl.
#56 Deternal
Selvfølgelig er de da det, i det store hele altså.
Ja men Linux kernen er netop ikke LGPL.. ;)
LGPL er et kompromis i mange tilfælde. Hvis vi lader dem bruge vores biblioteker, til at lave ufrie software med, så slæber de i det mindste ikke også flere ufrie biblioteker med... :o/ Hvis GLIBC var GPL licenseret, ville der nok bare dukke ufrie C biblioteker op istedet for... :( Det har vi FORHÅBENTLIGT forebygget... :)
Det er ikke gætterier - er ret overbevist om at FreeBSD og Linux driverne har samme versionering fordi de blot er compilet med lidt forskellige options.
Selvfølgelig er de da det, i det store hele altså.
Mht. linkingen, så er ovenfor beskrevne jo en af grundene til at mange libs er under lgpl, netop for at der kan linkes til dem eller de kan loades af en app uden at app'en skal være gpl.
Ja men Linux kernen er netop ikke LGPL.. ;)
LGPL er et kompromis i mange tilfælde. Hvis vi lader dem bruge vores biblioteker, til at lave ufrie software med, så slæber de i det mindste ikke også flere ufrie biblioteker med... :o/ Hvis GLIBC var GPL licenseret, ville der nok bare dukke ufrie C biblioteker op istedet for... :( Det har vi FORHÅBENTLIGT forebygget... :)
for lige at bringe tråden til bage igen må jeg sige, at jeg et eller andet sted fryder mig lidt over at *.doc formatet ikke er blevet dette allround format de havde håbet på.
Og det tyder også på at MS har opgivet at få deres XML udgave til at blive det.
Tænk vis firmaet på et eller andet tidspunkt bare på nogle områder overgav sig til den "mainstream" der faktisk er ved at opstå på nettet. Man kan jo få helt lykkelige drømme om at MS begyndte at satse på på det åbne XML format
Og det tyder også på at MS har opgivet at få deres XML udgave til at blive det.
Tænk vis firmaet på et eller andet tidspunkt bare på nogle områder overgav sig til den "mainstream" der faktisk er ved at opstå på nettet. Man kan jo få helt lykkelige drømme om at MS begyndte at satse på på det åbne XML format
PDF er komprimeret postscript og er et meget meget låst side baseret layout, hvor man stort set kan forvente perfekt reproduktion ned til de mest ubetydelige pixels, uanset hvordan modtagerens system er sat op.
På mange måder er PDF udviklet fra en slags bilede af den udskrevne side.
Det er det der gør PDF så udbredt i den grafiske branche, og det et det MS vil forsøge at kopiere.
Problemet er så at MS Metro format formenteligt vil arve PDF's problemer med at det er ret besværligt at have med at gøre.
At bringe XML ind i biledet svarer lidt til at diskutere om en læser er skrevet i comal80 eller lisp.
XML er en slags sprog der beskriver dokumentformater, ikke et dokumentformat, XML er en simplificeret udgave af SGML der ligger til grund for bla docbook og html.
#35
<dokument>
<side nummer="42">
bla bla
</side>
</dokument>
<xsl:value-of select="/dokument/side[42]"/>
Hvorfor er det et problem at implementere individuelle sider i et XML baseret format?
Med hensyn til komprimering er jeg ening hvis man kigger paa MS doc format og open office's format så er bliver doc betydeligt mindre end sxw hvis det udsættes for samme komprimering.
På mange måder er PDF udviklet fra en slags bilede af den udskrevne side.
Det er det der gør PDF så udbredt i den grafiske branche, og det et det MS vil forsøge at kopiere.
Problemet er så at MS Metro format formenteligt vil arve PDF's problemer med at det er ret besværligt at have med at gøre.
At bringe XML ind i biledet svarer lidt til at diskutere om en læser er skrevet i comal80 eller lisp.
XML er en slags sprog der beskriver dokumentformater, ikke et dokumentformat, XML er en simplificeret udgave af SGML der ligger til grund for bla docbook og html.
#35
<dokument>
<side nummer="42">
bla bla
</side>
</dokument>
<xsl:value-of select="/dokument/side[42]"/>
Hvorfor er det et problem at implementere individuelle sider i et XML baseret format?
Med hensyn til komprimering er jeg ening hvis man kigger paa MS doc format og open office's format så er bliver doc betydeligt mindre end sxw hvis det udsættes for samme komprimering.
#59
Hele ideen med PDF er jo netop et format elle kan læse. Og jeg vil mene at PDF lever op til dit "container" begreb.
Hvis man tog XML og så brugte en lås (skrivebeskytte det) ville man have det som alle drømmer om. Et dokument der kan skrive ud på alle prinere under alle styresystemer. Det er grunden til at jeg forerækker PDF fremfor hvilket som helst andet format når jeg vælger det.
Hele ideen med PDF er jo netop et format elle kan læse. Og jeg vil mene at PDF lever op til dit "container" begreb.
Hvis man tog XML og så brugte en lås (skrivebeskytte det) ville man have det som alle drømmer om. Et dokument der kan skrive ud på alle prinere under alle styresystemer. Det er grunden til at jeg forerækker PDF fremfor hvilket som helst andet format når jeg vælger det.
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