Skal din DE være forbundet med din pakkemanager?

#0: folk at de skal prøve distro x, y og z
eller http://bedrocklinux.org/ så er det ligesom ude af verden ;-)

For mig nej, men bruger heller ikke et DE. Men er helt enig i din pointe.

_Modellen_ som gnome os vil bruger er ikke specifik for gnome. Kde og andre de's skal være velkommende til at bruge samme metode. Gnome os vil specificere nogle libs, som er garanteret at være tilstede på et "gnome os system". Det vil ikke være praktisk muligt at inkludere libs for alle de's på samme system. Kde kan tilsvarende lave en "kde os" hvis de gider - de kan sandsynligvis tage en masse kode direkte fra gnome.

Gnome fokuserer naturligvis på at upstreame de gnome-baserede distro'er. Hvis man skulle forsøge at samle alle de's under solen i et upstream, så vi det blive et komite-arbjejde uden udsigt til at blive færdig før hurd gør.

#2:
Ok, det giver mening. Det du siger, sådan som jeg forstår det, er at GNOMEs model ikke kan gøres desktop uafhængig, da den ikke kan håndtere dependencies og derfor er afhængig af et vist antal installerede pakker per default.

Det lyder suboptimalt i mine øre, at man ikke har udviklet en DE uafhængig model, dette skulle nok kunne lade sig gøre.

Jeg vil sige nej, jeg fortrækker at jeg kan bruge Pacman under alle DE og WM's på Arch og at jeg helt kan undevære et DE eller WM hvis jeg fortrækker det i en periode.

Dog kan jeg godt se point i at det hænger sammen men jeg syntes at dette kun skal være et alternativ til noget jeg allerede syntes fungere fint

Jeg vil godt bevæge mig lidt ind på emnet i sidste tråd Paldepind oprettede, der handlede om Nautilus med/uden diverse features.

Hvis man nu eksempelvis gerne vil bruge Gnome OS, men i stedet for Nautilus foretrækker fx KDE's Dolphin og/eller Krusader, vil man så stadig kunne installere dem?

http://www.24.dk/group/linux/forum/thread/2215487

#frogmaster
Ja, forudsat at nogen laver en bundle til den.

En bundle bliver en distro-neutral pakke, hvor libs udover dem der findes i "core os'et" (gnome os) skal inkluderes. For et kde-program vil en bundle til en gnome os-baseret distro naturligvis fylde lidt mere i download.

Glimrende og tak for svaret Phomes.

#7: En bundle bliver en distro-neutral pakke, hvor libs udover dem der findes i "core os'et" (gnome os) skal inkluderes.Og så virker den vel og mærke udelukkende på systemer der har de pågældende libraries som en del af standard installationen, dvs. den er kun delvist distro-neutral og heller ikke DE-neutral.

Det er lige omvendt.

Du kan jo bare vælge at lave bundles der også inkluderer libs fra standard installen hvis du vil garantere alt.

Det handler mere om at definere et grundsystem/grundfunktionalitet der er installeret på et system. F.eks. dbus. En software producent skal kunne forvente, at en distro der er et Gnome OS har en bestemt funktionalitet ud af boksen. At bundle dbus fordi "distro X ud af 1000" ikke har den giver ikke mening. Det giver ikke at mening holde udviklingen tilbage for at lefle for laveste fællesnævner.

Som sagt, så skal kde være velkommen til at lave et "kde os". De kan endda sikkert kopiere gnomes model (core os, bundles, sandboxing).

#0: Det er blevet forsøgt før, men med et stort projekt som GNOME til at bakke det op (uafhængigt af GNOME), kunne det sikkert sagtens lade sig gøre.
Jamen det var da alletiders ide. Det kræver så bare velvillighed fra alle parter. Du kan lynhurtigt få alle frie upstreams til at gå med på sådan en løsning, hvis den er teknisk velfunderet. Men du får ALDRIG dem med særinteresser med på ideen, hvis det nedbryder deres siloer.

