3 Day Bitch Session
Heywood Mogroot
asked them what would happen if we had a blank sheet of paper to
replace the BIOS," Doran said. "It turned into a three-day bitch
session." He said that the original designers of the IBM PC BIOS had
no idea that it would survive this long. "They thought that 250,000
machines would see it through to the end of its life," he said.
http://news.com.com/2100-1001-985600.html
'EFI' previewed at this year's IDC; welcome to the fucking 90's,
Craptel.
=Heywood=
Craig Koller
Mogroot <imout...@mac.com> wrote:
> "When I started, I got senior managers together from across Intel and
> asked them what would happen if we had a blank sheet of paper to
> replace the BIOS," Doran said. "It turned into a three-day bitch
> session." He said that the original designers of the IBM PC BIOS had
> no idea that it would survive this long. "They thought that 250,000
> machines would see it through to the end of its life," he said.
>
> http://news.com.com/2100-1001-985600.html
>
Hey, hey, HEYWOOD!
Good to see your name. Damn, it was getting pretty bleak here for a
while...
Seeker1
> Craptel.
>
> =Heywood=
It always fascinates me that Win users interested in switching often ask
questions like "where's the A: drive" and "where's the C: drive" ... as
if it were somehow natural and rational to identify drives and/or
partitions by letters instead of names.
The weird thing is, the 2nd floppy disappeared in most Wintel machines
very early on, yet B: continued to be reserved for it.
Just one more legacy of that decision.
It does amaze me what 95% of the world considers acceptable and normal.
zolo
Back in 1998, SGI replaced the BIOS with its own much more elegant
ARCS PROM on the 320 and 540, and PeeCee types screamed bloody murder.
More proof that PeeCee lovers can't stand to abandon their legacy
technology, just like the PeeCee's sad dependence on floppy drives.
Just out of curiosity, how many average PeeCees ship with none of the
following installed as standard?
-DB9 serial ports
-PS/2 ports
-floppy drives
-parallel ports
Ironic that PCs can be further ahead in memory/CPU/bridge speed and
lag behind in other areas. That's the problem with an architecture that
tries to be all things to all people.
-zolo
Craig Koller
Seeker1 <see...@mac.com> wrote:
Well, let's be glad that Intel and friends are ready to finally take a
second look ... although the "digital rights management" feature seems
to have a Paladiumesque ring to it.
I'm also wondering if the cheap, commodity nature of PC's is motivating
the main players to try and come up with a way to reign things back in
by offering more complex, proprietary underpinnings on future machines.
Plus, all these freezing, troubleshooting, and security fixes in EFI
seem to be compensating for problems at the OS level (read Windows). I
could care less if I have to endure 20 seconds of blocky text on a
black 640x480 screen, as long as the machine runs reliably and
logically after that.
Admittedly, the A, B and C drive thing is pretty crude, especially from
a Mac perspective (I think the HD in my 4-year-old's Mac clone is
currently named "l;;;;;;;;;;;;;;;;;;;;;;;").
Something tells me a $200 box running LindowsOS won't be sitting on top
of EFI...
foo
>> 'EFI' previewed at this year's IDC; welcome to the fucking 90's,
>> Craptel.
>>
>> =Heywood=
>
>It always fascinates me that Win users interested in switching often ask
>questions like "where's the A: drive" and "where's the C: drive" ... as
>if it were somehow natural and rational to identify drives and/or
>partitions by letters instead of names.
It's easily done and learned; what's the issue?
>The weird thing is, the 2nd floppy disappeared in most Wintel machines
>very early on, yet B: continued to be reserved for it.
>
>Just one more legacy of that decision.
>
>It does amaze me what 95% of the world considers acceptable and normal.
What should a floppy be called? Floppy1? How is that significantly
better than A? And the boot hard drive - should that be
BootHardDrive, or what? C: is easy and everyone knows you mean the
boot hard drive of the PC.
foo
Why is being compatible with massive amounts of hardware "lagging
behind" in your worldview? Please tell me why I *wouldn't* want those
parts, assuming I don't buy new hardware requiring it but instead use
those ports for all of my old hardware that requires it?
Edwin
"Seeker1" <see...@mac.com> wrote in message
news:seeker1-1480F2...@news.comcast.giganews.com...
> > 'EFI' previewed at this year's IDC; welcome to the fucking 90's,
> > Craptel.
> >
> > =Heywood=
>
> It always fascinates me that Win users interested in switching often ask
> questions like "where's the A: drive" and "where's the C: drive" ... as
> if it were somehow natural and rational to identify drives and/or
> partitions by letters instead of names.
It's what they're used to, and there's nothing unnatural about it. It came
from CP/M, and it's not too far different than the way drives are designated
on Amgias or under Linux.
> The weird thing is, the 2nd floppy disappeared in most Wintel machines
> very early on, yet B: continued to be reserved for it.
That's so you can copy a floppy using only one floppy drive. You just tell
the PC to copy from A: to B:, and you get prompts telling you when to switch
disks.
> Just one more legacy of that decision.
Why do you think that's a problem?
> It does amaze me what 95% of the world considers acceptable and normal.
Why does it amaze you? It's not "acceptable and normal" because it's not
Apple's way of doing things?
Edwin
Flip
"Edwin" <ze...@aiur.org> wrote:
> "Seeker1" <see...@mac.com> wrote in message
> news:seeker1-1480F2...@news.comcast.giganews.com...
> > > 'EFI' previewed at this year's IDC; welcome to the fucking 90's,
> > > Craptel.
> > >
> > > =Heywood=
> >
> > It always fascinates me that Win users interested in switching often ask
> > questions like "where's the A: drive" and "where's the C: drive" ... as
> > if it were somehow natural and rational to identify drives and/or
> > partitions by letters instead of names.
>
> It's what they're used to, and there's nothing unnatural about it. It came
> from CP/M, and it's not too far different than the way drives are designated
> on Amgias or under Linux.
>
> > The weird thing is, the 2nd floppy disappeared in most Wintel machines
> > very early on, yet B: continued to be reserved for it.
>
> That's so you can copy a floppy using only one floppy drive. You just tell
> the PC to copy from A: to B:, and you get prompts telling you when to switch
> disks.
No kidding? It's bad enough that so many PCs still depend on floppy
drives. Now you're arguing that it's important to be able to copy one
floppy disk to another? Why?
Craig Koller
<f...@foo.com> wrote:
Reminds me of the old story of the woman who cut the ends off her ham
whenever she cooked it. Her daughter asked way and the woman told her
that's the way it's always been done. Her mother did it and her
grandmother did it.
After a little prompting they called the grandmother in the nursing
home and when asked that question, the old woman said, "Well, my pan
just wasn't long enough so I always had to cut the ends of the ham
off."
C'mon ... "C:" is dumb. You should be able to call any drive
whateverthehell you want. And with floppy drives going away, we'll be
perpetuating an alphabet that bypasses A and B and begins with C.
And "C" is dumb.
foo
You miss the point. C is always C, no matter whether it's on your
computer or the local server. The equivalent is really \, but even
that isn't the best way to write it - what about D: - where on \ is D:
mounted? It could be anywhere. D: removes that issue.
zolo
"foo" <f...@foo.com> wrote in message
news:hi8n5v0o3bqbt2j1o...@4ax.com...
Because they use up IRQ resources and cause conflicts with other add-in
devices, for one. Easily enough resolved by PC/Windoze savvy types, but
infuriating for the majority of laypeople who are confronted with cryptic
Windows messages when they just want their new *whatever* to work..
Resource conflicts/settings are one type of problem that newer technologies
like USB were designed to address.
-zolo
zolo
"Flip" <fli...@mac.com> wrote in message
news:flippo-B2BDF3....@nnrp05.earthlink.net...
Probably because floppies are so damned unreliable... ;)
-zolo
Flip
foo <f...@foo.com> wrote:
That's true. Of course, it creates the other issue - drive letters
change. There are lots of times when you lose your links if you change
the order that drives load - by, for example, having a CD installed in
your PC at boot time.
For that matter, if a program wants a CD and you put the disk in a
different drive (on the same computer, of course) than the one the
system expects, it won't find it.
foo
wrote:
So what? Why do you as a user care?
>and cause conflicts with other add-in
>devices, for one.
How so? What do you mean?
> Easily enough resolved by PC/Windoze savvy types, but
>infuriating for the majority of laypeople who are confronted with cryptic
>Windows messages when they just want their new *whatever* to work..
>Resource conflicts/settings are one type of problem that newer technologies
>like USB were designed to address.
Right - so everyone should drop all old buses - and all old hardware -
and go buy USB. Not!
foo
Dear Lord!
>Of course, it creates the other issue - drive letters
>change. There are lots of times when you lose your links if you change
>the order that drives load - by, for example, having a CD installed in
>your PC at boot time.
Why would you have that? To install an OS. Hence, not a problem.
>For that matter, if a program wants a CD and you put the disk in a
>different drive (on the same computer, of course) than the one the
>system expects, it won't find it.
Depends entirely on the program, flipper.
Flip
foo <f...@foo.com> wrote:
No, it happens if you add a new drive, for example. Or if you install
software on one drive and then move it to another. Or if you install
software with one CD drive empty and then try to use it with both CD
drives full.
Not all the time, but more than enough to be incredibly annoying. AND
unnecessary if Microsoft had gotten away from drive letters 15 years ago
like they should have.
>
> >For that matter, if a program wants a CD and you put the disk in a
> >different drive (on the same computer, of course) than the one the
> >system expects, it won't find it.
>
> Depends entirely on the program, flipper.
That may be. But many (if not most) programs have that behavior. The
only way around it is to ignore the system's APIs and write your own
mechanism for finding the CD. It's lousy design.
foo
If you add a CD, C: doesn't change.
>Or if you install
>software on one drive and then move it to another.
Typically you would reinstall, yes.
>Or if you install
>software with one CD drive empty and then try to use it with both CD
>drives full.
Huh?
>Not all the time, but more than enough to be incredibly annoying. AND
>unnecessary if Microsoft had gotten away from drive letters 15 years ago
>like they should have.
That wouldn't necessarily fix the pathing issues with software moving
from D: to C: or whathaveyou.
>> >For that matter, if a program wants a CD and you put the disk in a
>> >different drive (on the same computer, of course) than the one the
>> >system expects, it won't find it.
>>
>> Depends entirely on the program, flipper.
>
>That may be. But many (if not most) programs have that behavior. The
>only way around it is to ignore the system's APIs and write your own
>mechanism for finding the CD. It's lousy design.
I dunno; Microsoft's requestors seem to handle it well.... if they
can do it, one would think anyone could.
Flip
foo <f...@foo.com> wrote:
I never said it does. But 'D:', for example, could. Since you cited 'D:'
above, that was what I was referring to.
>
> >Or if you install
> >software on one drive and then move it to another.
>
> Typically you would reinstall, yes.
IOW, Windows has crappy file management.
>
> >Or if you install
> >software with one CD drive empty and then try to use it with both CD
> >drives full.
>
> Huh?
Learn to read.
>
> >Not all the time, but more than enough to be incredibly annoying. AND
> >unnecessary if Microsoft had gotten away from drive letters 15 years ago
> >like they should have.
>
> That wouldn't necessarily fix the pathing issues with software moving
> from D: to C: or whathaveyou.
No, but isn't it interesting that Macs have never had that pathing
issue? Which system is a better design?
>
> >> >For that matter, if a program wants a CD and you put the disk in a
> >> >different drive (on the same computer, of course) than the one the
> >> >system expects, it won't find it.
> >>
> >> Depends entirely on the program, flipper.
> >
> >That may be. But many (if not most) programs have that behavior. The
> >only way around it is to ignore the system's APIs and write your own
> >mechanism for finding the CD. It's lousy design.
>
> I dunno; Microsoft's requestors seem to handle it well.... if they
> can do it, one would think anyone could.
Yet they don't.
I'm not interested in what theoretically might be possible. I'm more
interested in the real world.
Edward Dodge
> I'm also wondering if the cheap, commodity nature of PC's is
> motivating the main players to try and come up with a way to reign
> things back in by offering more complex, proprietary underpinnings
> on future machines.
Bingo.
> Something tells me a $200 box running LindowsOS won't be sitting on
> top of EFI...
I think the noose^h^h^h^h^h standard will be "open" to all OS's.
--
Edward Dodge
/Confabulation Consulting/
Craig Koller
<fli...@mac.com> wrote:
Or using both floppies as an array to speed data transfers and double
storage capacity. Or instead you can *mirror* your floppies for
increased data integrity <sigh>...
Craig Koller
[cut]
>
> You miss the point. C is always C, no matter whether it's on your
> computer or the local server. The equivalent is really \, but even
> that isn't the best way to write it - what about D: - where on \ is D:
> mounted? It could be anywhere. D: removes that issue.
While you're saying that "C" is a symbol that represents a HD and "C"
also denotes a position in a hierarchy, I'm saying a hard drive is a
hard drive or a partition a partition. To the user, it shouldn't matter
what "letter" or "number" a drive or volume is. If you have three
children, they have names right? Not (e.g.), Tom (A:), Mary (B:) and
Joe (C:) but rather Tom, Mary and Joe.
Simple. Human. Better. Just lose the letters - if you need to sequence
volumes, make them part of the label. Hell, make'em roman numerals if
you want. This has been a non-issue on Macs for nearly 20 years. If the
PC BIOS has a problem with this then perhaps it's time that changed.
UI 101 dictates that the end user should be spared from as much clutter
as possible...
Flip
Craig Koller <cwko...@nutscrape.net> wrote:
> In article <jkjn5v84t6ks8lvpk...@4ax.com>, foo
> <f...@foo.com> wrote:
>
> [cut]
> >
> > You miss the point. C is always C, no matter whether it's on your
> > computer or the local server. The equivalent is really \, but even
> > that isn't the best way to write it - what about D: - where on \ is D:
> > mounted? It could be anywhere. D: removes that issue.
>
> While you're saying that "C" is a symbol that represents a HD and "C"
> also denotes a position in a hierarchy, I'm saying a hard drive is a
> hard drive or a partition a partition. To the user, it shouldn't matter
> what "letter" or "number" a drive or volume is. If you have three
> children, they have names right? Not (e.g.), Tom (A:), Mary (B:) and
> Joe (C:) but rather Tom, Mary and Joe.
It's actually worse than that. It's as if you had memorized the children
lined up in one way (Tom, Mary, and Joe in that order) but couldn't
recognize them if they stood in a different location in line.
zolo
When you use up available IRQs, things get ugly, and you get conflicts.
Your spiffy new SCSI card, ATA RAID or Firewire card doesn't work. Joe
Average User doesn't want to be confronted with IRQ conflict bullshit... He
just wants the damn thing to work without having to wade through resource
control panels. Why is that so difficult to understand?
>
> >and cause conflicts with other add-in
> >devices, for one.
>
> How so? What do you mean?
I guess I have to hold your hand and walk you through this... Obviously
you've never had to go through the annoying process of hunting down and
resolving resource conflicts when, for example, you try to add some type of
PCI expansion device (modem, NIC, etc.) that tries to grab an IRQ already in
use by, say a serial port that's connected to a Wacom tablet or some other
device. Maybe other IRQs are already being used by some other add-in like a
Firewire card. It can take quite a while to get it all sorted out. It's a
major annoyance, even for someone who is technically inclined. For a
layperson, it's infuriating.
>
> > Easily enough resolved by PC/Windoze savvy types, but
> >infuriating for the majority of laypeople who are confronted with cryptic
> >Windows messages when they just want their new *whatever* to work..
> >Resource conflicts/settings are one type of problem that newer
technologies
> >like USB were designed to address.
>
> Right - so everyone should drop all old buses - and all old hardware -
> and go buy USB. Not!
I'm not advocating that all legacy hardware should be dropped overnight,
but come on- USB has been around for over 5 years now, longer than the
useful life cycle of the average PC. There comes a time when things have to
move forward. I don't see anyone complaining about the lack of ISA slots in
new PCs. Most new printers have USB ports. I agree that getting a new PC
shouldn't mean that you have to throw out a perfectly good parallel ported
printer, but there are adapters that can take care of that, just like there
are USB adapters for DB9 serial port devices. At some point, painful as it
may be, it's out with the old and in with the new.
I'm merely commenting that PCs seem to be such a compromise between
cutting edge and legacy technology. Why is it that PC advocates always
trumpet the superiority of their platform for having the latest technology
like AGP 8X, but always defend the inclusion of legacy devices? Why is it
that USB 2.0 is seen as such a big deal when Firewire, a demonstratably
faster (or at least, equal) technology, has been around for years? Why is
it that even though AGP 8X has no usable practical advantage at this point
in time, it's an "essential feature," while gigabit Ethernet, which offers
real performance benefits on gigabit networks, is "no big deal," and
something that "just drives the cost up?"
The Windroid answer, of course, is that new technology on a PC is always
good, and new technology on a Mac is always unimportant. You can't have it
both ways. Either the latest technology/highest specs are important, or
they're not.
-zolo
zolo
"Craig Koller" <cwko...@nutscrape.net> wrote in message
news:250220031317149514%cwko...@nutscrape.net...
LOL... Hey, are those new floppy RAID cards out yet?
-zolo
Heywood Mogroot
> Heywood Mogroot wrote:
> Back in 1998, SGI replaced the BIOS with its own much more elegant
> ARCS PROM on the 320 and 540, and PeeCee types screamed bloody murder.
> More proof that PeeCee lovers can't stand to abandon their legacy
> technology, just like the PeeCee's sad dependence on floppy drives.
to be fair, people who like x86 self-select for status-quo backward
compatibility. God forbid they should ever lay out $1000 for a new CPU
and then *have* to buy a new mouse or something.
> Just out of curiosity, how many average PeeCees ship with none of the
> following installed as standard?
>
> -DB9 serial ports
> -PS/2 ports
> -floppy drives
> -parallel ports
>
> Ironic that PCs can be further ahead in memory/CPU/bridge speed and
> lag behind in other areas. That's the problem with an architecture that
> tries to be all things to all people.
Or a strength, depending on how you look at it and your specific
needs.
Evolutionism is fine, my only problem with x86 is that the *entire*
platform is still stuck in the 80's. Boot floppies are STILL a murky
future possibility for advanced use.
Itanium was a bold step in a better direction (like PPC was) but
didn't have the CPU oomph over P4 to bridge the emulation gap (which
PPC soon had over 68k).
Microsoft of course has been quite happy with the shitty MBR and BIOS
setting status quo, as it keeps the general public locked on Windows.
(Interestingly, WinXP 64-bit systems support EFI and another
partitioning scheme, GPT).
Wintel is moving, glacially, toward what Mac users enjoy now, but as
always they've got a bit more to do:
Get RID of the Super IO (floppy & serial port controller).
EFI boot manager / GPT partitioning instead of MBR
Gbit 802.3 & 1394b for high-speed storage/networking
Bluetooth & 802.11g for other peripherals
The next-generation PPC system has the potential to be the 2nd coming
of the Mac II.
Here's hoping.
=Heywood=
foo
(Apparently flipper's not familiar with NT/2k/XP's ability to change
driveletters... or 2k/XP's ability to use UNIX style mount points...)
>>
>> >Or if you install
>> >software on one drive and then move it to another.
>>
>> Typically you would reinstall, yes.
>
>IOW, Windows has crappy file management.
In some cases.
>>
>> >Or if you install
>> >software with one CD drive empty and then try to use it with both CD
>> >drives full.
>>
>> Huh?
>
>Learn to read.
Learn to explain what you mean. WTH are you talking about?
>>
>> >Not all the time, but more than enough to be incredibly annoying. AND
>> >unnecessary if Microsoft had gotten away from drive letters 15 years ago
>> >like they should have.
>>
>> That wouldn't necessarily fix the pathing issues with software moving
>> from D: to C: or whathaveyou.
>
>No, but isn't it interesting that Macs have never had that pathing
>issue? Which system is a better design?
Move some System or core "Unix" files around and see how well the Mac
does. You mean the Mac has no issues with applications, and typically
that's correct.
>> >> >For that matter, if a program wants a CD and you put the disk in a
>> >> >different drive (on the same computer, of course) than the one the
>> >> >system expects, it won't find it.
>> >>
>> >> Depends entirely on the program, flipper.
>> >
>> >That may be. But many (if not most) programs have that behavior. The
>> >only way around it is to ignore the system's APIs and write your own
>> >mechanism for finding the CD. It's lousy design.
>>
>> I dunno; Microsoft's requestors seem to handle it well.... if they
>> can do it, one would think anyone could.
>
>Yet they don't.
>
>I'm not interested in what theoretically might be possible. I'm more
>interested in the real world.
Fair enough.
foo
wrote:
It isn't. It's just that with a PCI system, that shouldn't happen.
ISA was the last common system that couldn't share IRQs. XP handles
shared IRQs. Look up what your IRQs are sometime; it's just not an
issue anymore.
>> >and cause conflicts with other add-in
>> >devices, for one.
>>
>> How so? What do you mean?
>
>I guess I have to hold your hand and walk you through this... Obviously
>you've never had to go through the annoying process of hunting down and
>resolving resource conflicts when, for example, you try to add some type of
>PCI expansion device (modem, NIC, etc.) that tries to grab an IRQ already in
>use by, say a serial port that's connected to a Wacom tablet or some other
>device.
No, because I use OSs that have ACPI and share IRQs. OSs like W2k and
XP.
>Maybe other IRQs are already being used by some other add-in like a
>Firewire card. It can take quite a while to get it all sorted out. It's a
>major annoyance, even for someone who is technically inclined. For a
>layperson, it's infuriating.
Can you give me a scenario? Have you ever seen this under XP or
Win2k? What did you do to resolve it?
>> > Easily enough resolved by PC/Windoze savvy types, but
>> >infuriating for the majority of laypeople who are confronted with cryptic
>> >Windows messages when they just want their new *whatever* to work..
>> >Resource conflicts/settings are one type of problem that newer
>technologies
>> >like USB were designed to address.
>>
>> Right - so everyone should drop all old buses - and all old hardware -
>> and go buy USB. Not!
>
>
> I'm not advocating that all legacy hardware should be dropped overnight,
>but come on- USB has been around for over 5 years now, longer than the
>useful life cycle of the average PC. There comes a time when things have to
>move forward. I don't see anyone complaining about the lack of ISA slots in
>new PCs.
You'd be very surprised then. We've got ISA cards worth thousands -
and without a big budget to replace them, the replacement PCs are
Intel 810-based with ISA sockets, rather than 845XY-based PCs.
> Most new printers have USB ports. I agree that getting a new PC
>shouldn't mean that you have to throw out a perfectly good parallel ported
>printer, but there are adapters that can take care of that, just like there
>are USB adapters for DB9 serial port devices. At some point, painful as it
>may be, it's out with the old and in with the new.
If there's no reason to buy a $50 adapter, why buy it?
> I'm merely commenting that PCs seem to be such a compromise between
>cutting edge and legacy technology.
I don't see any compromise - you use what you want and what works. If
you don't want to use the parallel port or serial port, turn them off
- no harm done.
> Why is it that PC advocates always
>trumpet the superiority of their platform for having the latest technology
>like AGP 8X, but always defend the inclusion of legacy devices?
Because people still use them.
>Why is it
>that USB 2.0 is seen as such a big deal when Firewire, a demonstratably
>faster (or at least, equal) technology, has been around for years? Why is
The implementation depends on what people need. There's also the
minor issue that the plug is the same, everyone under the sun has USB,
and *everyone* (except the digicam crowd, and a few others, sure)
develops for USB.
>it that even though AGP 8X has no usable practical advantage at this point
>in time, it's an "essential feature,"
I disagree with that statement.
>while gigabit Ethernet, which offers
>real performance benefits on gigabit networks, is "no big deal," and
>something that "just drives the cost up?"
I agree; it drives the cost up when most don't need it. Not now, and
certainly not 2 years ago when introduced.
John C. Randolph
Flip wrote:
> Not all the time, but more than enough to be incredibly annoying. AND
> unnecessary if Microsoft had gotten away from drive letters 15 years ago
> like they should have.
Actually, you can blame this one on CP/M, and ultimately on the IBM
mainframes that Kildall was used to when he wrote the OS that Gates & co copied.
-jcr
John C. Randolph
foo wrote:
>
> On Tue, 25 Feb 2003 08:57:55 -0500, Seeker1 <see...@mac.com> wrote:
> >It does amaze me what 95% of the world considers acceptable and normal.
>
> What should a floppy be called?
How about whatever the volume label is, or "Untitled Disk" if the user
hasn't set a label?
-jcr
flip
Not really.
That may be where drive letters started (I'll take your word for it),
but it should have been abandoned years ago.
Basically, DOS needed drive letters or something similar. But when they
switched to Windows, there was no real reason to continue using them.
Yet they did (and still do, btw).
zolo
<snip>
> >When you use up available IRQs, things get ugly, and you get conflicts.
> >Your spiffy new SCSI card, ATA RAID or Firewire card doesn't work. Joe
> >Average User doesn't want to be confronted with IRQ conflict bullshit...
He
> >just wants the damn thing to work without having to wade through resource
> >control panels. Why is that so difficult to understand?
>
> It isn't. It's just that with a PCI system, that shouldn't happen.
> ISA was the last common system that couldn't share IRQs. XP handles
> shared IRQs. Look up what your IRQs are sometime; it's just not an
> issue anymore.
I was not aware of this. Thankfully, I haven't had to troubleshoot Windows
boxes much since the NT 4.0 days.
>
> >> >and cause conflicts with other add-in
> >> >devices, for one.
> >>
> >> How so? What do you mean?
> >
> >I guess I have to hold your hand and walk you through this... Obviously
> >you've never had to go through the annoying process of hunting down and
> >resolving resource conflicts when, for example, you try to add some type
of
> >PCI expansion device (modem, NIC, etc.) that tries to grab an IRQ already
in
> >use by, say a serial port that's connected to a Wacom tablet or some
other
> >device.
>
> No, because I use OSs that have ACPI and share IRQs. OSs like W2k and
> XP.
Noted. It's good to see that progress is being made on this front. Now
about that pesky BIOS...
>
> >Maybe other IRQs are already being used by some other add-in like a
> >Firewire card. It can take quite a while to get it all sorted out. It's
a
> >major annoyance, even for someone who is technically inclined. For a
> >layperson, it's infuriating.
>
> Can you give me a scenario? Have you ever seen this under XP or
> Win2k? What did you do to resolve it?
Not under 2K or XP, under NT 4.0. Again, nice to hear that it's no longer
an issue.
<snip>
-zolo
foo
wrote:
>
>"foo" <f...@foo.com> wrote in message
>news:15un5v47n0vd7ephp...@4ax.com...
>> On Tue, 25 Feb 2003 17:49:04 -0500, "zolo" <zolo...@excite.com>
>> wrote:
>
><snip>
>
>> >When you use up available IRQs, things get ugly, and you get conflicts.
>> >Your spiffy new SCSI card, ATA RAID or Firewire card doesn't work. Joe
>> >Average User doesn't want to be confronted with IRQ conflict bullshit...
>He
>> >just wants the damn thing to work without having to wade through resource
>> >control panels. Why is that so difficult to understand?
>>
>> It isn't. It's just that with a PCI system, that shouldn't happen.
>> ISA was the last common system that couldn't share IRQs. XP handles
>> shared IRQs. Look up what your IRQs are sometime; it's just not an
>> issue anymore.
>
>
>I was not aware of this. Thankfully, I haven't had to troubleshoot Windows
>boxes much since the NT 4.0 days.
So if you aren't aware of this, why are you repeating it?
Typical, actually... and that's sad.
>> >> >and cause conflicts with other add-in
>> >> >devices, for one.
>> >>
>> >> How so? What do you mean?
>> >
>> >I guess I have to hold your hand and walk you through this... Obviously
>> >you've never had to go through the annoying process of hunting down and
>> >resolving resource conflicts when, for example, you try to add some type
>of
>> >PCI expansion device (modem, NIC, etc.) that tries to grab an IRQ already
>in
>> >use by, say a serial port that's connected to a Wacom tablet or some
>other
>> >device.
>>
>> No, because I use OSs that have ACPI and share IRQs. OSs like W2k and
>> XP.
>
>
>Noted. It's good to see that progress is being made on this front.
Do you routinely post knowledge and arguments that are years old?
> Now
>about that pesky BIOS...
What about it?
>>
>> >Maybe other IRQs are already being used by some other add-in like a
>> >Firewire card. It can take quite a while to get it all sorted out. It's
>a
>> >major annoyance, even for someone who is technically inclined. For a
>> >layperson, it's infuriating.
>>
>> Can you give me a scenario? Have you ever seen this under XP or
>> Win2k? What did you do to resolve it?
>
>
>Not under 2K or XP, under NT 4.0. Again, nice to hear that it's no longer
>an issue.
Shall I compare XP to OS8.0 or 8.1 for you? Would you like that?
Edwin
I'm telling you why B: was reserved for a floppy drive even though PCs
only come with one floppy drive as A:
I offered no argument on the importance of the ability to do this, but
obviously the need for it has diminished as PCs began to include HD
and then larger HD.
Does your assertion that many PCs "depend on floppy drives" come from
your experience at Oseco? I ask for information only.
Edwin
Try M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ --
This signature was created for the pleasure of Mike Dee
Seeker1
> from CP/M, and it's not too far different than the way drives are designated
> on Amgias or under Linux.
Well, I use the word "unnatural" to mean "arbitrary." If you can explain
why it's the case that a floppy drive should always be "A" or "B" or why
a hard disk should be "C"... I'm all ears.
Answering that it's convention is fine; I agree it's convention, but
it's convention that lacks logic. It's convention that's been carried
forward because, as was noted above, PC BIOSes haven't changed very much
in 15 years.
> > The weird thing is, the 2nd floppy disappeared in most Wintel machines
> > very early on, yet B: continued to be reserved for it.
>
> That's so you can copy a floppy using only one floppy drive. You just tell
> the PC to copy from A: to B:, and you get prompts telling you when to switch
> disks.
Ummm, this could work if the two floppies were named anything - say
"foo" and "bar".
> > Just one more legacy of that decision.
>
> Why do you think that's a problem?
Things that are continued even though they have no logic to them, seem
silly. I'm not saying anybody's being harmed by perpetuating this
system, anymore than anybody's being harmed by chopping off both ends of
their Christmas ham. But it seems silly to continue doing something when
it's no longer necessary.
> > It does amaze me what 95% of the world considers acceptable and normal.
>
> Why does it amaze you? It's not "acceptable and normal" because it's not
> Apple's way of doing things?
No, because it seems arbitrary to name drives by letters, since if you
were to sit down a person from Mars in front of a computer, how exactly
would they know "A" was the floppy drive and "C" was the hard drive? I
applaud the fact that Apple seems to be one of the only manufacturers
who recognizes this schema has no point.
Mike Dee
imout...@mac.com (Heywood Mogroot) wrote:
[snipped]
> Wintel is moving, glacially, toward what Mac users enjoy now, but as
> always they've got a bit more to do:
>
> Get RID of the Super IO (floppy & serial port controller).
> EFI boot manager / GPT partitioning instead of MBR
> Gbit 802.3 & 1394b for high-speed storage/networking
> Bluetooth & 802.11g for other peripherals
>
> The next-generation PPC system has the potential to be the 2nd coming
> of the Mac II.
And once they do, they'll claim to have invented it.
D.
Woofbert
A long time ago I bought a PDP-11, complete with operating system, its
source code, and documentation. I was struck by how similar CP/M was to
RT-11. The differences were that his OS used a BIOS and had far more
limited suport for i/o devices and no support for a background process.
I've been reading biographies of Gary Kildall, and they all say he was
working at Intel when he wrote CP/M.
http://www.joyce.de/english/cpmstory.htm says he used PDP-10 to simulate
the 8080 so he could write a PL/1 compiler for it. He wrote CP/M as a
workaround operating system for the compiler to run on.
http://www.eh.net/lists/archives/eh.res/aug-1997/0017.php claims that
Kildall worked for DEC, but that doesn't sound reliable.
--
Woofbert, Chief Rocket Surgeon, Infernosoft
Woofbert's Law on Learning Linux: When attempting to learn Linux,
study it thoroughly before you begin.
Woofbert
flip <fli...@mac.com> wrote:
> In article <3E5C1ED8...@idiom.com>,
> "John C. Randolph" <j...@idiom.com> wrote:
>
> > Flip wrote:
> >
> > > Not all the time, but more than enough to be incredibly annoying. AND
> > > unnecessary if Microsoft had gotten away from drive letters 15 years ago
> > > like they should have.
> >
> > Actually, you can blame this one on CP/M, and ultimately on the IBM
> > mainframes that Kildall was used to when he wrote the OS that Gates & co
> > copied.
>
> Not really.
>
> That may be where drive letters started (I'll take your word for it),
> but it should have been abandoned years ago.
Drive letters predate CP/M. DEC's operating systems had them long before
that. UNIX, which was written on DEC PDP-11, managed to do away with
them, but they made so much sense at the time that it was hard to get
away from them.
> Basically, DOS needed drive letters or something similar. But when they
> switched to Windows, there was no real reason to continue using them.
> Yet they did (and still do, btw).
DOS didn't really *need* drive letters. UNIX had a perfectly viable
alternative.
Mike Dee
Edwin <ze...@aiur.org> wrote:
> X-Newsreader: Forte Agent 1.8/32.548
[snipped]
> Edwin
> Try M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ --
> This signature was created for the pleasure of Mike Dee
OK, you've *almost* got a working sig happening here, Edwin. All you
need to do now is add a carriage return (that's marked as the Enter key
on your keyboard) to add a space between your name (it's Edwin,
remember) and your sig which IIRC, the sig should be preceeded by a
couple of "--" (without quote marks)
We'll teach you how use a news reader yet.
D.
Robert Fovell
Would that be a RAID, as in Redundant Array of Infinitesmal Disks? :-)
I swore off floppies after AOL stopped religiously mailing me one, every
week.
--
"Anyone who has been in a thunderstorm has enjoyed it, or has been
frightened, or at least has had some emotion. And in those places in
nature where we get an emotion, we find that there is generally a
corresponding complexity and mystery about it." -- Richard Feynman
C Lund
>>It does amaze me what 95% of the world considers acceptable and normal.
>
>What should a floppy be called? Floppy1?
How about calling it whatever the user decides to call it? That's how we
maccies do things.
--
C Lund, Oslo
http://www.notam02.no/~clund/
zolo
> On Tue, 25 Feb 2003 21:27:44 -0500, "zolo" <zolo...@excite.com>
> wrote:
>
>
>>"foo" <f...@foo.com> wrote in message
>>news:15un5v47n0vd7ephp...@4ax.com...
>>
>>>On Tue, 25 Feb 2003 17:49:04 -0500, "zolo" <zolo...@excite.com>
>>>wrote:
>>
>><snip>
>>
>>>>When you use up available IRQs, things get ugly, and you get conflicts.
>>>>Your spiffy new SCSI card, ATA RAID or Firewire card doesn't work. Joe
>>>>Average User doesn't want to be confronted with IRQ conflict bullshit...
>>
>>He
>>
>>>>just wants the damn thing to work without having to wade through resource
>>>>control panels. Why is that so difficult to understand?
>>>
>>>It isn't. It's just that with a PCI system, that shouldn't happen.
>>>ISA was the last common system that couldn't share IRQs. XP handles
>>>shared IRQs. Look up what your IRQs are sometime; it's just not an
>>>issue anymore.
>>
>>
>>I was not aware of this. Thankfully, I haven't had to troubleshoot Windows
>>boxes much since the NT 4.0 days.
>
>
> So if you aren't aware of this, why are you repeating it?
>
> Typical, actually... and that's sad.
What's typical and sad is your snotty, condescending attitude.
I graciously admitted my ignorance of the topic. Obviously I would not
have intentionally posted my comments had I known about 2K and XP's
advancements regarding IRQs. It's not my intention, nor my nature to
perpetuate old arguments based on outdated information. I felt that I
had a legitimate argument, and you proved otherwise. No need to be an
asshole about it.
>
>
>>>>>>and cause conflicts with other add-in
>>>>>>devices, for one.
>>>>>
>>>>>How so? What do you mean?
>>>>
>>>>I guess I have to hold your hand and walk you through this... Obviously
>>>>you've never had to go through the annoying process of hunting down and
>>>>resolving resource conflicts when, for example, you try to add some type
>>
>>of
>>
>>>>PCI expansion device (modem, NIC, etc.) that tries to grab an IRQ already
>>
>>in
>>
>>>>use by, say a serial port that's connected to a Wacom tablet or some
>>
>>other
>>
>>>>device.
>>>
>>>No, because I use OSs that have ACPI and share IRQs. OSs like W2k and
>>>XP.
>>
>>
>>Noted. It's good to see that progress is being made on this front.
>
>
> Do you routinely post knowledge and arguments that are years old?
Not intentionally. Do you routinely beat dead horses?
>
>
>> Now
>>about that pesky BIOS...
>
>
> What about it?
It is my opinion that the various BIOSes of PCs could benefit from
standardization and modernization. I think it would be ideal to have a
single common BIOS for all PCs, a single common method of accessing it
at bootup, and a fully mouse-driven GUI. Built-in disk partitioniong
tools would be nice as well. The ARCS PROM that SGI uses in its IRIX
systems and on its discontinued 320 and 540 are elegant examples of what
the BIOS could be on PCs. I think Macs could benefit from a similar
implementation, which would eliminate the need to boot from a CD.
>
>
>>>>Maybe other IRQs are already being used by some other add-in like a
>>>>Firewire card. It can take quite a while to get it all sorted out. It's
>>
>>a
>>
>>>>major annoyance, even for someone who is technically inclined. For a
>>>>layperson, it's infuriating.
>>>
>>>Can you give me a scenario? Have you ever seen this under XP or
>>>Win2k? What did you do to resolve it?
>>
>>
>>Not under 2K or XP, under NT 4.0. Again, nice to hear that it's no longer
>>an issue.
>
>
> Shall I compare XP to OS8.0 or 8.1 for you? Would you like that?
If it makes you feel superior, sure. Having never used Macs much prior
to OS X, I wouldn't have any use for that information.
-zolo
foo
>foo wrote:
>> On Tue, 25 Feb 2003 21:27:44 -0500, "zolo" <zolo...@excite.com>
>> wrote:
>>
>>
>>>"foo" <f...@foo.com> wrote in message
>>>news:15un5v47n0vd7ephp...@4ax.com...
>>>
>>>>On Tue, 25 Feb 2003 17:49:04 -0500, "zolo" <zolo...@excite.com>
>>>>wrote:
>>>
>>><snip>
>>>
>>>>>When you use up available IRQs, things get ugly, and you get conflicts.
>>>>>Your spiffy new SCSI card, ATA RAID or Firewire card doesn't work. Joe
>>>>>Average User doesn't want to be confronted with IRQ conflict bullshit...
>>>
>>>He
>>>
>>>>>just wants the damn thing to work without having to wade through resource
>>>>>control panels. Why is that so difficult to understand?
>>>>
>>>>It isn't. It's just that with a PCI system, that shouldn't happen.
>>>>ISA was the last common system that couldn't share IRQs. XP handles
>>>>shared IRQs. Look up what your IRQs are sometime; it's just not an
>>>>issue anymore.
>>>
>>>
>>>I was not aware of this. Thankfully, I haven't had to troubleshoot Windows
>>>boxes much since the NT 4.0 days.
>>
>>
>> So if you aren't aware of this, why are you repeating it?
>>
>> Typical, actually... and that's sad.
>
>
>What's typical and sad is your snotty, condescending attitude.
I don't like it when folks talk about problems solved years ago and
pretend they're an issue. Shall I next talk about how poorly a Mac
Plus handled a single-floppy system? It's just silly!
I'd rather vendors compete to get the best BIOSs available, rather
than standardizing without competition.
>Built-in disk partitioniong
>tools would be nice as well.
That's the OS's job.
>The ARCS PROM that SGI uses in its IRIX
>systems and on its discontinued 320 and 540 are elegant examples of what
>the BIOS could be on PCs. I think Macs could benefit from a similar
>implementation, which would eliminate the need to boot from a CD.
Can you discuss or describe the ARCS PROM for us?
zolo
> On Wed, 26 Feb 2003 17:15:58 GMT, zolo <zolo...@excite.com> wrote:
> I don't like it when folks talk about problems solved years ago and
> pretend they're an issue.
I wasn't "pretending," I was genuinely unaware the problem had been solved.
Sorry if you felt I was intentionally dredging up irrelevant information.
Thanks for setting me straight.
> >It is my opinion that the various BIOSes of PCs could benefit from
> >standardization and modernization. I think it would be ideal to have a
> >single common BIOS for all PCs, a single common method of accessing it
> >at bootup, and a fully mouse-driven GUI.
>
> I'd rather vendors compete to get the best BIOSs available, rather
> than standardizing without competition.
Agreed, but for the end user, a common means of accessing the BIOS might be
helpful. Different machines have different methods, and not all PCs display
the proper keycode to enter the BIOS upon bootup. Sometimes it's a funtion
key, sometimes it's the delete key, sometimes it's escape, etc. If the
required keycode isn't displayed on the startup screen and the manual isn't
readily available, one has to find the proper key combination by trial and
error. Not an insurmountable problem, just a minor annoyance.
>
> >Built-in disk partitioniong
> >tools would be nice as well.
>
> That's the OS's job.
Personal preference. Is it now possible in Windows 2K and XP to make
alterations on an active (OS) partition without rebooting?
>
> >The ARCS PROM that SGI uses in its IRIX
> >systems and on its discontinued 320 and 540 are elegant examples of what
> >the BIOS could be on PCs. I think Macs could benefit from a similar
> >implementation, which would eliminate the need to boot from a CD.
>
> Can you discuss or describe the ARCS PROM for us?
Sure, but SGI can do it better than I.
(Copied from SGI's technical publications website, as pretains to IRIX
systems):
DESCRIPTION
The PROM monitor is a program that resides in programmed read-only
memory, which controls the startup of the system. The PROM is started
whenever the system is first powered on, reset, or shutdown by the
administrator.
The PROM contains features that vary from system to system.
Description
of various commands, options, and interfaces below may not apply to the
PROM in your system and may vary between systems.
When the system is first powered on, the PROM runs a series of tests on
the core components of the system. It then performs certain hardware
initialization functions such as starting up SCSI hard disks,
initializing graphics hardware, and clearing memory. Upon successful
completion of these tasks, the PROM indirectly starts the operating
system by invoking a bootstrap loader program called sash, which in
turn
reads the IRIX kernel from disk and transfers control to it.
Menu Commands
By default, the PROM attempts to boot the operating system kernel when
the system is powered on or reset. Before doing so, however, the
opportunity to press the <Escape> key is given. If the <Escape> key is
pressed within approximately ten seconds, the PROM displays a menu of
alternate boot up options. These other choices allow various types of
system maintenance to be performed:
1. Start System
Causes the system to boot in the default way. It is the same as
if
the system had been allowed to boot on its own.
2. Install System Software
Transfers you to a menu that allows you to interactively select
the
type of device you will use to perform the installation (for
example, tape drive, network connection, or CD-ROM drive) and then
select the specific device from those of the specified type.
3. Run Diagnostics
Invokes the extended hardware diagnostic program, which performs a
thorough test of the CPU, I/O, and any graphics boards present.
It
reports a summary. This option is not implemented on all systems.
4. Recover System
Transfers you to a menu that allows you to interactively select
the
type of device you will use to perform the recovery (for example,
tape drive, network connection, or CD-ROM drive) and then select
the
specific device from those of the specified type.
5. Enter Command Monitor
Command monitor is a PROM mode where you can enter commands.
Additional functions can be performed from this interactive
command
monitor. It puts the PROM into a manual mode of operation.
6. Select Keyboard Layout
Some systems display a sixth option when the console is on the
graphics display, which allows the keyboard map to be
interactively
selected for SGI supported international keyboards.
Manual Mode
The PROM command monitor allows the user to customize certain features
of
the boot process for one-time only needs or longer term changes. The
command monitor has some features that are similar to an IRIX shell
such
as command-line options and environment variables. Some of the
environment variables used in the PROM are stored in nonvolatile RAM,
which means that their values are preserved even after the power to the
system is turned off. For specific information on your system, see the
owner manuals and other documentation that came with it.
Manual Mode Commands
The following list of manual mode commands include brief descriptions
and
syntax examples. These commands may or may not be supported by your
system. From the PROM prompt >>, enter help to see the commands your
PROM supports.
auto Attempts to boot the system into normal operation. This
command is the equivalent of the Start System menu command.
auto
boot Boots the named file with the given arguments.
boot [-f path] [-n] [args]
disable Disables hardware.
disable -m modid -s slotid [-cpu a|b|c|d] [-mem
[01234567]] [-pci [01234567]]
enable Enables hardware.
enable -m modid -s slotid [-cpu a|b||c|d] [-mem
[01234567]] [-pci [01234567]]
enableall Enables all disabled components.
enableall [-y] [-list]
exit Exits manual mode and returns to the PROM menu.
exit
flash Flashes all appropriate PROMs with file.
flash [-e] [-m modid] [-N nasid] [-f] [-F] [-y] [-v]
[-e] [-l] [-C] file
help Displays a short summary of the commands available in manual
mode.
help [command]
hinv Lists the hardware present in the system. This list includes
any disk or tape drives, memory, and graphics options. It
lists only those devices known to the PROM and may not
include
all optional boards.
hinv [-v] [-m] [-mvv] [-g path]
init Causes a partial restart of the PROM. This command can be
used
to change the default console immediately. See the console
environment variable.
init
ls Lists files on a specified device.
ls [device]
modnum Lists all current modules or bricks in the system.
modnum
passwd Sets the PROM password.
passwd
pod Enters the POD (Power On Diagnostics) mode command
interpreter.
POD mode is a command interpreter present in the PROM, which
is
most often used to debug a crashed system. POD can be used
to
examine the contents of CPU registers, support chip
registers,
and memory. It can also enable and disable certain compute
node features, such as CPUs, I/O, and memory banks. To
obtain
a list of available POD monitor commands, enter help at the
POD
monitor prompt. For additional POD information, see the
documentation that came with your system.
pod
printenv Lists the current state of the PROM environment variables.
Some of the variables listed retain their value after the
system is powered off.
printenv [env_var_list]
resetenv Sets all of the PROM nonvolatile environment variables to
their
factory defaults. This command does not affect the PROM
password.
resetenv
resetpw Removes the PROM password. With no PROM password set, all
commands and menu options function without restriction.
resetpw
setenv Sets environment variables.
setenv [env_var_string value]
setpart Transfers you to a menu that allows you to interactively set
up
system partitioning. System partitioning is not supported on
all systems. See your owner documentation for more
information
on partitioning your system.
setpart [-h]
single Boots the system in single-user mode.
single
unsetenv Clears an environment variable.
unsetenv [env_var_string]
update Updates the stored hardware inventory information.
update
version Displays the command monitor version.
version
Command Monitor Environment Variables
The command monitor maintains an environment, which is a list of
variable
names and corresponding values (the values are actually text strings).
These environment variables contain information that the command
monitor
either uses itself or passes to booted programs. The system stores
some
environment variables (those that are important and unlikely to change
frequently) in nonvolatile RAM. If you turn off power to the machine
or
reset the system, the system remembers these variables. When you
change
the setting of these variables using the setenv command, the PROM code
automatically stores the new values in nonvolatile RAM.
You can also use the /sbin/nvram command to set or print the values of
nonvolatile RAM variables on your system. For complete information on
the nvram command, see the nvram(1M) man page.
AutoLoad Controls whether the system boots automatically on
reset or power cycle. Can be set to Yes or No.
Previously, this function was controlled by setting
bootmode to c or m. This variable is overridden by
the
rebound variable and the reboot_on_panic kernel
tunable
parameter. This variable is stored in nonvolatile
RAM.
autopower Specifies whether a setting of y allows a system with
software power control to automatically power back on
after an AC power failure. The default setting of n
requires the power switch to be pressed to restart
the
system. This variable is stored in nonvolatile RAM.
bootfile Controls two aspects of the automatic boot up
process:
1. It names the standalone loader that is used as
an
intermediary when booting from disk.
2. The device portion of the filename is used to
determine the default boot disk.
The PROM assumes that the disk specified as part of
the
standalone loader pathname is the disk where the IRIX
root filesystem exists. Furthermore, during software
installation, the PROM uses that disk's swap
partition
for the miniroot. The actual partitions assumed by
the
PROM to contain the root filesystem and swap area are
determined by reading the volume header. This
variable
is stored in nonvolatile RAM. See the vh(7M) man
page
for more information.
boottune Selects the boot music string. A value of 0
randomizes
the selection each time. 1 is the default value.
(It
is supported only on POWER Indigo2 and Octane
systems.)
console Sets the system console. If console is set to g or
G,
the console is assumed to be the graphics display.
On
some systems with multiple graphics adapters, setting
console to g0 (identical to g), g1, or g2 can be used
to select alternate graphics displays. If console is
set to d, the console is assumed to be a terminal
connected to the first serial port. In addition,
some
systems also accept d2 for a terminal connected to
second serial port. Lastly, this can be overridden
on
some systems by removing the password jumper, which
forces the console to g, which is useful for for
recovering from setting console to d when a terminal
is
not available. This variable is stored in
nonvolatile
RAM.
ConsoleIn/ConsoleOut
Are set at system startup automatically from the
console variable.
dbaud Specifies the diagnostic baud rate. It can be used
to
specify a baud rate other than the default when a
terminal connected to serial port #1 is to be used as
the console.
diskless Specifies that the system is diskless and must be
booted over the network. The diskless system
environment parameters should be set as follows:
diskless=1
SystemPartition=bootp()host:/path
OSLoader=kernelname
ec0mode Disables autonegotiation and selects the desired
speed
and duplex of the ec0 ethernet controller on O2
(IP32)
systems. Legal values are 10, 100, f10, f100. It is
case-insensitive and illegal values are silently
ignored and will result in a 10Mb, half-duplex
setting.
It is stored in nonvolatile RAM and so is persistent
across resets and power-downs. Also see the
ethernet(7)
man page.
ef0mode Disables autonegotiation and selects the desired
speed
and duplex of the ef0 ethernet controller on Origin
2000/Onyx2 (IP27), Octaine (IP30), and Origin
3000/Onyx3/Fuel (IP35) systems. Legal values are 10,
100, h10, f10, h100 and f100. It is case-insensitive
and illegal values are silently ignored and will
result
in a 10Mb, half-duplex setting. It is stored in
nonvolatile RAM and so is persistent across resets
and
power-downs. Note that once IRIX is booted, a
different
mechanism is used to fix the speed and duplex of the
ef<n> interfaces (See the ethernet(7) man page).
keybd Specifies the type of keyboard used. The default is
df. Available settings depend on the exact PROM
revision, but may include some or all of the
following
settings: USA, DEU, FRA, ITA, DNK, ESP, CHE-D, SWE,
FIN, GBR, BEL, NOR, PRT, CHE-F. Or on systems with
the
keyboard layout selector, the settings may include:
US,
DE, FR, IT, DK, ES, deCH, SE, FI, GB, BE, NO, PT,
frCH.
On some systems, JP is also acceptable to specify a
Japanese keyboard.
netaddr Used when booting or installing software from a
remote
system by Ethernet. This variable should be set to
contain the Internet address of the system. It is
stored in nonvolatile RAM.
OSLoader Specifies the operating system loader. For the IRIX
system, this is sash. This variable is stored in
nonvolatile RAM, but is normally left unset, which
allows the PROM to automatically configure it at
system
power-on.
OSLoadFilename Specifies the filename of the operating system
kernel.
For the IRIX system, this is /unix. This variable is
stored in nonvolatile RAM, but is normally left
unset,
which allows the PROM to automatically configure it
at
system power-on.
OSLoadOptions Specifies the contents of this variable are appended
to
the boot command constructed when autobooting the
system. This variable is stored in nonvolatile RAM.
OSLoadPartition Specifies the device partition where the core
operating
system is found. For the IRIX system, this variable
is
used as the root partition when the root variable is
unused or not available and the device configured in
the system file with the ROOTDEV directive is not
available. (See the system(4) man page.) This
variable is stored in nonvolatile RAM, but is
normally
left unset, which allows the PROM to automatically
configure it at system power-on.
ProbeAllScsi Specifics that all devices on the SCSI bus are
automatically examined for disks.
root Specifies filesystem information that is passed on to
the IRIX system.
rebound Specifies that the system should automatically reboot
after a kernel panic if this variable is set to y.
The
variable interacts with the AutoLoad variable and the
reboot_on_panic kernel tunable parameter.
sgilogo Specifies whether the SGI logo and other product
information are shown on systems that support the
standalone GUI. To show this information, set the
variable to y. This variable is stored in
nonvolatile
RAM.
SystemPartition Specifies the device where the operating system
loader
is found. This variable is stored in nonvolatile
RAM,
but is normally left unset, which allows the PROM to
automatically configure it at system power-on.
volume Sets the speaker volume during boot up. This
variable
controls the volume of the startup, shutdown, and bad
graphics tunes generated on systems with integral
audio
hardware. This variable is stored in nonvolatile
RAM.
Environment Variables That Affect the IRIX Operating System
Some environment variables directly affect the IRIX operating system
and
are discarded if the system is powered off.
initstate Is passed to the IRIX system, where it overrides the
initdefault line in the /etc/inittab file. Permitted
values are s and the numbers 0-6. See the init(1M) man
page.
path Specifies a list of device prefixes that tell the
command
monitor where to look for a file, if no device is
specified.
showconfig Prints extra information as the IRIX system boots. If
set
through setenv, its value must be istrue.
swap Specifies in IRIX notation the swap partition to use.
If
not set, it defaults to the partition configured into
the
operating system, which is normally partition 1 on the
drive specified by the root environment variable.
verbose Tells the system to display detailed error messages.
Command Monitor Filename Syntax
When you specify filenames for command monitor commands, use this
syntax:
device ([cntrlr,[unit[,partition]]])file
device Specifies a device driver name known to the PROM.
cntrlr Specifies a controller number for devices that may have
multiple controllers.
unit Specifies a unit number on the specified controller.
partition Specifies a partition number within a unit.
file Specifies a pathname for the file to be accessed.
If you do not specify cntrlr, unit, and partition, they default to
zero.
The notation shows that you can specify only a controller, a unit and
partition, or all three variables. The commas are significant as place
markers.
For example, the root partition (partition 0) on a single SCSI disk
system is shown as:
dksc(0,1,0)
0 The first 0 indicates SCSI controller 0.
1 The 1 indicates drive number 1 on SCSI controller 0.
0 The final 0 indicates partition 0 (root partition) on drive 1 on
SCSI
controller 0.
The /usr partition (partition 3) on the same disk would be written as:
dksc(0,1,3)
Device Names in the Command Monitor
The command monitor defines the following devices:
Device Name Description
dksc SCSI disk controller (dks in the IRIX system)
tpsc SCSI tape controller (tps in the IRIX system)
tty CPU board uart
tty(0) Local console
tty(1) Remote console
gfx Graphics console
console Pseudo console, which may be one of gfx(0), tty(0), or
tty(1)
bootp Ethernet controller using bootp and TFTP protocols (See
tftp(1C) man page.)
tpqic Quarter-inch QIC02 tape drive
Virtual Debug Switch Settings
PROM boot behavior can be altered by changing the value of the virtual
debug switch. The value of the virtual debug switch can be displayed
or
altered from either the system controller or from POD mode with the dbg
POD command. The values in the following list of virtual debug switch
settings are hexidecimal numbers. These values can be OR-ed together
to
set multiple options.
Diagnostic Testing Level
0 Normal testing.
1 No testing.
2 Heavy testing.
3 Manufacturing-level testing.
Diagnostic Output Level
4 Verbose. Information level is set to verbose.
Boot Stop Point
0 Normal. Normal setting, do not stop.
8 Global POD. Global master stops in POD mode; slaves enter slave
loop.
10 Local POD. Boot stop requested at local POD. All local masters
and
CPUs with console access enter POD mode; the rest enter the slave
loop.
18 Memoryless POD. Boot stop requested at no memory POD. All CPUs
enter POD mode after memory is probed, but before it is tested or
initialized.
Default Environment
20 Ignores environment variable.
Override Disabling
100 Overrides CPUs and memory disabled with the environment variables
in
POD mode. It is useful for getting out of the situation in which
all CPUs or memory in the system have accidentally been disabled
simultaneously.
Hardware Error State
1000 Dumps hardware error state at system boot time.
Ignore Autoboot
2000 PROM ignores the AutoLoad environment variable.
The PROM in the 320/540 is somewhat similar, only with out the Command
Monitor option. The menu screens are full color and mouse driven. The PROM
is also flashable, which can be achieved by installing updates in the
Software Manager and rebooting the machine (no floppy required on IRIX
systems). Overall, the PROM is a really nice feature, one that I hope finds
its way to PCs and Macs in the future.
If I can find any screenshots, I'll post them.
-zolo
zolo
> > Can you discuss or describe the ARCS PROM for us?
Here's a good account of the PROM on an SGI 320:
http://www.arstechnica.com/reviews/1q99/sgivw.html
Please understand, I'm not holding up the 320/540 as the be-all end-all in
PC evolution. They both had some significant problems, like a
non-upgradable graphics subsystem and expensive, nonstandard memory. They
also could not boot to DOS, since the PROM handled the loading of the OS
(Windows NT or 2000). However, they had some interesting innovations, like
standard integrated analog AV I/O and a shared memory architecture that
allowed system memory to be manually reallocated to the graphics subsystem.
-zolo
3000 Peter Perlsø
> Hey, hey, HEYWOOD!
Floyd?
--
cordial regards, the prime minister of Peterburg:
http://www.nationstates.net/ +45 5192 3981
http://titancity.com/about.html - about me
http://haxor.dk/islamnyt/ - fordelene ved indvandringen i DK
3000 Peter Perlsø
>
> It does amaze me what 95% of the world considers acceptable and normal.
the world isn't rational.
The PC side of thing DEFINATELY isnt rational.
foo
wrote:
>
>"foo" <f...@foo.com> wrote in message
>news:riup5vkk61n1f7siq...@4ax.com...
>> On Wed, 26 Feb 2003 17:15:58 GMT, zolo <zolo...@excite.com> wrote:
>
>> I don't like it when folks talk about problems solved years ago and
>> pretend they're an issue.
>
>I wasn't "pretending," I was genuinely unaware the problem had been solved.
>Sorry if you felt I was intentionally dredging up irrelevant information.
>Thanks for setting me straight.
I blew it out of proportion.
>> >It is my opinion that the various BIOSes of PCs could benefit from
>> >standardization and modernization. I think it would be ideal to have a
>> >single common BIOS for all PCs, a single common method of accessing it
>> >at bootup, and a fully mouse-driven GUI.
>>
>> I'd rather vendors compete to get the best BIOSs available, rather
>> than standardizing without competition.
>
>Agreed, but for the end user, a common means of accessing the BIOS might be
>helpful. Different machines have different methods, and not all PCs display
>the proper keycode to enter the BIOS upon bootup. Sometimes it's a funtion
>key, sometimes it's the delete key, sometimes it's escape, etc. If the
>required keycode isn't displayed on the startup screen and the manual isn't
>readily available, one has to find the proper key combination by trial and
>error. Not an insurmountable problem, just a minor annoyance.
Granted, but most users would have no cause of going into the BIOS in
the first place, so I don't see it as an issue. HDD, RAM, etc - it's
all autodetected; why go in the BIOS?
>> >Built-in disk partitioniong
>> >tools would be nice as well.
>>
>> That's the OS's job.
>
>Personal preference. Is it now possible in Windows 2K and XP to make
>alterations on an active (OS) partition without rebooting?
Meaning shrink a 40G partition to 20G? No.
Meaning format a partition and bring it online? Yes.
>> >The ARCS PROM that SGI uses in its IRIX
>> >systems and on its discontinued 320 and 540 are elegant examples of what
>> >the BIOS could be on PCs. I think Macs could benefit from a similar
>> >implementation, which would eliminate the need to boot from a CD.
>>
>> Can you discuss or describe the ARCS PROM for us?
>Sure, but SGI can do it better than I.
<huge snip>
I'd hoped for a synopsis.
Heywood Mogroot
[blurgage snipped]
> OK, you've *almost* got a working sig happening here, Edwin. All you
> need to do now is add a carriage return (that's marked as the Enter key
> on your keyboard) to add a space between your name (it's Edwin,
> remember) and your sig which IIRC, the sig should be preceeded by a
> couple of "--" (without quote marks)
actually, "-- " (with the space).
=Heywood=
Josiah Fizer
>zolo <zolo...@excite.com> wrote in message news:<GnM6a.899$M85....@newsread2.prod.itd.earthlink.net>...
>> Heywood Mogroot wrote:
>> Back in 1998, SGI replaced the BIOS with its own much more elegant
>> ARCS PROM on the 320 and 540, and PeeCee types screamed bloody murder.
>> More proof that PeeCee lovers can't stand to abandon their legacy
>> technology, just like the PeeCee's sad dependence on floppy drives.
>
>to be fair, people who like x86 self-select for status-quo backward
>compatibility. God forbid they should ever lay out $1000 for a new CPU
>and then *have* to buy a new mouse or something.
>
new mouse, keyboard, layer 3 gigabit fiber switch, multi system KVM with on screen menus etc. Hell half that stuff can't be found without
requiring legacy ports.
>> Just out of curiosity, how many average PeeCees ship with none of the
>> following installed as standard?
>>
>> -DB9 serial ports
>> -PS/2 ports
>> -floppy drives
>> -parallel ports
>>
>> Ironic that PCs can be further ahead in memory/CPU/bridge speed and
>> lag behind in other areas. That's the problem with an architecture that
>> tries to be all things to all people.
>
>Or a strength, depending on how you look at it and your specific
>needs.
>
>Evolutionism is fine, my only problem with x86 is that the *entire*
>platform is still stuck in the 80's. Boot floppies are STILL a murky
>future possibility for advanced use.
>
The last several system I've had could boot off of anything, USB, firewire, SCSI, IDE etc. Last time I needed to update a BIOS on one I just
stuck in a USB to CF adaptor with a boatable 16meg CF card in it. Problem solved. I have a floppy drive because too many vendors still ship
software and drivers on the things.
>Itanium was a bold step in a better direction (like PPC was) but
>didn't have the CPU oomph over P4 to bridge the emulation gap (which
>PPC soon had over 68k).
>
Itanium sucked (still does). All it had was being 64bit, which to most people is useless. To the rest of us, guess we can just keep using
UltraSparcs.
>Microsoft of course has been quite happy with the shitty MBR and BIOS
>setting status quo, as it keeps the general public locked on Windows.
>(Interestingly, WinXP 64-bit systems support EFI and another
>partitioning scheme, GPT).
>
WinXP 32bit supports the same thing. Its not MS but the hardware vendors who keep screwing things up (look at ACPI).
>Wintel is moving, glacially, toward what Mac users enjoy now, but as
>always they've got a bit more to do:
>
>Get RID of the Super IO (floppy & serial port controller).
Can't use most networking equipment as they require a serial port for configuration. Great idea.
>EFI boot manager / GPT partitioning instead of MBR
Allready done.
>Gbit 802.3 & 1394b for high-speed storage/networking
Allready done it you want it.
>Bluetooth & 802.11g for other peripherals
>
Allready done if you want it.
>The next-generation PPC system has the potential to be the 2nd coming
>of the Mac II.
>
Slow, over priced, but in color? Hell I hope not.
>Here's hoping.
>
>=Heywood=
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Josiah Fizer
>
>"foo" <f...@foo.com> wrote in message
>news:hnmn5voa6nsffmfbq...@4ax.com...
>> On Tue, 25 Feb 2003 15:18:46 -0500, "zolo" <zolo...@excite.com>
>> wrote:
>>
>> >
>> >"foo" <f...@foo.com> wrote in message
>> >news:hi8n5v0o3bqbt2j1o...@4ax.com...
>> >> On Tue, 25 Feb 2003 15:57:26 GMT, zolo <zolo...@excite.com> wrote:
>> >>
>> >> >Heywood Mogroot wrote:
>> >> >> "When I started, I got senior managers together from across Intel
>and
>> >> >> asked them what would happen if we had a blank sheet of paper to
>> >> >> replace the BIOS," Doran said. "It turned into a three-day bitch
>> >> >> session." He said that the original designers of the IBM PC BIOS had
>> >> >> no idea that it would survive this long. "They thought that 250,000
>> >> >> machines would see it through to the end of its life," he said.
>> >> >>
>> >> >> http://news.com.com/2100-1001-985600.html
>> >> >>
>> >> >>
>> >> >> 'EFI' previewed at this year's IDC; welcome to the fucking 90's,
>> >> >> Craptel.
>> >> >>
>> >> >> =Heywood=
>> >> >
>> >> >
>> >> >
>> >> > Back in 1998, SGI replaced the BIOS with its own much more elegant
>> >> >ARCS PROM on the 320 and 540, and PeeCee types screamed bloody murder.
>> >> >More proof that PeeCee lovers can't stand to abandon their legacy
>> >> >technology, just like the PeeCee's sad dependence on floppy drives.
>> >> >
>> >> > Just out of curiosity, how many average PeeCees ship with none of
>the
>> >> >following installed as standard?
>> >> >
>> >> >-DB9 serial ports
>> >> >-PS/2 ports
>> >> >-floppy drives
>> >> >-parallel ports
>> >> >
>> >> > Ironic that PCs can be further ahead in memory/CPU/bridge speed and
>> >> >lag behind in other areas. That's the problem with an architecture
>that
>> >> >tries to be all things to all people.
>> >>
>> >> Why is being compatible with massive amounts of hardware "lagging
>> >> behind" in your worldview? Please tell me why I *wouldn't* want those
>> >> parts, assuming I don't buy new hardware requiring it but instead use
>> >> those ports for all of my old hardware that requires it?
>> >
>> >Because they use up IRQ resources
>>
>> So what? Why do you as a user care?
>
>
>When you use up available IRQs, things get ugly, and you get conflicts.
>Your spiffy new SCSI card, ATA RAID or Firewire card doesn't work. Joe
>Average User doesn't want to be confronted with IRQ conflict bullshit... He
>just wants the damn thing to work without having to wade through resource
>control panels. Why is that so difficult to understand?
>
Whats dificult to understand is that you think this is still a problem. Read up on ACPI, IRQ stearing, IRQ sharing and extended IRQ ranges.
If you have more then 32 PCI cards plugged into one system oods are you know how to deal with them. If not then you won't see any problems.
>>
>> >and cause conflicts with other add-in
>> >devices, for one.
>>
>> How so? What do you mean?
>
>
>I guess I have to hold your hand and walk you through this... Obviously
>you've never had to go through the annoying process of hunting down and
>resolving resource conflicts when, for example, you try to add some type of
>PCI expansion device (modem, NIC, etc.) that tries to grab an IRQ already in
>use by, say a serial port that's connected to a Wacom tablet or some other
>device. Maybe other IRQs are already being used by some other add-in like a
>Firewire card. It can take quite a while to get it all sorted out. It's a
>major annoyance, even for someone who is technically inclined. For a
>layperson, it's infuriating.
>
See above.
>>
>> > Easily enough resolved by PC/Windoze savvy types, but
>> >infuriating for the majority of laypeople who are confronted with cryptic
>> >Windows messages when they just want their new *whatever* to work..
>> >Resource conflicts/settings are one type of problem that newer
>technologies
>> >like USB were designed to address.
>>
>> Right - so everyone should drop all old buses - and all old hardware -
>> and go buy USB. Not!
>
>
> I'm not advocating that all legacy hardware should be dropped overnight,
>but come on- USB has been around for over 5 years now, longer than the
>useful life cycle of the average PC. There comes a time when things have to
>move forward. I don't see anyone complaining about the lack of ISA slots in
>new PCs. Most new printers have USB ports. I agree that getting a new PC
>shouldn't mean that you have to throw out a perfectly good parallel ported
>printer, but there are adapters that can take care of that, just like there
>are USB adapters for DB9 serial port devices. At some point, painful as it
>may be, it's out with the old and in with the new.
>
I have several ISA cards I wouldn't mind using in my new PC. If you've not heard people complaining its because you;ve chosen not to listen.
LPT and COM ports are also important to keep around. You cannot use a computer without a COM port to talk to Cisco, Sun etc equipment for
the first time. Most printers out there are parallel, they work so why replace them. Likewise many modems are external.
> I'm merely commenting that PCs seem to be such a compromise between
>cutting edge and legacy technology. Why is it that PC advocates always
>trumpet the superiority of their platform for having the latest technology
>like AGP 8X, but always defend the inclusion of legacy devices? Why is it
>that USB 2.0 is seen as such a big deal when Firewire, a demonstratably
>faster (or at least, equal) technology, has been around for years? Why is
>it that even though AGP 8X has no usable practical advantage at this point
>in time, it's an "essential feature," while gigabit Ethernet, which offers
>real performance benefits on gigabit networks, is "no big deal," and
>something that "just drives the cost up?"
>
Perhaps its because we don't throw out what works just for the sake of doing so? Why should I replace all my network hardware (needs COM
ports to configure) my printer and my KVM (has anyone made anything like the Apex Outlook series KVM for USB?) just bacause the ports they
use are old? It all works afterall.
> The Windroid answer, of course, is that new technology on a PC is always
>good, and new technology on a Mac is always unimportant. You can't have it
>both ways. Either the latest technology/highest specs are important, or
>they're not.
>
>
>-zolo
>
The problem I have with Apple is that they drop technology before their customers are ready.
Josiah Fizer
>In article <e38n5v0amfk3sd3u9...@4ax.com>, foo
><f...@foo.com> wrote:
>
>> On Tue, 25 Feb 2003 08:57:55 -0500, Seeker1 <see...@mac.com> wrote:
>>
>> >> 'EFI' previewed at this year's IDC; welcome to the fucking 90's,
>> >> Craptel.
>> >>
>> >> =Heywood=
>> >
>> >It always fascinates me that Win users interested in switching often ask
>> >questions like "where's the A: drive" and "where's the C: drive" ... as
>> >if it were somehow natural and rational to identify drives and/or
>> >partitions by letters instead of names.
>>
>> It's easily done and learned; what's the issue?
>>
>> >The weird thing is, the 2nd floppy disappeared in most Wintel machines
>> >very early on, yet B: continued to be reserved for it.
>> >
>> >Just one more legacy of that decision.
>> >
>> >It does amaze me what 95% of the world considers acceptable and normal.
>>
>> What should a floppy be called? Floppy1? How is that significantly
>> better than A? And the boot hard drive - should that be
>> BootHardDrive, or what? C: is easy and everyone knows you mean the
>> boot hard drive of the PC.
>
>Reminds me of the old story of the woman who cut the ends off her ham
>whenever she cooked it. Her daughter asked way and the woman told her
>that's the way it's always been done. Her mother did it and her
>grandmother did it.
>
>After a little prompting they called the grandmother in the nursing
>home and when asked that question, the old woman said, "Well, my pan
>just wasn't long enough so I always had to cut the ends of the ham
>off."
>
>C'mon ... "C:" is dumb. You should be able to call any drive
>whateverthehell you want. And with floppy drives going away, we'll be
>perpetuating an alphabet that bypasses A and B and begins with C.
>
>And "C" is dumb.
You can call a drive anything you want on a system using NTFS. You can also mount it at any location in the files system ala Unix. If you
don't like C: D: etc DON'T USE THEM!
Craig Koller
<jfi...@klassy.com> wrote:
[cut]
>
> You can call a drive anything you want on a system using NTFS. You can also
> mount it at any location in the files system ala Unix. If you
> don't like C: D: etc DON'T USE THEM!
>
"Can" and "do" are two different animals. You tell me when an
over-the-counter, or Dell or Gateway PC ships without lettered drives.
It's an archaic system that dates back to the stone age, and the
argument was about the pointlessness of using letter designations. Some
of your cohorts are strongly for it.
dc
wrote:
Which again brings us back to this: *IF* *YOU* don't like C: D: ...
Craig Koller
<d...@foo.bar> wrote:
No. No. No.
You don't get it. If you *DO* *LIKE* C: D: ... then you should be able
to add them. Not the other way around.
It's elitist to the Nth propellerhead degree to say that something is
"fine" simply because you can override it, when the *majority* of users
don't and won't and thus become resigned to the fact that that's "just
the way it is."
Next thing you know, it's part of the common vocabulary and you can't
get rid of it. There are some arguing that drive letters are the most
"logical" way, which is pure crap...
foo
Whatever. It's easy, it works, people know how to use it.