Gå til innhold

Xfce 4.10 - Apple usb tastatur virker ikke


kay

Anbefalte innlegg

Jeg støtter også Debian. Den er så nær "Free as in Freedom" som du kommer blant de store distroene. Ifølge FSF er ikke Debian 100% fri, men som du ser på den siden er heller ingen av de andre distroene regnet for å være 100% fri. FSF vil ikke annerkjenne Debian som 100% fri siden det er mulig å legge til non-free og contrib repos, selv om disse ikke er aktivert by default. Og ser du på f.eks Arch, så distribuerer de ufri binærkode med kernelen sin. Så Arch er mindre fri enn Debian, og oppsett av Arch er i tillegg unødvendig mye kjas og mas. Gentoo vil jeg si er bare for veldig spesielt interesserte som har for altfor mye tid til overs.

 

FSF har også en liste over 100% frie distroer, men siden alle sammen er nisje-distroer ser jeg ikke helt poenget med å velge dem. Spesielt ikke når Debian er 100% fri så lenge du ikke aktiverer non-free og contrib repoene.

Lenke til kommentar
Videoannonse
Annonse

Jeg støtter også Debian. Den er så nær "Free as in Freedom" som du kommer blant de store distroene. Ifølge FSF er ikke Debian 100% fri, men som du ser på den siden er heller ingen av de andre distroene regnet for å være 100% fri. FSF vil ikke annerkjenne Debian som 100% fri siden det er mulig å legge til non-free og contrib repos, selv om disse ikke er aktivert by default. Og ser du på f.eks Arch, så distribuerer de ufri binærkode med kernelen sin. Så Arch er mindre fri enn Debian, og oppsett av Arch er i tillegg unødvendig mye kjas og mas. Gentoo vil jeg si er bare for veldig spesielt interesserte som har for altfor mye tid til overs.

 

FSF har også en liste over 100% frie distroer, men siden alle sammen er nisje-distroer ser jeg ikke helt poenget med å velge dem. Spesielt ikke når Debian er 100% fri så lenge du ikke aktiverer non-free og contrib repoene.

 

Av distroer som utelukkende er laget med tanke på "Free as in freedom" så er Fedora det første jeg kommer på, som forøvrig passer nybegynnere fint.

Du har også "non-free" varianter av repoer der også, men de er ikke aktivert som default og det er heller ingen medie codecs etc installert som følge av dette, som i Debian.

 

Nå hadde ikke jeg i utgangspunktet tenkt til å starte en distro krig her, men påstanden over her hører heller hjemme i 9 klasse enn på et forum med voksne mennesker og gjenspeiler hvor uviten brukeren som skrev det er om disse to distroene.

En Arch installering tar vel omlag 10min fra start til du sitter ferdig innlogga i et os der DU har tatt de aller fleste valgene selv - noen andre har altså ikke konfigurert noe særlig for deg, med de fordelene og ulempene det medfører. Du har full kontroll, og vet du akkuratt hvilke valg du tar hele veien ender du opp med et system som du har skreddersydd. Jeg betjener en Arch maskin til daglig og er meget fornøyd (selvom jeg var enda mer fornøyd før de migrerte til SystemD).

 

Gentoo er en annen sak, og jeg kan være enig i at det er for de litt over gjennomsnittlig interesserte, selvom påstanden om for mye tid til overs er jeg rimelig uenig i. Om du har så dårlig tid at du ikke klarer å avse et par timer til å kompilere de aller viktigste programmene med de optimaliseringene og USE-flagsa du selv har satt mens du tar en pils på verandaen, lufter bikkja/whatever, så ville jeg revurdert hva du ellers bruker tia di til. Det er forøvrig lov å jobbe på PCen samtidig som man kompilerer.

 

Forøvrig morsomt at du ikke har tid til å kompilere programmer i Gentoo, mens du samtidig har tid til å poste 14 778 ganger på et forum. Det kunne du gjort samtidig foresten.

Endret av petter3k
Lenke til kommentar

