The only absolutely essential addon for me is NoScript. Everything else is gravy; tasty gravy perhaps, but gravy. HTTPSEverywhere is really high on the gravy list.
Slashdot videos: Now with more Slashdot!
At least one HP Proliant dual Pentium (Pentium I) had EISA. Some DEC AlphaServers had EISA.
Megahertz. We have dishes here that can receive that band, although our two 26 meter dishes (almost as old as the TIROS dish) are equipped as an interferometer on 2.4GHz and 8.5GHz.
I need submillisecond time here (where here is a radio astronomy observatory), with no discontinuities like an SNTP client will insert (stepping time is not 'accurate'). That's why I have three stratum 1 local NTP servers that use Agilent Z3816A GPS-disciplined clocks.
SNTP != NTP and is totally unsuited for any use that cares about real continuous, accurate, time. Read the 'time-nuts' mailing list at febo to see what real accuracy is.
I run three local (private) GPS-synced stratum 1 NTPD instances here. Stratum 1 is hard to get right, as hard as getting security right.
I've done the turkey smoking for eight years, now, and wouldn't have it any other way. I use a Chargriller 2121-style barrel grill; the bird goes on one end over a drip pan, and the fire goes on the other end. I start the fire in a chimney starter at 4:45AM; the coals go on the grill at 5:15AM along with pre-soaked apple, cherry, and pecan chips/chunks; damper to low, exhaust full closed; bird goes on the grill when the temp gets down to 225F (typically about 5:50AM). Keep the coals stoked and the temp at or around 225F until thigh joint is at 170F and the breast is at 165 (an 18 pound bird will take 6 to 6.5 hours at 225F). Cover with a tent of aluminum foil once the skin is the desired color, and keep the cavity full of liquid of your choice (I use a mix of one part Vernor's, one part white grape juice, and one part apple juice).
A 6 hour cook time gives a 12:30-1:00PM carving time (the meat absolutely must rest at least 15 minutes before carving, preferably breast down).
Heh, all of Intercal is strange.... but COMEFROM is just.... elegant.
It's been implemented for Python, of all things.....
Hmm, the transcript says 'Nortel' but it's actually 'Nautel'. They make good transmitters, and have for a very long time.
One of the problems with increasing clock speed is gate capacitance and the RC time constant charging curve causing the switching FETs to operate in the linear region, causing power dissipation to go up with clock speed. This is why a decrease in process size has typically yielded a corresponding decrease in power dissipation at a given clock speed.
If you make the capacitance smaller, you can increase the switching speed (capacitance would decrease with the square of the feature size (gate capacitance is dependent upon gate area), wheras resistance would increase linearly, inversely proportional to feature width, assuming the feature depth doesn't change (resistance dependent upon cross-sectional area)).
Another poster has already mentioned asynchronous designs, so I'll pass on that particular nuance.
But clock propagation is a serious issue, and I can see a vacuum transistor improving this considerably.
Now, figuring out how far a wavefront will propagate in some period of time isn't too hard.
Undoped silicon has a relative permittivity of 11.68; the reciprocal of the square root of the relative permittivity is the velocity factor of a particular dielectric; for undoped silicon that's about 30% of c. Silicon dioxide, as used for most of the insulation on the typical MOSFET design, has a relative permittivity of 3.9 and thus a VF of about 51%. On a stripline laid on silicon dioxide (silica glass) the velocity of propagation is about 153 million meters per second, or 153 meters per microsecond or 153 millimeters per nanosecond or 153 microns per picosecond. 153 microns is a bit larger than the cladding on a typical fiber optic strand (most have a cladding diameter of 125 microns; OM1 multimode is 62.5 micron core/125 micron cladding, OM4 is 50 micron core/125 micron cladding, and single-mode is 8 micron core/125 micron cladding, for comparison). That's best case propagation time.
Now, to see how this translates to something of today, at least one of the models of the latest Haswell-DT Core i7 chips has a die size of 177 square millimeters. The chip is not square, and seems to be about a 4:1 rectangle in photos, which would yield about a 6.5 mm by 27.25mm die (yes, I know that gives 177.125 square millimeters; close enough).
Now, if a clock signal needs to go straight across the narrow portion, it will take about 42.5 picoseconds to do so, assuming transmission across silion dioxide alone. Propagation in the long direction would take about 178 picoseconds to do so, with the same assumption. The published top speed of this processor is at the time of this writing about 4.5GHz (I know it's a bit higher, but that's a moving target). This is a 222 picosecond clock period; easily doable in the short dimension, a bit more difficult in the long dimension, and probably already requiring some asynchronous elements and delay compensation. If you limit solely on clock propagation time, and are able to work in a slip of a full clock cycle, the long dimension will give you a limit of a bit over 5.5GHz; the short dimension will similarly give you a limit of 23.5GHz.
That's drastically oversimplified; each gate has it's own propagation delay that must be figured, and there are four cores (which makes it pretty understandable why the chip would have a 4:1 die dimension ratio, no?). A 20% clock delay factor will allow, with care, a good chance for synchronous operation (42.5 is pretty close to 20% of 222), but that's assuming straight clock traces (and they are not just straight across the chip).
Food for thought.
Heh. In intercal, the "Hellow World" debugs you.
Hmmm... Windows is over 20 years old, yes? So is Unix, no? Mice, keyboards, VGA, USB, Dynamic RAM? LCDs?
What about C? Or x86 assembly code (with extension in the _64 variant)?
The ATA disk drive standard?
And what about TCP/IP, even IPv6 is nearly that old, no?
I seem to recall from my BIOS writing days with CP/M, that the 8" drives had twice the data rate of the 5" drives. They also spun faster, 360 RPM vs 300 RPM. The 8" IBM format was soft sectored 26 sectors of 128 bytes, and the 5" used 16 sectors of 128 bytes or something like that. too many numbers to remember.
Right, for the 360K double-density 5.25.
Like the 8 inch System/34 format, the 5.25 high-density drive in the PC AT also ran at 360 RPM instead of 300, and had double the data rate of the double-density 5.25 inch drives, yielding exactly the same number of sectors per track, with the only difference being that the 8 inch has 77 tracks and the 5.25 HD drive has 80.
By the time double-sided drives came out the FM-encoded IBM 3740 format had been pretty much superceded by the System/34 MFM format.
50 pin Shugart would be the most useful, unless you really really need DEC RX01 or RX02.