Re: Partitioning
On Wed, 10 Dec 1997, Gertjan Klein wrote:
> Bill Leach <bleach@bellsouth.net> wrote:
> ...
> > Though it depends upon what one might mean by the term "knows", the PC
> > BIOS _IS_ the implementation of this particular filesystem abstraction.
>
> You constantly confuse the issue. The BIOS 'knows' how to load a
> sector from disk to memory or vice versa. This has _nothing_ to do with
> filesystems. Filesystems define how data is ordered and stored on these
> sectors.
We appear to be "arguing" from different perspectives about the same
things. I am probably guilty in that I am not being at all specific about
what I mean when I talk about the BIOS. The BIOS, as you point out
(implicitly anyway) is not the same today as yesterday, etc. Obviously
these are judgement calls and opinions but when the original hard disk code
was written decisions were made concerning such things as sizes for device
storage parameters. While what you have said about the cost of 10Meg HDs
and the like is true, that fact did not seem to influence others in such a
limiting way about how to deal with the matter. More importantly, I
think, is that it has taken many years to finally to address this issue.
> ...
> > ...
> I'm not exactly sure what you think is the nightmare part of the
> original design (and frankly, I don't care). There are a ...
And if you don't care then we are probably both wasting our time.
> ...
> ... sequential block numbers, though, and e.g. W95 _will_ install MBR
> software that uses these (and install itself on a partition with a type
> that MS-DOS doesn't understand) if installed on a HD/partition of above
> (I believe) 2 GB.
Though, I must admit that you have provided a piece of information that I
was not aware of, since I have never installed Win95 nor tried to install
Linux on a machine with Win95 (I would look at the appropriate HOW-TO
before making such an attempt however).
> * There is a limited number of primary partitions available in the MBR.
> This limitation is no serious problem, as many modern OSes don't object
> to being installed in an extended partition (of which there can be as
> many as required). Of course the MS-DOS MBR software does not support
> booting them, but should modern PC hardware be judged by old software?
> There are plenty decent boot mangers around.
Yes, many often incompatible workarounds exist. As to your question, I
still maintain that the PC is a nightmare of horrible design decisions.
You obviously, to me anyway, to not agree -- so be it.
> ...
> > Linux, for very practical reasons, chooses to honor this brain dead,
> > convoluted drive abstraction.
>
> There is nothing brain-dead about partitioning a drive - it is a
> perfectly logical way of having multiple independent filesystems and/or
> operating systems on one disk.
No there is nothing brain dead about partitioning a drive and I see no way
that anyone could conclude from anything that I have said that I think
otherwise. It is the arbitrary decision to create the "tiered" partition
types (primary, extended, and logical) abstraction that I object to.
>
> > ...
> ...
> Not in modern BIOSes. It is backward compatibility that makes LILO
> use the old-style BIOS calls, but it is probably (by now) capable of
> making the newer style calls if told to (I can't check that as I don't
> have the latest version here). (Note that it is also backward
> compatibility that made the PC to what it is now: powerful hardware for
> very low prices).
These "modern BIOSes" have finally caught up with BIOSes of more than
twenty years ago. Are you suggesting that had different decisions
concerning how to deal compatibly with the various limitation that were
arbitrarily built into the original design had been handled differently
that the PC would not be as popular or have such a favorable
performance/price ratio as it currently has?
> > I repeat: There is _nothing_ inherent in Linux that requires any of this
> > "grew like topsy", screwball "design".
>
> Ignoring your qualifications here, I never said there was. I was
> objecting to your misinformation about the basic PC hardware and BIOS.
I have "lost it". In as much as I really do not wish to mislead anyone
then by "misinformation" are you talking about my assertions with respect
to the BIOS design (and indeed design evolution) upon the overall
filesystem design, or rather my (admitted) failure to even mention that
there are new BIOS designs that do not themselves impose this scheme, or
both?
> > ...
> ...
> > I would be
> > willing to defer to your claims that I am wrong concerning primary
> > partitions being visible in DOS, but am having some trouble with that.
> > My experience with DOS and Windoz is _very_ limited.
>
> Mine is quite extensive. Why do you not believe me, when you yourself
> say that your experience here is _very_ limited, and I am telling you I
> have the very thing you claim to be impossible running on my system (and
> on quite a few others, I might add)? Why do you combine lack of
> experience with such strong opinions?
As I pointed out in the previous message, I have seen many PCs with
multiple primary partitions where only ONE primary partition is visible to
DOS or Windoz (or OS2 for that matter). In addition I have read in
multiple books on PC machines that such is the normal design behaviour
for a PC. Though I consider my experience with PCs to be "_very_ limited"
in part because I have written very little software to run on ix86 or
under DOS and none to run under Windoz.
OTOH, I have HAD to fight with PC boxes from time to time for over 20
years. I have (several different times) had experience with PC scsi
controllers that refused to work with drives that would work fine on
non-PC scsi buses. I have had to solve (employers) problems with
incompatible hardware and software (hundreds of different times).
I have seen (though thankfully was not involved) with machine upgrades
where the new IDE drives were of the same make an model as the existing
drive but would not work as master/slave pairs. Yet the same drives would
work just fine on several other brands of PCs (and of course different IDE
drives would work on these PCs). The company was not thrilled as there
were several hundred of these machines.
I have worked with many hundreds of computers ranging from dedicated
micro-controllers to Super-Minis. While each certainly offered its'
problem sets, I honestly believe that none provided problems as ludicrous
as are available to you in the average PC.
Are you "right" that this disaster is what has given us an affordable
computing platform that has capabilities almost unimaginable 20 years ago?
I admit that I don't know for sure. The only real example in the PC world
suggests to me that you are right. IBM's microchannel attempted to
address many of the major points of the disaster but was clearly a
failure. Though if one asks why, then those answers are not so clear.
The "success" of things like "win-modems" suggests a possible answer to
me. And that is that the overwhelming majority of people buying computers
are attentive to price to such an extent that almost no other factor
"matters" (short of Windoz compatibility). It is also likely that
whatever does cause the incredible popularity of the PC and Micro$loth is
also involved in preventing a great many technically superior hardware and
software innovations from becoming common.
In a sense all of this opinion matters not. The PC is what it is and it
does seem to be evolving in the "right" direction even if it has taken
nearly 15 years to do make significant progress. In the meantime all of
the "standards" and incompatibilities that exist in the PC world are the
"part and parcel" of a huge percentage of the development work in Linux
and the activities of listservers.
best,
-bill
bleach@BellSouth.net b.leach@Worldnet.att.net
b.leach@usa.net LinuxPC@Hotmail.com
from a 1996 Micro$loth ad campaign:
"The less you know about computers the more you want Micro$oft!"
See! They do get some things right!
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: