Gå til innhold

Den frie kafeen


Anbefalte innlegg

Videoannonse
Annonse
Alt dette er jo overkommelig, men jeg mener det er lite intuitivt å gi 32-bits-pakker egne navn fordi pakkesystemet ikke er tilstrekkelig.
Tja, problemet er jo hvordan filene i pakkene skal plasseres. På et 64-bit system så plasseres de gjerne i lib32 kataloger isteden for lib. Dessuten finnes det jo en tilsvarende 64-bit pakke for det aller meste og det blir fort litt krasj om 64-bit pakkene og 32-bit pakkene har like navn. Disse støttebibliotekene blir jo uansett installert automatisk når man installerer programmer som trenger dem. F.eks. Wine.

 

Har heller ikke hatt noen problemer med 64-bit Ubuntu. Kjører en partisjon med den nå og jeg har enda ikke tenkt over at det er 64-bit jeg bruker.
Jepp, 64-bit Ubuntu er absolutt produksjonsklart.
Lenke til kommentar
Alt dette er jo overkommelig, men jeg mener det er lite intuitivt å gi 32-bits-pakker egne navn fordi pakkesystemet ikke er tilstrekkelig.
Tja, problemet er jo hvordan filene i pakkene skal plasseres. På et 64-bit system så plasseres de gjerne i lib32 kataloger isteden for lib. Dessuten finnes det jo en tilsvarende 64-bit pakke for det aller meste og det blir fort litt krasj om 64-bit pakkene og 32-bit pakkene har like navn. Disse støttebibliotekene blir jo uansett installert automatisk når man installerer programmer som trenger dem. F.eks. Wine.

Likevel så klarer yum å skille mellom 32- og 64-bits pakker. Som standard drar man ned 64-bits versjonen.

 

Saken er at i f.eks Arch Linux så kan man ikke ta en tilfeldig valgt pakke for Arch Linux for x86-32 og installere den i Arch Linux for x86-64. Ikke bare vil programmet tryne, pakkesystemet vil også anta at det er en 64-bits pakke som tilfredsstiller avhengigheter.

Lenke til kommentar
Alt dette er jo overkommelig, men jeg mener det er lite intuitivt å gi 32-bits-pakker egne navn fordi pakkesystemet ikke er tilstrekkelig.
Tja, problemet er jo hvordan filene i pakkene skal plasseres. På et 64-bit system så plasseres de gjerne i lib32 kataloger isteden for lib. Dessuten finnes det jo en tilsvarende 64-bit pakke for det aller meste og det blir fort litt krasj om 64-bit pakkene og 32-bit pakkene har like navn. Disse støttebibliotekene blir jo uansett installert automatisk når man installerer programmer som trenger dem. F.eks. Wine.

 

Såvidt jeg har registrert, så legger Fedora konsekvent alle 64-bit biblioteker i lib64, og 32-bits i lib. Slik blir det ingen problemer om man f.eks laster ned en pakke (utenom pakkesystemet) ment for 32-bit Fedora (eller en annen 32-bit rpm-distro) på 64-bit-versjonen. Man får heller ikke noe krøll med "autoextract"-pakker som bare dumper masse data uten dependency-sjekking overhodet.

 

Ting har helt klart forbedret seg i Ubuntu, men jeg mener også at apt kunne trengt en del forbedringer på dette området.

 

Egentlig er ting som dette kanskje noe som bør "standariseres" litt mer på tvers av distroer. Et universelt pakkesystem (eller en universell standard for hvor/hvordan pakker installeres) som ikke går på bekostning av mangfoldet mellom distroer, måtte jo vært det idéelle.

Lenke til kommentar

