Linux doorbreekt 100 Petabyte grens

The Register meldt dat Linux sinds kort ondersteuning biedt voor filesystems van meer dan 100 Petabyte, om precies te zijn 128 Petabyte (144,115,188,075,855,872 bytes). De driver die dit mogelijk maakt zit in de 2.4.13-ac6 kernel, maar is ook los te downloaden. De code maakt gebruik van een nieuwe toevoeging van de ATA specificatie, die onderdeel is aan de ATA-133 standaard. Hiermee is het mogelijk om 48-bit adressen te gebruiken. In eerste instantie dachten de mensen van de The Register dat Linux het eerste desktop besturingssysteem was die dergelijke grote filesystemen aankon, maar moest dit later herzien. FreeBSD heeft namelijk al een tijdje dezelfde mogelijkheden in de FreeBSD 4-STABLE branch:

Oops. Not only can Linux not claim to be the first desktop OS to support multi-PB file sizes, it isn't even the first Unix.

"Soren Schmidt of the FreeBSD Project has added 48-bit addressing support to the FreeBSD 4-STABLE branch," writes Bruce Simpson. "You can find the news here, and the code here (Check revision 1.114 and you will find the code).

"The date on which Soren added the 48-bit support to 5.0-CURRENT is October 6th, however, the Linux patches are dated this Monday. You can therefore clearly see that FreeBSD has had working 48 bit ATA addressing support since the beginning of October, which is as of now being grandfathered in to the 4-STABLE tree after undergoing extensive testing"

Met dank aan Hawks voor het submitten.

Reacties (120)

[Parlor_Inventor]

Waar heeft iedereen het hier over zeg? Natuurlijk is dit voor de thuisgebruiker nutteloos. Leuk dat dit kan, maar het is alleen nuttig om te kunnen zeggen dat ze volledige support voor ATA133 hebben... En misschien dat de grotere datacenters en internet zoekmachines hier wat aan hebben....

Ik ben een keer met een excursie van school naar het KPN datacenter in Groningen geweest, en daar doen ze heel luchtig over tape-cabinets van honderden terabytes, en van servers met schijfruimtes van 50 TB. Wij stonden te kwijlen bij het zien van de server-ruimte, maar daar zijn ze het gewoon nodig, om alle telefoongesprekken, post, internetverkeer, rekeningen enzovoorts te kunnen loggen......

En reken maar dat de kernel-developers zich op bovenstaande markt richten, en absoluut niet op de desktopmarkt. Wat de KDE en Gnome mensen doen zal hun een worst wezen. Okee, een OpenGL-drivertje in de kernel kan dan nog wel, maar Linux (de kernel) is altijd al zware overkill geweest voor de desktop....

[Onno]

En reken maar dat de kernel-developers zich op bovenstaande markt richten, en absoluut niet op de desktopmarkt.

Grapje zeker.. het gaat hier over IDE hoor, en dat wordt dus *niet* in zulke datacenters gebruikt.

[Verwijderd]

Dit opent op zich mogelijkheden voor het bouwen van gigantische databases, de vraag is alleen: kunnen de huidige database-software pakketen zoals MySQL, Progress, Oracle wel met zulke gigantische file(s) werken??

Het lijkt me dat daar ook nog een grensje doorbroken moet worden.

[Verwijderd]

Wil je een paar Pettabyte vol krijgen met een MySQL database, ben je toch HEEL lang bezig,
een Mysql database beslaat namelijk maar HEEL weinig ruimte.

Maar tis mooi dat het kan he

[Verwijderd]

Kan je eindelijk internet downloaden

[Rapzar]

[zwetsmode]
als je een film renderd doe je dat vaak in losse tga's
stel dat die 1600x800 zijn (om later te downscalen)
met alfa en gemiddeld 3 layers per frame, zit je voor 2 uur film zo aan de 5000Gb, en die ruimte heb je nog wel een keer nodig om te swappen als je gaat compileren. 10Tb is dus best te gebruiken voor je renderbakkie. oke,toegegeven, als hobby maak je vast geen 100 speelfilms te gelijk, maar het is fijn te weten dat t kan
[/zwetsmode]

