mboost-dp1
unknown
Ikke skide smart gjort af Xen (specielt mht. til de fimaer/personer der har bidraget til Xen koden) men det er jo set før, i varierende omfang, som med Mozilla Firefox (Bon Echo) og Linux (man skal markere at Linux(r)(tm)(c) tilhører Linus(?)). Egentlig er der er en meget god grund til det: hvis Xen ikke beskytter sit varemærke og alle begynder at kalde deres egne homebrews for Xen udvandes deres varemærke, og alle må kalde sig Xen, også selv om man ikke har den fjerneste forbindelse til Xen.
At de så vælger den hårdeste kurs må siges at være overkill, men det er deres eget problem. Med al sandsynlighed vil vi snart se en fork af Xen, der kalder sig noget andet, men med samme source og Xen kan meget let risikere at blive efterladt i kulden, da de mister en del PR via netop homebrews.
Desuden bør det på det kraftigste bemærkes at dette på ingen måde forhindre alle og en hver i at distribuere koden til Xen kvit og frit som altid, der skal blot laves en search & replace på Xen, XenSource osv.
At de så vælger den hårdeste kurs må siges at være overkill, men det er deres eget problem. Med al sandsynlighed vil vi snart se en fork af Xen, der kalder sig noget andet, men med samme source og Xen kan meget let risikere at blive efterladt i kulden, da de mister en del PR via netop homebrews.
Desuden bør det på det kraftigste bemærkes at dette på ingen måde forhindre alle og en hver i at distribuere koden til Xen kvit og frit som altid, der skal blot laves en search & replace på Xen, XenSource osv.
Det sjove er at netop Red Hat fare op. deres varemærke politik er den formentlige mest strenge i open source verden.
Da jeg skrev nyheden nævnte jeg også at XenSource er begyndt at bruge samme metode som Red Hat til at begrænse distrobutionen af deres kode. Ja koden er under GPL men det er deres varemærke ikke.
Red Hats varmærkepolitik er netop grunden til der er distro'er såsom CentOS, der ripper alle Red Hats varemærker ud og erstatter med deres egne.
For at Xen kan blive ordentlig integrer med en distro: Glib(c) version, kernel back- and forward porte til den kernel version en distro køre og modificeringer så den passer med andre patche som distro benytter. Så skal koden tilrettes, hvilke XenSource nu benytter til at tjene nogle penge. De skal nok ikke regne med at de for lige såmange kode timer fra Red Hat som før og de skal nok heller ikke regne med at alle Red Hats relevante rettelser bliver sendt tilbage til XenSource.
Da jeg skrev nyheden nævnte jeg også at XenSource er begyndt at bruge samme metode som Red Hat til at begrænse distrobutionen af deres kode. Ja koden er under GPL men det er deres varemærke ikke.
Red Hats varmærkepolitik er netop grunden til der er distro'er såsom CentOS, der ripper alle Red Hats varemærker ud og erstatter med deres egne.
For at Xen kan blive ordentlig integrer med en distro: Glib(c) version, kernel back- and forward porte til den kernel version en distro køre og modificeringer så den passer med andre patche som distro benytter. Så skal koden tilrettes, hvilke XenSource nu benytter til at tjene nogle penge. De skal nok ikke regne med at de for lige såmange kode timer fra Red Hat som før og de skal nok heller ikke regne med at alle Red Hats relevante rettelser bliver sendt tilbage til XenSource.
shadowsurfer
Næh, men RH skal frigive den ændrede kode under samme vilkår som Xen (GPL). Så hvis Xen meget gerne vil have RHs ændringer kan de blot sakse dem fra RHs distro. Det er jo det der er det smukke ved GPL: du kan ikke forhindre andre i adgangen til GPL-kode på en lovlig måde. Heller ikke selv om du selv har skrevet det. Og ingen kan tage din kode og bruge den uden af frigive ændringerne *Host* Linksys *Host*.
... og de skal nok heller ikke regne med at alle Red Hats relevante rettelser bliver sendt tilbage til XenSource
Næh, men RH skal frigive den ændrede kode under samme vilkår som Xen (GPL). Så hvis Xen meget gerne vil have RHs ændringer kan de blot sakse dem fra RHs distro. Det er jo det der er det smukke ved GPL: du kan ikke forhindre andre i adgangen til GPL-kode på en lovlig måde. Heller ikke selv om du selv har skrevet det. Og ingen kan tage din kode og bruge den uden af frigive ændringerne *Host* Linksys *Host*.
Men skal naturligvis huske på at XenSource har ret til at tjene penge og det er svært at finde en forretningsmodel på Open Source licenseret kode, der giver en stabil indtægt. Det her er så deres model. Om de for succes med den model ved jeg ikke, men tabet af Red Hat som støtter er stort.
#4 der er stor forskel på om XenSource selv skal sakse dem fra Red Hat eller om Red Hat giver dem til XenSource... Hvad tror du koster flest timer?
#6
Forskellen er minimal. Medmindre redhat helt forker Xen træet, og fører det i en helt anden retning, men det ville være alt for dyrt, og største delen af Xen ekspertise ligger alligevel hos Xensource.
Generelt er det da lidt kedeligt, men jeg ser på den anden side ikke nogen større Open Source relaterede problemer i det. Rent forretningsmæssigt er formålet selvfølgelig at udnytte (eller benytte om du vil) det buzz der er omkring Xen til at udbygge deres eget og evt. partnerers salg, således at Redhat f.eks. ikke kan tjene penge på det sikkert værdifulde Xen navn.
Personligt tror jeg, det kommer til at koste Xensource penge i længden, fordi det skader Xen mærket, der vil udvikle sig til et mindre marked end det ellers ville være blevet, og dermed vil koste Xensource. Jeg har altid svært ved at forstå, at firmaer synes det er en fordel for dem selv at skade andre firmaer meget selvom det også skader dem, omend mindre.
Med det her træk tror jeg alle chancer for at få et specifikt Xen modul ind i linux kernen er væk, men der har været snak om et generisk virtualiserings framework til kernen, så det kan være de satser på det.
Forskellen er minimal. Medmindre redhat helt forker Xen træet, og fører det i en helt anden retning, men det ville være alt for dyrt, og største delen af Xen ekspertise ligger alligevel hos Xensource.
Generelt er det da lidt kedeligt, men jeg ser på den anden side ikke nogen større Open Source relaterede problemer i det. Rent forretningsmæssigt er formålet selvfølgelig at udnytte (eller benytte om du vil) det buzz der er omkring Xen til at udbygge deres eget og evt. partnerers salg, således at Redhat f.eks. ikke kan tjene penge på det sikkert værdifulde Xen navn.
Personligt tror jeg, det kommer til at koste Xensource penge i længden, fordi det skader Xen mærket, der vil udvikle sig til et mindre marked end det ellers ville være blevet, og dermed vil koste Xensource. Jeg har altid svært ved at forstå, at firmaer synes det er en fordel for dem selv at skade andre firmaer meget selvom det også skader dem, omend mindre.
Med det her træk tror jeg alle chancer for at få et specifikt Xen modul ind i linux kernen er væk, men der har været snak om et generisk virtualiserings framework til kernen, så det kan være de satser på det.
#6:
du glemmer at det er i redhats egen interesse at få merged deres ting upstream. Jo mere de skal maintaine lokalt, uden upstream support, jo større bliver deres omkostninger, både på videreudvikling, bugfixing, support, maintenance, faktisk alt.
#8:
kernen har allerede fået det omtalte generiske paravirtualiserings framework, som bliver udviklet sammen med blandt andet XenSource, og VMWare Inc.
du glemmer at det er i redhats egen interesse at få merged deres ting upstream. Jo mere de skal maintaine lokalt, uden upstream support, jo større bliver deres omkostninger, både på videreudvikling, bugfixing, support, maintenance, faktisk alt.
#8:
kernen har allerede fået det omtalte generiske paravirtualiserings framework, som bliver udviklet sammen med blandt andet XenSource, og VMWare Inc.
#9
Interessant, jeg følger ellers normalt godt med, har du evt. et link til mailinglisten eller lignende? Det eneste jeg har hørt om er inklusionen af KVM.
Interessant, jeg følger ellers normalt godt med, har du evt. et link til mailinglisten eller lignende? Det eneste jeg har hørt om er inklusionen af KVM.
Omend det ikke vinder folk de store popularitetskonkurrencer, at gøres om Xen(tm) og Redhat(tm) har gjort, så er det den mindst obstruktive strategi af dem alle.
Hvis alternativet for deres ønsker, ville være at en restriktiv EULA, så er varemærke restriktioner langt at foretrække.
De har en måde at profilere sig, med en eksklusiv løsning kun de kan levere. Og communityet undgår stadig, en række af de værste restriktioner.
Forbeholdt strategien har hverken ESR eller RMS, da heller ikke set nogen problemer i fremgangsmåden.
Personligt er jeg ikke begrejstret, men ser det som et spiseligt kompromis. (Da jeg ved hvad alternativet kunne være.... ;( )
Hvis alternativet for deres ønsker, ville være at en restriktiv EULA, så er varemærke restriktioner langt at foretrække.
De har en måde at profilere sig, med en eksklusiv løsning kun de kan levere. Og communityet undgår stadig, en række af de værste restriktioner.
Forbeholdt strategien har hverken ESR eller RMS, da heller ikke set nogen problemer i fremgangsmåden.
Personligt er jeg ikke begrejstret, men ser det som et spiseligt kompromis. (Da jeg ved hvad alternativet kunne være.... ;( )
#12
De paravirtualiserings indstillinger der er, er såvidt jeg ved et helt andet virtualiseringssystem, kaldet kvm. Det er klart at som del af inklusionen af det, er der lavet mange ændringer der forbedreder virtualisering i forhold til kernen, f.eks. tickless kernel, der gør at kernen ikke vågner op når det ikke er nødvendigt, og dermed reducerer den pris der betales for at have flere kerner kørende side om side.
Men et generisk framework ville være en stor nyhed, og jeg tvivler på det er inkluderet, men der arbejdes sikkert på det.
De paravirtualiserings indstillinger der er, er såvidt jeg ved et helt andet virtualiseringssystem, kaldet kvm. Det er klart at som del af inklusionen af det, er der lavet mange ændringer der forbedreder virtualisering i forhold til kernen, f.eks. tickless kernel, der gør at kernen ikke vågner op når det ikke er nødvendigt, og dermed reducerer den pris der betales for at have flere kerner kørende side om side.
Men et generisk framework ville være en stor nyhed, og jeg tvivler på det er inkluderet, men der arbejdes sikkert på det.
Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen, Xen.
Har det noget at gøre med beskyttelsen af varemærket i forbindelse med lovgivningen? Det var da det, der skete for Linux på et tidspunkt? At en eller anden betaling var nødt til at komme i stand, fordi et eller andet gustent firma prøvede at registrere Linux som deres varemærke?
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