OS/2 2.0 (1993?) Windows 3.1 (1994) Windows 95 (1995) Windows NT 4.0 (1996) Windows 2000 (2000) Various Linux kernels and window managers (2001-2002) Windows 2000 (2002)
Windows 2000 "just works". BTW-- in my 4 years of running NT 4.0, I never had a single crash. Most stable OS I've ever used.
Interesting idea to integrate a Wiki with a version-control browser. I wouldn't want to use a Wiki as my editor however.
TWiki uses RCS as its backend. Thus if you use CVS for version control (which is based on RCS), modifying the Perl-based TWiki to talk with your CVS repository should be feasible.
Right on. Gosh darn those scientists and engineers for wanting to make a living and pay off those hundred thousand dollar student loans and have enough money left aside to convince a prospective wife to overlook his scientist-ic geekiness and marry him.
You are a fool if you got an engineering education and have that much debt. There are so many state schools that have fine engineering programs. And most M.S. and PhD students are supported and do not pay tuition. There is a big opportunity cost in pursuing a PhD, but not a direct cost.
Nope. The developers I'm talking about put out a top-selling game in 2004/2005 for the Xbox, PS2, and GameCube. They are now working on Xbox360 and PS3.
Got an Atari 400 when I was 5 or 6. Mostly a game machine, but included a "Basic" cartridge. Processor was 1.7MHz. Typed in long programs from some magazine and sometimes saved them out to the tape drive using standard audio cassette tapes.
Then came my Apple IIc with its speedy 1.4MHz processor.
Just as an example, from the other foot. The very first thing we did during the siege of Fallujah was take out the hospitals (the military viewed them as being sympathetic to the insurgents because they'd release civilian casualty figures, in addition to the obvious fact that they were rescuing wounded insurgents for medical care). We siezed the main hospital, bombed a smaller one flat, and shot up half a dozen ambulances.
Only because the militants used the hospital as their base. It wasn't taken out strategically to weaken the enemy.
So basically you get to drink a bottle of whiskey before building your computer. Does that sound like a good idea to anyone else?
My last computer build started at 3am after coming back from the bars completely hammered. I was completely wasted. In the morning, everything still worked except one case fan was backwards.
IBM cell based hardware running GNU/Linux is going to blow all of this trash into a distantly remembered nightmare.
You are seriously mistaken. The Cell is optimized for single-precision, floating-point workloads hand-coded to take advantage of the SPE units (which their "local memories" which is essentially just a programmer-managed cache). The Cell will be nothing special for typical integer workloads...in fact it will probably perform inferior to offerings from Intel and AMD. In fact any double-precision arithmatic is 10 times slower!!
Don't believe the IBM hype.
And do you really think that GNU/Linux applications will be re-coded to utilize the SPEs?! If so, you seriously underestimate the complexity of programming a heterogenous multiprocessor with programmer-managed memories.
The errata for the AMD Opteron is 85 pages long . I once spoke with a chipset designer and he told me that the Opteron errata was especially long with some convoluted workarounds, compared to other CPUs he's worked with.
Yes, 35mm is dying. But no digital camera can outperform my 4x5 large-format camera for the money. I get over 125 megapixels with a 2400dpi scan of a 4x5" peice of film. And this is with a cheap 2400dpi scanner. A 4000dpi drum scan blows everything away.
Do the math. 6-10 megapixel cameras can't make very large prints at 300dpi output. And some say that 300dpi isn't even good enough.
Moore's law doesn't apply to Bayer CMOS sensors either. And small sensors found in cheap digicams are diffraction-limited. You can't cheaply make a 4x5" sensor!
This leads me to believe that there will not be a decent, low-cost replacement for large format film in a LOONNG time.
First, Intel easily has the resources to integrate a memory controller on-chip if they wanted. It is fairly independent from the complex out-of-order pipeline (which is harder to change).
Second, SRAM cells only account for leakage power. This is becoming a bigger issue, but right now, SRAM leakage is not the primary heat issue.
Third, larger caches is not "overcompensating"!! Larger (L2) caches are nearly always a good thing because a cache miss causes a processor to sit idle for hundreds of cycles.
They'd have to because cache is their remedy for FSB memory latency issues. AMD has the better answer with the integrated memory controller.
Your integrated memory controller reduces DRAM latency, but it is NOT the answer to smaller caches!
And it isn't entirely clear that on-chip memory controllers are the way to go. For one thing, a northbridge allows the pin bandwidth to be used for both DRAM accesses and inter-chip sharing communication.
But Intel probably hasn't switched to on-chip memory controllers because of the uncertainty in DRAM markets and standards. Intel's volume is huge compared to AMD and by integrated an on-chip controller for a particular interface, they are placing a lot of eggs in one basket.
Intel's SRAM technology is pretty much an entire generation ahead of AMD's. Thus Intel can fit nearly twice as much cache into a given die area. Given this, its quite impressive that AMD's performance numbers are competitive (or better).
However you often don't see cache-sensitive benchmark numbers. SpecINT and SpecFP fit and the stuff you see on the./-type review sites (Tom's Hardware, etc) probably fit too. But give it something like TPC-C, does AMD's numbers lag here?
Slashdot Mirror
I've never had a blue-screen in XP.
I ran Windows NT 4.0 for 4 years, day in and day out, without a single crash or blue-screen.
Use good hardware with good drivers, and good configuration and Windows NT-based kernels are stable as a rock.
Which is why Windows XP is my device-driver platform, and Linux runs under VMWare.
Then I have access to raw hardware for games, the best drivers available, and Linux for some "serious work".
Its a simple matter of resolution. Typical photographic and typographic prints are 300+ dpi. A LCD screen is usually between 72-100 dpi.
This little contest is organized by one employee who works at the University of Wisconsin internal IT department (DoIT).
It is NOT sponsored by the University of Wisconsin. In fact it has nothing to do with acadamia or UW's top-10 Computer Science department.
Mine:
OS/2 2.0 (1993?)
Windows 3.1 (1994)
Windows 95 (1995)
Windows NT 4.0 (1996)
Windows 2000 (2000)
Various Linux kernels and window managers (2001-2002)
Windows 2000 (2002)
Windows 2000 "just works". BTW-- in my 4 years of running NT 4.0, I never had a single crash. Most stable OS I've ever used.
Who gives a rats ass about which OS you use? Its about the applications, not the OS.
Interesting idea to integrate a Wiki with a version-control browser. I wouldn't want to use a Wiki as my editor however.
TWiki uses RCS as its backend. Thus if you use CVS for version control (which is based on RCS), modifying the Perl-based TWiki to talk with your CVS repository should be feasible.
Right on. Gosh darn those scientists and engineers for wanting to make a living and pay off those hundred thousand dollar student loans and have enough money left aside to convince a prospective wife to overlook his scientist-ic geekiness and marry him.
You are a fool if you got an engineering education and have that much debt. There are so many state schools that have fine engineering programs. And most M.S. and PhD students are supported and do not pay tuition. There is a big opportunity cost in pursuing a PhD, but not a direct cost.
Nope. The developers I'm talking about put out a top-selling game in 2004/2005 for the Xbox, PS2, and GameCube. They are now working on Xbox360 and PS3.
Are you aware that the original XBox already has 720p HD output? Of course the PS2 and Gamecube do *not* have any HD.
Talk to game developers and many/most will say that Microsoft has better developer tools, documentation, and assistance.
Got an Atari 400 when I was 5 or 6. Mostly a game machine, but included a "Basic" cartridge. Processor was 1.7MHz. Typed in long programs from some magazine and sometimes saved them out to the tape drive using standard audio cassette tapes.
Then came my Apple IIc with its speedy 1.4MHz processor.
Just as an example, from the other foot. The very first thing we did during the siege of Fallujah was take out the hospitals (the military viewed them as being sympathetic to the insurgents because they'd release civilian casualty figures, in addition to the obvious fact that they were rescuing wounded insurgents for medical care). We siezed the main hospital, bombed a smaller one flat, and shot up half a dozen ambulances.
Only because the militants used the hospital as their base. It wasn't taken out strategically to weaken the enemy.
So basically you get to drink a bottle of whiskey before building your computer. Does that sound like a good idea to anyone else?
My last computer build started at 3am after coming back from the bars completely hammered. I was completely wasted. In the morning, everything still worked except one case fan was backwards.
IBM cell based hardware running GNU/Linux is going to blow all of this trash into a distantly remembered nightmare.
You are seriously mistaken. The Cell is optimized for single-precision, floating-point workloads hand-coded to take advantage of the SPE units (which their "local memories" which is essentially just a programmer-managed cache). The Cell will be nothing special for typical integer workloads...in fact it will probably perform inferior to offerings from Intel and AMD. In fact any double-precision arithmatic is 10 times slower!!
Don't believe the IBM hype.
And do you really think that GNU/Linux applications will be re-coded to utilize the SPEs?! If so, you seriously underestimate the complexity of programming a heterogenous multiprocessor with programmer-managed memories.
Would you feel comfortable at a game conference surrounded by scantily clad men flexing their muscles?
http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf
The errata for the AMD Opteron is 85 pages long . I once spoke with a chipset designer and he told me that the Opteron errata was especially long with some convoluted workarounds, compared to other CPUs he's worked with.
IMHO, Minolta makes the best light meters. Yes, these are still useful even for digital users.
Time to tear down the Statue of Liberty and melt it down for Cat5!
(Dear NSA: I'm only joking)
Yes, 35mm is dying. But no digital camera can outperform my 4x5 large-format camera for the money. I get over 125 megapixels with a 2400dpi scan of a 4x5" peice of film. And this is with a cheap 2400dpi scanner. A 4000dpi drum scan blows everything away.
Do the math. 6-10 megapixel cameras can't make very large prints at 300dpi output. And some say that 300dpi isn't even good enough.
Moore's law doesn't apply to Bayer CMOS sensors either. And small sensors found in cheap digicams are diffraction-limited. You can't cheaply make a 4x5" sensor!
This leads me to believe that there will not be a decent, low-cost replacement for large format film in a LOONNG time.
You speak like a true fanboy.
First, Intel easily has the resources to integrate a memory controller on-chip if they wanted. It is fairly independent from the complex out-of-order pipeline (which is harder to change).
Second, SRAM cells only account for leakage power. This is becoming a bigger issue, but right now, SRAM leakage is not the primary heat issue.
Third, larger caches is not "overcompensating"!! Larger (L2) caches are nearly always a good thing because a cache miss causes a processor to sit idle for hundreds of cycles.
Seriously, how many times have we heard this before?
Its a good way for Dell to increase their bargaining power with Intel. AMD's manufacturing capacity cannot currently fill much of Dell's volume.
They'd have to because cache is their remedy for FSB memory latency issues. AMD has the better answer with the integrated memory controller.
Your integrated memory controller reduces DRAM latency, but it is NOT the answer to smaller caches!
And it isn't entirely clear that on-chip memory controllers are the way to go. For one thing, a northbridge allows the pin bandwidth to be used for both DRAM accesses and inter-chip sharing communication.
But Intel probably hasn't switched to on-chip memory controllers because of the uncertainty in DRAM markets and standards. Intel's volume is huge compared to AMD and by integrated an on-chip controller for a particular interface, they are placing a lot of eggs in one basket.
Intel's SRAM technology is pretty much an entire generation ahead of AMD's. Thus Intel can fit nearly twice as much cache into a given die area. Given this, its quite impressive that AMD's performance numbers are competitive (or better).
./-type review sites (Tom's Hardware, etc) probably fit too. But give it something like TPC-C, does AMD's numbers lag here?
However you often don't see cache-sensitive benchmark numbers. SpecINT and SpecFP fit and the stuff you see on the