correctie: ik dacht dat 1Pb=1024 Tb, maar is blijkbaar 1024^2 Tb

[Verwijderd]

een gigantische wereldwijde en zo goed als allesomvattende database

En nu maar zeuren over M$ die al te veel gegevens hebben.

edit:

denk ook niet dat je snel een database kunt maken die allesomvattend is. Dan worden het al snel een aantal verschillende databases.

[Jochem Knoops]

* 786562 Jochem

dan ben je ongeveer 30.000.000 Jaar bezig met downloaden op mijn chello account.

[Verwijderd]

Heel vaak is voor DBMS'en de grens van het filesysteem de beperkende factor. Toegang tot de bestanden wordt niet door DBMS geregeld maar door het OS. Er zou misschien wel een patch uit moeten komen omdat de 100 PB grens wel wat erg ver ligt...

[apa]

Tegenwoordig hebben DBMS'en vooral last van de grens van het RAM geheugen: in 32-bit mode is dat 4 GB... Voor een desktop PC is dit momenteel nog te veel, maar voor DB-servers is dit echt wel krap. Dat is ook de reden waarom 64-bit CPU's steeds interessanter worden trouwens.

De plaats op HD's is voor grote DB's tegenwoordig minder belangrijk. De grootste DBMS'en ondersteunen drive-arrays zonder problemen.

[Munters]

Met 64-bits hardware is het mogelijk de complete database in het geheugen te houden. Wel geswapt natuurlijk.
De swap komt dan exact overeen met de disk-opslag.

Bij het opstarten wordt de complete database uitgeswapt in het ram geladen (in de praktijk hoeft er voor iedere pagina precies 1 verwijzing in het MMU gezet te worden).
Bij het page-mis geeft de MMU een interrupt en haalt het OS de juiste pagina van de "swap". Geen overhead, dus razendsnel.

Voor de Alpha is er in de begintijd zo'n DBMS gemaakt. Was (op onderdelen) tot 100x zo snel als de standaard implementatie.

Waarom het nooit echt wat geworden is weet ik niet. Waarschijnlijk is de markt toch te klein om zulke hele specifieke implementaties voor de vrije markt te maken.

[weird]

Er zijn 32 bitters die tot 64GB kunnen adresseren (bijv. de P2/PIII).

En *echte* databases (bijvoorbeeld Oracle) maken helemaal geen gebruik van je FS. Die slaan alles direct op de HD op, zodat ze zelf kunnen optimaliseren voor de snelste performance en een virtualisatie laag overslaan.

[RetepV]

"Waarom het nooit echt wat geworden is weet ik niet"

Ehm, in de begintijd was het geheugen heeeeeeeel erg duur. Da's nu niet meer zo :-).

Daarbij is de hele database in het geheugen houden niet bevorderlijk voor de stabiliteit van je database. Eén power-dip, je server loopt vast en hoe wou je dan nog de data uit het geheugen halen?

Caching van de hele database is onzin, het is nooit zo dat _alle_ records in de database tegelijkertijd worden aangesproken. In de praktijk worden een paar records vaak aangesproken, dus of je nou 10% van de database cached of 100% zal niet veel uitmaken in snelheid tijdens het gebruik.

Het is belangrijker om goede en snelle caching-methodes te hebben. Veel DBMSsen cachen de data in het geheugen op dezelfde manier als dat het op disk staat. Dat is natuurlijk onzin, als je toch iets in het geheugen cached, sla het dan ook zo op dat je er meer voordeel uit haalt. Op disk staat het in losse records, in het geheugen met onderlinge verwijzingen/tabellen. Kost je veel meer opslagruimte, maar het komt de snelheid zeker ten goede.

Overigens zijn dit soort dingen altijd een trade-off tussen prijs, prestatie en veiligheid. Als je het één bevoordeelt, benadeel je het andere.

[apa]

En dan maar zien dat er in zo'n Pentastische files (want gigantisch past niet meer IMHO ) geen bad sector zit... Wordt wel leuk:

Mom! There is a bad sector on the Internet file on my computer!! I'll need to download it again!