Har bredbånd fra NextGenTel, fikk mail om at de skulle oppdatere noe slik at nettet ville være nede. Sist jeg rebootet maskinen med Ubuntu 8.04 så kommer jeg overhode ikke på nett. Forsøkte med livecd på en annen maskin(siste jeg forsøkte kom jeg rett på nett med denne og livecd), men ikke tilkobling overhode. Det er kun trådet. Er det virkelig mulig at NextGenTel kan blokkere ut Linux - og bare Linux, kommer på nett med Vista... ? Det merkelige er at jeg heller ikke kan bruke ssh på LAN(mellom to maskiner), sw oppdatering fra NextGenTel skal vel ikke kunne forhindre det, dette mellom to maskiner tilkbolet en switch som igjen går til en ruter.

Lenke til kommentar

Rart om dette funker da internett funker fint i Windows, men kanskje vært et forsøk?

 

Har modemboksen routerfunksjon så kan du prøve å koble Linux PC-en rett til modemet. Om ikke kan du ta ut kabelen fra routeren, ha den ute i et minutt, starte den og prøve å koble den rett til Linux.

 

Høres rart ut om det er leverandøren som sperrer Linux ute, man noen andre med samme leverandør kan sikkert fortelle deg om de har det samme problemet.

Lenke til kommentar
Klikk for å se/fjerne innholdet nedenfor
Alt dette er jo overkommelig, men jeg mener det er lite intuitivt å gi 32-bits-pakker egne navn fordi pakkesystemet ikke er tilstrekkelig.
Tja, problemet er jo hvordan filene i pakkene skal plasseres. På et 64-bit system så plasseres de gjerne i lib32 kataloger isteden for lib. Dessuten finnes det jo en tilsvarende 64-bit pakke for det aller meste og det blir fort litt krasj om 64-bit pakkene og 32-bit pakkene har like navn. Disse støttebibliotekene blir jo uansett installert automatisk når man installerer programmer som trenger dem. F.eks. Wine.

 

Såvidt jeg har registrert, så legger Fedora konsekvent alle 64-bit biblioteker i lib64, og 32-bits i lib. Slik blir det ingen problemer om man f.eks laster ned en pakke (utenom pakkesystemet) ment for 32-bit Fedora (eller en annen 32-bit rpm-distro) på 64-bit-versjonen. Man får heller ikke noe krøll med "autoextract"-pakker som bare dumper masse data uten dependency-sjekking overhodet.

 

Ting har helt klart forbedret seg i Ubuntu, men jeg mener også at apt kunne trengt en del forbedringer på dette området.

 

Egentlig er ting som dette kanskje noe som bør "standariseres" litt mer på tvers av distroer. Et universelt pakkesystem (eller en universell standard for hvor/hvordan pakker installeres) som ikke går på bekostning av mangfoldet mellom distroer, måtte jo vært det idéelle.

Det er jo riktig. Men det blir mer et spørsmål om det er bedre å flytte de bibliotekene som følger "native"-arkitekturen altså 64-bits pakkene til et sted som ikke er standard i.flg. LSB (lib64) eller om det er bedre slik Ubuntu gjør å legge 64-bits bibliotekene i lib og 32-bits i lib32.

 

Selvsagt blir konsekvensen av "Ubuntu-måten" at man ikke kan laste ned et hvilket som helst 32-bit program fra pakkekildene til 32-bits Ubuntu og installere det som om man kjørte 32-bits Ubuntu. Man må laste ned 32-bits pakker som er ment å kjøre på 64-bits systemet.

 

Det medfører kanskje noe hodebry, men når man tenker på at sannsynligvis er alle programmene som ligger i 32-bits pakkekildene også tilgjengelig i 64-bits versjon i 64-bits pakkekildene, blir det sjelden (eller aldri) at man skulle ha bruk for å installere noe fra 32-bits pakkekildene på et 64-bits system.

 

Dessuten er det eneste jeg kan tenke meg at er noe som helst poeng å skulle ha i 32-bit versjon, en nettleser, men bare om man trenger Sun Java-plugin og ikke klarer seg med OpenJDK. 32-bit nettleser kan installeres enkelt og greit ved hjelp av et script.

 

Alle programmer har selvsagt forbedringspotensiale, også apt. Men jeg opplever ingen problemer med akkurat dette med 64-bit og 32-bit programmer og apt.

 

