If you coded a sendmail.cf from scratch then you are a damned fool.
When I accomplished this feat, the M4 macros were not available -- the only way to deal with SendMail was to tweak the sendmail.cf file by hand.
Having the M4 macros is an improvement, I will grant you, and SendMail is indeed powerful. In my opinion, though, that power has long since been rendered moot by the near-universal adoption of DNS-based mail, the elimination of bang paths, the deprecation of source routing, and the needs of the security folks to keep the Bad Guys from ruining everything for everyone.
Remember, I moved from Sendmail to PostFix for personal comfort as an administrator.
Don't get me wrong, postfix is a nice MTA. Yes, it is easier to set up depending on what you think is "easy", but still, it's a nice MTA, but no reason to not use Sendmail if you can help it.
I ditched SendMail because it made me uncomfortable as an administrator. Yes, I could get it working "good enough" that I wasn't a relay, but because of the arcane command file structure I wasn't satisfied that it was tuned the way I wanted it. (BTW, I had hand-coded a sendmail.cf from scratch before, and made it work, but that was when I had a whole day to spend on the project.)
Back in the days when there weren't a hoard of people trying to crack your system, SendMail was OK. Nowadays, you want to make absolutely sure there are zero holes in your system -- arguably you want to PROVE there are no holes, which is an impossibility -- and SendMail makes that very hard to do.
With PostFix, I can get a configuration file, sort it, and check each parameter against the manual. In fact, PostFix can get me EVERY setting (using postconf) so that I can verify I like the defaults, too.
In the current Internet environment, "good enough" isn't good enough.
Qmail is rock-solid. The best proof I can offer is that fact that no security flaw has been found since 1.03 was released in 1998. The man is a cryptographer and designed it for security.
I run a number of qmail instances as part of my job, and while it may remain unbroken from a compromise viewpoint, it can get suffer from denial-of-service problems by bogging down to the point that the mail queue has to be cleared and the daemon restarted for the thing to run
I've never had this problem with PostFix.
I stopped running SendMail a long time ago, so I can't comment on that package's behavior first-hand when presented with a crushing load.
I have an IBM PS/2 Model 95 at work that I still have powered on. It's a 50MHz 486 with Microchannel architecture. It's probably the best built computer in my office. IBM doesn't do things half-assed.
I have an IBM Personal Computer/AT that IBM exchanged in November 1984 for the box I purchased October 1984 to review for InfoWorld and PC Products (a Cahners magazine, R.I.P.). It still runs, although finding software for it is a bit of a pain. Irony: it currently has SCO Unix 286 loaded on it!
Oh, the CMOS battery is dead so I have to drag out the configuration disk every time I power up -- this was before the configuration software was burned into BIOS ROM. The keyboard (clack! clack!) still works flawlessly, which is more than I can say for many of the older keyboards around here, especially the Macintosh and Sun keyboards.
IBM did not fool around when it came to their hardware.
(I also have a PS/2 Model 80 that still runs, too.)
ust so I can avoid ever getting any hosting there, since you obviously have a fetish for upgrading everything to the latest unstable releases.
Not every server, even not every Linux server, is running at a hosting company. There are lots and lots of servers running in enterprises, in the IT room of medium businesses and at casinos, under the counter of small businesses, and even in spare bedrooms around the world. I suspect there are even Linux servers running in caves and tunnels.
And as a system administrator at a Web hosting company, I can assure you that we don't run in everything that Red Hat releases, either, for just the raason you indicated: instability.
I am sure I purchased Microsoft products during the covered period. I don't recall feeling ripped off, nor do I remember anyone making me buy the products.
I was required to purchase two computers to do development of software for a company. One of the computers was to run Linux exclusively. When I went to the dealer I had to pay for Windows on both computers, even when I told the sales droid what I was going to do.
Even worse, when I purchased a hard disk upgrade from the dealer, it had a copy of Windows on it, too! A copy of Windows, by the way, that never was loaded into RAM of any computer. Why do I know this? Well, "dd" and "/dev/zero" are friends in that situation. (Best way I have found to date to blow away the partitioning and virus junk from a drive.)
Before someone jumps on me about being "Anti-Microsoft" know that this message was posted from a machine running Windows XP Professional. Granted, I'm using Mozilla, but...
What you are describing isn't benchmarking, it's stress testing.
It's interesting you should mention this. What I discovered very quickly is that "benchmarks" that just tried to measure performance rarely correlated well with the real world of what people do with the stuff. Contrarwise, my high-stress benchmarks did indeed correlate well with real-world operation, particularly testing with real applications.
For solid-state components such as CPUs and RAM, stress didn't affect results much at all. Include a mechanical component, though, and stress did indeed affect the measured performance of the product, and in ways that become visible to users under high real loads. Include a highly undeterministic component (like the Public Switched Telephone Network) and things become really interesting, especially from the view of statistical analysis of what you measured.
I'm talking SpecINT / SpecFP here, other Spec benchmarks exist because (gasp!) SpecINT/FP don't cover the whole computing spectrum.
And they weren't intended to. Read the original report, and you will see that SpecINT and SpecFP were designed to only test specific subsystems, and in my experience working with Spec they did their advertised function well. Pity that more editors didn't let stuff like that get into articles that talk about Spec -- including the one I wrote for a couple of magazines.
You also don't seem to have much of a clue about how processors are really tested.
You're entitled to your opinion. You don't have a clue about my experience, even if you check my resume -- there is a lot that isn't in there. (I wanted to keep it to two pages; the addendum is seven pages of tight-set typeset copy for the three people who give a damn.) Remember, too, that I'm not paid by the word on SlashDot (I'm not paid, period) so I'm not going to go on and one for nothing. TANSTAAFL.
Any idea what a 74LS181 is? Let alone how to test a system including that part?
Easy solution: print 2 numbers: a score, and the standard deviation. How hard would that be?
You don't know business-publication editors, do you?:)
"OK, explain in 20 words what a 'standard deviation' is, why it's important, and make sure that Joe CEO can understand it."
Then you have to fight for those 20 words when space sales calls and say they are down a couple of ads for the edition in which the article is to appear. Never mind that the Managing Editor just lost about 1,200 words of news-hole because some jerk pulled his double-truck four-color four-edge-bleed ad...
Nobody would test an FPU based on how many times per second it could take the square root of seven.
Really? Do you write benchmarks?
I used to write benchmarks. It was very common to include worst-case patterns in benchmark tests to try to find corner cases -- the same sort of things that QA people do to try to find errors. For example, given your example of a floating-point unit: I would include basic operations that would have 1-bits sprinkled throughout the computation. If Intel's QA people would have done this with the Pentium, they would have discovered the un-programmed quadrant of the divide look-up table long before the chip was committed to production.
Why do we benchmark people do this? Because we are amazed (and amused) at what we catch. Hard disk benchmarks that catch disk drives that can't handle certain data patterns well at all, even to the point of completely being unable to read back what we just wrote. My personal favorite: how about modems from big-name companies that drop data when stressed to their fullest?
The SPECmark group recognizes that the wrong answer is always bad, so they insist that in their benchmarks the unit under test get the right answer before they even talk of timing. This is from canned data, of course, not "generating random scenes." The problem with using random data is that you don't know if the results are right with random data -- or at least that you get the results you've gotten on other testbeds.
Besides, how is the software supposed to know how the scene was rendered? Read back the graphics planes and try to interpret the image for "correctness"? First, is this possible with today's graphics cards, and, second, is it feasible to try? Picture analysis is an art unto itself, and I suspect that being able to check rendering adds a whole 'nuther dimension to the problem. I won't say it can't be done, but I will say that it would be expensive.
For FPUs, it's easy: have a test vector with lots of test cases. Make sure you include as many corner cases as you can conceive. When you make a test run, mix up the test cases so that you don't execute them in the same order every pass. (This will catch problems in vector FPU implementations.) Check those results!
Now, if you will tell me how to extend that philosophy to graphic cards, we will have something.
[Nvidia] used to be great.. but now i have my doubts
Oh, c'mon. Benckmark fudging has been an on-going tradition in the computer field. When I was doing computer testing for InfoWorld, I found some people in a vendor's organization would try to overclock computers so they would do better in the automated benchmarks. ZD Labs found some people who "played" the BAPco graphics benchmarks to earn better scores by detecting a benchmark was running and cutting corners.
<Obligatory-Microsoft-bash>
One of the early players was Microsoft, with its C compiler. I have it from a source in Microsoft that when the Byte C-compiler benchmarks figures were published in the early 1980s Microsoft didn't like being back of the pack. "It would take six months to fix the optimizer right." It would take two weeks, though, to put in recognizers for the common benchmarks of the time and insert hand-optimized "canned code" to better their score.
</Obligatory-Microsoft-bash>
Microsoft wasn't the only one. How about a certain three-letter company who fudged their software? You have multiple right answers to this one.:)
When the SPECmark people first formed their benchmark committee, they knew of these practices and so they made the decision that SPECmarks were to be based on real programs, with known input and output, and the output was checked for correct answers before the execution times would be used.
And now you know why reputable testing organizations who use artifical workloads check their work with real applications: to catch the cheaters.
Let me reiterate an earlier comment by Alan Partridge: it's idiots who think that a less-than-one-percent difference in performance is significant. (Whether you the shoe fits you is something you have to decide for yourself.) What benchmark articles don't tell you is the spread of results they obtain through multiple testing cycles. When I was doing benchmark testing at InfoWorld, it was common for me to see trial-to-trial spreads of three percent in CPU benchmarks, and broader spreads than that with hard-disk benchmarks. Editors were unwilling to admit to readers that results were collected that formed a "cloud" -- they wanted a SINGLE number to put in print. ("Don't confuse the reader with facts, I want to make the point and move on.") I see that in the years since I was doing this full-time that editors are still insisting on "keep it simple" even when it's wrong.
Another observation: when I would trace back hardware and software that was played with, the response from upper management was universally astonishment. They would fall over backwards to ensure we got a production piece of equipment. To some extent, I believed their protestations, especially when bearded during their visits to our Labs. One computer company (name withheld to protect the long-dead guilty) was amazed when we took them into the lab and opened up their box. We pointed out that someone had poured White-Out over the crystal can, and that when we carefully removed the layer of gunk the crystal was 20% faster than usual. Talk about over-clocking!
So when someone says "Nvidia is guilty of lying" I say "prove it", further saying that you have to show with positive proof that the benchmark fudging was authorized by top management. I can't tell from the article, but I suspect someone pulled a fast one, and soon will be joining the very long high-technology bread line.
Pray the benchmarkers will always check their work.
And remember, the best benchmark is YOUR application.
Watch the P2P networks add the concept of karma and moderation to the system, so that people can vote (or anti-vote) for a particular contribution. After all, once you are burned by a "what the F*KC are you doing" track you go and mark it.
Then where do all the buffer overruns come from? I'm not saying that developers are idiots, but every developer makes mistakes. Bugs are usually rooted in opportunities for error, so whatever your library can do to help trace brain farts is time and effort well spent.
I guess I look at maintenance and integration issues in development, more than some people do, because of my background in DVT and QA.
Try feeding invalid data to most of the C standard library and you will often get creashes.
Feed a null pointer to a properly-written C library and you get a diagnostic, not a crash. Feed a pointer to a string that is not zero-terminated and you will get astonishing effects, but that's from poor language design, not poor implementation. For example many of the str* functions are hard to do with crash protection, although there are techniques to deal with the problem without costing too much performance.
I've worked on libraries, and it's possible to deal with issues without compromising performance and capability. It does add a small amount of bloat, but in many cases it's worth it.
It's been a long time since memory was measured in cents per bit.
I work on an industry-leading mathematical library. We rely, in a few places, on getting sensible input from our client apps. If they give us garbage, they have no guarantees about getting a sensible error back, or even about anything ever coming back.
I'm sorry you don't mention the name of your company, because your company makes software that should be shunned. No software should respond in an astonishing way when fed valid data that is outside of the domain of the function -- it should do range-checking and set an appropriate error flag and return to the caller with something, even if that "something" is a NAN. Even when fed absolute junk, it should detect the junk and error out in a predictable manner.
In particular, taking down the application (and perhaps the entire system it's running on) is not an option.
I was very surprised at the analysis expressed by Mr. Jakob Nielsen's little essay. He missed one of the most important lessons of the Web: many web pages are one large ad, on behalf of the page owner.
Take several of the Web sites I manage. www.softwarr.com is a Web site for selling and providing support for a computer program. The entire site is one big ad. Another one: www.tahoetrans.com, a single-page (so far) site with a short, pithy message directed at the few people that need natural-language translation.
How many of you have Web pages that advertise YOU? After all, a resume is a form of advertising.
We talk about banner advertising (and ads of any kind) in a negative way because ads are intended to intrude on one's quest for information. We forget that many times the very information we are seeking is to be found in... an ad! An ad that is germane to our quest, that is information we seek, that answers a problem or a question or a need.
What a number of Web advertisers forget is that the original paradigm for the World Wide Web is seekers finding you, not you trying to lure seekers of other knowledge. The ubiquitious banner ad is off-topic, un-wanted, and in many cases a waste of perfectly good bandwidth. The text ad has the virtue of being far more conservative of bandwidth, which is music to the ears of our European brothers and sisters who pay by the byte.
The days of ad broadcasts in the United States being "free" are coming to an end. Broadband providers are slapping transmission caps on users, so every single banner ad takes away from the user being able to see or hear something else. (This is especially true for those ads that have sound attached to them.) I've found that banner ads don't cache well at all, probably because the ad salesmen would otherwise have no way to measure the number of exposures with accuracy. I can see the day when banner ads are viewed exactly like junk faxes are viewed, as we end up having to pay to receive these commercial messages as a form of "tax" on trying to find useful things on the Web. Then you will hear people wanting to charge back the cost of connectivity, just as hapless fax users want to charge back the cost of paper, ink, and phone line time.
"But how do I make a site pay if we don't have banner/text advertising?" Good question, and one that the continued use of advertising has set aside. Instead of clinging to a business model that is quickly dying, embrace a new business model that will continue long after the last banner ad is sent. Be as creative in coming up with new revenue methods as you were coming up with the banner ad, and the cookies as market tracking tool.
If all the ad-supported sites were required to think up something better or die, we would already have an alternative that works. I'm firmly convinced that the crutch that is the banner ad has slowed down the development of a better way to do Web business.
The whole point of the wc3 existance is to prevent this and encourage innovation and a level playing field on the web.
Sbc claims sounds borderline fraudulant.
You'd be right if SBC was a member of W3C and worked on the technical committee. This was true before the W3C request for comment on intellectual property last year -- before they were operating under the ANSI rules of incorporating intellectual property into Standards.
Here we have a company, though, who did not protect its intellectual property. SBC cannot claim harm, because they offer Internet Services for sale (I was an early customer before firing them) and so were aware of customary practice and the standardization of that practice by a Standards-setting body.
In short, they are complaining too late in the process. Was their delay just stupidity, or was there something more to it? Or is SBC hurting so much that they need to go after every dime they can?
Actually, it sounds like this patent description is describing the outline display used in Adobe Acrobat -- you have navigation on the left side that doesn't change (much) as you work your way through the document in the right-hand window.
It is so much easier to do this with vlans no four port ethers or cross over cables or little hubs just one switch and a machine with one interface (router on a stick).
Gee, amazing how we learn something every day. I didn't know that existing switch technology incorporated stateful packet filtering into VLANs. After all, the entire purpose for using four-port ethers and crossover cables was to provide each server class a private DMZ, with custom firewall rules. The only reason to have a little hub for the DNS servers was that to do the job right you would need two ports, and it's far cheaper to use a $20 hub.
Too bad Cisco didn't mention this capability of VLANs in its documentation, nor included a description of how to program the stateful firewall per port in IOS. But I'll look again...
put firewalls between every server and the rest of the network... not one firewall, but one for each server (a dedicated firewall).
OK, now that some people have had their fun...
Your idea isn't as lame as some people think it is. I'll tell you how I did essentially just what you suggested at one site I built up. Multiple DMZs.
Here's how it plays. Take a standard 1U rackmount computer. Add 4-port Ethernet card in the PCI slot. Run cross-over cables from each port to each of a Web server, FTP server, mail server, and DNS server 4-port hub (for two BIND servers). Load with a recent distribution of Linux. Code up IPTABLES rules so that each of the three servers only see in-bound requests of the particular type, and can make sensible outbound requests. (In other words, use a mostly-closed policy.) Define a/27 or/28 for each port, and set up your routing tables appropriately.
That's a $500-delta solution to a thorny problem, but when you consider that a firewall appliance is $430 each, you are saving a bundle and protecting the servers from each other and from your internal network.
Got a large intranet? Consider breaking it into zones, with more of those hydra-headed pizza boxes to prevent inter-zone pollution should some moron let a virus loose. (My experience is that the execs should be in their own God's little acre -- the last major virus outbreak I had to fight was caused by a VP!)
Acid Zebra has the right idea, although the admonishment "be careful" seems to be as effective with network users as it does with young unmarried women (and boys).
But, but, but... we are talking about spam-spewing viruses in this discussion, not just any virus. Let's try to stay on topic, OK?
Sure, I forward a number of well-known ports to the Internet from my LAN, but not smtp. This is all NetAdmin 101. I run an MTA (PostFix) that handles all outgoing mail -- all systems on the inside network send their mail there to be relayed to the outside world.
Could the spew-virus use my MTA? Only if it is very, very careful. (No, I'm not going to give away all my secrets on a public forum.) Suffice to say that a virus writer would have to be very clever indeed to find a way out. In addition to other measures, the MTA box has IPTABLES with a custom configuration that would further slow down any virus that does get inside and worms around the protections in place.
You bet I'm a paranoid son of a bitch. I visited a company just after a virus swept through its 150-system intranet, and that company lost more than $2 million in recovery efforts and lost productivity. I also remember that Microsoft found itself with the SQA thingie loose on its internal network. It happens. You plan for it. Indeed, in company intranets your inside systems are more of a hazard than anything from the outside. NetAdmin 102.
I also do not allow Outlook or Outlook Express to be used on my internal network. Period. NetAdmin 301.
How to configure PostFix, and possibly some other software, to stop a virus running on an authorized system/IP is an exercise left to the student. Term project for NetAdmin 401. Hint: think about authorization.
Fun. So now they realize after they create the chip that they want 20 years of backwards compatibility.
Back before Bill Gates and IBM's Entry System Division thrust Intel microprocessors into every other home on the planet, electronic systems designers were actively courted by Intel by their claim to developing products that won't invalidate all existing design work in one swell foop. And, for the most part, they held up on their end of that promise, which is why the Pentium 4 still has a little bit of the 8080 in it.
Now, when the i432 came out, it was a completely different beast -- and the i432 died a justified death. The i860 didn't fare that well, either. The i960 has seen quite a number of design-ins, because the solution base the i960 was geared to was sufficiently different from the 80x86 that designers didn't try to replace 80x86 chips with the RISC-based i960.
Intel, that was a clue.
What Intel didn't foresee, but should have, is the great technological bust of 1999 put a number of companies under. Source code has flown to the four winds, in some cases the foreclosures also nailed every single backup. In short, the migration path via recompilation was no longer an option. (Not to mention that there were no dollars to make even the most trivial changes to the source to deal with 64-bit processors.)
So this announcement is surprising only in that it comes so late in the product development cycle, as Intel is coming out with its second generation of IA64 chips.
Secondly, you can have the best firewall in the world, but if a trusted host behind it is compromised then it's "game over". The attacker doesn't have to connect to your machine through your firewall. The compromised machine can connect out and initiate a backchannel - literally punching a hole through the firewall. This would normally be to an IRC server, but could be anywhere really, using any protocol allowed out by the firewall.
You are right, the spam-virus can try to initiate a connection to something on the other side. Of course, I don't forward smtp traffic, so a spam virus would find little happiness running on any of my computers, because it will find itself in a little jail -- and the discussion was a spamming SMTP zombie.
No host behind my firewall is "trusted". One of the beauties of my firewall implementation is that perimeter protection is both ways: protect my computers from bad-boy Internet packets, and protect the Internet from any nastiness that might creep into my computer.
That's the power provided by IPTABLES under Linux. I can filter traffic independently in both directions, using the stateful capabilities of IPTABLES, so that my sieve can handle in-bound SMTP separately from out-bound SMTP, passing one and blocking the other. And I do, because I can.
(N.B.: that's not to take anything away from firewall products for Windows, Macintosh, BeOS, and other systems that implement stateful filtering. There are $50 software packages that afford the same protection, if you elect to use it. The problem, of course, is that a computer virus may be able to "sneak around" a same-system firewall implementation. That's why I like separate firewall computers, and firewall appliances such as the SonicWall. A virus would have to work very hard indeed then to get past the protection.)
In short, my firewall does protect other machines on the Internet from a stupid user opening a virus on a local machine.
How does punishing people who commit crimes reduce our civil liberties?
Define "crime" as "harm to society" and you start to see that many of the "crimes" on the books are not true harm, but rather annoyances on the order of "disturbing the peace." The thicker the statutes become, the more likely you will run afoul of them. (Some people claim that LEOs like this, because it lets them engage in selective enforcement to punish those people doing things said LEOs don't like.)
"I didn't know about that law!" is not a defense; as you pile on more laws, though, the chance that you didn't know about that law rises to unity. Using firearm laws as an example, the laws on the books since we were children were not being enforced, so the "popular" answer was to pass new laws! Some of those new laws made sense, some of them just warmed over what was already on the books.
The problem is that a legislature is sorely tempted, at some point, to stop telling us prohibitions and start telling us permissions. At that point, civil liberties are out the windows.
OK, so I'm an old fuddy-duddy who remembers the days of vinyl. When I was a kid I got an old tube-type pre-amp that had an unusual dial on it. It selected the record de-emphasis to use for each particular label, and it had 19 positions. That's right, each record cutting company had its own ideas as to what the "best" pre-emphasis curve to use to reduce SNR without overcutting the record. (Yes, this was in the days of 78-rpm records, although even the early 33-1/3-rpm records were cut using proprietary filters.)
One of the reasons the Recording Industry Association of America, a.k.a the hated RIAA, was formed was to reign in the madness and develop some sensible standards for recordings. The work of the RIAA was to reduce the cost of both recording and playing back recordings in a number of formats: vinyl, magnetic tape, and at one point magnetic wire. By reducing the Babel, makers of cartridge pre-ampliers would need to put in less circuitry, makers of record-cutting lathes could provide the "standard" circuits for each speed/format, and the listening public didn't have to mess with that 19-position knob anymore when changing records.
The RIAA did such a good job that it put itself out of its original business, setting standards. Much of the standards work is now done by the developers of media: Phillips for cassettes, and I don't recall who brought us the digital compact disc. The DVD is pretty much out of RIAA's hands, too.
Interesting that the RIAA and many computer engineers have something in common -- a lack of need for what they do...
If you need the book for COBOL, you should seriously reconsider your career choice. It may be verbose and frustrating, but it's also about as easy to read and use as you can possibly get.
Yes, it's easy to read, but most varients of COBOL and most especially the first ANSI COBOL was the absolute devil to WRITE -- and writing programs is what it is all about. The basic structures were easy, but try doing a complex multi-phrase selector in the language -- you need the book and then some in order to keep the clauses from tripping over each other. Unlike ALGOL, PL/I, and C, the "sentence" structure of COBOL can be its own worst enemy.
When the shortage gets bleak enough that people are willing to take people without narrow skills like years of DB/2, then I'll get back into the mainframe world. Like the so-called "programmer shortage" that the H-1B visa boosters complain about, the mainframe shortage is of the same order of balderdash.
Slashdot Mirror
When I accomplished this feat, the M4 macros were not available -- the only way to deal with SendMail was to tweak the sendmail.cf file by hand.
Having the M4 macros is an improvement, I will grant you, and SendMail is indeed powerful. In my opinion, though, that power has long since been rendered moot by the near-universal adoption of DNS-based mail, the elimination of bang paths, the deprecation of source routing, and the needs of the security folks to keep the Bad Guys from ruining everything for everyone.
Remember, I moved from Sendmail to PostFix for personal comfort as an administrator.
I ditched SendMail because it made me uncomfortable as an administrator. Yes, I could get it working "good enough" that I wasn't a relay, but because of the arcane command file structure I wasn't satisfied that it was tuned the way I wanted it. (BTW, I had hand-coded a sendmail.cf from scratch before, and made it work, but that was when I had a whole day to spend on the project.)
Back in the days when there weren't a hoard of people trying to crack your system, SendMail was OK. Nowadays, you want to make absolutely sure there are zero holes in your system -- arguably you want to PROVE there are no holes, which is an impossibility -- and SendMail makes that very hard to do.
With PostFix, I can get a configuration file, sort it, and check each parameter against the manual. In fact, PostFix can get me EVERY setting (using postconf) so that I can verify I like the defaults, too.
In the current Internet environment, "good enough" isn't good enough.
I run a number of qmail instances as part of my job, and while it may remain unbroken from a compromise viewpoint, it can get suffer from denial-of-service problems by bogging down to the point that the mail queue has to be cleared and the daemon restarted for the thing to run
I've never had this problem with PostFix.
I stopped running SendMail a long time ago, so I can't comment on that package's behavior first-hand when presented with a crushing load.
I have an IBM Personal Computer/AT that IBM exchanged in November 1984 for the box I purchased October 1984 to review for InfoWorld and PC Products (a Cahners magazine, R.I.P.). It still runs, although finding software for it is a bit of a pain. Irony: it currently has SCO Unix 286 loaded on it!
Oh, the CMOS battery is dead so I have to drag out the configuration disk every time I power up -- this was before the configuration software was burned into BIOS ROM. The keyboard (clack! clack!) still works flawlessly, which is more than I can say for many of the older keyboards around here, especially the Macintosh and Sun keyboards.
IBM did not fool around when it came to their hardware.
(I also have a PS/2 Model 80 that still runs, too.)
Not every server, even not every Linux server, is running at a hosting company. There are lots and lots of servers running in enterprises, in the IT room of medium businesses and at casinos, under the counter of small businesses, and even in spare bedrooms around the world. I suspect there are even Linux servers running in caves and tunnels.
And as a system administrator at a Web hosting company, I can assure you that we don't run in everything that Red Hat releases, either, for just the raason you indicated: instability.
I was required to purchase two computers to do development of software for a company. One of the computers was to run Linux exclusively. When I went to the dealer I had to pay for Windows on both computers, even when I told the sales droid what I was going to do.
Even worse, when I purchased a hard disk upgrade from the dealer, it had a copy of Windows on it, too! A copy of Windows, by the way, that never was loaded into RAM of any computer. Why do I know this? Well, "dd" and "/dev/zero" are friends in that situation. (Best way I have found to date to blow away the partitioning and virus junk from a drive.)
Before someone jumps on me about being "Anti-Microsoft" know that this message was posted from a machine running Windows XP Professional. Granted, I'm using Mozilla, but...
It's interesting you should mention this. What I discovered very quickly is that "benchmarks" that just tried to measure performance rarely correlated well with the real world of what people do with the stuff. Contrarwise, my high-stress benchmarks did indeed correlate well with real-world operation, particularly testing with real applications.
For solid-state components such as CPUs and RAM, stress didn't affect results much at all. Include a mechanical component, though, and stress did indeed affect the measured performance of the product, and in ways that become visible to users under high real loads. Include a highly undeterministic component (like the Public Switched Telephone Network) and things become really interesting, especially from the view of statistical analysis of what you measured.
And they weren't intended to. Read the original report, and you will see that SpecINT and SpecFP were designed to only test specific subsystems, and in my experience working with Spec they did their advertised function well. Pity that more editors didn't let stuff like that get into articles that talk about Spec -- including the one I wrote for a couple of magazines.
You're entitled to your opinion. You don't have a clue about my experience, even if you check my resume -- there is a lot that isn't in there. (I wanted to keep it to two pages; the addendum is seven pages of tight-set typeset copy for the three people who give a damn.) Remember, too, that I'm not paid by the word on SlashDot (I'm not paid, period) so I'm not going to go on and one for nothing. TANSTAAFL.
Any idea what a 74LS181 is? Let alone how to test a system including that part?
You don't know business-publication editors, do you? :)
"OK, explain in 20 words what a 'standard deviation' is, why it's important, and make sure that Joe CEO can understand it."
Then you have to fight for those 20 words when space sales calls and say they are down a couple of ads for the edition in which the article is to appear. Never mind that the Managing Editor just lost about 1,200 words of news-hole because some jerk pulled his double-truck four-color four-edge-bleed ad...
Really? Do you write benchmarks?
I used to write benchmarks. It was very common to include worst-case patterns in benchmark tests to try to find corner cases -- the same sort of things that QA people do to try to find errors. For example, given your example of a floating-point unit: I would include basic operations that would have 1-bits sprinkled throughout the computation. If Intel's QA people would have done this with the Pentium, they would have discovered the un-programmed quadrant of the divide look-up table long before the chip was committed to production.
Why do we benchmark people do this? Because we are amazed (and amused) at what we catch. Hard disk benchmarks that catch disk drives that can't handle certain data patterns well at all, even to the point of completely being unable to read back what we just wrote. My personal favorite: how about modems from big-name companies that drop data when stressed to their fullest?
The SPECmark group recognizes that the wrong answer is always bad, so they insist that in their benchmarks the unit under test get the right answer before they even talk of timing. This is from canned data, of course, not "generating random scenes." The problem with using random data is that you don't know if the results are right with random data -- or at least that you get the results you've gotten on other testbeds.
Besides, how is the software supposed to know how the scene was rendered? Read back the graphics planes and try to interpret the image for "correctness"? First, is this possible with today's graphics cards, and, second, is it feasible to try? Picture analysis is an art unto itself, and I suspect that being able to check rendering adds a whole 'nuther dimension to the problem. I won't say it can't be done, but I will say that it would be expensive.
For FPUs, it's easy: have a test vector with lots of test cases. Make sure you include as many corner cases as you can conceive. When you make a test run, mix up the test cases so that you don't execute them in the same order every pass. (This will catch problems in vector FPU implementations.) Check those results!
Now, if you will tell me how to extend that philosophy to graphic cards, we will have something.
Oh, c'mon. Benckmark fudging has been an on-going tradition in the computer field. When I was doing computer testing for InfoWorld, I found some people in a vendor's organization would try to overclock computers so they would do better in the automated benchmarks. ZD Labs found some people who "played" the BAPco graphics benchmarks to earn better scores by detecting a benchmark was running and cutting corners.
<Obligatory-Microsoft-bash>
One of the early players was Microsoft, with its C compiler. I have it from a source in Microsoft that when the Byte C-compiler benchmarks figures were published in the early 1980s Microsoft didn't like being back of the pack. "It would take six months to fix the optimizer right." It would take two weeks, though, to put in recognizers for the common benchmarks of the time and insert hand-optimized "canned code" to better their score.</Obligatory-Microsoft-bash>
Microsoft wasn't the only one. How about a certain three-letter company who fudged their software? You have multiple right answers to this one. :)
When the SPECmark people first formed their benchmark committee, they knew of these practices and so they made the decision that SPECmarks were to be based on real programs, with known input and output, and the output was checked for correct answers before the execution times would be used.
And now you know why reputable testing organizations who use artifical workloads check their work with real applications: to catch the cheaters.
Let me reiterate an earlier comment by Alan Partridge: it's idiots who think that a less-than-one-percent difference in performance is significant. (Whether you the shoe fits you is something you have to decide for yourself.) What benchmark articles don't tell you is the spread of results they obtain through multiple testing cycles. When I was doing benchmark testing at InfoWorld, it was common for me to see trial-to-trial spreads of three percent in CPU benchmarks, and broader spreads than that with hard-disk benchmarks. Editors were unwilling to admit to readers that results were collected that formed a "cloud" -- they wanted a SINGLE number to put in print. ("Don't confuse the reader with facts, I want to make the point and move on.") I see that in the years since I was doing this full-time that editors are still insisting on "keep it simple" even when it's wrong.
Another observation: when I would trace back hardware and software that was played with, the response from upper management was universally astonishment. They would fall over backwards to ensure we got a production piece of equipment. To some extent, I believed their protestations, especially when bearded during their visits to our Labs. One computer company (name withheld to protect the long-dead guilty) was amazed when we took them into the lab and opened up their box. We pointed out that someone had poured White-Out over the crystal can, and that when we carefully removed the layer of gunk the crystal was 20% faster than usual. Talk about over-clocking!
So when someone says "Nvidia is guilty of lying" I say "prove it", further saying that you have to show with positive proof that the benchmark fudging was authorized by top management. I can't tell from the article, but I suspect someone pulled a fast one, and soon will be joining the very long high-technology bread line.
Pray the benchmarkers will always check their work.
And remember, the best benchmark is YOUR application.
Watch the P2P networks add the concept of karma and moderation to the system, so that people can vote (or anti-vote) for a particular contribution. After all, once you are burned by a "what the F*KC are you doing" track you go and mark it.
Then where do all the buffer overruns come from? I'm not saying that developers are idiots, but every developer makes mistakes. Bugs are usually rooted in opportunities for error, so whatever your library can do to help trace brain farts is time and effort well spent.
I guess I look at maintenance and integration issues in development, more than some people do, because of my background in DVT and QA.
Feed a null pointer to a properly-written C library and you get a diagnostic, not a crash. Feed a pointer to a string that is not zero-terminated and you will get astonishing effects, but that's from poor language design, not poor implementation. For example many of the str* functions are hard to do with crash protection, although there are techniques to deal with the problem without costing too much performance.
I've worked on libraries, and it's possible to deal with issues without compromising performance and capability. It does add a small amount of bloat, but in many cases it's worth it.
It's been a long time since memory was measured in cents per bit.
I'm sorry you don't mention the name of your company, because your company makes software that should be shunned. No software should respond in an astonishing way when fed valid data that is outside of the domain of the function -- it should do range-checking and set an appropriate error flag and return to the caller with something, even if that "something" is a NAN. Even when fed absolute junk, it should detect the junk and error out in a predictable manner.
In particular, taking down the application (and perhaps the entire system it's running on) is not an option.
I was very surprised at the analysis expressed by Mr. Jakob Nielsen's little essay. He missed one of the most important lessons of the Web: many web pages are one large ad, on behalf of the page owner.
Take several of the Web sites I manage. www.softwarr.com is a Web site for selling and providing support for a computer program. The entire site is one big ad. Another one: www.tahoetrans.com, a single-page (so far) site with a short, pithy message directed at the few people that need natural-language translation.
How many of you have Web pages that advertise YOU? After all, a resume is a form of advertising.
We talk about banner advertising (and ads of any kind) in a negative way because ads are intended to intrude on one's quest for information. We forget that many times the very information we are seeking is to be found in... an ad! An ad that is germane to our quest, that is information we seek, that answers a problem or a question or a need.
What a number of Web advertisers forget is that the original paradigm for the World Wide Web is seekers finding you, not you trying to lure seekers of other knowledge. The ubiquitious banner ad is off-topic, un-wanted, and in many cases a waste of perfectly good bandwidth. The text ad has the virtue of being far more conservative of bandwidth, which is music to the ears of our European brothers and sisters who pay by the byte.
The days of ad broadcasts in the United States being "free" are coming to an end. Broadband providers are slapping transmission caps on users, so every single banner ad takes away from the user being able to see or hear something else. (This is especially true for those ads that have sound attached to them.) I've found that banner ads don't cache well at all, probably because the ad salesmen would otherwise have no way to measure the number of exposures with accuracy. I can see the day when banner ads are viewed exactly like junk faxes are viewed, as we end up having to pay to receive these commercial messages as a form of "tax" on trying to find useful things on the Web. Then you will hear people wanting to charge back the cost of connectivity, just as hapless fax users want to charge back the cost of paper, ink, and phone line time.
"But how do I make a site pay if we don't have banner/text advertising?" Good question, and one that the continued use of advertising has set aside. Instead of clinging to a business model that is quickly dying, embrace a new business model that will continue long after the last banner ad is sent. Be as creative in coming up with new revenue methods as you were coming up with the banner ad, and the cookies as market tracking tool.
If all the ad-supported sites were required to think up something better or die, we would already have an alternative that works. I'm firmly convinced that the crutch that is the banner ad has slowed down the development of a better way to do Web business.
Go to it!
You'd be right if SBC was a member of W3C and worked on the technical committee. This was true before the W3C request for comment on intellectual property last year -- before they were operating under the ANSI rules of incorporating intellectual property into Standards.
Here we have a company, though, who did not protect its intellectual property. SBC cannot claim harm, because they offer Internet Services for sale (I was an early customer before firing them) and so were aware of customary practice and the standardization of that practice by a Standards-setting body.
In short, they are complaining too late in the process. Was their delay just stupidity, or was there something more to it? Or is SBC hurting so much that they need to go after every dime they can?
Actually, it sounds like this patent description is describing the outline display used in Adobe Acrobat -- you have navigation on the left side that doesn't change (much) as you work your way through the document in the right-hand window.
Now there would be a fight.
Gee, amazing how we learn something every day. I didn't know that existing switch technology incorporated stateful packet filtering into VLANs. After all, the entire purpose for using four-port ethers and crossover cables was to provide each server class a private DMZ, with custom firewall rules. The only reason to have a little hub for the DNS servers was that to do the job right you would need two ports, and it's far cheaper to use a $20 hub.
Too bad Cisco didn't mention this capability of VLANs in its documentation, nor included a description of how to program the stateful firewall per port in IOS. But I'll look again...
RTFR, please.
OK, now that some people have had their fun...
Your idea isn't as lame as some people think it is. I'll tell you how I did essentially just what you suggested at one site I built up. Multiple DMZs.
Here's how it plays. Take a standard 1U rackmount computer. Add 4-port Ethernet card in the PCI slot. Run cross-over cables from each port to each of a Web server, FTP server, mail server, and DNS server 4-port hub (for two BIND servers). Load with a recent distribution of Linux. Code up IPTABLES rules so that each of the three servers only see in-bound requests of the particular type, and can make sensible outbound requests. (In other words, use a mostly-closed policy.) Define a /27 or /28 for each port, and set up your routing tables appropriately.
That's a $500-delta solution to a thorny problem, but when you consider that a firewall appliance is $430 each, you are saving a bundle and protecting the servers from each other and from your internal network.
Got a large intranet? Consider breaking it into zones, with more of those hydra-headed pizza boxes to prevent inter-zone pollution should some moron let a virus loose. (My experience is that the execs should be in their own God's little acre -- the last major virus outbreak I had to fight was caused by a VP!)
Acid Zebra has the right idea, although the admonishment "be careful" seems to be as effective with network users as it does with young unmarried women (and boys).
But, but, but... we are talking about spam-spewing viruses in this discussion, not just any virus. Let's try to stay on topic, OK?
Sure, I forward a number of well-known ports to the Internet from my LAN, but not smtp. This is all NetAdmin 101. I run an MTA (PostFix) that handles all outgoing mail -- all systems on the inside network send their mail there to be relayed to the outside world.
Could the spew-virus use my MTA? Only if it is very, very careful. (No, I'm not going to give away all my secrets on a public forum.) Suffice to say that a virus writer would have to be very clever indeed to find a way out. In addition to other measures, the MTA box has IPTABLES with a custom configuration that would further slow down any virus that does get inside and worms around the protections in place.
You bet I'm a paranoid son of a bitch. I visited a company just after a virus swept through its 150-system intranet, and that company lost more than $2 million in recovery efforts and lost productivity. I also remember that Microsoft found itself with the SQA thingie loose on its internal network. It happens. You plan for it. Indeed, in company intranets your inside systems are more of a hazard than anything from the outside. NetAdmin 102.
I also do not allow Outlook or Outlook Express to be used on my internal network. Period. NetAdmin 301.
How to configure PostFix, and possibly some other software, to stop a virus running on an authorized system/IP is an exercise left to the student. Term project for NetAdmin 401. Hint: think about authorization.
Back before Bill Gates and IBM's Entry System Division thrust Intel microprocessors into every other home on the planet, electronic systems designers were actively courted by Intel by their claim to developing products that won't invalidate all existing design work in one swell foop. And, for the most part, they held up on their end of that promise, which is why the Pentium 4 still has a little bit of the 8080 in it.
Now, when the i432 came out, it was a completely different beast -- and the i432 died a justified death. The i860 didn't fare that well, either. The i960 has seen quite a number of design-ins, because the solution base the i960 was geared to was sufficiently different from the 80x86 that designers didn't try to replace 80x86 chips with the RISC-based i960.
Intel, that was a clue.
What Intel didn't foresee, but should have, is the great technological bust of 1999 put a number of companies under. Source code has flown to the four winds, in some cases the foreclosures also nailed every single backup. In short, the migration path via recompilation was no longer an option. (Not to mention that there were no dollars to make even the most trivial changes to the source to deal with 64-bit processors.)
So this announcement is surprising only in that it comes so late in the product development cycle, as Intel is coming out with its second generation of IA64 chips.
Competition. It's a good thing.
You are right, the spam-virus can try to initiate a connection to something on the other side. Of course, I don't forward smtp traffic, so a spam virus would find little happiness running on any of my computers, because it will find itself in a little jail -- and the discussion was a spamming SMTP zombie.
No host behind my firewall is "trusted". One of the beauties of my firewall implementation is that perimeter protection is both ways: protect my computers from bad-boy Internet packets, and protect the Internet from any nastiness that might creep into my computer.
That's the power provided by IPTABLES under Linux. I can filter traffic independently in both directions, using the stateful capabilities of IPTABLES, so that my sieve can handle in-bound SMTP separately from out-bound SMTP, passing one and blocking the other. And I do, because I can.
(N.B.: that's not to take anything away from firewall products for Windows, Macintosh, BeOS, and other systems that implement stateful filtering. There are $50 software packages that afford the same protection, if you elect to use it. The problem, of course, is that a computer virus may be able to "sneak around" a same-system firewall implementation. That's why I like separate firewall computers, and firewall appliances such as the SonicWall. A virus would have to work very hard indeed then to get past the protection.)
In short, my firewall does protect other machines on the Internet from a stupid user opening a virus on a local machine.
Define "crime" as "harm to society" and you start to see that many of the "crimes" on the books are not true harm, but rather annoyances on the order of "disturbing the peace." The thicker the statutes become, the more likely you will run afoul of them. (Some people claim that LEOs like this, because it lets them engage in selective enforcement to punish those people doing things said LEOs don't like.)
"I didn't know about that law!" is not a defense; as you pile on more laws, though, the chance that you didn't know about that law rises to unity. Using firearm laws as an example, the laws on the books since we were children were not being enforced, so the "popular" answer was to pass new laws! Some of those new laws made sense, some of them just warmed over what was already on the books.
The problem is that a legislature is sorely tempted, at some point, to stop telling us prohibitions and start telling us permissions. At that point, civil liberties are out the windows.
OK, so I'm an old fuddy-duddy who remembers the days of vinyl. When I was a kid I got an old tube-type pre-amp that had an unusual dial on it. It selected the record de-emphasis to use for each particular label, and it had 19 positions. That's right, each record cutting company had its own ideas as to what the "best" pre-emphasis curve to use to reduce SNR without overcutting the record. (Yes, this was in the days of 78-rpm records, although even the early 33-1/3-rpm records were cut using proprietary filters.)
One of the reasons the Recording Industry Association of America, a.k.a the hated RIAA, was formed was to reign in the madness and develop some sensible standards for recordings. The work of the RIAA was to reduce the cost of both recording and playing back recordings in a number of formats: vinyl, magnetic tape, and at one point magnetic wire. By reducing the Babel, makers of cartridge pre-ampliers would need to put in less circuitry, makers of record-cutting lathes could provide the "standard" circuits for each speed/format, and the listening public didn't have to mess with that 19-position knob anymore when changing records.
The RIAA did such a good job that it put itself out of its original business, setting standards. Much of the standards work is now done by the developers of media: Phillips for cassettes, and I don't recall who brought us the digital compact disc. The DVD is pretty much out of RIAA's hands, too.
Interesting that the RIAA and many computer engineers have something in common -- a lack of need for what they do...
Yes, it's easy to read, but most varients of COBOL and most especially the first ANSI COBOL was the absolute devil to WRITE -- and writing programs is what it is all about. The basic structures were easy, but try doing a complex multi-phrase selector in the language -- you need the book and then some in order to keep the clauses from tripping over each other. Unlike ALGOL, PL/I, and C, the "sentence" structure of COBOL can be its own worst enemy.
When the shortage gets bleak enough that people are willing to take people without narrow skills like years of DB/2, then I'll get back into the mainframe world. Like the so-called "programmer shortage" that the H-1B visa boosters complain about, the mainframe shortage is of the same order of balderdash.