Misschien is het wel de bedoeling een soort van distributed network op te bouwen voor HD-space. Op die manier zou je dus een programma op je thuis-HD kunnen draaien die je een bepaalde quota geef op je HD. In Linux zou je dan een extra drive hebben die gemaakt is van de 1000'en distributed HD-space clients. Aangezien je dan een enorme adresseerbare ruimte hebt, zou je zoiets misschien wel kunnen doen.

edit:
aanvulling

[odysseus]

Misschien is het wel de bedoeling een soort van distributed network op te bouwen voor HD-space. Op die manier zou je dus een programma op je thuis-HD kunnen draaien die je een bepaalde quota geef op je HD. In Linux zou je dan een extra drive hebben die gemaakt is van de 1000'en distributed HD-space clients. Aangezien je dan een enorme adresseerbare ruimte hebt, zou je zoiets misschien wel kunnen doen.

En wat is het internet dan? In feite ook een groot filesystem waar iedereen dingen van af kan halen en op kan zetten. Die quota zijn dan de quota die je aan je webserver oplegt en het addresseren doe je met IP's en directory-namen. Het enige wat nog niet gebeurt bij mijn weten is het verdelen van een groot bestand over meerdere computers over de hele wereld, al kan dat technisch natuurlijk wel. En naast het www zoals de meesten het gebruiken bestaat er ook al een tijdje een alternatief: freenet. Daar ga je niet naar een bepaalde host toe, maar een bepaalde key. Die key kan overal ter wereld opgeslagen zijn (zelfs zonder dat je het weet op je eigen computer). De computers van gebruikers slaan steeds veelgevraagde keys op, terwijl ze minder belangrijke informatie weggooien. Alle belangrijke informatie blijft dus automatisch staan, de minder interessante verdwijnt vanzelf. Een mooi idee, vind ik.

[d-motion]

Format HD0 :

Volgend jaar is die wel klaar dan ? Mischien ?

Windows systemen dan maar helemaal buiten beschouwing gelaten.

Ga maar eens 160 GB defraggen! laat staan 1 Petabyte !

[Verwijderd]

Voordat je aan het einde bent heb je de volgende 3 defraggers al weer runnen

FF foutcontrole, en dan wel uitgebreid he

Denk dat als iemand zo'n opslagruimte heeft, het ook wel de snelste schijven zullen zijn, en hij ook wel een aantal leuke proc erbij heeft staan.

Zo'n opslagruimte krijgen we (voorlopig ) NOOIT op 1 schijf, dus je kunt het defraggen en de foutcontrole per schijf uitvoeren.

En als er 1 gruwelijk grote database (lees ff 1 bestand) op staat hoeft er niets gedefragd te worden.

[Verwijderd]

En als er 1 gruwelijk grote database (lees ff 1 bestand) op staat hoeft er niets gedefragd te worden.

Nou, je zou maar de index opnieuw op moeten bouwen op zo'n grote database

[Dj Neo Ziggy]

Neem dan gewoon een indeling die niet of weinig fragmenteert!

[B-BRAIN]

euhh heb laatst 100 gig gedrefragmenteert
valt wel mee

staat voor 70% vol met films
maar gaat lekker snel in 4 uur

[Verwijderd]

Nou alleen zo'n grote schijfjes zien te maken

Tis wel weer een mooie doorbraak van linux, maar denk dat er voorlopig nog niet zo veel gebruik van gemaakt zal worden.

[mr_a]

which is as of now being grandfathered in to the 4-STABLE tree after undergoing extensive testing"

Dit is dus ironisch bedoeld. Waarschijnlijk bestaat er helemaal nergens op deze planeet een storage system welke meer dan 100 PetaByte is. Van testen kan dus helemaal geen sprake zijn....

[Parlor_Inventor]

Ligt er aan. je kunt met virtuele devices een hoop emuleren hoor....

[grimlock]

Een 48bits adressering kan je al testen met een 32bits+1 adres natuurlijk... Testen is dus WEL mogelijk...

[Verwijderd]

Waarschijnlijk wordt bedoeld, dat de nieuwe driver die de grotere file systems mogelijk maakt wordt getest. Als deze stabiel werkt met huidige storage devices, zal deze ook werken met de toekomstige storage devices.