Den måten Fedora gjør det på, altså legger native-bibliotekene et annet sted enn lib, tror jeg må bryte med LSB og så kan det virke som de mener 32-bit programmene er viktigere enn 64-bit programmene eller at de ikke ønsker å ta seg bryet med å kompilere to versjoner.

 

Så selv om man må gå en "omvei" for å installere 32-bit nettleser, mener jeg Ubuntu-måten er riktigere.

Lenke til kommentar

Nextgentel sperrer ikke linux ute, det er Telenor som synder med sin forhatte pppoe (noe heldigvis nyeste network manager skal adressere). Dessuten har vel nextgentel ingenting å gjøre med din router? Gjør som foreslått her, prøv deg frem til du ser hvor det stopper, spør om hjelp etterhvert hvis behov. Du kan starte med å gå inn i web-interfacen til routeren din, så ser du om maskinene dine kommer opp, og hvilken IP du kan pinge de på.

Lenke til kommentar
Nextgentel sperrer ikke linux ute, det er Telenor som synder med sin forhatte pppoe (noe heldigvis nyeste network manager skal adressere). Dessuten har vel nextgentel ingenting å gjøre med din router? Gjør som foreslått her, prøv deg frem til du ser hvor det stopper, spør om hjelp etterhvert hvis behov. Du kan starte med å gå inn i web-interfacen til routeren din, så ser du om maskinene dine kommer opp, og hvilken IP du kan pinge de på.

Er PPPOA, som NGT bruker, så mye lettere å sette opp i Linux? Problemet er vel heller at Telenor i noen tilfeller ikke leverer router hvor de har satt opp tilkobling for PPPoE, slik at dette må settes opp på PC-en i stedet.

 

Slik jeg forstår det har Dy$no trådløs router fra NGT. Da kan det jo hende at oppdateringen har fucket noe på WLAN'et.

Endret av RattleBattle
Lenke til kommentar

Usj, NTFS er et sabla makkverk, mista nettopp et par timers video i DV-format (jobber med en annens eksterne harddisk). En liten re-boot og de var vekk.

Heldigvis ligger de fortsatt på kassettene, men tar jo et par timer å få de inn i igjen.

Lenke til kommentar
Er PPPOA, som NGT bruker, så mye lettere å sette opp i Linux? Problemet er vel heller at Telenor i noen tilfeller ikke leverer router hvor de har satt opp tilkobling for PPPoE, slik at dette må settes opp på PC-en i stedet.
Jeg har ennå til gode å se nextgentel overlate oppsett av pppoa til bruker, Telenor og pppoe derimot.
Slik jeg forstår det har Dy$no trådløs router fra NGT. Da kan det jo hende at oppdateringen har fucket noe på WLAN'et.
Det var vel ikke like tydelig for meg, derfor puttet jeg et spørsmåltegn ved dette punktet.
Lenke til kommentar
Er PPPOA, som NGT bruker, så mye lettere å sette opp i Linux? Problemet er vel heller at Telenor i noen tilfeller ikke leverer router hvor de har satt opp tilkobling for PPPoE, slik at dette må settes opp på PC-en i stedet.
Jeg har ennå til gode å se nextgentel overlate oppsett av pppoa til bruker, Telenor og pppoe derimot.

Nettopp. Hadde NGT gjort det samme med PPPoA hadde brukerne hatt det samme problemet. Telenor leverer også med ferdig oppsatte routere, i de tilfellene er det like problemfritt for Linux-brukerne, som med NGT.

 

Det var vel ikke like tydelig for meg, derfor puttet jeg et spørsmåltegn ved dette punktet.

Når jeg leser det en gang til, er det vel ganske 50/50 om han har en trådløs router fra NGT, ja...

Endret av RattleBattle
Lenke til kommentar

