“Brillo, pompous ass and troll wrote…”

You and Koz seem to rely on character attacks and ad hominem rather than facts and rational discussion. Why not just say “you’re wrong because you’re fat” since it’s about the same caliber of argument you seem to used to delivering.

Likewise, using “M$” and saying “the other OS” is incredibly petty. Notice how I don’t call it “LinSux” or something equally childish? That’s because I argue on merit, without having to resort to baseless mudslinging and villification.

Here’s an anecdote for you; Nobody uses Windows 98 anymore. I’ll refer again to the wikipedia data:

http://en.wikipedia.org/wiki/Usage_share_of_operating_systems

Oh look “Other Windows” has virtually the same usage stats on Wikipedia as desktop linux does! Keep in mind, this includes 95, 98, 2000, and ME as well.

Finally, if you actually bothered to research the TCP/IP stack, you’d know that Microsoft licensed Spider to add TCP/IP to NT; Spider was used under the BSD license. By NT3.5 they’d rewritten the stack so that it didn’t rely on the Streams architecture that Spider did, reducing the overhead of needing to simulate a Streams environment. Spider used elements of the BSD TCP stack for checksums which remained in the NT rewrite. The NT3.5 stack was used in Windows 95.

I’d really like to know if you were using TCP or some other protocol Windows supported like NetBEUI.

http://en.wikipedia.org/wiki/NetBIOS#NetBEUI

True, but I still highly doubt your understanding of the implication of that beyond the first layers of the OSI model.

Believe it or not at one of the largest school divisions where I worked the head IT guy, an MSCE, (not I) used a staple gun to affix surface-mounted Cat-5 in a computer lab.

I don’t think an MCSE in or of itself qualifies you in anyway to handle indoor electricial wiring. In fact, DIY wiring like this can even get you into troble in some countries. Of course, with that aside, knowing what you are actually using is also an important part of the equation.

In the school system I designed, Cat-6 was used and properly mounted in conduit and cable-trays.

But obviously not in that particular school where the IT personnel decided to work around “network chatters” with more servers.

Got any more apples-to-oranges comparisons to throw at your detractors?

No, but it was necessary and very useful in 1973 when I built my detector.

I am glad that you finally admit all that guff is essentially irrelevant to the discussion. Moving on…

I taught hundreds of students how to terminate cables

So you taught hundreds of students how to (dubiously) use a cable crimp. More power to you, I guess?

I tested them. GNU/Linux had three times the throughput of Lose 98 on those cables because Lose ’98 still used M$’s own TCP/IP stack…

As TR points out, that’s pure anecdote, and this is to set aside the obvious fact that all this discussion on an ancient OS almost nobody uses these days is entirely irrelevant to the subject matter at hand.

Both M$ and GNU/Linux eventually used the BSD stack or modified it to suit but Lose ’98 did not use the BSD stack.

So, in a nutshell, you are invaliding your own argument by claiming that now every operating system uses the same network stack.

Well played, PR! Well played!

Well, most participants in that discussion seem to have been almost as knowledgable as you However, the Point about “not more than 25-30″ was in regard to managing that without a central Server – just changing passwords on 30 machines for each user isn’t really fun.

However, if you really wanted to max out your LAN, way back then the ticket was NFS. Before NFS 4, it was a stateless protocol – for file-sharing!? Our LAN guys loved it

If you don’t like anecdotes, go elsewhere or research the history of the TCP/IP stack. Both M$ and GNU/Linux eventually used the BSD stack or modified it to suit but Lose ’98 did not use the BSD stack. Slow networking was a characteristic of both that other OS and MacOS in school labs about that time. M$ imported BSD stuff and Apple switched to BSD UNIX OS and got the stack that way. GNU/Linux used the BSD stack much earlier.

Just for fun, read this discussion of Lose ’98 from the good old days. Note the part about maxing out the LAN with 10-30 users.

Even if that was actually true: Why didn’t you use NetBEUI for the Win98 machines?

Sounds like a very scientific test. What’d you do? Copy a file in a bash terminal and try to do the same thing in the command prompt on Windows? Can you show us the actual numbers of your tests?

No? Well I guess this is just more anecdotal evidence then.

No, but it was necessary and very useful in 1973 when I built my detector. No off-the-shelf unit would fit my custom-built detector which needed a preamp right on the wire, not nearby. The idea is that the detector produces a small charge on what is essentially a capacitor, the wire. Adding capacitance to the wire by leading the signal to a distant pre-amp lowers the voltage of the signal and thus the signal to noise ratio. Nuclear physics labs are electronically noisy places with all the usual 60Hz stuff as well as high voltage and RF power supplies nearby. It is vital to produce a signal large enough that it’s timing is minimally affected by noise. We had suitable pre-amps for other kinds of detectors but mine was the first of its kind in Canada in those days. CERN still does it that way because they have many thousands of wires and each must have its own preamp in confined spaces. e.g.
“includes on-detector and off-detector electronics, encompassing five different types of custom circuit boards designed to handle the high event rate at the LHC. The on-detector electronics includes Cathode Front End Boards (CFEB) [R. Breedon, et al., Nucl. Instr. and Meth. A 471 (2001) 340], which amplify, shape, store, and digitize chamber cathode signals; “

see http://www.sciencedirect.com/science/article/pii/S0168900208021153

There just isn’t any practical way to produce a product that fits in the confined space of a particle detector that’s a separate unit. You build the detector to fit the physics and preamps and such need to be part of it. My little “proof of principle” prototype had only 5 wires. CERN has tens of thousands in confined spaces. I used a few discrete components and a transistor. The important features were protection from kilovolt spikes, small size, amplification before putting the signal on cables in a noisy environment (RF, high-current spikes and high-voltage leakage). The system worked beautifully giving position and particle identification for a tiny investment. I built all the hardware in a few hours in the machine-shop and at my desk. Of course it took a year to design, a year to test and a year to write the thesis, but those were some of the best years of my life.

Google has something about that thesis. I wonder if they have scanned it…

Wikipedia does not have much information about the technology. Perhaps I should dig up my copy of the thesis and put it online. Some of the technology can be seen here (1969 onward). I was quite privileged to work on technology only seven years old in concept for a Master’s degree. Normally state of the art is restricted to PhD projects.

It’s stuff like this that messes up what you, a layman, think is perfectly done wiring.”

Silly. You get a discontinuity/reflection in the transmission line even if you do not cut the cable. Believe it or not at one of the largest school divisions where I worked the head IT guy, an MSCE, (not I) used a staple gun to affix surface-mounted Cat-5 in a computer lab. In the school system I designed, Cat-6 was used and properly mounted in conduit and cable-trays. Cat-6 jacks were properly installed in each classroom by proper technicians and tested/certified for throughput with an expensive cable-tester. Every cable was properly marked at the patch panel and the outlet. The stapled cable still worked well at 100 mbits/s. I tested them. GNU/Linux had three times the throughput of Lose 98 on those cables because Lose ’98 still used M$’s own TCP/IP stack…

I taught hundreds of students how to terminate cables and we often made LANs fully operational on table-tops for their benefit.