Den frie kafeen

[A!1]

Klikk for å se/fjerne innholdet nedenfor

Sliter med merkelig problem her...

Skulle slette en mappe, men får denne feilmeldingen:

hrisebro@server:~/homepage3$ rmdir attachments
rmdir: �attachments�: Filkatalogen er ikke tom

Så jeg gikk inn i mappa for å se om det var noe der.. men...

hrisebro@server:~/homepage3/attachments$ dir
hrisebro@server:~/homepage3/attachments$ 

Den er jo tom...

Noen ideer?

7775767[/snapback]

En idé kan være å slutte å bruke dos-utils. Er du på linux, så er du det og da er det vel en fordel å bruke verktøy som er beregnet på linux og ikke de som tilbys som en kompatibilitetsløsning for de som er vant med dos. I dos måtte man vel bruke deltree eller noe slikt også for å slette kataloger med underfiler.

 

rm -r mappe

 

skulle fjerne mappen og alle skjulte underfiler/mapper. Hvis ikke så skal rm -rf som jorgis foreslår fjerne den. Men dersom mappen er eid av root eller brukeren din ikke har tilgang til mappen så må du kjøre rm som root. Det kan du enten gjøre ved å skrive kommandoen su først eller ved å slenge på sudo forran (sudo rm -r mappe). NB! På noen distroer så er det kun en av su/sudo som virker.

[pgdx]

du kan også prøve, hvis du har muligheten, å gjøre det grafisk, via nautilus eller konqueror. Det har jeg god erfaring med hvis mappenavnet inneholder tegn som av en eller annen grunn ikke vises, eller tegn du tror du skriver rett, men som bare ligner o.l..

[kyrsjo]

dir er svært ofte en symlink/alias til ls. Bare synd at det ikke er omvendt på DOS...

 

Typisk meg foran dos-maskin (dvs. stort sett en med blåskjermfunksjonalitet, dvs. nymotens):

 

>ls

ls: Command not found

>ls

ls: Command not found

>ls

ls: Command not found

*aha! Dette var dos det ja*

>dir

blablabla

>cd c:/Program~1/heioghå

c:/Program~1/heioghå: Path not found.

*What?!?*

>c:

>ls

ls: Command not found

>ls

ls: Command not found

Hmmm..

>dir

blablalba

>cd Program~1

man blæh

man: Command not found

*rive ut hårtuster*

*åpne en nettleser og gooogle, "help" i DOS er temmelig ubrukelig...*

>ls

ls: Command not found

 

osv...

 

Ang. katalogen din: Jeg tipper det er noen skjulte filer der (begynner på punktum), bruk "ls -la" for å se dem.

[olefiver]

Edit: Jeg har samme problem med mitt raidarray (1TB raid0 via firewire).

Free space: 466.7GB

Available space: 429.5GB

Filsystem: ext2

 

Jeg vet ikke hvorfor, men er også interessert i å vite det. Det er ganske nøyaktig 36GB som mangler. Det var slik rett etter at jeg opprettet filsystemet, da det var tomt også.

havarN og chills: Begge dere bruker ext3/ext2?

 

Dere må huske på at ext3/2 er utrolig kjip på diskplassen. En partisjon på ca. 440GB her gav meg et filsystem på rundt 410GB, altså tapte jeg hele 30GB i prosessen. Om du vil ha maksimalt utbytte av partisjonen, bør du velge et annet filsystem, som f.eks. XFS, som hos meg gav meg et tap på bare ca. 0.3GB.

ext2/3 reserverer automagisk av en viss prosentdel av disken til root. Mener den er satt til 5% som standard.

 

Tapet i diskplass fra XFS sin side kommer av at ingen filsystemer gir deg tilgang til 100% av disken, pluss at f.eks. en 200GB disk ikke er 200GiB.

Harddisk produsenter regner ikke byte riktig. De regner f.eks. 1 KiloByte som 1000 Byte. Det riktige er 1 KiloByte -> 1024 Byte

Endret 22. januar 2007 av olefiver

[jorgis]

Edit: Jeg har samme problem med mitt raidarray (1TB raid0 via firewire).

Free space: 466.7GB

Available space: 429.5GB

Filsystem: ext2

 