Tror du Digia bryder sig om skrive frontend software fra frie upstreams?
Tror du Canonical vil slippe deres CAede alternativer?
Tror du Canonical vil slippe deres deres distro-silo?
Tror du diverse firmaer uden Linuxsfhængighed vil acceptere et linux-only init og service system?

Så længe der ikke er enighed om at drive mest muligt i frie upstreams, så bliver der kæmpet mod. Og GNOMEs rolle her? Jeg kan ikke komme i tanke om et foretagende der gør mere for at nedbryde siloer og promovere frie upstreams. Kan du? GNOME gør alt hvad de kan, det er andre der er bagstræberiske af egoistiske grunde.

#11: Du kan jo bare vælge at lave bundles der også inkluderer libs fra standard installen hvis du vil garantere alt.Eller man kunne lave et andet system, der ikke er afhængig af noget sådant.

GNOMES tilgang minder enormt meget om Apples. Og for Apple giver det god mening, da de slet ikke har samme diversitet som i Linux userland.

#12: Det kræver så bare velvillighed fra alle parterHvorfor det? Hvis GNOME og RedHat er med, er de i sig selv en stor ting. Hele pointen med det jeg foreslår, er at det skal favne bredere. Man kunne ligefrem forestille sig et system som andre DEer og distros ville deltage i.

Den primære regression er at man ikke håndtere afhængigheder. Hvis vi forestiller os et system der
1/ Håndterer afhængigheder
2/ Giver mulighed for flere versioner af samme bibliotek på en gang
3/ Der både kunne fungere som primært pakkeværktøj og som sekundært til et eksisterende pakkeværktøj.
Ja, så har man pludselig et system der er distro neutralt og DE-neutralt. Tilmed et system som kan virke på alle distros, uagtet om f.eks. Canonical ønsker at have det på deres distro.

Men hvad, måske har GNOME ingen interesse i et DE neutralt pakkesystem. De vil nok helle en gerne holde deres forbedringer for dem selv, så de kan lave en DE-silo.

Jeg har altid været modstander af at distroer laver ting downstream, god software skal komme alle til gode uanset distro. Således kan Linux-brugere sammensætte deres system præcis som de ønsker det. F.eks. bør et distrovalg intet have at gøre med ens DE-valg (ie. præcis det modsatte af hvad Canonical arbejder hen imod). Præcis det samme tankegang mener jeg gælder for dette. Ens valg af DE bør ikke betinge hvilket pakkesystem man benytter.

Men jeg ser også mange gode ting i GNOMES model. Det er kritisk at vi får et system der er gøre det lettere at pakke og installere software på Linux.

Har du et bevis på at GNOME/RedHat gør det modsatte? Ja undskyld mig, men hvem fanden tror du der betaler for størstedelen af alt plumbingen, og hvem tror du der modrbejder det fordi der tilnærmelsesvis kan være en særinteresse?

og lad os da bare tage en case: color calibration. Har Qt-ejerne direkte modarbejdet upstreaming af teknologien og modarbejdet frit software OG frit hardware med henvisning til "redhatism"? Ja eller nej.

#15:
Hvis du ønsker at diskutere Qt's implementering af color calibration må du gøre det i en anden tråd. Det har ingen relevans her. Forhold dig til trådens emne, hvad Digia gør og ikke gør er underordnet.

Det var så Nokia der modarbejdede RedHats forsøg på at få et DE-neutralt color calibration vha. henvisning til at det var fra RedHat! Ergo et bevis på at særinteressser modarbejder neutrale tiltag. Hvilket er yderst relevant. GNOME gør hvad de kan!

#17:
Denne tråd handler om at GNOME laver et pakkesystem, der ikke er DE-neutralt, og til dels heller ikke distro-neutralt. Tråden handler om hvad GNOME gør på dette område, ikke hvad Nokia gør.

Du ved udemærket godt at GNOME aldrig vile kunne få det igennem, det ville gå mod alle særinteresser. Og beviset herfor: Color calibration eksemplet.

Hvis vi ikke engang kan få et uafhængigt og frit color calibration system, hvordan skulle vi så få et tilsvarende pakkesystem!?