[PowerFlower]

<nostalgia alert>
Mmz, toen ik hoorde dat er een 5Mb harddisk op de markt kwam dacht ik ook - dat is alleen voor bedrijven. Nooit gedacht dat ik een klein Palmpje zou hebben met 72Mb RAM
</nostalgia alert>

[Verwijderd]

Disk array van 100,000 Maxtor 160GB disks kom je wel een eind mee

[Verwijderd]

van 100,000 Maxtor 160GB

daar heb je flink wat SCSI controllers voor nodig

[DeBolle]

Inderdaad - ik heb dit (oude) beestje staan http://www.compaq.com/alphaserver/archive/8400/as800 0_pb.html en kan daar dus 132 PCI bordjes in stoppen.

[Verwijderd]

Dat is nog steeds 2.5TB respectievelijk 4.5TB.

Maar 128 PetaByte (PB) is nog steeds 128 x 1024 = 131072 GigaByte (GB).

En het is trouwens Promise.

[GarBaGe]

Niet helemaal: 128 PetaByte (PB) = 128 x 1024 TeraByte (TB) = 128 x 1024 x 1024 GigaByte.
Je vergat een factortje 1024

Dus:
Mega, Giga, Tera, Peta...

[Onno]

daar heb je flink wat SCSI controllers voor nodig

Dit gaat over IDE...

[Verwijderd]

had ik maar zoveel Peta's
<droom, zucht, koude douche :o>
Ik ben nieuwsgierig welke instanties/bedrijven hier gebruik van kunnen maken...
<edit ->typo's>

[apa]

Wat ben je daar NU mee als thuisgebruiker? Maak eens zo'n pak folders aan zodat je een alles mooi kan sorteren... op zo'n schijf vind je immers helemaal niks terug!

Met aparte partities werken wordt ook al zottenwerk... Bij mijn weten ben je in Win-systemen nog steeds beperkt tot 26 drive-letters. Zo'n 128 Petabytes verspreiden over 26 drive-letters is dan ook niet echt praktisch: je blijft dan nog steeds over met een kleine 5 petabyte per partitie. Zo'n systemen zouden *op dit moment* enkel handig voor netwerk server systemen. Maar dan nog enkel indien de netwerken zelf een PAK sneller zouden werken.

't is leuk dat dat nu al ondersteund wordt, maar ik vrees dat dat momenteel erg weinig nut heeft. En waarom hebben ze daarvoor moeten wachten op een nieuwe spec in ATA133? De grootste schijven gebruik je toch voor servers en dan gebruik je op zijn minst SCSI dacht ik zo?! Of zie ik iets over het hoofd?

edit:
aanvulling

[Verwijderd]

Bij mijn weten ben je in Win-systemen nog steeds beperkt tot 26 drive-letters.