Jeg vet ikke hvorfor, men er også interessert i å vite det. Det er ganske nøyaktig 36GB som mangler. Det var slik rett etter at jeg opprettet filsystemet, da det var tomt også.

havarN og chills: Begge dere bruker ext3/ext2?

 

Dere må huske på at ext3/2 er utrolig kjip på diskplassen. En partisjon på ca. 440GB her gav meg et filsystem på rundt 410GB, altså tapte jeg hele 30GB i prosessen. Om du vil ha maksimalt utbytte av partisjonen, bør du velge et annet filsystem, som f.eks. XFS, som hos meg gav meg et tap på bare ca. 0.3GB.

ext2/3 reserverer automagisk av en viss prosentdel av disken til root. Mener den er satt til 5% som standard.

 

Tapet i diskplass fra XFS sin side kommer av at ingen filsystemer gir deg tilgang til 100% av disken, pluss at f.eks. en 200GB disk ikke er 200GiB.

Harddisk produsenter regner ikke byte riktig. De regner f.eks. 1 KiloByte som 1000 Byte. Det riktige er 1 KiloByte -> 1024 Byte

7778778[/snapback]

 

Det er mer enn 5% som går tapt med ext3/2, jeg mistet ca. 9-10%.

 

At GB != GiB er jeg også fullstendig klar over, men burde kanskje gjøre det tydeligere, og skrive GiB istedet for GB i posten over. Men tapet jeg fikk med ext3 og (mindre) XFS kom ikke av GB->GiB men av filsystemets overhead, og bare det at jeg tapte 30GiB ledig diskplass er nok for meg til å velge XFS istedet.

 

Og jo, harddiskprodusentene regner det riktig. 1 Kilo er alltid lik tusen. 1kB = 1000 B. Derimot ligger problemet i at mye programvare regner med KiB (kilobinærbyte, kibibyte) som er lik 1024 Byte, og angir det som KB. I praksis måler de i 1024-deler, men angir det som 1000-deler.

Endret 22. januar 2007 av jorgis

[derezzed]

1. Installere Ubuntu 6.06

2. Oppdatering

2.1 Laster ned fil 18 av 217

2.2 Nedlastningshastighet: 25.3 kB/s - 4h1m4s gjenstår.

 

Trenger jeg alt dette? Nå er det iallefall lunsj.

[Hell Toupée]

Har du veldig treg linje, eller er du koblet opp mot en tjener i Uganda?

[j--]

1. Installere Ubuntu 6.06

2. Oppdatering

    2.1 Laster ned fil 18 av 217

    2.2 Nedlastningshastighet: 25.3 kB/s - 4h1m4s gjenstår.

 

Trenger jeg alt dette? Nå er det iallefall lunsj.

7780281[/snapback]

Om du vil ha et "up to date" system: ja.

 