Som FSF-siden nevner, så havner Fedora i samme kategori som Arch: De shippes begge med properitære binærblobs i kernel, og kan derfor ikke regnes som 100% frie. Debian har kategorisk kvittet seg med alle slike binærblobs ene og alene for å bli så fri som mulig. Dvs at du kan mangle støtte for enkelte hardwarekomponenter i Debian før du har installert firmware fra non-free repo. Den type problemer støter du ikke på i Arch og Fedora fordi begge har inkludert disse driverene i standardkernel/-repo.

Så FOSS-messig vil jeg rangere de tre slik:

1. Debian

2 (delt). Fedora og Arch

 

Angående Arch-installasjon tar det kanskje 10 min for en som er dreven. Forøvrig tar det minst 10 min bare å laste ned alle pakkene for Fedora- eller Debian-pakkene for KDE her hos meg. Men for en nybegynner tar Arch timesvis hvis du faktisk skal skjønne hva du driver med. I tillegg har du det faktum at samme problemet kan løses på en haug av måter, og hvordan skal nybegynneren vite hvilken som er den mest optimale måten? Sannsynligvis er det 50/50 sjanse for at han ender opp med et optimalt eller sub-optimalt system. Og det er veldig få måter å sjekke det på uten å gjøre mye om igjen. Jeg har installert Arch ved flere anledninger, men ble aldri like fornøyd som i en distro med ferdig oppsatt DE (f.eks Fedora KDE). Jeg endte alltid opp med å savne enkelte småting som vanligvis er integrert i ferdige distroer (automount, konfigurasjon i GUI, osv.). Jeg er også en kar som stortrives med SystemD fordi det enkelt lar meg få oversikten over alle tjenester, og fordi jeg har ett felles og enkelt interface jeg trenger å forholde meg til. CentOS og Fedora har til og med GUI for å administrere det. Så sånn sett tror jeg ikke vi blir enige om Arch.

 

Jeg antar at poenget med å velge optimalisering og USE-flagg ved kompilering skal være å oppnå et så optimalt system som mulig. For å oppnå dette, dvs. finne ut hvilke flagg som funker og ikke funker, så trengs det en enorm mengde kompilering, benchmarking og dokumentasjon, noe som også tar enormt mye tid. Jeg har vært gjennom en del kompilering i f.eks FreeBSD fordi det ikke fantes noe alternativ for disse pakkene (ports som ikke var tilstede i pkg). Jeg hadde overhodet ikke noe glede av det. Både fordi jeg ikke aner hvilke flagg som funker og ikke funker (derfor lot jeg alt være som default), og fordi det tok unødvendig mye tid. Underveis i kompileringen dukket det også opp dependencies som enten manglet eller som også måtte kompileres, med dertil nye flagg som måtte knotes med. Jeg måtte derfor følge med, og noen ganger kompilere på nytt. Jeg føler langt større glede av å løse virkelige utfordringer, f.eks på et forum. Og jeg har troen på at de som kompilerer og pakker software til distroene jeg bruker har bedre peiling på dette enn meg.

Endret av endrebjo
Lenke til kommentar

Som FSF-siden nevner, så havner Fedora i samme kategori som Arch: De shippes begge med properitære binærblobs i kernel, og kan derfor ikke regnes som 100% frie. Debian har kategorisk kvittet seg med alle slike binærblobs ene og alene for å bli så fri som mulig. Dvs at du kan mangle støtte for enkelte hardwarekomponenter i Debian før du har installert firmware fra non-free repo. Den type problemer støter du ikke på i Arch og Fedora fordi begge har inkludert disse driverene i standardkernel/-repo.

Så FOSS-messig vil jeg rangere de tre slik:

1. Debian

2 (delt). Fedora og Arch

 

Angående Arch-installasjon tar det kanskje 10 min for en som er dreven. Forøvrig tar det minst 10 min bare å laste ned alle pakkene for Fedora- eller Debian-pakkene for KDE her hos meg. Men for en nybegynner tar Arch timesvis hvis du faktisk skal skjønne hva du driver med. I tillegg har du det faktum at samme problemet kan løses på en haug av måter, og hvordan skal nybegynneren vite hvilken som er den mest optimale måten? Sannsynligvis er det 50/50 sjanse for at han ender opp med et optimalt eller sub-optimalt system. Og det er veldig få måter å sjekke det på uten å gjøre mye om igjen. Jeg har installert Arch ved flere anledninger, men ble aldri like fornøyd som i en distro med ferdig oppsatt DE (f.eks Fedora KDE). Jeg endte alltid opp med å savne enkelte småting som vanligvis er integrert i ferdige distroer (automount, konfigurasjon i GUI, osv.). Jeg er også en kar som stortrives med SystemD fordi det enkelt lar meg få oversikten over alle tjenester, og fordi jeg har ett felles og enkelt interface jeg trenger å forholde meg til. CentOS og Fedora har til og med GUI for å administrere det. Så sånn sett tror jeg ikke vi blir enige om Arch.

 

