Just FYI, when someone misspells things at the rate you do (it's "C'est la vie", "breach of contract", "</p>"), I'm not inclined to trust their memory regarding fine detail or attribute credibility to their interpretation of said fine detail.
You might want to introspect about that.
Of course, WTF kind of network admins don't understand about buffering effects on dataflows?
Last question first: those admins who haven't worked with large numbers of TCP-to-serial converters -- I'm talking 6,000 independent datastreams at the same time -- and forget how TCP buffers get filled from a 1000 cps steady-rate source when the converter calculates a RTT of 2 milliseconds over the local network between it and the server. A server running as a guest in VMWare, with no packet aggregation optimization in the host's Ethernet interface. Who never heard of the word "thrashing". Who never saw the guest's real-time clock losing time because of interrupt overload. Who never took a WireShark capture of a connection, to see just how many packets are created for each stream
Criticism on my English and my spelling from an Anonymous Coward? Like that's worth much. Yes, I misspelled some stuff, but that's because what I published was first draft done in a hurry. If it were an article for paid publication, I would have used a real word processor, with a real spell checker, instead of a stupid HTML form. (Free Republic, another forum I occasionally contribute to, does have a decent spell-checker in its contribution entry form.)
And I'll be the first to say that my memory is a photographic one, but the filmbase is made from Swiss Cheese. That's why when I design a system, I use a number of methodologies to minimize the dependence on memory. I tend to design from the top down, then revise from the bottom up. Repeat as needed to nail down the details. I also create use cases: "I'm x and I need to do y," and then I ensure each case is covered in the initial design specification. I'm also a great fan of concordance generators to identify and eliminate "overloading" variable names within a project. Ever hear of one?
I'm 61, and still love solving technical challenges and learning new shit, so I still code...and it helps that I have skills that many consider "antiquated." In the case of my current job, knowing intimately the details of RS-232 based communication and drivers for same -- how to correctly program the NS16550 and ASIC cell equivalents, and more importantly how younger coders MISprogram the chip -- puts me head and shoulders over some of the new grads. Having more than 40 years' experience in project life cycles also means I can set priorities that make sense. I'm willing to adopt any new buzzword that makes sense...but reject new principles where I can't see any advantage to the company and myself.
I've seen the results of a tendency for people to be distracted by "shiny", and work through the problems it causes. For example, I remember when my company embraced virtual machines without fully understanding our system and network environment...and we are talking long-time certified networkers who don't fully grasp how TCP buffer-fill management works and how it affects dataflows, even when quoted chapter and verse from R Steven's book TCP/IP Illustrated. ("He doesn't know what he's talking about.") I fixed the problem, and no one liked my solution. The fact it worked was lost on them. Se la vie.
I don't play nice with stupid or shallow people, so I don't have to worry about management. I was a manager for a while, and my employees said I was the best manager they had seen. What tripped me up is that I couldn't lie to customers, even when told to. That inability to lie convincingly cost me a nice job and pension, but it also cost the company a seven-figure breech-of-contract lawsuit judgement. So I will stay where I am, doing cool stuff, until the day I'm forced into retirement.,/p>
The NTSB says they recovered the engine and NOX tank. No evidence of explosion in those components. Now, perhaps you are thinking of a different kind of explosion, such as how BOAC flight 781, a de Havilland DH.106 Comet 1 exploded -- a fuselage failure instead of engine failure. According to forensics after the wreakage was lifted from its watery grave, inspectors concluded that the aircraft had broken up in mid-air. If SpaceShipTwo experienced a similar type of failure, it could explain how one pilot survived -- he could have been blown out of the aircraft like that captain flying British Airways Flight 5390, who found himself "out in the breeze" after a windscreen failure, and who survived only because he didn't get pulled completely free and fell.
Or perhaps you were talking about the 2007 ground test of the rubber-fueled engine, where the three engineers were standing inside the danger zone when the test went wrong. That's why you run tests, to find out if things do go wrong, and you take proper safety precautions. To compare that failure with this one just doesn't hold up -- they are two different failure modes.
Actually, EBCDIC was weird because it's tied so closely to 80-column Hollerith encoding. Back in those early days of BCDIC encoding (which pre-dated EBCDIC), conversion of card hole punches was done with actual wires, plus a few transistors (or tubes!). When the System/360 came along, the engineers used the same techniques to decode card column patterns "at speed". I learned this for myself when I had to write a driver for a minicomputer (GA SPC-16) to interpret the punches. I didn't have enough words to use a proper 4096-entry table, so I had to use the same tricks to do a 1-of-n selection of the digits field, and then use the three bits from that and combine with the five bits of zone field, and look up the correct value in a 256-character table. The generation of the punch solenoid pattern used the same table in reverse, saving space at the expense of CPU cycles. In a 16-bit machine with 32 users, space -- especially low memory space -- was at a premium.
One advantage of doing the punch portion of the driver that way was that there was no way for anyone to cause the punch to generate "lace cards", like the earlier, clunkier driver did. Great way to destroy the card punch we were using, as the power supply in the external box was too small to drive ALL solenoids for ALL columns of a card, especially card after card. The Field Service people told stories of the damage they found at customer sites because of lace-card punching. The FS people were relieved when the new driver proved to prevent the problems.
As I recall, there was an "ASCII mode" in the decimal arithmetic instructions in the S/360 and follow-on systems so "zero and add packed" (ZAP) worked just fine in dealing with ASCII source data. The conversion of the sign was a bit of a problem, but most ASCII input didn't try to encode the number sign in the last character anyway.
Did you know that one of the early porting targets for Unix was a System/360 computer?
It sounds like they're intending to draw a distinction between nodes that principally receive data from those that principally transmit data.
This has been the traditional way to measure the type of peering between two networks: are you a net supplier of data or a net sink for data. Networks with a high number of web browsers would be a net sink, because HTML requests have high ratio of data received by the customer to the data sent. Networks with a high number of web servers are just the opposite. Most peering arrangements make the assumption that there would be some kind of balance, so the data load across the peering point(s) would be about the same.
The Internet, as it has developed, doesn't work that way any more. You have massive providers on the one hand, then you have massive sinks on the other, and the balance goes away. The receiving networks have difficulty being compensated for the additional bandwidth they have to handle from the upstream network, which is where the heartburn sets in. "If you want to send data to my network, who pays the freight?" In telephony, the model has been "sender pays". In cable television, it's "sender pays" with the customer's being billed for the right to receive "unlimited amounts" of content (disregarding pay tv).
This last option is what some of the transit and ISP networks want to impose on the likes of NetFlix.
Internet Service Provider, or ISP, is an outdated concept. If you are a Big Guy like Google or NetFlix, you contract with a transit provider of carriage. If you are Joe Six-Pack, then you contract with a retail-level provider like Comcast, AT&T, or your local wireless provider. The two are completely separate businesses.
How separate? Cisco, in its certifications make a distinction between ISPs (CCIE R&S, Security), and transit (CCIE Service Provider).
There are times when I use a drive-thru. What I absolutely hate is the delay from the time I order until the time my food is ready to deliver to me. The reason: it takes time to cook. I understand that. So the ability to order "over my phone" means that there is an overlap between travel time and food prep time. So, I get to the drive-up line, confirm my order, pay, and then get the food, all in seconds. Instead of waiting in the car line, engine idling all that time. (No, I don't have an electric car...yet.)
This order-by-phone process has become standing operating procedure for me when I'm getting a pizza, because the 20-minute cook time matches my overall travel time to the pizza place. No time wasted. (No, my usual haunt doesn't have drive-up -- I'm expecting that trend to start sometime, too. If you can have drive-up funeral viewing...)
How about this? You enter the drive-up and place your order, only to discover the two people in front of you have large orders...and all you want is coffee, soft drink, or other beverage. You sit and wait...and wait...and wait. Car idling, of course
It used to be that the fast-food restaurants would prepare food in advance, and possibly have to throw out some of that "spec" food. During rush times, they can prepare some things in advance; during slower times, they don't. I think the "new" way is better in some respects, but it plays hob with wait time.
Why would anyone have a windows machine around? My tribe does not support monsters nor evil doers. Freedom insists that I run Linux. Freedom is my buddy and you should get to know about Freedom.
I've been using Linux as my primary OS for more than 10 years, and I don't look back. That doesn't mean, though, that I don't have a Windows machines for those few times I need one -- depending on Fedex (nee Kinkos) is a real time waste. But I don't buy new -- the lease-return used computers are quite inexpensive and work for my few needs. (WINE isn't an answer, and I'm not a fan of virtual machines, if I had a CD and a license, the last being more expensive than a cheap used computer.)
Still, I have to eat, and Linux is not the be-all and end-all yet. LibreOffice does about 98 percent of what I need to service my clients, but that last five percent has to be handled, too. If you can enjoy total Freedom, do it. Many of us aren't that lucky. Also, I use the Windows box to do my taxes (US 1040) because I don't trust the "free" solutions yet -- 26 USC, the 10 book-feet of regulations, and the entire bookcase of case law makes understanding tax law hard. You mention Freedom; I want to be free of audits and accusations of tax cheating. So I buy the software, and that software runs on Macs and Windows. "The right tools for the right job." (Why do I hear these words with James Doohan's voice?)
I'm curious to see how the movement to cloud applications is going to change this. I'm already seeing an effect with Google Apps, which I need to use from time to time with some clients.. When Microsoft jumps into that game with Office, I may be able to give the Windows boxes the heave-ho. Maybe.
>The proper file format for that purpose is usually PDF.
I know that. But the customers want editable copies, and do not want to go through Adobe or anyone else for a PDF editor. The customers want Word files. Now, tell me how to educate the customers, when the competition will do exactly what they want and so my client loses business to that competition, and your comment will be reasonable.
Absent that critical step, my hands are tied. And so are my client's hands tied.