Men jeg ville antagelig skiftet ut alle "dapper" til "edgy" i fila /etc/apt/sources.list før jeg kjørte sudo apt-get update && apt-get dist-upgrade Da vil du bruke 6.10 istedenfor 6.06 (:

 

-----------

 

Spørsmål fra meg:

- Er det forstatt nVidia man burde velge om man skal kjøpe nytt grafikkort?

- når nye xorg kommer, og xorg.conf blir unødvendig(har jeg forstått det riktig?), vil det da bli lettere å få til et dualscreenoppsett med linux?

[Hell Toupée]

Ja, gå for nVidia. Sitter med ATI 9700 PRO, og ytelsen i Linux er nada i forhold til hva jeg oppnår i Windows.

 

Cedega klarer ikke engang å dra WoW skikkelig, mens med et nVidiakort, får jeg faktisk bedre ytelse enn hva tilfellet er i Windows.

[derezzed]

Har du veldig treg linje, eller er du koblet opp mot en tjener i Uganda?

7780313[/snapback]

 

Koblet opp mot norsk tjener, men Haakonsvern Orlogstasjon sine ansatte bruker internettlinjen flittig... Hadde jeg vært hjemme hadde dette gått smooth.

 

Hva vil endre seg når jeg skifter fra dapper til edgy da?

EDIT: skifter i sources.list

EDIT2: 45m37s

Endret 23. januar 2007 av Aleksander

[olefiver]

Det er mer enn 5% som går tapt med ext3/2, jeg mistet ca. 9-10%.

 

At GB != GiB er jeg også fullstendig klar over, men burde kanskje gjøre det tydeligere, og skrive GiB istedet for GB i posten over. Men tapet jeg fikk med ext3 og (mindre) XFS kom ikke av GB->GiB men av filsystemets overhead, og bare det at jeg tapte 30GiB ledig diskplass er nok for meg til å velge XFS istedet.

 

Og jo, harddiskprodusentene regner det riktig. 1 Kilo er alltid lik tusen. 1kB = 1000 B. Derimot ligger problemet i at mye programvare regner med KiB (kilobinærbyte, kibibyte) som er lik 1024 Byte, og angir det som KB. I praksis måler de i 1024-deler, men angir det som 1000-deler.

7779059[/snapback]

Jo-ho, produsentene regner feil, så

 

Min erfaring er at begrepene GB og GiB har kommet rett og slett pga f.eks. harddiskprodusentene. Merk også at dette kun gjelder på ide/sata disker. SCSI-disker er angitt med riktig kapasitet, uten at de bruker GiB. Produsentene har rett og slett tatt et valg for å forenkle opp mot vanlige, "uvitende" forbrukere.

 

Dessuten syns jeg det er litt rart at du får "ca. 440GB" minus "rundt 410GB" til å bli "hele 30GB"

Jeg regna selvsagt på det sjøl og ser at det ikke stemmer med 5%. 30GB er ~6,82% av 440GB

Resterende tap tilegnet jeg til GB/GiB forskjellen og innboende tap i filsystemet.

 

Denne filsystem testen har forresten en sammenlikning av filsystemene på linux med henhold på tap av kapasitet.

Endret 23. januar 2007 av olefiver

[stigfjel]

Det som blir interessant er når det begynner å komme benchmark som sammenligner Linux-filsystemene mot ZFS.

[jorgis]

Det er mer enn 5% som går tapt med ext3/2, jeg mistet ca. 9-10%.

 

At GB != GiB er jeg også fullstendig klar over, men burde kanskje gjøre det tydeligere, og skrive GiB istedet for GB i posten over. Men tapet jeg fikk med ext3 og (mindre) XFS kom ikke av GB->GiB men av filsystemets overhead, og bare det at jeg tapte 30GiB ledig diskplass er nok for meg til å velge XFS istedet.

 

Og jo, harddiskprodusentene regner det riktig. 1 Kilo er alltid lik tusen. 1kB = 1000 B. Derimot ligger problemet i at mye programvare regner med KiB (kilobinærbyte, kibibyte) som er lik 1024 Byte, og angir det som KB. I praksis måler de i 1024-deler, men angir det som 1000-deler.

7779059[/snapback]

Jo-ho, produsentene regner feil, så

 

Min erfaring er at begrepene GB og GiB har kommet rett og slett pga f.eks. harddiskprodusentene. Merk også at dette kun gjelder på ide/sata disker. SCSI-disker er angitt med riktig kapasitet, uten at de bruker GiB. Produsentene har rett og slett tatt et valg for å forenkle opp mot vanlige, "uvitende" forbrukere.

 

Dessuten syns jeg det er litt rart at du får "ca. 440GB" minus "rundt 410GB" til å bli "hele 30GB"

Jeg regna selvsagt på det sjøl og ser at det ikke stemmer med 5%. 30GB er ~6,82% av 440GB

Resterende tap tilegnet jeg til GB/GiB forskjellen og innboende tap i filsystemet.

 

Denne filsystem testen har forresten en sammenlikning av filsystemene på linux med henhold på tap av kapasitet.

7780765[/snapback]

Produsentene regner rett, og de regner også på den måten som er mest hensiktsmessig for dem. Da harddisker er et lineært medium er det veldig unødvendig å regne alt i toerpotenser (GiB) og ikke tusener/millioner osv. (GB). Samme gjelder båndbredde; 2.1GB/s minnebåndbredde er 2100MB minnebåndbredde, en fil som overføres i 400kB/s overføres i 400 000 B/s. Det er så vidt jeg vet bare minne/RAM som er hensiktsmessig å benytte toerpotenser på, og det er den ideen som har hengt seg fast i software-produsentene, til tross for at det ikke er noen mening med det.

 

Programvare som regner med toerpotenser bør bruke rett benevning (GiB), og ikke bruke GB som enhet for tallene sine. Det er dette som er kilden til alle søksmålene mot diskprodusentene. For min del kunne en godt ha sløyfet å bruke GiB på disker og overføringsstørrelser, da det er utrolig upraktisk å regne med. Hvor mange B er én MB? 1 000 000. Hvor mange B er det i én MiB? 1,048,576. Logisk? Lett å regne med?

 

 

Som jeg skrev over, glemte jeg å sette riktige benevnelser på tallene. Vi snakker om 440GiB (lvdisplay sine data, ikke noen harddiskprodusenter) som ble redusert til 410GiB diskkapasitet, ganske nøyaktig 30GiB som forsvant ved opprettelse av filsystem. Poenget mitt er og har hele tiden vært at ext3 er et lite effektivt filsystem mtp. brukt diskplass ved opprettelse. Om 6.81% av diskplassen skal brukes til filsystem-overhead ser en fort at en kan spare mange GiB på å heller velge et mer effektivt filsystem.

[stigfjel]

Fant en kort benchmark av ZFS mot UFS. ZFS ser ut til å være lynkjapt.

 

Edit: fant en annen ZFS-benchmark. Denne tar også med ext3 og reiserfs. Testen er ikke så lang og grundig, men vi kan vel snakke om utklassing her. Med tanke på at ZFS ikke har nådd full funksjonalitet kan man si at ZFS virker utrolig lovende. Enda en grunn til å bruke Solaris 10 på min planlagte filserver.

Endret 23. januar 2007 av stigfjel

[LessThanJake]

Det går jo rykter om en GPL openSolaris, hvis det blir realitet håper jeg ZFS blir med i dragsuget. Har lenge hatt lyst til å prøve det, virker jo veldig lovende og enkelt å bruke.

Endret 23. januar 2007 av LessThanJake

[stigfjel]

Spørs om Sun kan lisensiere OpenSolaris under GPL. Husk at Solaris bruker den omstridte UNIX System V-koden som både Novell og SCO gjør krav på. Det siste jeg har lyst til å se er at det kan bety slutten. CDDL sikrer Solaris sin videre eksistens.

[JonJ]

Spørs om Sun kan lisensiere OpenSolaris under GPL. Husk at Solaris bruker den omstridte UNIX System V-koden som både Novell og SCO gjør krav på. Det siste jeg har lyst til å se er at det kan bety slutten. CDDL sikrer Solaris sin videre eksistens.

7781467[/snapback]

 

Noen spesiell grunn til at CDDL er sikrere enn GPL? Begge er lisenser for fri programvare, faktisk har Sun offentlig lekt med tanken på å lisensiere Solaris under GPLv3 når den kommer. Sun er blant de som har frigitt mest kode, det gir mening for dem å være en leder innen fri programvare og lisensiere Solaris under GPL. Kanskje det kunne hjulpet dem også, da Solaris da hadde fått tilgang til mange flere enhetsdrivere.

[stigfjel]

Noen spesiell grunn til at CDDL er sikrere enn GPL? Begge er lisenser for fri programvare, faktisk har Sun offentlig lekt med tanken på å lisensiere Solaris under GPLv3 når den kommer. Sun er blant de som har frigitt mest kode, det gir mening for dem å være en leder innen fri programvare og lisensiere Solaris under GPL. Kanskje det kunne hjulpet dem også, da Solaris da hadde fått tilgang til mange flere enhetsdrivere.

7781633[/snapback]

Selvfølgelig ser jeg fordelene med GPL, at Solaris kan få tilgang til de mange enhetsdriverne som GNU/Linux har. Men saken er at Solaris bruker UNIX System V-koden, den som det har vært så mye stridigheter om. Kan nevne saken mellom SCO og IBM, og tvisten mellom SCO og Novell. CDDL-lisensen ble utformet nettopp for å forhindre et rettslig problem med å gjøre om Solaris til åpen kildekode. Selv om CDDL og GPL er inkompatible, er CDDL like fullt en OSI-godkjent open-source lisens.

[jorgis]

Fant en kort benchmark av ZFS mot UFS. ZFS ser ut til å være lynkjapt.

 

Edit: fant en annen ZFS-benchmark. Denne tar også med ext3 og reiserfs. Testen er ikke så lang og grundig, men vi kan vel snakke om utklassing her. Med tanke på at ZFS ikke har nådd full funksjonalitet kan man si at ZFS virker utrolig lovende. Enda en grunn til å bruke Solaris 10 på min planlagte filserver.

7781205[/snapback]

 

Den første benchmarken der viser at ZFS bruker enormt mye mer CPU enn UFS, er ikke det temmelig relevant for en typisk filserver med svak CPU? Hjelper lite om den er 600% raskere om den samtidig makser CPUen for én bruker. Hvordan blir da ytelsen om det er 10 samtidige brukere?

[olefiver]

Produsentene regner rett, og de regner også på den måten som er mest hensiktsmessig for dem. Da harddisker er et lineært medium er det veldig unødvendig å regne alt i toerpotenser (GiB) og ikke tusener/millioner osv. (GB). Samme gjelder båndbredde; 2.1GB/s minnebåndbredde er 2100MB minnebåndbredde, en fil som overføres i 400kB/s overføres i 400 000 B/s. Det er så vidt jeg vet bare minne/RAM som er hensiktsmessig å benytte toerpotenser på, og det er den ideen som har hengt seg fast i software-produsentene, til tross for at det ikke er noen mening med det.

7781045[/snapback]

Hvis det er mest hensiktsmessig å oppgi kapasitet i desimal form for produsentene, forklar kapasitetsoppgivelsen på SCSI-disker

 

Programvare som regner med toerpotenser bør bruke rett benevning (GiB), og ikke bruke GB som enhet for tallene sine. Det er dette som er kilden til alle søksmålene mot diskprodusentene. For min del kunne en godt ha sløyfet å bruke GiB på disker og overføringsstørrelser, da det er utrolig upraktisk å regne med. Hvor mange B er én MB? 1 000 000. Hvor mange B er det i én MiB? 1,048,576. Logisk? Lett å regne med?

7781045[/snapback]

Fra spøk til alvor. Toerpotens eller tierpotens burde ikke bli styrt av hva som er praktiskt. Det er praktiskt å regne med pi=3,14, men ikke riktig.

Det er heller ikke riktig å regne harddiskkapasitet med rene SI prefix.

En datamaskin er et binært system og det er riktig å regne med toerpotens.

Skal en ofre nøyaktighet på alteret for praktikaliteten?

Vel, det har allerede blitt gjort, så jeg kan ikke gjøre noe med det. Jeg kan bare være fryktelig dramatisk/teatretalsk og flisespikkende i min beklagelse over situasjonen. Da har jeg også en god grunn til å gi meg, siden det skjelden er bra å være dramatisk/teatretalsk og flisespikkende i en teknisk diskusjon.

 

Men uansett. KiB, GiB osv er meget nye benevninger som har kommet ut av en økende forvirring blant "almuen" over uoverenstemmelsen mellom f.eks. harddisker og RAM. (BTW, det er ikke konsekvent bruk av tierpotene i software f.eks. Microsoft Windows rapporterer HDD kapasitet i to former, "30,064,771,072" og "28 GB")

 

Som jeg skrev over, glemte jeg å sette riktige benevnelser på tallene. Vi snakker om 440GiB (lvdisplay sine data, ikke noen harddiskprodusenter) som ble redusert til 410GiB diskkapasitet, ganske nøyaktig 30GiB som forsvant ved opprettelse av filsystem. Poenget mitt er og har hele tiden vært at ext3 er et lite effektivt filsystem mtp. brukt diskplass ved opprettelse. Om 6.81% av diskplassen skal brukes til filsystem-overhead ser en fort at en kan spare mange GiB på å heller velge et mer effektivt filsystem.

7781045[/snapback]

Og poenget mitt har også hele tiden vært at ext2/3 som standard reserverer 5% til root. Både HavarN og du var ute etter et svar på hvorfor dere "mistet" byte med ext2/3, og jeg har vel svart på det