#19: Du ved udemærket godt at GNOME aldrig vile kunne få det igennemFå det igennem? Hvor og hvorfor? Man behøver ikke, at få noget igennem nogen steder for at udvikle et DE og distro neutralt pakkesystem. Det kan man frit gøre i det omfang at det behager en. Jeg kan ikke se din pointe?

Øh hallo, der sidder en masse nay-sayers der plejer egne særinteresser! Det du kræver er at GNOME skal komme med en magisk løsning der både har den tekniske kvalitet og opfylder alverdens særinteresser. Det kommer ikke til at ske med dagens linux økosystem. Siloerne er ikke interesseret i at blive fjernet, den eneste måde de kommer ned er ved at blive gjort irrelevante en for en.

#21:
Då du mener altså at nay-sayers med særinteresser har forhindret GNOME i at lave en DE neutralt pakkeløsning? Tænk, jeg troede at GNOME gjorde hvad de havde lyst til, uden at tage hensyn til at det kunne gå ud over nay-sayers. Ingen kan forhindre GNOME i at lave det system jeg beskriver, det er deres eget valg. Lad være med at give andre skylden!

Nu er jeg fuldstændigt på bar bund, men konceptet med at man kan garantere et bestemt minimum af pakker lyder lidt som Linux Standard Base. Nogen der kan fortælle mig forskellen?

Lsb virkede ikke GnomeOS gør måske

#24:
Ja, LSB er ikke det store hit i dag. Men er GNOME OS noget konceptuelt anderledes, udover en opdateret LSB?

#23: Nu er jeg fuldstændigt på bar bund, men konceptet med at man kan garantere et bestemt minimum af pakker lyder lidt som Linux Standard Base. Nogen der kan fortælle mig forskellen?Linux Standard Base har også den fordel, at det er udviklet uafhængigt af nogen distro eller DE. Det samme er ikke tilfældet med GNOME OS.

Linux Standard Base prøvede også rent faktisk at bliver en standard, GNOME OS har det fint så længe de understøttet dem selv ;)

#22: Ja det mener jeg. Medmindre selvfølgelig du mener at GNOME skal stille med et hav af flere folk til at hacke det som de andre alligevel ikke vil have.

Mht DE-specifik base vs. alment

Det er vel rimeligt nok at GNOME gerne vil definere et 'SDK' hvor bl.a. GTK+ og GNOME-ting er med i basen? Når nu rigtigt meget udvikling drejer sig om desktop-integration og alt det der jazz, så skulle DE'et gerne være en del af pakken. Medmindre FreeDesktop.org kom op i 12. gear, så vil langt det meste skulle kodes op i mod DE'ets særheder for at kunne integrere ordentligt.

Det er så fremadrettet op til GNOME at sørge for at så meget af basen som muligt er DE-uspecifik, sådan at andre vil kunne overtage modellen, sådan at eks. KDEOS og GNOMEOS er så tæt på hinanden som muligt.

Og så er der brandingen, det distro-neutralt korrekte ville selvfølgelig være at kalde det LSBOS* + GNOME extensions, men altså, nu har vi nok af tungekrampefremkaldende sammensætninger i GNU/Linux-verdenen.

* Man kunne overveje Linux Enhanced Standard Base Operating System og få LGBT-miljøet og en græsk ø med på vognen

Glem fd.o, der er ikke noget der forhindrer dem med særinteresser i at lave "first post" i form af specs eller kode.

#27: Ja det mener jeg. Medmindre selvfølgelig du mener at GNOME skal stille med et hav af flere folk til at hacke det som de andre alligevel ikke vil have.Andre alligevel ikke vil have? Jeg er overbevist om at der vil være interesse for et pakkesystem i stil med det jeg beskriver. Du tænker for meget i virksomheder bg, jeg tænker på at et sådan pakkesystem kunne have interesse for open source entusiaster, og er ellers ligeglad med om Canonical etc. er interessered.

#28: Det er vel rimeligt nok at GNOME gerne vil definere et 'SDK' hvor bl.a. GTK+ og GNOME-ting er med i basen?Ja, ingen problem der. Men der er ingen grund til at blande et sådant ønske sammen med pakkesystemet.