Jeg antar at poenget med å velge optimalisering og USE-flagg ved kompilering skal være å oppnå et så optimalt system som mulig. For å oppnå dette, dvs. finne ut hvilke flagg som funker og ikke funker, så trengs det en enorm mengde kompilering, benchmarking og dokumentasjon, noe som også tar enormt mye tid. Jeg har vært gjennom en del kompilering i f.eks FreeBSD fordi det ikke fantes noe alternativ for disse pakkene (ports som ikke var tilstede i pkg). Jeg hadde overhodet ikke noe glede av det. Både fordi jeg ikke aner hvilke flagg som funker og ikke funker (derfor lot jeg alt være som default), og fordi det tok unødvendig mye tid. Underveis i kompileringen dukket det også opp dependencies som enten manglet eller som også måtte kompileres, med dertil nye flagg som måtte knotes med. Jeg måtte derfor følge med, og noen ganger kompilere på nytt. Jeg føler langt større glede av å løse virkelige utfordringer, f.eks på et forum. Og jeg har troen på at de som kompilerer og pakker software til distroene jeg bruker har bedre peiling på dette enn meg.

 

Brukeren kan vite den optimale måten å gjøre ting på ved å følge dokumentasjonen til Arch Linux der det som regel blir forklart hvilke forskjellige valg man har. Brukeren vil lære ufattelig mye av å følge dokumentasjonen og installeringen, nettopp fordi man må det for å få et system oppe å gå for første gang.

 

Når det gjelder USE-flags og optimalisering.

 

Dette er ikke hovedpoenget med USE-flags i det hele tatt (selvom det KAN være det).

Poenget med USE-flags er å definere hvilket funksjoner du ønsker at programmet skal ha basert på hvilke funksjoner du selv bruker i programmet, og Gentoo sin dokumentasjon på området er meget bra.

 

F.eks:

 

Hvis jeg ønsker å kun ha VLC uten et grafisk grensesnitt, legger jeg til USE="-x11" før jeg kompilerer VLC, og får kun CLI versjonen.

Å finne ut hvilke USE flags som er tilgjengelige, får du opp om du skriver

emerge -av vlc

.

Portage vil spørre deg om du vil fortsette installasjonen om du er fornøyd med default-settet med USE-flags, eller om du vil avbryte og definere egne selv. På dagens hardware tar ikke kompileringen spesielt lang tid, med unntak av programmer som Chromium eller lignende som kan ta omlag 1time.

Skal også nevnes at Gentoo har mange forskjellige "overlays" eller repo's som du kan legge til. Mange av disse har ferdige kompilerte pakker. Pakker som ikke er åpne, som f.eks Chrome, finnes tilgjengelig kun som binære pakker, mens firefox finnes som både firefox og firefox-bin (ferdig kompilert).

 

Å påstå at det tar enorme mengder dokumentasjon, kompilering og benchmarks for å vite hvilke funksjoner du ønsker i et program er ikke bare misvisende, men også totalt feil.

 

Her er Gentoo sin artikkel på f.eks VLC:

 

https://wiki.gentoo.org/wiki/Project:Video/VLC

 

Sider som dette finnes på veldig mange eksempler på, og Gentoo sin dokumentasjon kan ikke sies å være annet enn imponerende.

Det samme gjelder Arch. I Arch har du også fordelen av at du ikke trenger å legge inn titalls forskjellige PPAer for å finne programmene du ønsker å installere (som ikke er FOSS, men som nybegynnere ofte ønsker fordetom - f.eks Spotify, Chrome osv)

 

