mboost-dp1
Linux
#1 Hvis du vil have den i Ubuntu sker det gennem en ppa. Den kommer ikke gennem Canonical.
Den føromtalte 200 linjers patch til styresystemet, der kraftigt forbedrer ydeevnen ved multitasking, også kaldet "automated per session task groups", kommer først med i 2.6.38 .
Du kan jo altid selv bygge din kerne ;) https://help.ubuntu.com/community/Kernel/Compile
nbca (2) skrev:#1 Hvis du vil have den i Ubuntu sker det gennem en ppa. Den kommer ikke gennem Canonical.
Du kan jo altid selv bygge din kerne ;) https://help.ubuntu.com/community/Kernel/Compile
Moth (4) skrev:Den føromtalte 200 linjers patch til styresystemet, der kraftigt forbedrer ydeevnen ved multitasking, også kaldet "automated per session task groups", kommer først med i 2.6.38 .
Du kan jo altid selv bygge din kerne ;) https://help.ubuntu.com/community/Kernel/Compile
Jep og så recompile igen hver anden uge fordi der er ny version. Nej tak, når jeg sidder på en distro med binære releases fortrækker jeg at vente.
ruvald (5) skrev:Moth (4) skrev:Den føromtalte 200 linjers patch til styresystemet, der kraftigt forbedrer ydeevnen ved multitasking, også kaldet "automated per session task groups", kommer først med i 2.6.38 .
Du kan jo altid selv bygge din kerne ;) https://help.ubuntu.com/community/Kernel/Compile
Jep og så recompile igen hver anden uge fordi der er ny version. Nej tak, når jeg sidder på en distro med binære releases fortrækker jeg at vente.
For det er nemlig et kæmpe problem at kompilere sin egen kerne. Men hver sin smag :)
Arkimedes (7) skrev:Vi har jo alle sammen kørt Gentoo på et eller andet tidspunkt. Det er lidt ligesom Breezers; Man vokser fra det.
Jeg vil gerne vide, hvilken dist du mener give samme niveau af fleksibilitet og frihed, samt hvor nye versioner af pakker kommer så hurtigt, og har et så stort udvalg indbygget i sin pakke manager som Gentoo.
T-Hawk (9) skrev:Jeg vil gerne vide, hvilken dist du mener give samme niveau af fleksibilitet og frihed, samt hvor nye versioner af pakker kommer så hurtigt, og har et så stort udvalg indbygget i sin pakke manager som Gentoo.
Jeg har lavet en kort optælling på antal pakker i de nævnte distroer:
Arch 8767
Gentoo 14217
Debian 28237
Det kan ikke bruges til så meget.
#9
Arch med Arch Build System?
Hvis du altså ikke ønsker at bruge de i686/x86_64-optimerede binære pakker...
Samtidig har Arch sit AUR, hvorfor ny software hurtigt kan findes til Arch, eksempelvis findes hverken nevernote eller synapse i Gentoo's repos.
Arch med Arch Build System?
Hvis du altså ikke ønsker at bruge de i686/x86_64-optimerede binære pakker...
Samtidig har Arch sit AUR, hvorfor ny software hurtigt kan findes til Arch, eksempelvis findes hverken nevernote eller synapse i Gentoo's repos.
#17
PGP har intet med udgivelseshastighed at goere.
Der en grund til at Debian foerst anser noget som "stable" efter en ret lang testperiode.
Det samme er gaeldende for OpenBSD, fx.
Ubuntu faar pakker *ZOMG FAST*, men det er saa at sidestille med unstable eller testing, ifht. Debian.
Arch er lidt i samme dur. Der er pakkerne bare smidt i dit ansigt, uden at der har vaeret nogen bredere test.
PGP har intet med udgivelseshastighed at goere.
Der en grund til at Debian foerst anser noget som "stable" efter en ret lang testperiode.
Det samme er gaeldende for OpenBSD, fx.
Ubuntu faar pakker *ZOMG FAST*, men det er saa at sidestille med unstable eller testing, ifht. Debian.
Arch er lidt i samme dur. Der er pakkerne bare smidt i dit ansigt, uden at der har vaeret nogen bredere test.
#18
Og hvor mange udgivede pakker er ikke testet upstream?
Udviklere har ikke noget ønske om at ødelægge deres egne pakker.
Og hvor mange udgivede pakker er ikke testet upstream?
Udviklere har ikke noget ønske om at ødelægge deres egne pakker.
#19
Upstream? Mod stroemmen?
Saa derfor er der simpelthen aldrig sikkerhedsfejl/huller eller bare generelt problemer med software der egentligt er beta udgaver?
Og hvor mange udgivede pakker er ikke testet upstream?
Upstream? Mod stroemmen?
Udviklere har ikke noget ønske om at ødelægge deres egne pakker.
Saa derfor er der simpelthen aldrig sikkerhedsfejl/huller eller bare generelt problemer med software der egentligt er beta udgaver?
#20
Før en udgivelse der ikke blot er snapshots af git/bzr/svn er der som regel foregået noget test, der tjekker at pakkerne ikke er ubrugelige og knækker systemet. Upstream er blot en anden måde at sige tæt på kilden, som det stammer fra geografien.
Jo, men det er der også med udførligt testet software.
Før en udgivelse der ikke blot er snapshots af git/bzr/svn er der som regel foregået noget test, der tjekker at pakkerne ikke er ubrugelige og knækker systemet. Upstream er blot en anden måde at sige tæt på kilden, som det stammer fra geografien.
Saa derfor er der simpelthen aldrig sikkerhedsfejl/huller eller bare generelt problemer med software der egentligt er beta udgaver?
Jo, men det er der også med udførligt testet software.
#21
Tjah, personligt stoler jeg ikke paa at "Per RapeYourFace" har lavet en ordentlig test af hans SSH-keygen. Der vil jeg saa vaere mere tilboejelig til at stole paa Debians dev team og deres test.
(Og jeg valgte netop dette, fordi der ogsaa var huller i *efter* Debian lod det komme med)
.. Skal vi lige hurtigt blive enige om selvtest typisk ikke er saerligt optimalt?
Det er i hvert fald min erfaring fra arbejde i QA og samtlige andre QA arbejdere jeg kenders mening.
Før en udgivelse der ikke blot er snapshots af git/bzr/svn er der som regel foregået noget test, der tjekker at pakkerne ikke er ubrugelige og knækker systemet.
Tjah, personligt stoler jeg ikke paa at "Per RapeYourFace" har lavet en ordentlig test af hans SSH-keygen. Der vil jeg saa vaere mere tilboejelig til at stole paa Debians dev team og deres test.
(Og jeg valgte netop dette, fordi der ogsaa var huller i *efter* Debian lod det komme med)
Jo, men det er der også med udførligt testet software.
.. Skal vi lige hurtigt blive enige om selvtest typisk ikke er saerligt optimalt?
Det er i hvert fald min erfaring fra arbejde i QA og samtlige andre QA arbejdere jeg kenders mening.
Der vil jeg saa vaere mere tilboejelig til at stole paa Debians dev team og deres test.
(Og jeg valgte netop dette, fordi der ogsaa var huller i *efter* Debian lod det komme med) skrev:
De samme devs der lod OpenSSL køre med så alvorlige sikkerhedsfejl på grund af heavy patching? Hvilket jo kun var et problem, fordi de ændrede ved den originale pakke.
Skal vi lige hurtigt blive enige om selvtest typisk ikke er saerligt optimalt? skrev:
Enig, derfor har man betatests før udgivelse.
Egentlig er jeg imponeret af Debian og forstår deres incitament til at gøre deres produkt så stabilt. Det er særdeles velegnet til servere. Problemet for mit vedkommende med et sådanne produkt er blot, at hverken lydkort, netværk eller grafik er understøttet særlig godt i lenny eller squeeze og at skulle rode med apt-pinning og 3 forskellige repos for software er for mig unødvendigt uoverskueligt. Arch e.l. appellerer mere til mig, da vedligeholdelse af pakker forekommer mig meget nemmere.
#23
Nej, jeg gjorde ej. Som jeg skrev, valgte jeg specifikt dette eksempel.
#22
Du er velkommen til at undersoege sagen igen.
Jeg fik et fix til fejlen inden jeg overhovedet saa at fejlen var der.
As in, systemet er ikke "fool proof", men det er klart at foretraekke.
"De" ? Du mener en 3. parts udvikler? Ja.
Det er netop problemet her, at de ikke fik testet det ordentligt.
Ja, det virkede jo rigtigt godt for Debian OpenSSL :P
Betatests er fint. Hvor meget "beta" er der i Ubuntu? Arch? Gentoo?
Mit bud (fra sidst jeg brugte dem): meget.
Ja. Jeg bruger testing paa ikke-servere. Det er Debians udgave af "beta" eller "ikke helt egnet til stable" :)
Err, I beg to differ.
Jeg har endnu ikke haft en server, laptop eller stationaer, hvor jeg skulle rode med "apt-pinning" ? (Det udtryk har jeg endda aldrig hoert foer. ...)
Broadcom, Intel netkort, amd grafikkort, etc. Alt virker.
Det er faktisk mere end 6-7 aar siden jeg sidst havde et problem af den art.
Du tilfoejer Contrib og Non-free til dit *ene* repo?
(de to andre der er, er sikkerhedsopdateringer)
How so?
Og hvad mener du med "vedligeholdelse"?
Som udvikler eller som bruger?
Fra udviklerens side kan jeg *snildt* se argumentet. Debian ville ikke have din pakke med foer om min. 6 maaneder.
Fra brugerens side kan jeg ikke se hvordan det kan vaere "nemmere". Debian har et fint gui til opdateringer. Det er automatisk og du behoever faktisk ikke goere andet end at klikke OK. :)
Nej, jeg gjorde ej. Som jeg skrev, valgte jeg specifikt dette eksempel.
#22
De samme devs der lod OpenSSL køre med så alvorlige sikkerhedsfejl på grund af heavy patching?
Du er velkommen til at undersoege sagen igen.
Jeg fik et fix til fejlen inden jeg overhovedet saa at fejlen var der.
As in, systemet er ikke "fool proof", men det er klart at foretraekke.
Hvilket jo kun var et problem, fordi de ændrede ved den originale pakke.
"De" ? Du mener en 3. parts udvikler? Ja.
Det er netop problemet her, at de ikke fik testet det ordentligt.
Enig, derfor har man betatests før udgivelse.
Ja, det virkede jo rigtigt godt for Debian OpenSSL :P
Betatests er fint. Hvor meget "beta" er der i Ubuntu? Arch? Gentoo?
Mit bud (fra sidst jeg brugte dem): meget.
Egentlig er jeg imponeret af Debian og forstår deres incitament til at gøre deres produkt så stabilt. Det er særdeles velegnet til servere.
Ja. Jeg bruger testing paa ikke-servere. Det er Debians udgave af "beta" eller "ikke helt egnet til stable" :)
Problemet for mit vedkommende med et sådanne produkt er blot, at hverken lydkort, netværk eller grafik er understøttet særlig godt i lenny eller squeeze
Err, I beg to differ.
Jeg har endnu ikke haft en server, laptop eller stationaer, hvor jeg skulle rode med "apt-pinning" ? (Det udtryk har jeg endda aldrig hoert foer. ...)
Broadcom, Intel netkort, amd grafikkort, etc. Alt virker.
Det er faktisk mere end 6-7 aar siden jeg sidst havde et problem af den art.
og at skulle rode med apt-pinning og 3 forskellige repos for software er for mig unødvendigt uoverskueligt.
Du tilfoejer Contrib og Non-free til dit *ene* repo?
(de to andre der er, er sikkerhedsopdateringer)
Arch e.l. appellerer mere til mig, da vedligeholdelse af pakker forekommer mig meget nemmere.
How so?
Og hvad mener du med "vedligeholdelse"?
Som udvikler eller som bruger?
Fra udviklerens side kan jeg *snildt* se argumentet. Debian ville ikke have din pakke med foer om min. 6 maaneder.
Fra brugerens side kan jeg ikke se hvordan det kan vaere "nemmere". Debian har et fint gui til opdateringer. Det er automatisk og du behoever faktisk ikke goere andet end at klikke OK. :)
Mht. OpenSSL forekom problemet jo kun, fordi Debian valgte at patche deres pakker i den grad, de nu engang gør det.
Hvis betatest er af 1 år gammel software efter udgivelse.
Varierende grad. Ubuntu har en intensiv brugerflade, der hjælper under betatests før en 'stable' udgivelse. Arch har i højere grad software, der lige er kommet fra upstream, men det er ikke betasoftware m.m. det har betatagget. Arch har sit testing repo til at gennemteste for de værste fejl. Gentoo derimod har vist rene vanilla pakker.
Det hele munder dog ud i en forskellig tilgang til softwarehåndteringen på den måde, at Arch brugere nok hellere vil have nye funktioner fra deres programmer og det forventes, at der dertil er nogle fejl(fejlrettelser kommer også hurtigt, når de er fixet upstream). Hvor Debian i stedet går efter stabilitet fremfor features. Begge har deres plads i økosystemet, jeg ville personligt aldrig turde køre Arch på en server.
Apt-pinning er den prioritering du gør igennem din /etc/apt/preferences fil.
Mit lydkorts HDMI funktion kan ikke bruges med Debian. Jeg installerede den nyeste ALSA-driver fra Unstable via dpkg og konfigurede den. Lyden duede herefter lokalt på maskinen(det gør den ikke med default-alsa, da driveren kom i 2.6.34). Nvidia er også en kamp at få til at køre ordentligt...
Ja til mit experimental, unstable og squeeze repo til deb-src og deb udgaven.
Vedligeholdensen er nemmere ved at jeg selv har installeret pakkerne og sat dem op. Dermed ved jeg, hvor(dan) konfigurationen skal ændres, hvis jeg vil det. At afinstallere den prop. ATI driver til fordel for den åbne i Debian og at sætte den op efterfølgende var ligeledes en kamp at rode med, da jeg ikke vidste, hvad APT havde gjort af konfigurationer. Ligeledes duede mit lydkort efter en simpel opdatering og grafikkortet duede efter to simple kommandoer.
Vedligeholdelse generelt bliver meget nemmere, når det er sat op, fordi blacklisting af daemons og moduler findes i en .conf modsat min debian installation, der render rundt med 6 af disse .conf filer for tiden.
Jeg slår det fra, at den automatisk skal opdatere sig. Jeg har det bedre med, selv at bestemme, hvornår den opdatere pakkedatabasen og pakkeinstallationerne(og det er ikke monstersvært at skrive sudo pacman -Syu).
Jeg bruger testing paa ikke-servere. Det er Debians udgave af "beta" eller "ikke helt egnet til stable
Hvis betatest er af 1 år gammel software efter udgivelse.
Betatests er fint. Hvor meget "beta" er der i Ubuntu? Arch? Gentoo?
Varierende grad. Ubuntu har en intensiv brugerflade, der hjælper under betatests før en 'stable' udgivelse. Arch har i højere grad software, der lige er kommet fra upstream, men det er ikke betasoftware m.m. det har betatagget. Arch har sit testing repo til at gennemteste for de værste fejl. Gentoo derimod har vist rene vanilla pakker.
Det hele munder dog ud i en forskellig tilgang til softwarehåndteringen på den måde, at Arch brugere nok hellere vil have nye funktioner fra deres programmer og det forventes, at der dertil er nogle fejl(fejlrettelser kommer også hurtigt, når de er fixet upstream). Hvor Debian i stedet går efter stabilitet fremfor features. Begge har deres plads i økosystemet, jeg ville personligt aldrig turde køre Arch på en server.
Jeg har endnu ikke haft en server, laptop eller stationaer, hvor jeg skulle rode med "apt-pinning" ? (Det udtryk har jeg endda aldrig hoert foer. ...)
Broadcom, Intel netkort, amd grafikkort, etc. Alt virker.
Det er faktisk mere end 6-7 aar siden jeg sidst havde et problem af den art.
Apt-pinning er den prioritering du gør igennem din /etc/apt/preferences fil.
Mit lydkorts HDMI funktion kan ikke bruges med Debian. Jeg installerede den nyeste ALSA-driver fra Unstable via dpkg og konfigurede den. Lyden duede herefter lokalt på maskinen(det gør den ikke med default-alsa, da driveren kom i 2.6.34). Nvidia er også en kamp at få til at køre ordentligt...
Du tilfoejer Contrib og Non-free til dit *ene* repo?
Ja til mit experimental, unstable og squeeze repo til deb-src og deb udgaven.
How so?
Og hvad mener du med "vedligeholdelse"?
Vedligeholdensen er nemmere ved at jeg selv har installeret pakkerne og sat dem op. Dermed ved jeg, hvor(dan) konfigurationen skal ændres, hvis jeg vil det. At afinstallere den prop. ATI driver til fordel for den åbne i Debian og at sætte den op efterfølgende var ligeledes en kamp at rode med, da jeg ikke vidste, hvad APT havde gjort af konfigurationer. Ligeledes duede mit lydkort efter en simpel opdatering og grafikkortet duede efter to simple kommandoer.
Vedligeholdelse generelt bliver meget nemmere, når det er sat op, fordi blacklisting af daemons og moduler findes i en .conf modsat min debian installation, der render rundt med 6 af disse .conf filer for tiden.
Debian har et fint gui til opdateringer. Det er automatisk og du behoever faktisk ikke goere andet end at klikke OK. :)
Jeg slår det fra, at den automatisk skal opdatere sig. Jeg har det bedre med, selv at bestemme, hvornår den opdatere pakkedatabasen og pakkeinstallationerne(og det er ikke monstersvært at skrive sudo pacman -Syu).
#26
Tjoh, "problemet" forekommer saa i mange andre pakker, hvor det ikke skyldes Debians fixes, men udviklerens. Der er mange fordele og ulemper ved de forskellige maader at goere det paa :)
Tjoh, igen, beta og beta. Debian tager det med i testing naar det har vaeret i Unstable og er fundet "godt nok".
Det var en lemfaeldig maade at sige "meget" paa? :)
Tjah, Ubuntu er klasse eksemplet paa hvad der er galt med forhastede releases :D
Jeg har stadig traumer efter sidste gang jeg proevede det :P
Gentoo er bare for folk der ikke kan lide at deres ting virker. Jeg har ikke noget imod Arch, jeg har bare et problem med at bruge Arch til alt andet end "Jeg er ligeglad med om den her maskine virker"-computere :)
Helt enig :)
Default.
Jeg har ikke roert det endnu og kommer nok heller ikke til det :)
Hvilket lydkort?
Mit har ikke HDMI, men mit grafikkorts HDMI virker med lyd default :)
Det samme goer mit TerraTek med SPDIF.
nVidia er en kamp uanset hvilken linux distro du vaelger. Det skyldes aerligt og redeligt at nVidia ikke oensker at frigive noget som helst information om deres drivere, saa alt skal reverse-engineeres. (Jeg kender btw en der udvikler grafikkort drivere til MorphOS, som netop ogsaa har problemer med nVidia af samme aarsag :))
Hvorfor squeeze?
Og i det hele taget, hvorfor ikke blot hente pakkerne selv ellers?
Pakkehandleren vil alligevel fucke dig haardt hvis du mikser for meget, saa du vil nok faa meget mere ud af ikke at bruge apt til at haandtere mixet mellem stable/testing/unstable.
Ah, I see.
Det giver ikke mening at bruge AMDs prop. drivers. At all.
Debians er langt hurtigere og mere stabile.
Korrekt. Spoergsmaalet er, hvordan du vil definere "nemmere".
Automatisk er nemmere end at rode med alt muligt :)
Well, saa er du nok ogsaa mere klasse eksemplet paa en der ikke boer koere Debian.
Arch er fint hvis du selv vil goere alting.
Mit problem ligger mest i at jeg ikke kan se noget grund til at goere dette.
Debian kan customizes til du bliver groen i hovedet og doer. Reelt set kan du goere alt hvad Arch kan, nemmere i Debian - det kraever bare at du tager "Arch"-tilgangen til det.
HVis du vil have et "not-so-stable"-OS, saa tager du bare unstable og er picky med hvilke pakker du vil have. :)
Mht. OpenSSL forekom problemet jo kun, fordi Debian valgte at patche deres pakker i den grad, de nu engang gør det.
Tjoh, "problemet" forekommer saa i mange andre pakker, hvor det ikke skyldes Debians fixes, men udviklerens. Der er mange fordele og ulemper ved de forskellige maader at goere det paa :)
Hvis betatest er af 1 år gammel software efter udgivelse.
Tjoh, igen, beta og beta. Debian tager det med i testing naar det har vaeret i Unstable og er fundet "godt nok".
Varierende grad.
Det var en lemfaeldig maade at sige "meget" paa? :)
Ubuntu har en intensiv brugerflade, der hjælper under betatests før en 'stable' udgivelse.
Tjah, Ubuntu er klasse eksemplet paa hvad der er galt med forhastede releases :D
Jeg har stadig traumer efter sidste gang jeg proevede det :P
Arch har i højere grad software, der lige er kommet fra upstream, men det er ikke betasoftware m.m. det har betatagget. Arch har sit testing repo til at gennemteste for de værste fejl. Gentoo derimod har vist rene vanilla pakker.
Gentoo er bare for folk der ikke kan lide at deres ting virker. Jeg har ikke noget imod Arch, jeg har bare et problem med at bruge Arch til alt andet end "Jeg er ligeglad med om den her maskine virker"-computere :)
Det hele munder dog ud i en forskellig tilgang til softwarehåndteringen på den måde, at Arch brugere nok hellere vil have nye funktioner fra deres programmer og det forventes, at der dertil er nogle fejl(fejlrettelser kommer også hurtigt, når de er fixet upstream). Hvor Debian i stedet går efter stabilitet fremfor features. Begge har deres plads i økosystemet, jeg ville personligt aldrig turde køre Arch på en server.
Helt enig :)
Apt-pinning er den prioritering du gør igennem din /etc/apt/preferences fil.
Default.
Jeg har ikke roert det endnu og kommer nok heller ikke til det :)
Mit lydkorts HDMI funktion kan ikke bruges med Debian.
Hvilket lydkort?
Mit har ikke HDMI, men mit grafikkorts HDMI virker med lyd default :)
Det samme goer mit TerraTek med SPDIF.
Jeg installerede den nyeste ALSA-driver fra Unstable via dpkg og konfigurede den. Lyden duede herefter lokalt på maskinen(det gør den ikke med default-alsa, da driveren kom i 2.6.34). Nvidia er også en kamp at få til at køre ordentligt...
nVidia er en kamp uanset hvilken linux distro du vaelger. Det skyldes aerligt og redeligt at nVidia ikke oensker at frigive noget som helst information om deres drivere, saa alt skal reverse-engineeres. (Jeg kender btw en der udvikler grafikkort drivere til MorphOS, som netop ogsaa har problemer med nVidia af samme aarsag :))
Ja til mit experimental, unstable og squeeze repo til deb-src og deb udgaven.
Hvorfor squeeze?
Og i det hele taget, hvorfor ikke blot hente pakkerne selv ellers?
Pakkehandleren vil alligevel fucke dig haardt hvis du mikser for meget, saa du vil nok faa meget mere ud af ikke at bruge apt til at haandtere mixet mellem stable/testing/unstable.
Vedligeholdensen er nemmere ved at jeg selv har installeret pakkerne og sat dem op. Dermed ved jeg, hvor(dan) konfigurationen skal ændres, hvis jeg vil det.
Ah, I see.
At afinstallere den prop. ATI driver til fordel for den åbne i Debian og at sætte den op efterfølgende var ligeledes en kamp at rode med, da jeg ikke vidste, hvad APT havde gjort af konfigurationer.
Det giver ikke mening at bruge AMDs prop. drivers. At all.
Debians er langt hurtigere og mere stabile.
Vedligeholdelse generelt bliver meget nemmere, når det er sat op, fordi blacklisting af daemons og moduler findes i en .conf modsat min debian installation, der render rundt med 6 af disse .conf filer for tiden.
Korrekt. Spoergsmaalet er, hvordan du vil definere "nemmere".
Automatisk er nemmere end at rode med alt muligt :)
Jeg slår det fra, at den automatisk skal opdatere sig. Jeg har det bedre med, selv at bestemme, hvornår den opdatere pakkedatabasen og pakkeinstallationerne(og det er ikke monstersvært at skrive sudo pacman -Syu
Well, saa er du nok ogsaa mere klasse eksemplet paa en der ikke boer koere Debian.
Arch er fint hvis du selv vil goere alting.
Mit problem ligger mest i at jeg ikke kan se noget grund til at goere dette.
Debian kan customizes til du bliver groen i hovedet og doer. Reelt set kan du goere alt hvad Arch kan, nemmere i Debian - det kraever bare at du tager "Arch"-tilgangen til det.
HVis du vil have et "not-so-stable"-OS, saa tager du bare unstable og er picky med hvilke pakker du vil have. :)
#30
Sid er ikke et rolling release af stable. Det er et rolling release af pakker der ikke er testede og typisk kommer direkte fra udvikleren.
Det er nok mere at sammenligne med Gentoo..
Udover det saa er Debian jo super-nazi naar det kommer til sikkerhed og stabilitet. Den typiske Debian bruger hader jo alt andet end Stable, som jo er min. 6 maaneder gamle releases ;)
Sid er ikke et rolling release af stable. Det er et rolling release af pakker der ikke er testede og typisk kommer direkte fra udvikleren.
Det er nok mere at sammenligne med Gentoo..
Udover det saa er Debian jo super-nazi naar det kommer til sikkerhed og stabilitet. Den typiske Debian bruger hader jo alt andet end Stable, som jo er min. 6 maaneder gamle releases ;)
#29
Det samme står i about ved både Gentoo og Arch
Use at own risk og Software comes with NO WARRANTY
Men hvis en fejl skyldes noget upstream og denne fejl løses så er det nemmere blot at installere denne opdatering end at en anden dev skal gøre specifikke patches til deres distro.
Der er ikke noget /etc/apt/preferences fil ved default, da der ikke er mere end enten Lenny el. Squeeze i din sources.list fil ved default.
Den åbne driver tager 20% af min batterilevetid i 2.6.32 implementeringen. Det er ikke ligefrem det værd. Samtidig kan den ikke køre mine spil.
Aldeles ikke fucke mig op, dertil har jeg min apt-pinning opsætning, der definerer, at kun Squeeze opdateringer skal komme ind m.m. jeg siger til apt gennem -t unstable el. -t experimental at den skal bruge disse repos som dl-kilde.
For folk som ikke skal rode med det bagefter eller føler et behov for at vide, hvad ens computer foretager sig. Da jeg prøvede Debian Squeeze gennem et netinstall fandt jeg, at jeg alligevel skulle ind og rode med laptop-mode, cpufrequtils og andre strømstyringsværktøjer, hertil vidste jeg ikke, hvor det lå og det blev et rod at rende rundt med. Arch kræver eg at du selv sætter det op, og henviser derfor til, hvor filerne er, så kan jeg som bruger nemt finde tilbage og rette noget, hvis det ikke fungere ved default.
Aldeles ikke. Unstable har stadig 2.6.32 i sine repos og har samme browser udgave som jeg har Squeeze.
I Debian skal jeg også rode med at rydde op efter, hvad Debian mener skal være default, for derefter selv at indstiller det, som jeg vil have det. Desuden er Archs dokumentation Debians overlegen, hvor jeg har haft behov for at slå det op.
Det samme står i about ved både Gentoo og Arch
Use at own risk og Software comes with NO WARRANTY
Tjoh, "problemet" forekommer saa i mange andre pakker, hvor det ikke skyldes Debians fixes, men udviklerens. Der er mange fordele og ulemper ved de forskellige maader at goere det paa :)
Men hvis en fejl skyldes noget upstream og denne fejl løses så er det nemmere blot at installere denne opdatering end at en anden dev skal gøre specifikke patches til deres distro.
Default. Jeg har ikke roert det endnu og kommer nok heller ikke til det :) skrev:
Der er ikke noget /etc/apt/preferences fil ved default, da der ikke er mere end enten Lenny el. Squeeze i din sources.list fil ved default.
Det giver ikke mening at bruge AMDs prop. drivers. At all.
Debians er langt hurtigere og mere stabile.
Den åbne driver tager 20% af min batterilevetid i 2.6.32 implementeringen. Det er ikke ligefrem det værd. Samtidig kan den ikke køre mine spil.
Pakkehandleren vil alligevel fucke dig haardt hvis du mikser for meget, saa du vil nok faa meget mere ud af ikke at bruge apt til at haandtere mixet mellem stable/testing/unstable.
Aldeles ikke fucke mig op, dertil har jeg min apt-pinning opsætning, der definerer, at kun Squeeze opdateringer skal komme ind m.m. jeg siger til apt gennem -t unstable el. -t experimental at den skal bruge disse repos som dl-kilde.
Korrekt. Spoergsmaalet er, hvordan du vil definere "nemmere".
Automatisk er nemmere end at rode med alt muligt :)
For folk som ikke skal rode med det bagefter eller føler et behov for at vide, hvad ens computer foretager sig. Da jeg prøvede Debian Squeeze gennem et netinstall fandt jeg, at jeg alligevel skulle ind og rode med laptop-mode, cpufrequtils og andre strømstyringsværktøjer, hertil vidste jeg ikke, hvor det lå og det blev et rod at rende rundt med. Arch kræver eg at du selv sætter det op, og henviser derfor til, hvor filerne er, så kan jeg som bruger nemt finde tilbage og rette noget, hvis det ikke fungere ved default.
Debian kan customizes til du bliver groen i hovedet og doer. Reelt set kan du goere alt hvad Arch kan, nemmere i Debian - det kraever bare at du tager "Arch"-tilgangen til det.
HVis du vil have et "not-so-stable"-OS, saa tager du bare unstable og er picky med hvilke pakker du vil have. :)
Aldeles ikke. Unstable har stadig 2.6.32 i sine repos og har samme browser udgave som jeg har Squeeze.
I Debian skal jeg også rode med at rydde op efter, hvad Debian mener skal være default, for derefter selv at indstiller det, som jeg vil have det. Desuden er Archs dokumentation Debians overlegen, hvor jeg har haft behov for at slå det op.
#33
Hvis du læser hele mit indlæg kan du se at jeg netop selv skriver at det er det samme uanset hvad man vælger at køre. Og jeg uddyber endda at OpenSSL fadæsen er det største problem ved den udtalelse fra Debian teamet. Det virker som om der skete en fejl med samarbejdet med upstream projektet. Jeg går ud fra at de normalt har et samarbejde i en eller anden form?
Hvis du læser hele mit indlæg kan du se at jeg netop selv skriver at det er det samme uanset hvad man vælger at køre. Og jeg uddyber endda at OpenSSL fadæsen er det største problem ved den udtalelse fra Debian teamet. Det virker som om der skete en fejl med samarbejdet med upstream projektet. Jeg går ud fra at de normalt har et samarbejde i en eller anden form?
#34
jeg forstod det sidste som en indsigelse imod Debians erklæring af deres rolling release repos som værende unødvendig?
Jeg er klar over at man altid selv har ansvaret for ens system men andre kan klare roling releases uden større problemer...
jeg forstod det sidste som en indsigelse imod Debians erklæring af deres rolling release repos som værende unødvendig?
#31
Ja, debian teamet er langt fra perfekte. Vi kan ikke alle vaere ligesaa selvfede som OpenBSD :D
#32
Baade og. Det kommer vel an paa hvor hurtigt det loeses?
At noget bliver fikset af selve udvikleren er ikke altid hurtigere end at dev teamet fra Debian naar at skrive en patch.
Debian patcher jo stadig sikkerhedsfejl, selvom man bruger Stable :P
PRaecis. Som sagt, Default.
WTF. Scary. Hvilket gfxkort har du?
Jeg har testet med en raekke af ATI kort gennem tiderne og har endnu ikke set Debians drivere vaere underlegne :)
Tjah, jeg kan blot sige at alle gange jeg har mikset med pakkerne, har den vaeret umaadeligt ked af det naar jeg saa ville lave roll back, eller dist-upgrade :)
NetInstall er ikke til folk der ikke selv vil vaelge hvad de vil opsaette/installere :)
Ja, Arch er fint nok, hvis man selv vil goere arbejdet :)
Jeg bruger ikke IceWeasel. Eller Firefox. Opera, all the way.
Det er faktisk noget af det foerste jeg goer: Tilfoeje opera til mit apt-sources :)
Men hvis du vil have en nyere kernel, er det dig frit at installere den.
Du kunne ogsaa vaelge selv at konfigurere det inden install, fx.
Eller installere det manuelt. Der er mange loesninger i Debian.
OK? Jeg har sjaeldent brug for den dybe dokumentation og har aldrig brugt det i Arch. Debian har stort set altid haft fyldestgoerende dokumentation til mig. Det mest besvaerlige jeg har lavet var opsaetning af TC .. Fuck hvor det sutter roev >.< PacketFilter all the way baby :D
Ja, debian teamet er langt fra perfekte. Vi kan ikke alle vaere ligesaa selvfede som OpenBSD :D
#32
Men hvis en fejl skyldes noget upstream og denne fejl løses så er det nemmere blot at installere denne opdatering end at en anden dev skal gøre specifikke patches til deres distro.
Baade og. Det kommer vel an paa hvor hurtigt det loeses?
At noget bliver fikset af selve udvikleren er ikke altid hurtigere end at dev teamet fra Debian naar at skrive en patch.
Debian patcher jo stadig sikkerhedsfejl, selvom man bruger Stable :P
Der er ikke noget /etc/apt/preferences fil ved default, da der ikke er mere end enten Lenny el. Squeeze i din sources.list fil ved default.
PRaecis. Som sagt, Default.
Den åbne driver tager 20% af min batterilevetid i 2.6.32 implementeringen. Det er ikke ligefrem det værd. Samtidig kan den ikke køre mine spil.
WTF. Scary. Hvilket gfxkort har du?
Jeg har testet med en raekke af ATI kort gennem tiderne og har endnu ikke set Debians drivere vaere underlegne :)
Aldeles ikke fucke mig op, dertil har jeg min apt-pinning opsætning, der definerer, at kun Squeeze opdateringer skal komme ind m.m. jeg siger til apt gennem -t unstable el. -t experimental at den skal bruge disse repos som dl-kilde.
Tjah, jeg kan blot sige at alle gange jeg har mikset med pakkerne, har den vaeret umaadeligt ked af det naar jeg saa ville lave roll back, eller dist-upgrade :)
For folk som ikke skal rode med det bagefter eller føler et behov for at vide, hvad ens computer foretager sig. Da jeg prøvede Debian Squeeze gennem et netinstall fandt jeg, at jeg alligevel skulle ind og rode med laptop-mode, cpufrequtils og andre strømstyringsværktøjer, hertil vidste jeg ikke, hvor det lå og det blev et rod at rende rundt med.
NetInstall er ikke til folk der ikke selv vil vaelge hvad de vil opsaette/installere :)
Arch kræver eg at du selv sætter det op, og henviser derfor til, hvor filerne er, så kan jeg som bruger nemt finde tilbage og rette noget, hvis det ikke fungere ved default.
Ja, Arch er fint nok, hvis man selv vil goere arbejdet :)
Aldeles ikke. Unstable har stadig 2.6.32 i sine repos og har samme browser udgave som jeg har Squeeze.
Jeg bruger ikke IceWeasel. Eller Firefox. Opera, all the way.
Det er faktisk noget af det foerste jeg goer: Tilfoeje opera til mit apt-sources :)
Men hvis du vil have en nyere kernel, er det dig frit at installere den.
I Debian skal jeg også rode med at rydde op efter, hvad Debian mener skal være default, for derefter selv at indstiller det, som jeg vil have det.
Du kunne ogsaa vaelge selv at konfigurere det inden install, fx.
Eller installere det manuelt. Der er mange loesninger i Debian.
Desuden er Archs dokumentation Debians overlegen, hvor jeg har haft behov for at slå det op.
OK? Jeg har sjaeldent brug for den dybe dokumentation og har aldrig brugt det i Arch. Debian har stort set altid haft fyldestgoerende dokumentation til mig. Det mest besvaerlige jeg har lavet var opsaetning af TC .. Fuck hvor det sutter roev >.< PacketFilter all the way baby :D
nbca (35) skrev:#34
jeg forstod det sidste som en indsigelse imod Debians erklæring af deres rolling release repos som værende unødvendig?
Jeg er ikke helt med på hvad du mener. Men jeg er ret sikker på at jeg skal sige nej?
Jeg er på ingen måde mostander af roling releases. Jeg har altid brugt roling releases' systemer.. når vi taler open source systemer. :)
Baade og. Det kommer vel an paa hvor hurtigt det loeses?
Selvf. men Debians pakker er ikke ofte lige så langt fremme i skoene som upstream, så upstream får nok lavet et fix hurtigere end Debian tager den nye pakke til sig. De kan selvfølgelig backporte patchen.
WTF. Scary. Hvilket gfxkort har du?
ATI Mobility Radeon 42et-eller-andet fra september på den omtalte computer.
Tjah, jeg kan blot sige at alle gange jeg har mikset med pakkerne, har den vaeret umaadeligt ked af det naar jeg saa ville lave roll back, eller dist-upgrade :)
Det er vel kun et problem hvis ens sources kører på squeeze, lenny el. oldstable? Er de sat til testing eller unstable forekommer der jo ikke dist-upgrades.
NetInstall er ikke til folk der ikke selv vil vaelge hvad de vil opsaette/installere :)
Det er det for Arch :)...
Men Debian i sig selv kører jo med autoconfig(der ofte er anderledes end den, der kommer i vanilla pakker), så det nytter ikke meget selv at installere pakken :)...
Ja, Arch er fint nok, hvis man selv vil goere arbejdet :)
Jeg vil hellere udføre det godt fra starten end at skulle bøvle med det ved en senere lejlighed. Ved selv at sætte det op fra starten, ved jeg, hvad der er sket og kan således lettere ændre tingene bagefter.
OK? Jeg har sjaeldent brug for den dybe dokumentation og har aldrig brugt det i Arch. Debian har stort set altid haft fyldestgoerende dokumentation til mig.
Hvad skal man lægge i dyb dokumentation?
Arch fortæller blot, hvordan en pakke er skruet sammen og hvordan du konfigurerer den. Eksempelvist hvordan den har inddelt KDE og hvorledes du ændrer basale ting i KDE(samt almen debugging).
Debians dokumentation for ATIProprietary var særdeles mangelfuld for mit vedkommende. De henvist til en meget bar xorg.conf fil jeg først skulle oprette og så copy-paste noget over i, i stedet for at bruge ATIs eget værktøj hertil ved dette kald: "aticonfig --initial" hvilket ikke er nævnt men giver langt flere muligheder(mange af dem med # foran).
Hubert,#37 skrev:Jeg er på ingen måde mostander af roling releases. Jeg har altid brugt roling releases' systemer.. når vi taler open source systemer. :)
jeg forstod dit indlæg som værende en kritik imod Debians erklæring af deres Unstable som værende "ikke til dagligt brug", når andre håndterede rolling release modellen så godt.
Det var med baggrund heri at jeg skrev, at Arch også havde det, da jeg tolkede dit indlæg som værende indirekte kritisk overfor Debian. Jeg tog vist fejl :).
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