#30:
Ja, ingen problem der. Men der er ingen grund til at blande et sådant ønske sammen med pakkesystemet.

Hvis konceptet er at man skulle have det ønske at pakker skal kunne leveres med alle libs i en bundle, der ligger ud over den fælles base, så er det da ret essentielt om gnome-libs er en del af den fælles base?

Eller er det hele konceptet i bundles vi diskuterer?

Eller er det noget helt andet?

#30: Du tænker for meget i virksomheder bg, jeg tænker på at et sådan pakkesystem kunne have interesse for open source entusiaster, og er ellers ligeglad med om Canonical etc. er interessered.
Næh jeg er bare tilpas velinformeret til at være realistisk pessimistisk. Du var jo ikke engang klar over at Nokia konsekvent modarbejdede at få en anstændig løsning for color correction, du troede det var digia. Et andet eksempel: se videoen med Datenwolf og hans KLANG, det han vil løse er kun relateret til Phonon. Altså en død abstraktion der fpr Trolltech tjente det formål at tilbyde kunder DRM media stacks. Sådan nogle vanvittige og ufrie særinteresser skader os stadig. Tak skaberen for at han blev pillet ned. Ellers skulle en amatør fucke hele lyddelen op nu hvor vi endelig er godt på vejod bedre tider.

Eller tror du at en skare af amatører designer, udvikler, implementerer og vedligeholder services fremover? Hvis ja, så kom da lige med et par referencer på at det er lykkedes tidligere at en glok husmoderhackers har løst den opgave.

#31: Eller er det hele konceptet i bundles vi diskuterer?Nemlig! Bundles er ikke at foretrække, netop af den grund du angiver.

#32:
Vi stopper her bg. Det her kommer ingen vegne. Dette handler ikke om ressourcer. Hvis GNOME har ressourcer til at udvikle et DE-afhængigt pakkesystem, kunne de nok også lave et der ikke var det.

#33: Vi stopper her bg.
Nej du stopper her, for du har ingen eksempler på at den slags lader sig gøre af amatører, til gengæld har jeg vist dig flere eksempler på at særinteresser modarbejder fællesinteresserne.

Hvis du mener det er så nemt, så vis det sker, eller fold kortene.

#34:
Dine eksempler har ingen relevans. Men klart, hvis GNOME udviklerne er amatøre (dine ord) kan det nok ikke lade sig gøre.

De har fin relevans, color correction og soundservers er en integreret del af et OS. ja se bare på konkurrenterne i OSX og Win.. GNOME har ingen chance for at pile siloerne ned her, det står sort på hvidt. Og init/service management: hvem kæmper mod linux-only systemd? Jep en silo!

Tag du hellere et kig på hvad der sker i San Diego i disse dage, hvem står for stort set al plumbing? Hvor er alle amatørene og dem med slrinteresser? Bemærk dette er et rent teknisk forum hvor den slags OS integration diskuteres.

#38:

Summen af dine overtrædelser har på trods af adskillige advarsler gennem tiden nået den kritiske masse. Stort set hver eneste uge er der anmeldelser over dine indlæg, og den sidste uge er ingen undtagelse.

Efter du holdt op med at levere nyheder for nogle måneder siden, er der grundlæggende kun tre formål med dine indlæg:

1. Anprise Gnome
2. Nedgøre KDE
3. Skabe splid i al almindelig

En sådan opførsel gennem så lang tid kan ikke toleres, og jeg har derfor taget konsekvensen og bannet dig.

Så er der måske mulighed for, at denne tråd kan komme tilbage på sporet.

Måske nogen med større teknisk viden end mig f.eks. kunne forklare hvorfor, at den pakkeløsning jeg beskriver i #13, ikke kan lade sig gøre, eller hvorfor at GNOMEs model stadig er at foretrække?

#39 Hvor længe? Må indrømme og nyder og læse hans tekniske snilde og viden - og ja jeg er i stand til ignorere hans sprog.