Skal sies at jeg ikke er her for å fremme Gentoo som en nybegynner-vennlig distro, men påstandene du kommer med er jeg rimelig uenig i, når det gjelder det du sier om disse to distroene. Det du derimot sier om Fedora var jeg ikke klar over, men det stemmer nok helt sikkert.

 

Gentoo kan forøvrig være 100% foss med å kjøre en vanilla-kernel uten binary blobs og og sette USE-flags deretter. Ikke nybegynnervennlig, men argumentet om at det er for spesielt interesserte med altfor mye tid til overs er misvisende. Ingen andre distroer har muligheten til å gi deg like mye kontroll og kalles derfor en metadistribusjon, fordi det blir hva du gjør det til selv.

Endret av petter3k
Lenke til kommentar

@petter3k - det er ikke brukervennlig for den jevne nybegynner. De har sannsynligvis mistet interessen i det du nevner USE flagget.

 

Det betyr ikke at disse systemene ikke er nyttige eller til dels viktige deler av linux universet; det er de. Men de er for spesielt interesserte som har holdt med Linux eller lingende operativ-systemer en stund.

Endret av tomsi42
  • Liker 2
Lenke til kommentar

Å påstå at det tar enorme mengder dokumentasjon, kompilering og benchmarks for å vite hvilke funksjoner du ønsker i et program er ikke bare misvisende, men også totalt feil.

 

Her er Gentoo sin artikkel på f.eks VLC:

 

https://wiki.gentoo.org/wiki/Project:Video/VLC

I utgangspunktet ønsker jeg så mye funksjonalitet som mulig. Jeg ønsker å bruke programmet mest mulig slik som utvikleren ønsker at det skal bli brukt. Det er først hvis noe av denne funksjonaliteten går vesentlig utover ytelsen at jeg ønsker å deaktivere funksjonen. Men for å kunne deaktivere de rette tingene må jeg vite hvilke funksjoner som gir meg en ytelses-penalty. Å finne ut av dette krever systematisk benchmarking og dokumentering av ulike funksjons-/flagg-kombinasjoner.
Lenke til kommentar

 

Å påstå at det tar enorme mengder dokumentasjon, kompilering og benchmarks for å vite hvilke funksjoner du ønsker i et program er ikke bare misvisende, men også totalt feil.

 

Her er Gentoo sin artikkel på f.eks VLC:

 

https://wiki.gentoo.org/wiki/Project:Video/VLC

I utgangspunktet ønsker jeg så mye funksjonalitet som mulig. Jeg ønsker å bruke programmet mest mulig slik som utvikleren ønsker at det skal bli brukt. Det er først hvis noe av denne funksjonaliteten går vesentlig utover ytelsen at jeg ønsker å deaktivere funksjonen. Men for å kunne deaktivere de rette tingene må jeg vite hvilke funksjoner som gir meg en ytelses-penalty. Å finne ut av dette krever systematisk benchmarking og dokumentering av ulike funksjons-/flagg-kombinasjoner.

 

 

Dette trenger ikke nødvendigvis å gjenspeile versjonen din distro har kompilert for deg, da disse valgene allerede har blitt tatt når pakkene har blitt

./configure
-ed - altså av de som maintainer pakken for din distro.

 

Du klarer altså ikke sette deg inn i det scenarioet der du evt. ikke ønsker å dra inn hele Qt-frameworket fordi du ønsker å benytte deg av en spesifikk videoavspiller eller annet? Deg om det isåfall. Å fjerne tunge komponenter/funksjonalitet kan fjerne betydelig tyngde og størrelse i et program og man trenger ikke benchmarke for å forstå at å fjerne disse komponentene øker ytelsen i programmet - eller rettere sagt, øker ytelsen generelt på maskinen din fordi programmet tar opp mye mindre minne.

 

Det er fint at du ønsker så mye funksjonalitet som mulig, men det er ikke alltid funksjonaliteten er det som spesifiseres heller. Det kan være støtte for ting du ikke engang har på PCen din. På en stasjonær-PC uten bluetooth, kan du f.eks fjerne bluetooth-flagget i et f.eks Gnome eller et annet DE for å slippe å dra med deg xxxMB ekstra i dependencies.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...