Mario Lombardo wrote:
>
> Yes, I do have another machine (386 and 486) I could load an x86 version
> of Linux, then setup a network card, get on the net and surf to get the
> Sun images, and set up a tftp server to boot this machine, etc., but I
> think it would be easier if somebody knew of a tftp repository
> somewhere. If there isn't one, I'd like to start one.
>
> I'm the one being dense here, so here it goes:
> I feel with all the newer intelligent x86 BIOSes, such as rebuilding
> BIOS' flash via a floppy drive during a catastophic event, issuing a
> bootp request when all local boots fail, and other such nifty things
> these *Intel based* machines can do, I feel by now there should at least
> be somewhere somebody can get a Linux machine started w/o the need of an
> archaic floppy drive or an expensive and bulky CD-ROM drive. Like I was
> saying, 'I'm the one being dense here.'
>
> I'm sure most people will agree. The Internet is here to stay. Floppy
> drives are going the way of the mad cow, and CD-ROMs are just too much
> when it comes to filling the need for a quick two or three megabytes of
> intelligence to get things started. Suns have been able to take care of
> themselves with their kick-butt Boot PROMs long before PC BIOSes. I
> think with PCs now being able to do the same, I thought something would
> be out there. Perhaps it's wishful thinking.
I understand. I think you're just blinded a bit by how smart Sun-class
hardware is. :)
A PC BIOS in general can't boot over the network. Nobody cares because
you can't load Windows over the network so nobody is going to put any
effort into that. Plus the idea is that a PC motherboard is CHEAP and
nobody wants to build a little miniOS into the BIOS that has smarts
enough to run diags and do network booting and all that sort of thing
like Sun boot monitors can do.
A lot of network cards nowadays have the ability to do netboot stuff
right on the card without needing the EPROM that used to be required.
(Which was never standard because, again, you can't boot Windows over
the network so nobody wanted to pay the extra few bucks to have the
netboot EPROM on their network cards.) When you find a motherboard
nowadays that claims to have the "BOOT FROM NETWORK" option in BIOS,
it's relying on you having a card that supports this behaviour, or has
one of those chipsets built in. The BIOS itself could care less for the
most part.
Recently Intel (along with some of the Free OS camp, FreeBSD and Linux
guys, if I understand the story correctly) has kind of pushed through a
new netboot protocol called PXE that allows a network card to have
enough intelligence to really boot over the network without needing all
the overhead of what historically lived on the EPROM. i.e. it's
basically just a very lightweight BOOTP or DHCP stack built into the
network card with the ability to load a kernel into system RAM and boot
it. (Possibly one of the big prerequisites for this being able to
happen is the PCI bus, with its better memory bus, as opposed to the old
ISA bus which would have serious problems trying to do DMA into modern
systems with more than 16MB of RAM to copy that kernel image into the
right place in memory for booting. But I don't really know - that's
just educated guesswork.)
It's only been in the last couple of years that you could really get a
network card that could do - almost - the sort of thing Sun machines
have been able to do for years and years from their boot monitor. I'm
sure there are many out there now, but I've only personally seen Intel
and 3Com cards with "modern" network boot functionality on them.
So there's never been an impetus for being able to do this sort of thing
with PCs, and you're unlikely to find any public bootp/tftp servers out
there.
The other, and maybe bigger, issue is that, at least as far as Linux or
FreeBSD or the other free OS's out there, you'll need to have a kernel
pretty much built specifically for the hardware you're running or it may
not be able to boot correctly. The Linux and *BSD distros get around
this by building a very lowest-common-denominator kernel for their
install CDs and then including every possible option as a
run-time-loadable module. However, I don't think ANY of the free OS's
have the ability to do run-time-loading of modules via tftp - it has to
be on a local media, so right there you get stuck with either not being
able to boot the kernel you've loaded, or not having support for all
your hardware, or having a massive kernel with every possible option
built in which is more likely to cause problems than actually work
properly.
That's one of the biggest advantages with companies like Sun and Apple -
they own the hardware platform as well as the OS development, so they
can very strictly control the hardware so they know exactly what's
required to make the OS work. In PC land, it's very different and
you're not likely to find, or make, any public server that would allow
netbooting that would be of any use to anyone other than the person who
made it.
I would recommend just building out one of your machines to act as your
local repository and make it available to the rest of the world if you'd
like, but I don't know that it's going to be of much use to anyone but
you.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
http://www.eff.org/ http://www.anti-dmca.org/
http://www.sciencemag.org/cgi/content/full/293/5537/2028
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:53:52 EDT