> Gee that's funny, I don't remember anything > in the PCI spec about having to have PROMs...;P
It is in the PCI spec. Search for IEEE 1275. PCI cards have a ROM header which can include sections for the traditional BIOS (x86 specific), IEEE1275, or something else. That PROM you are referring to which Sun requires is IEEE 1275.
> This is bad for two reasons. First, I hate it > when vendors screw with the PCI specs. It was > adopted as a spec for a reason, not so vendors > can then change it so it only works with their > HW. Just ask linux-kernel how much they love > broken PCI workarounds...
A PC can boot from a PCI card if it has a BIOS. That BIOS lives in a ROM on the PCI board, and contains real-mode x86 instructions. Now, how exactly could a Sparc CPU, or a PowerPC CPU, or any other CPU architecture, boot from an x86 BIOS? It cannot. To boot from a PCI device a Sparc machine requires an IEEE 1275 ROM to be present. 1275 is essentially a Forth interpreter, and defines enough of a bootstrap environment to access the I/O devices and fetch a file to boot from.
FCode was developed by Sun a long, long time ago, and is the underlying language for the "OpenBoot" environment. It actually later inspired a lot of things in Java, in that it is a CPU independant operating environment, but that would be a different/. thread. Sun offered OpenBoot to the IEEE for standardization. Later, the PCI SIG picked it up as an option in the PCI ROM header.
Current Macintoshes use OpenFirmware to boot, right? What do you think it is? Its FCode. PowerPC has the same problem: it needs bootable devices, and the x86 BIOS can't provide it.
> Reason 2 is that "plug and play" (a Micro$soft > term BTW) can be had for PCI without having > those PROMs on board.
Yes, and Sun machines are perfectly capable of using a PCI device which does not have a 1275 ROM. It simply cannot be used to boot the kernel. Some of Sun's own products (like their serial port expansion card) don't have this 1275 ROM, because it doesn't make sense to try to boot a kernel over the serial port.
> The reason Sun uses those PROMs is to get > licensing fees from hardware vendors to get > that "Sun Compatible" moniker. Creative revenue > generation no doubt, but it prevents PCI > interoperability, which is a Bad Thing.
Actually, vendors can incorporate an IEEE 1275 PROM into their product without paying a licensing fee to Sun. It is an open standard, and Sun makes the FCode tokenizer freely available.
The reason Sun uses these ROMs is to build bootable devices. It is the same reason Apple requires the 1275 ROM, and why SCSI cards for Macintoshes have to be flashed with a new ROM image. The flasher is replacing the x86 BIOS image with FCode. There really is no nefarious purpose, it simply stems from the fact that Sparc and PowerPC are not x86.
ST-II was an experimental protocol which implemented bandwidth controls for IP. It really evolved as a reaction to ATM, which was supposed to take over the world about 5 years ago. ST-II relied on keeping state at every router along the path. It didn't scale terribly well, and its failure modes (when one router along the path loses its state) could be difficult to deal with.
RSVP is an attempt to replicate this stateful bandwidth control model without having to modify the underlying IP protocols. It has many of the same problems, however, with maintaining a distributed state. RSVP did learn a number of lessons from ST-II, and can deal with partial failures (where some of the intervening hops lose their bandwidth information) much more cleanly. Still, RSVP is considered a pretty havyweight mechanism.
Differentiated Services is yet another Quality of Service effort at the IETF. DS takes the opposite tack. There is no global bandwidth reservation, everything is resolved hop by hop. That is, each network link in the path makes its best effort to meet the QoS defined for that packet. There are no guarantees, but it works well in practice. Its just like the IP protocol itself: there are no guarantees, but the Internet works pretty well in practice.
I gather they're being so aggressive about speculative execution that they're defining a whole bunch of new exceptions.
I.e. I speculatively executed a bunch of stores and didn't keep them in order, but when I got around to looking at the MMU page I found it was marked to not do PSO so now I throw it all away and start again, in order this time.
[[ Doh! hit return in Subject. Pop stack, try again. ]]
Well, after wading through the patent my brain hurts, and only one thing is clear.
Most modern processors implement a PSO mode, for Partial Store Ordering. That is, if you do a series of stores:
a = 1; b = 2; c = 3;
You would expect the processor to store things to the memory system in the order they were run. So the memory location corresponding to "a" should be set to 1 before the memory location corresponding to "b" is set to 2.
But that is slow, because you're serializing. Modern memory architectures are oriented around cache lines. A cache line is usually 16 to 64 bytes, depending on what kind of CPU it is. To modify a single byte the CPU must first read the entire cache line from RAM, then modify it, then write the whole cache line back. (Its actually a lot more complicated than this, I'm simplifying).
To make the stores happen exactly in order the CPU must issue the read for the cache line containing "a", wait for the result, merge the change, and then write the cache line back. Then it issues the read for the cache line containing "b"... and so on. Lots of dead time in the middle.
A faster scheme is to issue the read for the cache line containing "a", and continue. When the store to "b" is executed, issue the read for the cache line containing "b", even though "a" hasn't finished. This is generically called a "store buffer": it buffers up stores.
This is where things get interesting, especially if you are in a multiprocessor system. Lets say "b" is currently held in the cache of some other CPU in the system, while "a" is not. When your CPU issues a read for the cache line containing "a" it will have to go all the way to RAM, and might take a while to return. When your CPU issues a read for the cache line containing "b", it will get the answer right away because it is in a cache much closer to you.
Now you have a problem: you're ready to finish up the store to "b", but "a" isn't ready yet. What to do? That is what Partial Store Ordering means. You are allowed to complete the store to "b" before the store to "a" is finished.
In most cases, this is fine. Most of the time you don't care if stores complete out of order, and if its faster its better. There are two cases where you do care:
1. You're implementing a mutex lock 2. You're a device driver
A mutex is a data structure to protect some other data structure from simultaneous accesses by different CPUs. It is vital that the stores to the mutex be complete before you start modifying the data structure you wanted to protect. Most modern processors provide a special instruction specifically for mutexes, generally some sort of test-and-set. And generally processors which provide PSO provide a synchronization or barrier instruction so that you can force things to complete in a specific order.
Device drivers are more problematic. Lets say you have an exceptionally stupid disk controller which expects you to write 512 bytes to a buffer, and then command it to write the buffer to disk. Pseudo-code is:
for (i = 1; i 512; i++) buffer[i] = mydata[i];
command = WRITE_TO_DISK;
If the processor did the stores out of order, such that command is set to WRITE_TO_DISK before all of the buffer[i] locations are set, the result is disastrous: the disk controller will write corrupted data to the disk.
Again, this is handled in modern processors. Generally there is a bit in the MMU per page which enables PSO for that page. Pages which are mapping hardware devices will have PSO disabled.
This finally brings us to the topic of the patent. They provide a store buffer (presumably a LARGE store buffer) where they can speculatively execute instructions in advance. They can perform the instructions in whatever order they want, whatever is fastest. If when they get through with all that, they find that actually the memory they are looking at is marked as PSO-disabled... they throw everything in the store buffer away and do it again on a slower path that maintains ordering.
It is true that Field Programmable Gate Arrays are reconfigurable hardware. The classic Xilinx architecture (the first FPGA I know of to be commercially available) has a large number of small blocks of SRAM which drive logic gates at the periphery. By loading a bit pattern into the SRAM, you can make that block behave like any small block of logic you wish: an 8-1 mux, an adder, part of a barrel shifter, etc.
Xilinx parts can be reloaded "on the fly". You reset the part and tell it to reload, and it tristates its outputs and reconfigures itself according to the new code you supply. So for example, after identifying what sort of monitor is connected to your VGA port (640x480, 1024x768, 1280x1024), the FPGA on your framebuffer might reload itself with a wad optimized for that screen size. I know of a Mac video card from Radius about 5 years ago which worked like this.
The research projects you list take this a step further. After identifying what sort of task you want it to perform, the FPGA in your CPU would reload itself with a wad optmized for that function. So, for example, if it figured out you were doing lots of very large multiplies (because you're running an RSA key exchange), it could dump the floating point unit and reload that FPGA with a 512 bit exponentiator. Later when you start Quake it could dump the exponentiator and bring the floating point unit back. Still later when you start up your Finite Element Analysis package it could dump the single precision floating point unit which was fine for Quake, and bring in the slower but more accurate double precision FPU.
The transmeta patent doesn't describe anything of this nature. The patent describes a very sophisticated store buffer which can delay, commit, or discard a speculative instruction stream as needed. It isn't FPGA based, as far as I can see.
Actually, Netscape said a while back that they were relying on a feature of that old rev of Mercutio which was removed in the more recent versions, preventing them from simply copying in the most recent revision. They requested and received an update to that old version to fix the "freeing GHandle" problem, which is what would cause the crashes. So Netscape is not suffering from that particular cause of crash on the Macintosh, even though they are using an old version.
Things expected to be used more than a few months probably would be better made of petroleum plastic.
When it rains, my newspaper comes wrapped in a plastic bag secured with a rubber band. That bag could easily be made of biodegradable plastic (assuming the stuff is water resistant). The newspaper inside turns a uniform yellow after a few weeks in the sun, having it then get soaked because the plastic degraded wouldn't be a big deal, really.
I bet there are all kinds of highly disposable packaging material which would be fine for this stuff.
Yup, McNealy has always been pretty abrasive. But has anyone considered that McNealy's abrasiveness towards MS is deliberate?
5 years ago, Sun would always compare itself to other Unix workstation companies: DEC, HP, SGI. The rhetoric was probably the thickest where DEC was concerned. Sun then had about $1 billion in sales per year.
McNealy started taking aim at M$ when the hype for NT began. Always with a twisted barb at the ready, he tended to get quoted in the trade press. And what has been the effect? In ZD publications it isn't just "Sun" it is "Microsoft's arch-nemesis, Sun". Sun now has over $15 billion in sales per year.
Being portrayed as the only staunchly anti-Microsoft computer company has distinct advantages. It means you get invited to bid on lots of large server contracts, because you are seen as the only reasonable alternative platform. These are contracts that "Sun, workstation company" would never be invited to bid on, but "Sun, Microsoft arch-nemesis" does.
/. seems to love an opportunity to Sun-bash. At least three threads will spawn, regardless of the actual topic.
1. Sun hasn't released the source code to . Sun is EVIL! 2. Thin clients are a terrible way to run Quake. 3. Sun should abandon Slowlaris and run Linux on those 64 processor E10Ks! (note: calling it "Solaris" when comparing it to Linux is strictly verboten, it must be labelled "Slowlaris").
SunOS 4 (the BSD-derived OS) shipped with a K&R C compiler (i.e. not ANSI. No function prototypes). It lived in/bin/cc, and was used to link new kernels. People also had the bizarre idea that they should use it to compile software from the net, which is the main reason unprotoize scripts are still included in many GNU packages.
SunOS 5 (Solaris) never included a C compiler. The old/bin/cc only generated a.out format executables, not the ELF format Solaris uses, and was thus never included in Solaris. Sun included gcc on a number of demo CDs over the years.
Sun sells their professional compilers as separate products, called "SunPro" I believe.
Actually the 64 bit extension to PCI is part of the regular PCI spec. The fastest PCI bus is 64 bits wide running at 66 MHz. Some Wintel server machines implement this, as do many Sun SPARCstations. Other RISC workstations probably do too, I just don't keep up with them all.
You may be thinkng of PCI-X, which is an extension to PCI to up the clock rate to 133 MHz. PCI-X may require royalty payments, I'm not sure.
Intel intended to make NGIO an open spec. NGIO and FutureIO recently merged into a single proposal, and I'm not sure where they are going wrt licensing.
Re:Suggestions for corporate Intranet?
on
CNN On IPv6
·
· Score: 2
IPv4 and IPv6 can co-exist on the same subnet. In fact, they can co-exist on the same host. You can have a machine which has an IPv4 address and operates as an IPv4 machine, which simultaneously has an IPv6 address and operates as an IPv6 machine.
Every ethernet packet has an ethernet header. There is a two byte field in the ethernet header called the ethertype (also called the SAP in some terminology). The ethertype identfies what kind of packet it is. For example, IPv4 is ethertype 0x0800, which IPv6 is 0x86dd. Thus, you can happily mix IPv4 and v6 packets on an ethernet, your machines will look at the ethertype to figure out what to do with them. Likewise your routers can simultaneously handle IPv4 and IPv6 traffic. BTW, it isn't just ethernet. Every modern network type, including FDDI, ATM, Token Ring, PPP, etc has a two byte SAP field in its header. The only two network links I can remember which didn't are SLIP and Apollo Token Ring, and I'll wager you aren't using either of those.
Re:Every toaster on the internet?
on
CNN On IPv6
·
· Score: 2
Imagine this picture in 5 years:
I carry a digital cellular phone. Maybe it uses Voice over IP, or maybe it can just connect to the web to check my email. Either way, it needs its own IP address.
I carry a PDA, hopefully a descendant of my beloved Palm V. I carry it because my phone is a tiny little thing, making its screen so small that I'm willing to carry a separate PDA. My PDA can hotsync itself to my databases, which are on a server on the Internet of course. So my PDA needs an IP address.
My watch synchronizes itself to the atomic clock, using multicasted NTP packets. It also sets its alarm to tell me when its time to take my heart medication. It sets its alarm by checking my medical schedule, which is on a server on the Internet of course. So now we have three IP addresses on my body.
After my last heart attack (brought on by the stress of working 70 hour days in Silicon Valley back in 2003), the hospital gave me a monitor to affix to my ankle which monitors my blood pressure, hydration levels, etc. It collects its data and sends a packet to the hospital once per hour.
At my house, all five of my very expensive cars (the oldest being my old 1999 junker) have a mobile entertainment center which can pull in HDTV broadcasts, connect to whatever the WWW looks like in 2004, etc. So I have 5 more IP addresses.
And of course, the fax machine in my main vehicle is an aftermarket addon which doesn't cooperate with the car's built-in gigabit ethernet network, preferring to use its own wireless net connection. Another IP address.
These are all mobile connections. MobileIP doesn't work with NAT: you have to have a globally unique IP address for the remote proxy to route things to you.
NAT is useful to hook up the 27 computer systems I expect to have in my house by 2004.
Every car on the internet?
on
CNN On IPv6
·
· Score: 1
An engineer from GM attended one of the IPv6 design meetings at the IETF (a number of years ago). That is GM as in General Motors. He was making the case for a larger IP address space. Imagine, if you will, GM coming to the IETF every year for 10 million more IP addresses. Because GM is imagining it.
Actually, Citrix has made a lot of money selling ICA, where a central NT server runs all of the apps and remote displays them on PC desktops. M$ introduced the Windows Terminal Server to try to get some of that revenue back from Citrix. Sun isn't alone in pushing this stuff.
Sun acquired Wabi when it purchased a small company on the east coast (don't remember the name) in 1993. It got quite a bit of attention for a while, as Sun started a little crusade to document and standardize the Windows APIs (under the rubric of PWI, the Public Windows Initiative).
All of the developers who worked with Wabi were the employees of the little company Sun bought. Generally when a company is purchased the employees are issued options which vest over 4 years. You will note that they would have been fully vested in 1997. Flush with Sun options, the people who had worked on Wabi gradually left the company. On a product as complex as Wabi you can replace engineers if they leave one at a time, spaced far apart. If a group of them leave together (the day after their options for that year vest) it is nearly impossible the keep the product going.
Evan, I'm sorry you got burned when Wabi finally died. But there is an old saying:
Never ascribe to malice what can be adequately explained by incompetence.
Wabi became moribund a few years ago when Sun had so few people left who understood how it worked. Wabi was discontinued as an afterthought. I doubt anyone at Sun even knows where the workspaces with the final source code are, nor whether Sun owns the rights to every bit of code in it to be able to release its source. Over 6 years as a product lots of licenses for Wabi got negotiated, and all of them would have to be investigated to make sure Sun had the rights to all of the code. No one at Sun sat down and planned it out that Wabi had to be killed in favor of Java. No one at Sun has given a second thought to Wabi for several years. It was a mercy killing.
Wabi's big contribution to Wine was giving impetus to the Wine project. Somewhere around here I have my Prime Time Freeware CD-ROM set, where I first saw mention of Wine. It was in a directory named "wabi". I remember thinking it was pretty rude to try to get mileage out of Sun's product name like that. Rather ironic now.
If Sun started producing a JDK for Linux, a thread would start up on/. bitterly complaining that Sun was trying to kill off the free Java implementations. Sun just can't win in this forum.
Slashdot Mirror
> Gee that's funny, I don't remember anything ;P
/. thread. Sun offered OpenBoot to the IEEE for standardization. Later, the PCI SIG picked it up as an option in the PCI ROM header.
> in the PCI spec about having to have PROMs...
It is in the PCI spec. Search for IEEE 1275. PCI cards have a ROM header which can include sections for the traditional BIOS (x86 specific), IEEE1275, or something else. That PROM you are referring to which Sun requires is IEEE 1275.
> This is bad for two reasons. First, I hate it
> when vendors screw with the PCI specs. It was
> adopted as a spec for a reason, not so vendors
> can then change it so it only works with their
> HW. Just ask linux-kernel how much they love
> broken PCI workarounds...
A PC can boot from a PCI card if it has a BIOS. That BIOS lives in a ROM on the PCI board, and contains real-mode x86 instructions.
Now, how exactly could a Sparc CPU, or a PowerPC CPU, or any other CPU architecture, boot from an x86 BIOS? It cannot. To boot from a PCI device a Sparc machine requires an IEEE 1275 ROM to be present. 1275 is essentially a Forth interpreter, and defines enough of a bootstrap environment to access the I/O devices and fetch a file to boot from.
FCode was developed by Sun a long, long time ago, and is the underlying language for the "OpenBoot" environment. It actually later inspired a lot of things in Java, in that it is a CPU independant operating environment, but that would be a different
Current Macintoshes use OpenFirmware to boot, right? What do you think it is? Its FCode. PowerPC has the same problem: it needs bootable devices, and the x86 BIOS can't provide it.
> Reason 2 is that "plug and play" (a Micro$soft
> term BTW) can be had for PCI without having
> those PROMs on board.
Yes, and Sun machines are perfectly capable of using a PCI device which does not have a 1275 ROM. It simply cannot be used to boot the kernel. Some of Sun's own products (like their serial port expansion card) don't have this 1275 ROM, because it doesn't make sense to try to boot a kernel over the serial port.
> The reason Sun uses those PROMs is to get
> licensing fees from hardware vendors to get
> that "Sun Compatible" moniker. Creative revenue
> generation no doubt, but it prevents PCI
> interoperability, which is a Bad Thing.
Actually, vendors can incorporate an IEEE 1275 PROM into their product without paying a licensing fee to Sun. It is an open standard, and Sun makes the FCode tokenizer freely available.
The reason Sun uses these ROMs is to build bootable devices. It is the same reason Apple requires the 1275 ROM, and why SCSI cards for Macintoshes have to be flashed with a new ROM image. The flasher is replacing the x86 BIOS image with FCode. There really is no nefarious purpose, it simply stems from the fact that Sparc and PowerPC are not x86.
Do you mean to imply there are any worthwhile programming books other than K&R? Absurd.
ST-II was an experimental protocol which implemented bandwidth controls for IP. It really evolved as a reaction to ATM, which was supposed to take over the world about 5 years ago. ST-II relied on keeping state at every router along the path. It didn't scale terribly well, and its failure modes (when one router along the path loses its state) could be difficult to deal with.
RSVP is an attempt to replicate this stateful bandwidth control model without having to modify the underlying IP protocols. It has many of the same problems, however, with maintaining a distributed state. RSVP did learn a number of lessons from ST-II, and can deal with partial failures (where some of the intervening hops lose their bandwidth information) much more cleanly. Still, RSVP is considered a pretty havyweight mechanism.
Differentiated Services is yet another Quality of Service effort at the IETF. DS takes the opposite tack. There is no global bandwidth reservation, everything is resolved hop by hop. That is, each network link in the path makes its best effort to meet the QoS defined for that packet. There are no guarantees, but it works well in practice. Its just like the IP protocol itself: there are no guarantees, but the Internet works pretty well in practice.
Perhaps it is the realization that very little of what Sun does is aimed at Linux that really annoys the crowd here.
I gather they're being so aggressive about speculative execution that they're defining a whole bunch of new exceptions.
I.e. I speculatively executed a bunch of stores and didn't keep them in order, but when I got around to looking at the MMU page I found it was marked to not do PSO so now I throw it all away and start again, in order this time.
[[ Doh! hit return in Subject. Pop stack, try again. ]]
Well, after wading through the patent my brain hurts, and only one thing is clear.
Most modern processors implement a PSO mode, for Partial Store Ordering. That is, if you do a series of stores:
a = 1;
b = 2;
c = 3;
You would expect the processor to store things to the memory system in the order they were run. So the memory location corresponding to "a" should be set to 1 before the memory location corresponding to "b" is set to 2.
But that is slow, because you're serializing. Modern memory architectures are oriented around cache lines. A cache line is usually 16 to 64 bytes, depending on what kind of CPU it is. To modify a single byte the CPU must first read the entire cache line from RAM, then modify it, then write the whole cache line back. (Its actually a lot more complicated than this, I'm simplifying).
To make the stores happen exactly in order the CPU must issue the read for the cache line containing "a", wait for the result, merge the change, and then write the cache line back. Then it issues the read for the cache line containing "b"... and so on. Lots of dead time in the middle.
A faster scheme is to issue the read for the cache line containing "a", and continue. When the store to "b" is executed, issue the read for the cache line containing "b", even though "a" hasn't finished. This is generically called a "store buffer": it buffers up stores.
This is where things get interesting, especially if you are in a multiprocessor system. Lets say "b" is currently held in the cache of some other CPU in the system, while "a" is not. When your CPU issues a read for the cache line containing "a" it will have to go all the way to RAM, and might take a while to return. When your CPU issues a read for the cache line containing "b", it will get the answer right away because it is in a cache much closer to you.
Now you have a problem: you're ready to finish up the store to "b", but "a" isn't ready yet. What to do? That is what Partial Store Ordering means. You are allowed to complete the store to "b" before the store to "a" is finished.
In most cases, this is fine. Most of the time you don't care if stores complete out of order, and if its faster its better. There are two cases where you do care:
1. You're implementing a mutex lock
2. You're a device driver
A mutex is a data structure to protect some other data structure from simultaneous accesses by different CPUs. It is vital that the stores to the mutex be complete before you start modifying the data structure you wanted to protect. Most modern processors provide a special instruction specifically for mutexes, generally some sort of test-and-set. And generally processors which provide PSO provide a synchronization or barrier instruction so that you can force things to complete in a specific order.
Device drivers are more problematic. Lets say you have an exceptionally stupid disk controller which expects you to write 512 bytes to a buffer, and then command it to write the buffer to disk. Pseudo-code is:
for (i = 1; i 512; i++)
buffer[i] = mydata[i];
command = WRITE_TO_DISK;
If the processor did the stores out of order, such that command is set to WRITE_TO_DISK before all of the buffer[i] locations are set, the result is disastrous: the disk controller will write corrupted data to the disk.
Again, this is handled in modern processors. Generally there is a bit in the MMU per page which enables PSO for that page. Pages which are mapping hardware devices will have PSO disabled.
This finally brings us to the topic of the patent. They provide a store buffer (presumably a LARGE store buffer) where they can speculatively execute instructions in advance. They can perform the instructions in whatever order they want, whatever is fastest. If when they get through with all that, they find that actually the memory they are looking at is marked as PSO-disabled... they throw everything in the store buffer away and do it again on a slower path that maintains ordering.
Ok. My brain hurts now.
No, I don't think so.
It is true that Field Programmable Gate Arrays are reconfigurable hardware. The classic Xilinx architecture (the first FPGA I know of to be commercially available) has a large number of small blocks of SRAM which drive logic gates at the periphery. By loading a bit pattern into the SRAM, you can make that block behave like any small block of logic you wish: an 8-1 mux, an adder, part of a barrel shifter, etc.
Xilinx parts can be reloaded "on the fly". You reset the part and tell it to reload, and it tristates its outputs and reconfigures itself according to the new code you supply. So for example, after identifying what sort of monitor is connected to your VGA port (640x480, 1024x768, 1280x1024), the FPGA on your framebuffer might reload itself with a wad optimized for that screen size. I know of a Mac video card from Radius about 5 years ago which worked like this.
The research projects you list take this a step further. After identifying what sort of task you want it to perform, the FPGA in your CPU would reload itself with a wad optmized for that function. So, for example, if it figured out you were doing lots of very large multiplies (because you're running an RSA key exchange), it could dump the floating point unit and reload that FPGA with a 512 bit exponentiator. Later when you start Quake it could dump the exponentiator and bring the floating point unit back. Still later when you start up your Finite Element Analysis package it could dump the single precision floating point unit which was fine for Quake, and bring in the slower but more accurate double precision FPU.
The transmeta patent doesn't describe anything of this nature. The patent describes a very sophisticated store buffer which can delay, commit, or discard a speculative instruction stream as needed. It isn't FPGA based, as far as I can see.
Actually, Netscape said a while back that they were relying on a feature of that old rev of Mercutio which was removed in the more recent versions, preventing them from simply copying in the most recent revision.
They requested and received an update to that old version to fix the "freeing GHandle" problem, which is what would cause the crashes. So Netscape is not suffering from that particular cause of crash on the Macintosh, even though they are using an old version.
Yes, you are.
Things expected to be used more than a few months probably would be better made of petroleum plastic.
When it rains, my newspaper comes wrapped in a plastic bag secured with a rubber band. That bag could easily be made of biodegradable plastic (assuming the stuff is water resistant). The newspaper inside turns a uniform yellow after a few weeks in the sun, having it then get soaked because the plastic degraded wouldn't be a big deal, really.
I bet there are all kinds of highly disposable packaging material which would be fine for this stuff.
useradd(1) -- replaced by convert(1) and/or baptize(1)
su(1) -- replaced by deify(1)
init replaced by creation
rc files will be reorganized from rc1.d to rc7.d. rc7.d must be empty, as no work may be performed at that run level.
apache -- the heathen web server is replaced by pilgrim
Heh. I remember when Telebit Trailblazers were the greatest thing because they would spoof uucp.
Yup, McNealy has always been pretty abrasive. But has anyone considered that McNealy's abrasiveness towards MS is deliberate?
5 years ago, Sun would always compare itself to other Unix workstation companies: DEC, HP, SGI. The rhetoric was probably the thickest where DEC was concerned.
Sun then had about $1 billion in sales per year.
McNealy started taking aim at M$ when the hype for NT began. Always with a twisted barb at the ready, he tended to get quoted in the trade press. And what has been the effect? In ZD publications it isn't just "Sun" it is "Microsoft's arch-nemesis, Sun".
Sun now has over $15 billion in sales per year.
Being portrayed as the only staunchly anti-Microsoft computer company has distinct advantages. It means you get invited to bid on lots of large server contracts, because you are seen as the only reasonable alternative platform. These are contracts that "Sun, workstation company" would never be invited to bid on, but "Sun, Microsoft arch-nemesis" does.
1. Sun hasn't released the source code to
. Sun is EVIL!
2. Thin clients are a terrible way to run Quake.
3. Sun should abandon Slowlaris and run Linux on
those 64 processor E10Ks! (note: calling it
"Solaris" when comparing it to Linux is
strictly verboten, it must be labelled
"Slowlaris").
SunOS 4 (the BSD-derived OS) shipped with a K&R C compiler (i.e. not ANSI. No function prototypes). It lived in /bin/cc, and was used to link new kernels. People also had the bizarre idea that they should use it to compile software from the net, which is the main reason unprotoize scripts are still included in many GNU packages.
/bin/cc only generated a.out format executables, not the ELF format Solaris uses, and was thus never included in Solaris. Sun included gcc on a number of demo CDs over the years.
SunOS 5 (Solaris) never included a C compiler.
The old
Sun sells their professional compilers as separate products, called "SunPro" I believe.
Actually the 64 bit extension to PCI is part of the regular PCI spec. The fastest PCI bus is 64 bits wide running at 66 MHz. Some Wintel server machines implement this, as do many Sun SPARCstations. Other RISC workstations probably do too, I just don't keep up with them all.
You may be thinkng of PCI-X, which is an extension to PCI to up the clock rate to 133 MHz. PCI-X may require royalty payments, I'm not sure.
Intel intended to make NGIO an open spec. NGIO and FutureIO recently merged into a single proposal, and I'm not sure where they are going wrt licensing.
IPv4 and IPv6 can co-exist on the same subnet. In fact, they can co-exist on the same host. You can have a machine which has an IPv4 address and operates as an IPv4 machine, which simultaneously has an IPv6 address and operates as an IPv6 machine.
Every ethernet packet has an ethernet header. There is a two byte field in the ethernet header called the ethertype (also called the SAP in some terminology). The ethertype identfies what kind of packet it is. For example, IPv4 is ethertype 0x0800, which IPv6 is 0x86dd. Thus, you can happily mix IPv4 and v6 packets on an ethernet, your machines will look at the ethertype to figure out what to do with them. Likewise your routers can simultaneously handle IPv4 and IPv6 traffic.
BTW, it isn't just ethernet. Every modern network type, including FDDI, ATM, Token Ring, PPP, etc has a two byte SAP field in its header. The only two network links I can remember which didn't are SLIP and Apollo Token Ring, and I'll wager you aren't using either of those.
Imagine this picture in 5 years:
I carry a digital cellular phone. Maybe it uses Voice over IP, or maybe it can just connect to the web to check my email. Either way, it needs its own IP address.
I carry a PDA, hopefully a descendant of my beloved Palm V. I carry it because my phone is a tiny little thing, making its screen so small that I'm willing to carry a separate PDA. My PDA can hotsync itself to my databases, which are on a server on the Internet of course. So my PDA needs an IP address.
My watch synchronizes itself to the atomic clock, using multicasted NTP packets. It also sets its alarm to tell me when its time to take my heart medication. It sets its alarm by checking my medical schedule, which is on a server on the Internet of course. So now we have three IP addresses on my body.
After my last heart attack (brought on by the stress of working 70 hour days in Silicon Valley back in 2003), the hospital gave me a monitor to affix to my ankle which monitors my blood pressure, hydration levels, etc. It collects its data and sends a packet to the hospital once per hour.
At my house, all five of my very expensive cars (the oldest being my old 1999 junker) have a mobile entertainment center which can pull in HDTV broadcasts, connect to whatever the WWW looks like in 2004, etc. So I have 5 more IP addresses.
And of course, the fax machine in my main vehicle is an aftermarket addon which doesn't cooperate with the car's built-in gigabit ethernet network, preferring to use its own wireless net connection. Another IP address.
These are all mobile connections. MobileIP doesn't work with NAT: you have to have a globally unique IP address for the remote proxy to route things to you.
NAT is useful to hook up the 27 computer systems I expect to have in my house by 2004.
An engineer from GM attended one of the IPv6 design meetings at the IETF (a number of years ago). That is GM as in General Motors. He was making the case for a larger IP address space.
Imagine, if you will, GM coming to the IETF every year for 10 million more IP addresses. Because GM is imagining it.
Actually, Citrix has made a lot of money selling ICA, where a central NT server runs all of the apps and remote displays them on PC desktops. M$ introduced the Windows Terminal Server to try to get some of that revenue back from Citrix.
Sun isn't alone in pushing this stuff.
The SunRay is aimed at corporate markets. Not being able to run games is considered a major plus by IT departments.
Yep, and now you know the real reason Bill Gates invested in Teledesic (a satellite communications company):
He needed to call in orbital strikes.
Sun acquired Wabi when it purchased a small company on the east coast (don't remember the name) in 1993. It got quite a bit of attention for a while, as Sun started a little crusade to document and standardize the Windows APIs (under the rubric of PWI, the Public Windows Initiative).
All of the developers who worked with Wabi were the employees of the little company Sun bought. Generally when a company is purchased the employees are issued options which vest over 4 years. You will note that they would have been fully vested in 1997. Flush with Sun options, the people who had worked on Wabi gradually left the company. On a product as complex as Wabi you can replace engineers if they leave one at a time, spaced far apart. If a group of them leave together (the day after their options for that year vest) it is nearly impossible the keep the product going.
Evan, I'm sorry you got burned when Wabi finally died. But there is an old saying:
Never ascribe to malice what can be adequately explained by incompetence.
Wabi became moribund a few years ago when Sun had so few people left who understood how it worked. Wabi was discontinued as an afterthought. I doubt anyone at Sun even knows where the workspaces with the final source code are, nor whether Sun owns the rights to every bit of code in it to be able to release its source. Over 6 years as a product lots of licenses for Wabi got negotiated, and all of them would have to be investigated to make sure Sun had the rights to all of the code.
No one at Sun sat down and planned it out that Wabi had to be killed in favor of Java. No one at Sun has given a second thought to Wabi for several years. It was a mercy killing.
Wabi's big contribution to Wine was giving impetus to the Wine project. Somewhere around here I have my Prime Time Freeware CD-ROM set, where I first saw mention of Wine. It was in a directory named "wabi". I remember thinking it was pretty rude to try to get mileage out of Sun's product name like that. Rather ironic now.
If Sun started producing a JDK for Linux, a thread would start up on /. bitterly complaining that Sun was trying to kill off the free Java implementations. Sun just can't win in this forum.