Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
|
|
|
|
|
|
und ohne Linux wuerde es keine Sau interessieren.
|
|
|
|
|
|
|
|
|
|
|
|
|
für was braucht man eigentlich ein betriebssystem das es erst ende jahr 2004 geschafft hat ein dateisystem zu intergrieren das auch grössere filesysteme unterstütz wie 2gb?
ist das nicht einbisschen lächerlich?
was soll an gnu hurd eigentlich so toll sein?
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 21. December 2004, 13:04 MEW (#4)
|
|
|
|
|
Schreib du erst einmal einen Betriebssystem-Kernel, dann weißt du, was es bedeutet, ein FS>2GB zu unterstützen...
|
|
|
|
|
|
|
|
|
|
|
|
|
es interessiert mich kaum wie schwierig es ist mehr als 2gb zu unterstützen.
es ist einfach total unnütz in der heutigen zeit wo man min. ne 40gb platte kaufen kann etwas zu releasen das sowas nicht kann (obwohl jetzt kann es ja... aber das konnte schon windows 95 ;))
|
|
|
|
|
|
|
|
|
|
|
|
|
Nee, Du. Win95 musstest Du schon patchen, wenn die HD grösser als 8 GB war. -- Scientology sagt Dir nicht alles - www.xenu.ch
|
|
|
|
|
|
|
|
|
|
|
|
|
hier schreibt aber niemand was von 8gb oder? hurd war doch immer noch bei 2? ;)
|
|
|
|
|
|
|
|
|
|
|
|
|
Fuer die Adressrechnung im Kernel long long statt einfach signed int Datentyp nehmen, damit ist es eigentlich schon erledigt. Das ist jetzt echt keine Hexerei.
Selbst unsigned int reicht bis 2T Platz, solange man pro Datei 4G Limite Akzeptiert, dort Byte->Sektor (= /512) rechnet, und dann danach nur noch Sektor Rechnungen in uint macht.
Hmmm, ich hab den Verdacht dass da 2T stehen sollte. [Nachschau] Ist sogar im Orignal auf Kerneltrap 2G.
Uh, Aua:
The original implementation of the ext2 file system translator simply mmap'ed the whole file system into its address space, which limited support to filesystems of no greater than approximately 2 GB on 32 bit architectures.
Ich hoffe bloss, dass das nicht representativ ist fuer Hurd Code. Das ist ja graesslich. Alleine schon dass 2G Disk vor 10 Jahren standard wurden und der Muell-Code immer noch am Leben ist sieht fuerchterlich schlecht aus. --
hardware runs the world, software controls the hardware,
code generates the software, have you coded today
|
|
|
|
|
|
|
|
|
|
|
|
|
Block-Devices zu mmap()en finde ich als Idee elegant. Das Problem bei dieser Loesung sind, bei "normalen" PCs, nur die winzigen (lies: 32bit)-Addressraeume.
Das hat gar nichts mit dem Code zu tun, sondern mit dem Design; das Design ist schlichtwegs nicht 32bit tauglich.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 21. December 2004, 13:08 MEW (#6)
|
|
|
|
|
Vielleicht offtopic, aber am Wochenende habe ich in einem SuSE-Buch gelesen, dass z.B. XFS eine Dateigrösse von einem Exabyte zulässt... Für was ist das brauchbar? ;-)
Ich glaube, dass die meisten Fragen nach brauchbar/unbrauchbar selber unbrauchbar sind, weil nicht zu beantworten. Die GNU Hurd Benutzer/Entwickler haben wohl andere Erwartungen an "ihr" Betriebssystem wie jene, die sich diese "Brauchbar-Frage" stellen...
Gruss
|
|
|
|
|
|
|
|
|
|
|
|
|
was haben sie den für anforderungen an das os? ausser das es ein gnu os ist?
|
|
|
|
|
|
|
|
|
|
|
|
|
Das es ein Microkernel-OS ist? Auf Mach basiert?
Jedes Filesystem ein Prozess ist?
|
|
|
|
|
|
|
|
|
|
|
|
|
Exabyte? Ich warte nun schon seit mehr als einem Jahr darauf grössere Disks als 300 GB zu bekommen. Das ist etwa das einzige was mich daran hindert Terabyteweise Daten zu horten (sprich, bin momentan erst auf ca. 1 TB insgesamt).
--
"The more prohibitions there are, The poorer the people will be"
-- Lao Tse
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 21. December 2004, 19:31 MEW (#12)
|
|
|
|
|
Okeh, Korrektur: XFS lässt eine maximale Dateigrösse von 8 (!) Exabyte zu, der Linux-Kernel 2.6 aber nur eine maximale Dateigösse von 2 TB. Dafür aber eine maximale Dateisystemgrösse von 2^73 Byte. ;-)
(Quelle: SuSE Linux Administrations-Handbuch.)
In diesem Sinne frohe Festtage ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
gibts ja...
LaCie d2 Bigger Disk Triple Interface 1 Terabyte
1249.00
externe Harddisk mit USB 2.0, Firewire 400 (6pin) und Firewire 800 (9pin) Anschluss, 7200rpm, 10ms, 8MB Cache, BigDisk DV, 173x88x268mm, 5kg, inkl Firewire800-800 (9-9 pin), FW400-800 (6-9 pin), FW400-400 (6-6 pin), FW400-400 (6-4 pin) und USB 2.0 Kabel
---
LaCie d2 Bigger Disk Extreme Firewire 800/400 1.6 Terabyte
2927.00
externe Harddisk mit Firewire 800, 7200rpm, 10ms, 2MB Cache, Dual Speed bis 88MB/s, Masse 268x173x44mm und 2.5kg, inklusive FireWire800 (9-to-9 pin) und FireWire400 (6-to-6 pin) Kabel
---
gefunden bei digitec.ch
die dinger haben aber erfahrungsgemäs lange lieferzeiten
|
|
|
|
|
|
|
|
|
|
|
|
|
> Vielleicht offtopic, aber am Wochenende habe
> ich in einem SuSE-Buch gelesen, dass z.B. XFS
> eine Dateigrösse von einem Exabyte zulässt...
> Für was ist das brauchbar? ;-)
Ich glaube es war Bill Gates, der mal sagte, dass
man nie mehr als 640 KB Hauptspeicher benoetigen
wuerde. :-> Wart einfach ab, bis Du die erste
Exabyte-Platte in Haenden haeltst, dann bist Du
froh, gewappnet zu sein. ;-)
-gaga
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 21. December 2004, 20:09 MEW (#13)
|
|
|
|
|
GNU Hurd wird nicht auf Brauchbarkeit entwickelt,
es ist der Zen des Codens, die höchste Immanation des OS(S)-CODEN, (sinn)freier als eine
Software unter GPL es je sein kann ;)
neuste historische Quellen besagen
sogar das schon Budha die Grundlagen
für den Hurd gelegt hat, mit
den Worten, "Hürden sind nicht dazu da um
über sie hinweg zu steigen oder sie
zu umgehen, man soll sie bauen und mit dem Bau erhebt man sich in eine neue Bewusstseinsebene."
langsam sollte man RMS aber mal sagen das
LSD von einem (Wer chhat's erfuunden ?)
erfunden wurde, aber jeder braucht
sein Hobby, Hurd ist wie die nie
fertig werdende Eisenbahnplatte im Keller,
sie wächst und verschlingt sich Stück für
Stück, aber fertig wird sie nie ;)
|
|
|
|
|
|