Em 03/07/2009, às 04:38, "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> escreveu:
I can't agree with this at all.
Aww, and I thought we were reaching some common ground...
Having a known partitioning system * secures* your data. It makes other systems aware of what is where on disk, making sure they won't overwrite it with other stuff.
That's the usual argument pro partitions. That's also something that I can't possibly imagine happening in practice for any foreign OS that's installed on a well-defined file system (one that has a beginning, an end, and an internal structure). I have never seen an OS write outside the boundaries of its own file system unless explicitly given a raw device to manipulate. I can postulate that one exists for the sake of argument, but then I can't see it being any popular, given this ability to do things behind the operator's back.
It also achieves that the disk looks the same on all systems - that certainly avoids confusion, and helps organizing the disk.
Sure, that's not being disputed.
If you prefer to remember the disk offsets instead, that's obviously nothing to win a majority.
You can only reach this as a conclusion to what I said after stripping out a lot of context...
Currently, this is quite exactly what is done when Haiku is installed on a raw device from a raw image. Except that this is special-cased to work only if the image is dd'd to absolute offset 0.
What I proposed is: instead of *relying* on a partitioning scheme to find the *boot* volume, let the *boot* volume, and it alone, be defined only by it's absolute offset plus (block size times block count). Any *other* volumes *must* have a reference on some, any, partitioning scheme.
This is meant to *protect* the system against *foreign* agression in the form of a corrupt partition map. This is the feature here. But this property also have some other consequences that can be easily derived from requiring only the absolute starting offset and the size it spans, namely that it becomes possible to boot from "unpartitioned" space.
But this came to me as a possible consequence of the ability to boot from the minimum necessary information to define a volume, strictly as a mental exercise of the "what else could happen if we simplify this thing to the bare minimum" kind. Another consequence I imagined while doing this mental exercise is, for example, that boot becomes somewhat faster, since you don't have to re-scan the disk to determine the boot partition, and can postpone partition scanning to a later, asynchronous part of the booting process :)
I'm not ditchig common sense, but simply providing an appreciation of the consequences of simplifying the process of finding the boot volume. Currently, to (re-)discover its boot volume, Haiku must parse the partition table after it already *has* all the information it needs.
If you argue that this redundancy is there for the user's protection, I have expressly agrees with that. But redundant systems exist to protect from (n - 1) failures, n being 2 in this case; where's the fallback mechanism? Well, it's what I just proposed!
Now Dear Grandma can proceed to listen to her carefully organised music collection on a BFS volume, complete with full ID3-to-attributes mapping for her playlisting pleasure, while she waits for her grandson to restore her partition tables back to a sane state ;) Which she was prompted to do after reading the warning message Haiku showed her. As an alert box, I'm proposing now, lest she die of a heart attack, scared breathless after reading a red message the a cold, black console screen of the loader. O_O
I hope this clarifies the matter now. Cheers, A.