#41:
#40 var et hint om ikke at tage dén diskussion her. Tak :)

Ak ja sorry..

#43:
Det er ok :)

On-topic: Et spørgsmål (primært til phomes): Har GNOME tænkt sig selv at pakke bundelsne, eller er det meningen at upsreams selv skal tage sig af det?

#13: 2/ Giver mulighed for flere versioner af samme bibliotek på en gang
Dette findes i flere distros.
#13: Ja, så har man pludselig et system der er distro neutralt
Kan du uddybe dette? Jeg forstår det ikke.

#45: Kan du uddybe dette? Jeg forstår det ikke.Gerne :) I teorien er alle pakkesystemer vel distroneutrale på et eller andet plan. F.eks. er der mange distroer der bruger rpm, PCLinuxOS bruger deb og Frugalware bruger Arch pakkeformat.

Men distroneutraliteten i det pakkesystem jeg forestiller mig kommer af punkt 3. Nemlig at pakkesystemet skal kunne installeres parallelt med et eksisterende pakkesystem. F.eks. ligesom 0install (der er uden tvivl andre eksempler, men dette var lige fra toppen af mit hoved). Dvs. at uanset hvilken distro du benytter, kan du installere pakkesystemet, og med det samme få adgang til alle pakker det.

Det ville med andre ord være et system uafhængigt af både distroer, DEs og noget som helst andet. Upstream ville kunne udgive pakker, der ville kunne installeres på en hvilket som helst Linux distribution*. Men som et hvert andet pakkesystem kræver det selvfølgelig en hvis opbakning fra starten af, for at kunne blive en success. Men det er jo netop det GNOME kunne, hvis at de ville.

* Dog muligvis med nogle få forbehold. X server version, grafik drivers og deamons kunne jeg forestille mig. Men disse problemer løser GNOMEs bundles heller ikke.

Hvad var der galt med Linux Standard Base?

Det er jo understøttet på de fleste distroer, og hvis man kunne rette fejlene så er der en installeret base at arbejde sig videre med.

#47

Der er for så vidt ikke noget galt med LSB, men det vil være en teknisk fordel, hvis man kunne enes om et fælles koncept, eksempelvis som de to store OS allerede har det.

Forskellen er blot at disse store er organiseret Top-Down, og Linux Buttom-Up. Har man kendskab til organisations struktur, så forstår man fordele og ulemper.

Det virker logisk at organisere LSB Top-Down, men det kan tænkes at medføre, at uenigheden vedr. Backends, DE's og ikke mindst engagemenet i forsøget på at skabe nye IU's m.m. vil dale, eller måske stige, hvis en del af Bottom-Up friheden formindskes, som følge af en mere top styret organisation.

Spørgsmålet er så om et GnomeOS så vil udvikle sig til endnu en ny distro, eller den vil danne basis for de andre Linux med Gnome. Det skal Gnome så bevise om de kan.

----------

Det er korrekt at Bundles allerede installeres med fx et KDE program på Gnome. Også at man allerede, til en vis grænse, kan installere andre Backends end distroens egen. Blot virker det ikke altid som man kunne håbe, og det vil et fælles fodslag formentlig kunne løse, hvis man ellers kan blive enige.

#46:
Faktisk, så er jeg ret sikker på at PCLinuxOS også bruger RPM - de bruger bare et eller andet apt-for-rpm-halløj :) Sådan var det ihvertfald tidligere.

#49

PClos bruger stadig RPM, men ikke DEB, og ganske rigtigt heller ikke YUM som backend. Istedet har de valgt apt-get og aptitude.

Man kan installere YUM på Debian, og Alien er vist også en RPM manager

Det er alt i alt ret forvirret hvis man vælger andet end default. Fx kan man installere kdesudo på gnome osv .... Det giver mening hvis man på Fedora vil installere KDE programmet Krusader og køre den som root, mens den på Ubuntu, Mint m.f. skal køres fra terminalen, eller startes fra en batch.

#49:
Hov ja! Det har du helt ret i. De bruger rpm pakkeformat men Debian pakkeværktøjer.