We hebben het hier dan ook over Linux en BSD systemen. Natuurlijk blijft de hoeveelheid nauwelijks te beheersen door 1 persoon, maar als je dus een mega-server in je bedrijf wilt plaatsen met daarop viruele disks (iedere gebruiker z'n eigen stukkie dat er hetzelfde uitziet, maar fysiek op een andere plek is opgeslagen) dan wordt het wel ineens heel interessant. Of wat dacht ge van het webarchief waarin heel veel oude websites zijn opgeslagen (zie het stukje van een aantal dagen geleden). Allee, dat kost toch echt wel een bak aan schuifruimte. Zeker en vast!

[cyclone]

Bij mijn weten ben je in Win-systemen nog steeds beperkt tot 26 drive-letters

Aangezien dit een *nix smaak betreft hoe je je hier geen zorgen om te maken .. hier gebruik je geen driveletters maar kun je gewoon de zoveel partities mounten als je wil ( je bent in ieder geval niet beperkt tot de lettertjes van het alfabet )

[boner]

bij NT kon ja altijd al filesystemen aanmaken zonder driveletter. Hoe dat er dan uit gaan zien weet ik niet maar het kan wel!

[Stealthje]

Dat kon in dos ook al lang

subst T: C:\divx

werkt ook in win98/Me/2k/XP

not a problem

[Adion]

Het lijkt mij niet dat driveletters veeluitmaken.
Of je je data nu sorteert in partities of in directories op 1 partitie maakt eigenlijk toch niks uit.
Die directories zou je dan kunnen mappen als echte Network Drives, en die hebben, zoals directories geen beperkingen qua naamgeving.
Het enige nut van meerdere partities zou dan data-veiligheid zijn, omdat er dan verschillende apparte FAT tables (algemeen dus, niet specifiek verwijzend naar FAT16 of FAT32, maar ook naar andere) zijn, zodat 1 partitie nog kan werken als een andere fouten vertoont.
Of de verschillende FAT tables echt op verschillende delen van de drive zitten, of toch allemaal in het begin ofzo, weet ik echter niet, en zal ook wel afhangen van het gebruikte systeem.

[Verwijderd]

Je gebruikt dan een soort mount commando, zoals in Linux (zie de help).

[Verwijderd]

Yep in je Volume manager van windows
kan je zowaar disken mounten aan een dir

Word steeds mooier met ze , ohja is veritas hehe

Anyway's in de adressering van ide drives hebben we geen problemen meer voorlopig

[freaky]

Of je je data nu sorteert in partities of in directories op 1 partitie maakt eigenlijk toch niks uit.

Ik hoor je nog wel een keer als je format moet doen

[SiGNe]

Bij mijn weten ben je in
Win-systemen nog steeds beperkt tot 26 drive-letters.

Ik dacht dat ie dan gewoon verder gaat met drive AA, AB, AC, etc. t/m ZZ, maar ik kan het mis hebben.

[Verwijderd]

"... Bij mijn weten ben je in Win-systemen nog steeds beperkt tot 26 drive-letters."

dit is fout, in windows 2000 kan je je schijven makkelijk mounten op een andere letter
bijvoorbeeld:
drive 1 == C:\
drive 2 == C:\Program files
drive 3 == C:\DriveXYZ

misschien zit er een limiet op, dat weet ik niet, maar de 26 letters is zeker geen limiet...

[SvMp]

Bij mijn weten ben je in Win-systemen nog steeds beperkt tot 26 drive-letters. Zo'n 128 Petabytes verspreiden over 26 drive-letters is dan ook niet echt praktisch: je blijft dan nog steeds over met een kleine 5 petabyte per partitie

Uhm..Linux en FreeBSD doen niet aan drive-letters hoor.
En dit nieuwtje gaat over Linux/FeeeBSD, daar heeft Windows niks mee te maken. Bovendien haalt het FAT32 filesystem die 128 petabyte ook niet. (NTFS volgens mij ook niet)

[Verwijderd]

Is wel leuk hoor.
Dan kan je elke film die ooit is gemaakt op je PC opslaan

Da's pas een video-jukebox

[gpex]

Tja ik vind het jammer dat als ik een Filmpje ga capturen met mijn capture kaart dat i max 3,99Gb kan opslaan aangezien met mijn software alles in avi moet opslaan en pas later kan omzetten in Mpg2 bv kan ik max een filmpje maken van 2 a 4 min met een resolutie van 800x600x32bitsx25FPS dus...

ik draai nu nog win982de ik weet niet of het is opgelost in Win2k?

In ieder geval is de limiet veel groter bij Win2k/WinXP indien je NTFS als filesysteem gebruikt (ik dacht dat dan de maximale bestandsgrootte zo rond de 1600GB lag). Dat lijkt me voorlopig wel voldoende

[freaky]

Denk nog maar een keer dan. De installatie van verschillende distributios mag dan niet zo vriendelijk zijn (alhoewel elke tweakers makkelijk SuSE of Mandrake installeerd) als je kde 2.2.1 hebt draaien is ie echt WEL gebruiksvriendelijk...

[Verwijderd]

T'ja jongens, het gaat hier dan ook om een " enabling technologie" de doorbraak in zichzelf is niet zo veelzeggend als wat men ermee gaat kunnen. Denk nu eens na hoeveel instanties geld kunnen sparen en tegelijkertijd imposante bestandsystemen kunnen implementeren voor dingen waar ze vroeger alleen maar konden kibbelen in budget overleggen. Ik denk met name aan de academische en wetecnschappelijk gemeenschap die hierbij mega baat kan aan hebben door telkens een beetje meer enabling technologie te implementeren en, al lerende -muddling through- , nieuwe operationele processen ontwikkelen in hun core activiteiten. Grote rganisaties zijn als het ware een oersoep van ideen en voorstellen waaruit blijkt dat het voortgangsprocess een beetje chaotisch verloopt en aldus voortchaossend (bestaat dit woord??) "enabling" randvoorwaarden opslorpt in de oersoep der vooruitgang.

(voor de geinteresseerden zoek effe op, "the science of muddling through van Lindblom)

To geek where no geek has geeked before....

[real[B]art]

Heb je wel ruimte voor een vette swapfile

[apa]

... en zit je RAM vol met de virtuele adres-mapping voor deze pentastische swapfile.

Ik vind zo'n filesysteem enkel zinvol om onderzoekers op een volledig nieuw systeem te laten zoeken om de ruimte in te delen. Je zou er bv. aan kunnen denken om een volledige cluster dezelfde HD adres-space te laten gebruiken (geshared dus). Als je dan zo'n 1024 nodes hebt, dan komt dat neer op zo'n 1024 TB per node. Momenteel is dat nog enorm veel, maar de TerraByte is de volgende stap na de GigaByte.

[Haywire]

... en zit je RAM vol met de virtuele adres-mapping voor deze pentastische swapfile.

Daar heb je toch die lekkere grote swapfile voor?

[-=unicron=-]

SGI heeft een File system dat heet XFS dat kan 9 exebytes aan is dat meer dan 128 Petabyte ?
meer info http://www.sgi.com/software/xfs/

[Verwijderd]

http://www.webopedia.com/TERM/e/exabyte.html

An exabyte is equal to 1,024 petabytes.

[Cyberjunkie]

Nou, he he, kan ik EIN-DE-LIJK m'n nieuwe schijf een keer gaan gebruiken!

[Verwijderd]

Eindelijk! Vroeg me al af wat ik toch met dat bestandje op m'n C-schijf moest. Nu weet ik het: gewoon Linux installeren... hadden ze dan niet even eerder kunnen vertellen

[cool0]

Hoeveel GB is dat dan?

[Verwijderd]

petabyte = 1.024 terabyte
terabyte = 1.024 gigabyte

ergo, petabyte = 1.024 * 1.024 gigabyte = 1.048.576 gigabyte

[PWA]

1.048.576 Gb = 1.073.741.824 Mb = 214.748.364,80 mp3z (van 5Mb. per stuk)

[hightower]

Volgens mij zit het iets anders
1 petabyte = 1024 exabyte
1 exabyte = 1024 tera byte
1 terabyte = 1024 gigabyte

[Maurits van Baerle]

Je hebt gelijk:

= 1/9671406556917033397649408 yottabyte
= 1/9444732965739290427392 zettabyte
= 1/9223372036854775808 exabyte
= 1/9007199254740992 petabyte
= 1/8796093022208 terabyte
= 1/8589934592 gigabyte
= 1/8388608 megabyte
= 1/1048576 Megabit
= 1/8192 kilobyte
= 1/1024 Kilobit
= 1/8 byte
= 1/4 nibble
bit = 1 bit

Dit betekent overigens dat NTFS verder gaat dan dit systeem. Die kan tot 16 exabyte adresseren.

[Verwijderd]

Dit is het goede lijstje:
kilo 1000^1 1024^1 = 2^10 = 1,024
mega 1000^2 1024^2 = 2^20 = 1,048,576
giga 1000^3 1024^3 = 2^30 = 1,073,741,824
tera 1000^4 1024^4 = 2^40 = 1,099,511,627,776
peta 1000^5 1024^5 = 2^50 = 1,125,899,906,842,624
exa 1000^6 1024^6 = 2^60 = 1,152,921,504,606,846,976
zetta 1000^7 1024^7 = 2^70 = 1,180,591,620,717,411,303,424
yotta 1000^8 1024^8 = 2^80 = 1,208,925,819,614,629,174,706,176

[bartware]

1 petabyte = 1024 exabyte

volgens mij andersom:
1 exabyte= 1024 petabyte

[Verwijderd]

[off-topic]
Om verwarring te voorkomen (of om er te scheppen) bestaat er een nieuwe term. Een gigabyte is 1000 megabyte en een gibibyte (van giga-binair) komt overeen met 1024 megabyte. Persoonlijk heb ik de termen zoals gibibyte en mebibyte nog nergens ontmoet, behalve dan in een artikel dat het hierover had (weet wel niet meer in welk tijdschrift dat was). Deze term zou er gekomen zijn om onderscheid te maken tussen geheugen, waar men met de factor 1024 werkt en de harde schijven, waar met de factor 1000 gewerkt word. Als er nog iemand van deze termen gehoord heeft, laat het even weten, want ik vraag me af of het geen late aprilgrap was.
[off-topic]

[RG]

mebibyte, dat klinkt ook leuk spreek het Engels uit en je hebt "may be byte". Wordt vast de eenheid voor kapotte harde schijven ofzo

[Haywire]

Kan best dat iemand dat bedacht heeft en daar een artikel over heeft geschreven, maar gemeen goed is het zeker niet.

Beetje onzin ook wel. Het is welliswaar een typische newbie-instinker, maar ach... om daar nou zo moeilijk over te doen. Er zijn veel meer mensen die eraan gewend zijn dat het zo in elkaar zit en helemaal niet zitten te achten op een nieuw term dan mensen die erdoor verward zijn.

Overigens wordt er niet alleen met machten van 10 gewerkt bij harde schijven, maar ook bij datacommunicatie. 1 Mbps is precies 1.000.000 bits per seconde.

[Andamanen]

het is wel een officieel standaard van het IEC, maar aanslaan zal het niet...

http://physics.nist.gov/cuu/Units/binary.html

[ACM]

De hoeveelheid in bytes staat er bij, dus reken maar uit

[wmeester]

Grofweg 144 miljoen.
144,115,188,075,855,872 / 1000.000.000

[real[B]art]

Da's wel heel grofweg...eigenlijk moet je in stappen van 1024 rekenen. Bij 'kleine' hoeveelheden kun je dan voor het gemak uitgaan van 1000, maar bij dit soort getallen krijg je dan wel een heel vertekend beeld...
Je ziet het nu ook al bij HDs: dan zet de fabrikant erop 30.000.......bytes, als je dat op de juiste manier omrekent kom je toch iets lager uit

[edit] overbodig? misschien wat voor de hand liggend maar overbodig...<div class=r>[Reaktie gewijzigd door real[B]art]</div><!-- end -->

[Verwijderd]

In ieder geval blijkt dat er vooruit gedacht wordt, dat is in het verleden wel anders geweest (millennium-bug, bijvoorbeeld). We zitten voor de nabije toekomst wel weer even goed. Alhoewel ik nu ook maar 1 "gebruiker" zie die hier iets aan heeft: http://web.archive.org
Zoals in een eerder nieuwsbericht is besproken, die hebben dus getracht het gehele internet te downloaden en zelfs meer dan dat (ook vele updates).

* 786562 Cool

[Verwijderd]

Linux zware overkill voor desktop? Als je alle opties in je kernel meebakt ja. Het mooie is juist dat het zo goed mogelijk ok jouw systeem kunt aanpassen, en dat kan dus heeeel licht zijn. Maar goed, 100 Petabyte is nie nodig nee.

[Parlor_Inventor]

Antwoord op de verkeerde reply?

Wat ik dus bedoelde met zware overkill is dat Linux dingen ondersteunt, zoals terabytes aan RAM en petabytes aan schijfruimte, wat je als desktopgebruiker nooit nodig bent. En performance-details waar je als desktopgebruiker nooit wat van zult merken. Wat een zelf-compileerbare kernel betreft is Linux natuurlijk nog steeds ideaal. Je bakt alleen wat je nodig bent en de drivers mee in de kernel, en je hebt een retestabiel lichtgewicht systeem. Wat kernel betreft dan. Ik word helemaal ziek als ik de default rc.d files van enkele grotere distro's zie....