Actually, the -e switch doesn't work under ash and some versions of ksh (including that shipped with HP-UX), where it's a built in.
I don't remember whether I found any copies of/bin/test that don't support -e.
As I recall, the problem with accept() actually had to do with socklen_t, which isn't defined the same on all platforms.
It's not a big deal, but I like to keep my code warning free.
I was hoping to help them by providing software to at least partially automate their processes.
Testing is not a job that exercises a lot of creativity, unlike development.
If your observation is an accurate reflection of your QA department, then it may not be prepared to take on the responsibility of automation.
As another poster says, test automation is a full-time job.
Like most development projects, the test tools and the tests themselves require maintenance.
You can give them a pole, but they need to know how to fish.
Is your company willing to pay $50K+ for QA staff with this expertise?
Put another way: would you work in your company's QA department?
I was running a 1 GHz Athlon on a KT133A board that died (of the dreaded capacitor goo).
I replaced it with a KT266A board that died, at which point it became difficult to find anything that supports PC133.
Somewhere in the process of diagnosing all of this, I cracked the CPU core.
Faced with buying a new motherboard and new RAM, the cost of an Athlon 64 over an Athlon XP seemed worth it.
This review claims that the cheapest socket 939 processor is $450.
With the recent price drops, you can get a retail 3500+ for about $350, compared to $220 for a 3200+ or $175 for 3000+.
Also, the review would have been much more useful had it shown results for both versions of the 3200+, so that you can compare the impact of clock speed and cache.
Good advice to actually seek out test platforms. I've found subtle bugs in shell scripts and POSIX-ish C code on certain platforms.
Some examples:
The ls command returns success on OS X, even if no files were found.
The test command has some options, like -e, which are not portable.
HP-UX requires an ioctl() to detect that a slave PTY has closed.
AIX has fewer than 64 PTYs configured, by default, which exposed a bug in one of my programs.
There seems to be disagreement on the types of some socket functions.
I have yet to figure out how to get the client's address from accept() without causing a compile warning on at least one platform.
Reaping child processes seems to be another mess.
The most portable solution I've found is to double fork, letting init clean up the zombies.
I've started porting a Unix program to Windows and VMS, which has been interesting.
For example, Windows and VMS both have a select() function, but it only works on sockets.
The popen()/_popen() function on Unix and Windows doesn't redirect stderr, whereas it does on VMS.
VMS only lets you get the actual exit status from waitpid() or pclose() in recent versions.
You can always try to install gcc in some temp dir.
This may not be an option for the latest version of GCC. I seem to recall a mention in the release notes that you can no longer bootstrap with a K&R compiler.
automation maintenance for even a small suite... is a full time job
Excellent point.
I am fortunate to be able to work on test automation full time, and to have at least one other person to do most of the "lab jockey" chores.
My day is divided between improving the tools, writing new tests, and analyzing results (which often requires revising a test).
There are times when I resist adding new tests (usually a big pile of stored procedures that a developer or another tester wrote), because I don't have the resources to analyze the results and maintain the code.
you shouldn't be doing large scale testing on your own systems
I would qualify that statement by saying that you shouldn't be the only one to test your own system.
Development should do unit testing.
QA should do functional testing.
The sooner you test, the sooner you find bugs.
The more experience you have (with testing and with the product), the more productive you can be.
End user testing is great, but it's only one part of the process.
I've used SilkTest for the last five years, and I'm working on getting rid of it.
I have not been able to develop an effective strategy for automated testing of GUIs, and it is not ideal for the rest of the automation I do (mostly CHUIs and APIs).
Good:
the 4Test scripting language
easy to call out to some Windows API functions
Mixed:
the outline-based test selection (I'd rather query a database)
the results view (I'd really rather put the results in a database)
Bad:
the cost (~$5,000 / seat)
the maintenance (~$1,000 / year)
the licensing scheme (node-locked license server)
the support (before and after they sent it to Ireland)
how about price in dollars squared times year of release?
Price is not a very good approximation of performance.
A few current examples:
the $352 Athlon 64 3500+ is not 61% faster than the $219 Athlon 64 3200+
the $829 Athlon 64 FX-53 is not 55% faster than the $535 Athlon 64 3700+
the $995 3.4 GHz Pentium 4 EE is not 139% faster than the $416 3.4 GHz Pentium 4
Each of these pairs runs at the same clock speed, and has a performance difference of about 5% (with, perhaps, a few exceptions for the EE).
At its worst, clock speed tells me that a 3.4 GHz Pentium 4 is 42% faster than a 2.4 GHz Athlon 64, but I'm already aware that the Pentium 4 is less efficient.
Intel needs to get a clue, and develop a set of benchmarks that truly show real-world performance. AMD has done quite a good job with their "+" rating.
Rating systems are annoying.
Imagine if Ford advertised the next Mustang as a 300+, because thinner tires and less weight gave it the performance of a car with 40 more HP.
Clock speed is the best first-order approximation of a chip's performance.
It is true that the Pentium 4 is less efficient, but it's not like we're talking about an order of magnitude.
At worst, we're talking about a 2 GHz Athlon 64 competing with a 3 GHz Pentium 4, a difference of 50%.
Keeping in mind that AMD claims that its ratings are derived from previous Athlon models, the variety of Athlon 64 and Sempron models gives us an opportunity to benchmark the impact of clock speed (ranging from 1.8 GHz to 2.4 GHz), L2 cache (ranging from 256 KB to 1 MB), and memory bandwidth (single- v. dual-channel).
Doubling the cache or bandwidth is usually worth less than a 10% increase in clock speed.
I think that Intel's NetBurst gamble was, in large part, a marketing ploy.
I also think that it was successful.
However, it was an expensive ploy, from which Intel appears to be retreating.
If it takes a billion dollars to temporarily skew clock speed by 50%, I'd say it's holding up pretty well.
It makes AMD64 seem like it's not a priority; if Microsoft isn't excited about it, then customers won't be, either.
It leaves IA64 as the only option for people who need 64-bit Windows today.
It gives EMT64 an opportunity to catch up to AMD64 and, perhaps, give Intel a stronger voice in defining the standard.
Microsoft declared that it would not make yet another 64-bit Windows, implying that Intel had better play ball with AMD.
That was an easy position to hold when EMT64 was just on paper.
If there's actual silicon in customer's hands before Windows is shipped, then Intel has a much stronger case for changing the platform somehow.
On the one hand, the fact that it's taking so long looks bad for AMD64.
On the other hand, the folks at AMD wisely delivered top-notch 32-bit performance.
In some ways, this delay further vindicates the AMD64 design, despite all the x86 haters.
I'm not sure you can market any incompatible architecture to the PC market, with the possible exception of OS X on PowerPC.
AMD64 is the perfect bridge.
If Intel gets another year to catch up, that's okay.
In fact, it may lend credibility to a market in which AMD is poised to excel.
Initial reports are that Intel's EMT64 implementation is lacking.
It may take a generation or two for them to catch up.
After the recent price cuts, my Athlon 64 is in the mail.
While I will install Windows 2000 to get my Doom 3 fix, this machine will probably spend more time running SuSE Linux 9.1.
the issue of being able to GUARANTEE that your code base is not and cannot be coerced is very real.
Free software competes with companies that, in most cases, can make no such guarantee.
In an era of outsourcing, H1-B, and high turn over, proprietary software can hardly be considered safer than free software.
Consider Microsoft's early efforts at Chinese localization, which turned out to contain anti-communist slogans.
Not a big deal, but it must have been a lot more overt than slipping in a vulnerability.
Anybody COULD do anything. Why don't you report on it when MS does?
If HP is cooling its heels because of Microsoft threats, then this is newsworthy.
No less than the VP of strategic marketing said: "We will need to change how we donate software to the open source, probably the type of license we use, lower the profile of our opensource portal, etc."
I bet he has other plans, rather than GPLing the source.
I reckon so.
The reference to "our service" makes it sound like the first outing will be on line, like Motor City (or Hawaii or TEN).
Judging by the disparaging comments about retail, it won't likely be cheap, either.
I like Papy's games (especially Grand Prix Legends), but I wish they had spent a little more time on the gameplay.
NASCAR Heat isn't half the sim that NASCAR Racing 4 is, but the challenges are fun, and require a much smaller time commitment.
Ditto Need for Speed: Porsche Unleashed.
I'd also like to see the representation of the sport approach the fidelity of the car: provisionals, multi-car teams, sponsorships, spotter-negotiated partnerships, rules changes, and so on.
The single-player experience may never rival that of league racing, but it's a huge cop out to ignore it.
You can look at GPL's poor sales and decry the unwashed masses, or you can explore ways to make the racing experience more fun and less intimidating.
Language standards don't even last 200 years, how do we expect something as new as software standards to be more uniform than language standards?
How do you know?
Lisp has been around for a while, and it's not dead, yet.
Some Lispers are working on a language called Arc, which they hope will last a hundred years.
On another front, perhaps Parrot or.NET will provide a stable base that will allow languages to evolve, while remaining compatible.
That said, I don't think it's necessary for a long-lived software project to use one language, exclusively.
Standard interfaces can commoditize the language, to some extent.
No company in the world will ever try and develop software that never needs (costly) upgrades and add-ons.
The author is clearly aware of the problems of that kind of incentive model, and devotes several paragraphs to addressing it.
An important point is that free software doesn't have to be about "pet projects."
The incentive for a for-profit company or a volunteer to develop and maintain the software can't match that of the actual users.
People are recognizing that free software is more than a fad.
It's time that collaborative development models move out of the basement and into the mainstream.
I'm not talking about IBM or Novell pitching in to Linux or GNOME;
I'm talking about customers really banding together.
How many millions of dollars have colleges given to get-rich-quick Oracle VARs for slap-dash grading and payroll systems?
Can't a few thousand colleges (some of which have been in existence for 200 years) scrape together the cash and manpower to make a decent database that meets their needs?
For that matter, consider schools in developing countries, for whom license fees are out of all proportion.
Even if you give them a fee-free license, it's tantamount to giving them genetically neutered crops.
I agree that it's unrealistic to expect software not to change for 200 years, because its problem domain is so much more dynamic than "don't fall into the river during a storm or earthquake."
I don't think the author is making that literal an argument.
The important thing is that there be continuity, to preserve the investment in training and data.
0, EXIT_SUCCESS, and EXIT_FAILURE are the only portable exit values.
I'm pretty sure you'll find that returning 0 from main() on VMS results in a $severity value of 1.
You may be able to return 0 with a non-standard function, like _exit().
I suppose most of the "missing manuals" are worthless
The only Missing Manual I've spent any time with is for Mac OS X.
So far, it has been a worthwhile purchase.
I've picked up several tips in the first few chapters, especially keyboard shortcuts.
These may be in the on-line help, but I'm getting up to speed more quickly with the book.
I haven't felt the urge to get the iPod book.
Maybe if I wanted to figure out how to copy songs, or boot from the iPod, it would be worth it.
Even then, for one or two tasks, Google and USENET are your friends.
One of my favorite books is Unix Power Tools.
O'Reilly's Hacks series is similar, but less comprehensive.
A quick peek at Mac OS X Hints was encouraging, as well.
I happened upon a hint to turn off the textured metal skin of a Cocoa app. by opening a file from its package in Xcode.
Check the About dialog to confirm that you actually downloaded 0.9.1. I accidentally clicked on one of the European links on the front page and got 0.9.
Of more general concern is the fact that such special exemptions need to be made in the first place, suggesting that the whole DMCA is bogus in the first place.
Copyright is a monopoly granted for a limited time, after which the work goes into the public domain.
Copy protection is an attempt to renege on the deal.
If copy protection is legal, but circumvention is not, then copy protected works should enjoy no copyright protection.
I think it's pretty safe to say we're gonna have an all new iMac at WWDC.
My first reaction to the new PowerMac line up was underwhelming.
Then I realized that the bottom of the line just got more expensive--no 1.6, no SP.
Then it occurred to me that a good reason to drop SP PowerMacs was to avoid overlap with new iMacs (headless, please).
I'd like to build a system with a 35 W mobile Athlon 64 (e.g., AMD2800BQX4AX).
It would be just the ticket for a Shuttle, or even a quiet mid tower.
The only problem is, it lacks the integrated heat spreader, so I don't know what heat sink to use.
The problems with Microsoft/virus issue are all legacy issues.
We just read a story about Netscape's last gasp against IE's dominance, in which one comment linked to Browsers used to visit Google, April 2004.
The graph shows an overwhelming adoption of IE 6.0--if Microsoft delivers a secure browser, users will adopt it.
Slashdot Mirror
As I recall, the problem with accept() actually had to do with socklen_t, which isn't defined the same on all platforms. It's not a big deal, but I like to keep my code warning free.
If your observation is an accurate reflection of your QA department, then it may not be prepared to take on the responsibility of automation. As another poster says, test automation is a full-time job. Like most development projects, the test tools and the tests themselves require maintenance. You can give them a pole, but they need to know how to fish. Is your company willing to pay $50K+ for QA staff with this expertise? Put another way: would you work in your company's QA department?
I was running a 1 GHz Athlon on a KT133A board that died (of the dreaded capacitor goo). I replaced it with a KT266A board that died, at which point it became difficult to find anything that supports PC133. Somewhere in the process of diagnosing all of this, I cracked the CPU core. Faced with buying a new motherboard and new RAM, the cost of an Athlon 64 over an Athlon XP seemed worth it.
This review claims that the cheapest socket 939 processor is $450. With the recent price drops, you can get a retail 3500+ for about $350, compared to $220 for a 3200+ or $175 for 3000+. Also, the review would have been much more useful had it shown results for both versions of the 3200+, so that you can compare the impact of clock speed and cache.
- The ls command returns success on OS X, even if no files were found.
- The test command has some options, like -e, which are not portable.
- HP-UX requires an ioctl() to detect that a slave PTY has closed.
- AIX has fewer than 64 PTYs configured, by default, which exposed a bug in one of my programs.
- There seems to be disagreement on the types of some socket functions.
I have yet to figure out how to get the client's address from accept() without causing a compile warning on at least one platform.
- Reaping child processes seems to be another mess.
The most portable solution I've found is to double fork, letting init clean up the zombies.
I've started porting a Unix program to Windows and VMS, which has been interesting. For example, Windows and VMS both have a select() function, but it only works on sockets. The popen()/_popen() function on Unix and Windows doesn't redirect stderr, whereas it does on VMS. VMS only lets you get the actual exit status from waitpid() or pclose() in recent versions.This may not be an option for the latest version of GCC. I seem to recall a mention in the release notes that you can no longer bootstrap with a K&R compiler.
Excellent point. I am fortunate to be able to work on test automation full time, and to have at least one other person to do most of the "lab jockey" chores. My day is divided between improving the tools, writing new tests, and analyzing results (which often requires revising a test).
There are times when I resist adding new tests (usually a big pile of stored procedures that a developer or another tester wrote), because I don't have the resources to analyze the results and maintain the code.
I would qualify that statement by saying that you shouldn't be the only one to test your own system. Development should do unit testing. QA should do functional testing.
The sooner you test, the sooner you find bugs. The more experience you have (with testing and with the product), the more productive you can be. End user testing is great, but it's only one part of the process.
Good:
Mixed:
Bad:
Price is not a very good approximation of performance. A few current examples:
- the $352 Athlon 64 3500+ is not 61% faster than the $219 Athlon 64 3200+
- the $829 Athlon 64 FX-53 is not 55% faster than the $535 Athlon 64 3700+
- the $995 3.4 GHz Pentium 4 EE is not 139% faster than the $416 3.4 GHz Pentium 4
Each of these pairs runs at the same clock speed, and has a performance difference of about 5% (with, perhaps, a few exceptions for the EE).At its worst, clock speed tells me that a 3.4 GHz Pentium 4 is 42% faster than a 2.4 GHz Athlon 64, but I'm already aware that the Pentium 4 is less efficient.
Rating systems are annoying. Imagine if Ford advertised the next Mustang as a 300+, because thinner tires and less weight gave it the performance of a car with 40 more HP.
Clock speed is the best first-order approximation of a chip's performance. It is true that the Pentium 4 is less efficient, but it's not like we're talking about an order of magnitude. At worst, we're talking about a 2 GHz Athlon 64 competing with a 3 GHz Pentium 4, a difference of 50%.
Keeping in mind that AMD claims that its ratings are derived from previous Athlon models, the variety of Athlon 64 and Sempron models gives us an opportunity to benchmark the impact of clock speed (ranging from 1.8 GHz to 2.4 GHz), L2 cache (ranging from 256 KB to 1 MB), and memory bandwidth (single- v. dual-channel). Doubling the cache or bandwidth is usually worth less than a 10% increase in clock speed.
I think that Intel's NetBurst gamble was, in large part, a marketing ploy. I also think that it was successful. However, it was an expensive ploy, from which Intel appears to be retreating. If it takes a billion dollars to temporarily skew clock speed by 50%, I'd say it's holding up pretty well.
Microsoft declared that it would not make yet another 64-bit Windows, implying that Intel had better play ball with AMD. That was an easy position to hold when EMT64 was just on paper. If there's actual silicon in customer's hands before Windows is shipped, then Intel has a much stronger case for changing the platform somehow.
If Intel gets another year to catch up, that's okay. In fact, it may lend credibility to a market in which AMD is poised to excel. Initial reports are that Intel's EMT64 implementation is lacking. It may take a generation or two for them to catch up.
After the recent price cuts, my Athlon 64 is in the mail. While I will install Windows 2000 to get my Doom 3 fix, this machine will probably spend more time running SuSE Linux 9.1.
Free software competes with companies that, in most cases, can make no such guarantee. In an era of outsourcing, H1-B, and high turn over, proprietary software can hardly be considered safer than free software. Consider Microsoft's early efforts at Chinese localization, which turned out to contain anti-communist slogans. Not a big deal, but it must have been a lot more overt than slipping in a vulnerability.
If HP is cooling its heels because of Microsoft threats, then this is newsworthy. No less than the VP of strategic marketing said: "We will need to change how we donate software to the open source, probably the type of license we use, lower the profile of our opensource portal, etc."
I reckon so. The reference to "our service" makes it sound like the first outing will be on line, like Motor City (or Hawaii or TEN). Judging by the disparaging comments about retail, it won't likely be cheap, either.
I like Papy's games (especially Grand Prix Legends), but I wish they had spent a little more time on the gameplay. NASCAR Heat isn't half the sim that NASCAR Racing 4 is, but the challenges are fun, and require a much smaller time commitment. Ditto Need for Speed: Porsche Unleashed. I'd also like to see the representation of the sport approach the fidelity of the car: provisionals, multi-car teams, sponsorships, spotter-negotiated partnerships, rules changes, and so on. The single-player experience may never rival that of league racing, but it's a huge cop out to ignore it.
You can look at GPL's poor sales and decry the unwashed masses, or you can explore ways to make the racing experience more fun and less intimidating.
How do you know? Lisp has been around for a while, and it's not dead, yet. Some Lispers are working on a language called Arc, which they hope will last a hundred years. On another front, perhaps Parrot or .NET will provide a stable base that will allow languages to evolve, while remaining compatible.
That said, I don't think it's necessary for a long-lived software project to use one language, exclusively. Standard interfaces can commoditize the language, to some extent.
The author is clearly aware of the problems of that kind of incentive model, and devotes several paragraphs to addressing it. An important point is that free software doesn't have to be about "pet projects." The incentive for a for-profit company or a volunteer to develop and maintain the software can't match that of the actual users.
People are recognizing that free software is more than a fad. It's time that collaborative development models move out of the basement and into the mainstream. I'm not talking about IBM or Novell pitching in to Linux or GNOME; I'm talking about customers really banding together. How many millions of dollars have colleges given to get-rich-quick Oracle VARs for slap-dash grading and payroll systems? Can't a few thousand colleges (some of which have been in existence for 200 years) scrape together the cash and manpower to make a decent database that meets their needs?
For that matter, consider schools in developing countries, for whom license fees are out of all proportion. Even if you give them a fee-free license, it's tantamount to giving them genetically neutered crops.
I agree that it's unrealistic to expect software not to change for 200 years, because its problem domain is so much more dynamic than "don't fall into the river during a storm or earthquake." I don't think the author is making that literal an argument. The important thing is that there be continuity, to preserve the investment in training and data.
0, EXIT_SUCCESS, and EXIT_FAILURE are the only portable exit values. I'm pretty sure you'll find that returning 0 from main() on VMS results in a $severity value of 1. You may be able to return 0 with a non-standard function, like _exit().
The only Missing Manual I've spent any time with is for Mac OS X. So far, it has been a worthwhile purchase. I've picked up several tips in the first few chapters, especially keyboard shortcuts. These may be in the on-line help, but I'm getting up to speed more quickly with the book.
I haven't felt the urge to get the iPod book. Maybe if I wanted to figure out how to copy songs, or boot from the iPod, it would be worth it. Even then, for one or two tasks, Google and USENET are your friends.
One of my favorite books is Unix Power Tools. O'Reilly's Hacks series is similar, but less comprehensive. A quick peek at Mac OS X Hints was encouraging, as well. I happened upon a hint to turn off the textured metal skin of a Cocoa app. by opening a file from its package in Xcode.
Check the About dialog to confirm that you actually downloaded 0.9.1. I accidentally clicked on one of the European links on the front page and got 0.9.
Copyright is a monopoly granted for a limited time, after which the work goes into the public domain. Copy protection is an attempt to renege on the deal. If copy protection is legal, but circumvention is not, then copy protected works should enjoy no copyright protection.
My first reaction to the new PowerMac line up was underwhelming. Then I realized that the bottom of the line just got more expensive--no 1.6, no SP. Then it occurred to me that a good reason to drop SP PowerMacs was to avoid overlap with new iMacs (headless, please).
I'd like to build a system with a 35 W mobile Athlon 64 (e.g., AMD2800BQX4AX). It would be just the ticket for a Shuttle, or even a quiet mid tower. The only problem is, it lacks the integrated heat spreader, so I don't know what heat sink to use.
We just read a story about Netscape's last gasp against IE's dominance, in which one comment linked to Browsers used to visit Google, April 2004. The graph shows an overwhelming adoption of IE 6.0--if Microsoft delivers a secure browser, users will adopt it.