Er det flere enn meg som har problemer med at disken jobber frenetisk i Ubuntu 8.04. Enkelte ganger begynner den å jobbe så mye at jeg ikke får bevegd på musepekeren en gang, heller ikke trykket CTRL + SHIFT + Backspace. Eneste jeg kan gjøre er å trykke på svenskeknappen. Det kan være tilfeldig bruk fra alt til å se på film til å kompilere kildekode. Er det diskfeil, eller noe bug med Ubuntu? Noen flere som opplever det?

Lenke til kommentar

Veldig morro: Som snarlig mastergradsstudent, har jeg fått utdelt en "skikkelig" plass med stor pult, diger hylle, og egen arbeidsstasjon (en tilsynelatende ganske digg og veldig stillegående Dell Optiplex arbeidsstasjon med RHEL-4). Etter litt om og men, fikk jeg tilgang til maskina (dvs. den godkjenner brukernavn og passord), men hjemmeområdet mitt har ikke kommet "online" ennå. Og ettersom det er søndag, og jeg har sett en annen person på bygget i dag (dog da litt på avstand), er det få å mase på...

 

Løsning?

- Logg inn med failsafe terminal i GDM

- SSH med thrusted X-forwarding (ssh -Y) til en terminalserver

- Start gnome-session på terminalserveren.

 

Insta-tynnklient :)

Lenke til kommentar

Nyheten er noen dager gammel, men jeg så nettopp at Phoronix Media har lansert en ny version av deres testverktøysett (denne versjonen hadde kodenavn "Trondheim", faktisk) for bruk til benchmarking av [GNU/]Linux-maskiner: Phoronix Test Suite 1.0.0.

 

Testrammeverket er ment som en utvidbar test-plattform for benchmarking og profilkartlegging og er ment brukt av uavhengige hardware- eller software-leverandører samt dataentusiaster, såklart. Det gis ut under GNU GPLv3 og inneholder allerede en noen testprofiler for enkelte applikasjoner man kan ta i bruk. I tillegg skal man kunne laste opp benchmarkresultater på web og sammenligne ytelse og se på statistikk. Man kan benchmarke ytelse med ulike applikasjoner som f.eks. kompilering, nexuiz, lydkoding , etqw, super-pi, teste ramytelse m.m. Man kan i prinsippet lager tester som omfatter det meste, på sikt vil vel enkelte tester bli gjengangere som man vil standardisere på.

 

Phoronix Test Suite finner du her.

 

Dette er kanskje noe for hw.no å bruke i testene sine fremover. For kan man virkelig som heltids GNU/Linux-bruker stole på en benchmark-test som utelukkende er utført i et MS Windows-miljø? Jeg mener ikke at det er snakk om forfalskning av resultater e.l., men tallene man får ut trenger jo ikke være representative for den samme hardware'n med en annen software, hvis dere skjønner. Du vil jo ikke nødvendigvis få samme resultater med samme hardware, men med et annet OS og annet sett med drivere.

 

Så jeg hadde gjerne sett at det ble gjennomført mer benchmarking på GNU/Linux-plattformen til glede for den økende andelen GNU/Linux-brukere. Det burde vel vært mulig for hw.no å etterhvert gjort dette som et supplement til den benchmarkingen som gjøres i Windows, vil jeg tro (hvis ikke så bør man vel kanskje tro at Phoronix vil levere artikler med slike benchmarktester til oss).

 

Selv har jeg ikke testet Phoronix Test Suite ennå.

Endret av kommers
Lenke til kommentar

Har et merkelig problem i Arch. Jeg har en mappe som inneholder alt av dokumenter jeg har skrevet i forbindelse med studiene. Denne mappen ligger på en NTFS-disk. Denne disken har alle tre operativsystemene mine tilgang til. Ubuntu og Vista kan finne mappen med disse dokumentene, men det kan ikke Arch. Mappen er tilsynelatende borte der. Hva kan være årsaken til dette? Hvis jeg i Ubuntu kopierer nevnte mappe over til Home finner også Arch mappen der, men hvorfor finner ikke Arch mappen på NTFS-disken? Jeg finner den heller ikke med sudo nautilus.

 

Anyone?

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...