Instead of inspecting lots of stuff in your code with the debugger, code what you are looking for in the form of assertions and invariants. That way, your knowledge will become part of the code. It will document it and verify it much more thoroughly than you ever could in a debugger.
Relying on debuggers is a bad habit, and it is didactically bad for systems like Visual C++ to make it so easy. Very early on, beginning programmers may find program tracing educational, but programmers at such early stages shouldn't be using C++ to begin with.
I've had lots of headaches with Compaq hardware as well, both under Linux and under various versions of Windows.
The problem is that Compaq decides to do things differently with no apparent good reason. For example, on my desktop machine, there is no BIOS configuration screen. Instead, you are supposed to install a configuration system on the first partition of your hard disk. That thing turns out to be a Windows 3.1 derivative, complete with BSOD.
Linux cannot support every weird piece of hardware in existence--you have to look at the hardware you are buying and make sure it works with your OS. After all, the hardware you bought wouldn't run MacOS either, and it would probably not run BeOS or other PC-based operating systems either.
You got exactly what was advertised and what you bargained for: a low-cost system running a particular version of Windows that will probably never be really happy running anything else. And there is probably a good reason why it was so cheap: Compaq systems are always a pain, even running Windows.
Next time, if you want a Linux system, go out and configure and buy something that's compatible. Unless, of course, you enjoy fiddling around with oddball hardware, but if you do, don't complain about it.
And if you want to redeem your current situation, go out and invest maybe $100 in a new modem, a new Ethernet card, and a new graphics card, and your system probably will still work OK. If it uses a USB keyboard, you probably also should be running RedHat 7.0 or some other more recent distribution.
Mature teens want to gain skills [in highschool] that will help them in life.
And if they think that learning to operate a vendor-specific IDE that will be obsolete in two years represents those skills they are either not very mature or not very smart.
Most high-school programmers I know, and it continues into high-school, realize that *nix hacking is fun- but not likely to provide a decent living.
UNIX jobs pay just fine, and there are lots of them out there.
But perhaps more importantly, in my experience, companies prefer people with a UNIX background even for Windows NT jobs. The reason is that when the going gets tough, NT is really much more like UNIX than like the GUI-based auto-magic system it pretends to be. Even though most of our users run Windows, almost everybody on our staff has a good grasp of UNIX, and most of them are running UNIX themselves on some machine.
It's really much like the old line "give someone a fish and you feed them for a day, give them a fishing rod and you'll feed them forever". NT and its color-by-the-numbers approach is giving someone a fish, but to really be able to survive in the long term, people need deeper skills.
If you start developing for KDE/Qt, you will be developing for a GPL'ed library from a single vendor.
That's fundamentally different from using GPL'ed software like gcc. If you start developing using gcc, your software doesn't automatically become GPL'ed and you can always switch to any of a number of other vendors.
With KDE/Qt, if you start developing for it, you are for practical purposes tied to the library and the company. If you ever want to make a commercial version of your software, you must license from that vendor and pay whatever they ask.
Choosing a complex library that falls under the GPL is a big step that you need to consider very carefully, since it closes off most of your options later on. My recommendation would be to stay away from KDE/Qt development, as well as from any library portions of Gnome/GTK that are covered by the GPL. Of course, there is no problem with using GPL'ed software as applications or tools.
It's also unnecessary to make that kind of commitment to a GPL'ed library when it comes to GUI libraries. wxWindows is a very complete C++ interface to several different toolkits, including Win32 and GTK, and if anybody cares to, it could be adapted to a Qt backend as well. And FLTK is a nice, simple cross-platform GUI library, good for many applications and much easier to deploy than either GTK or Qt.
optical mark recognition and standard ballot
on
eLection '04
·
· Score: 1
The punch ballots from Palm Beach are really antiquated technology and cannot even be scanned very reliably using the devices built for it back then.
But optical mark recognition, where you check boxes on paper, seems like a good compromise. It's easy to use (pencil and paper), keeps a permanent record that humans can recount if necessary, can be evaluated easily, it's cheap, and it can easily be used inside polling booths.
The only other change I would like to see is the adoption of a universal format for ballots: one column, candidates (or propositions) listed in 12 pt font on the left with big check boxes on the right. Candidates would be separated from one another by thick lines. Different ballots may have different sets of candidates and propositions, but they would be handled just by adding more pages.
With Internet or computer-based voting, there are all sorts of security problems. You can't just go back later and reexamine the original votes. And if you can vote over the Internet, unlike the voting you do in the privacy of the booth, you can be coerced by someone to vote the way they want.
If.NET is about cross platform programming, where are the specifications for the cross-platform runtime and the cross-platform APIs? Without those,.NET is merely a VisualBasic runtime on steroids--nice for Windows programmers and occasionally capable of running on non-Windows machines, but nothing more.
I think you underestimate the functionality of Java implementations. Yes, Java is a pretty simple object-oriented language that you can compile to.NET and other platforms. But Java also has a well-specified, very powerful runtime that offers functionality (dynamic inlining/optimization, sandboxing, reflection, dynamic code generation, etc.) that goes beyond anything available in.NET or most other languages and runtimes.
Will the Java runtime functionality matter in practice? That remains to be seen. Maybe Sun tried to do too much for the industry to swallow at once. Maybe.NET is better matched to the incremental needs of Windows programmers. But let's not compare apples and oranges. Java isn't just.NET for only one language, it is much more powerful than that.
I assume you are complaining about large memory usage for a JVM. 153M suggests that you are running a fairly big program, not something that's intrinsic to the JVM. But, still, yes, full Java runtimes take more memory than C++ runtimes.
There are many reasons for that. One is that for native Windows programs, the OS doesn't account for all the resources in the process size: shared libraries and other resources are not mentioned. Another is that supporting some of the functionality in Java requires more runtime support, like dynamic compilation and reflection. Those are very useful, but they aren't cheap. There are some parts of the Java libraries that ought to be optimized (more packed representations for images, for example), so if you are using a lot of images, your process might be larger than an equivalent Windows program. And memory management by the Java runtime may appears to use more memory than it actually does anyway.
If you want to, you can batch-compile Java just like you batch-compile C++ or.NET, and you get executables with similar size and similar behavior. But you also get similar limitations on dynamic loading and reflection as you would get in C++ and.NET.
Java process sizes already aren't a problem for most applications (in particular, server applications). In a few years, they'll seem miniscule, just like the humungous Windows executables from a few years ago are the lean and mean applications of today.
So? What does that have to do with the bogosity of Natapoff's argument? Natapoff claims that the EC is good because it gives individual votes more influence "on the average" (under a pretty shaky assumption of "average"). That says nothing about the power of smaller states.
In fact, the only reason smaller states have more power is because they have disproportionate representations in the EC. If you wanted to preserve that principle, you could easily do so in a popular system: just weigh the votes from those states more heavily. Of course, trying to get support for that would probably be next to impossible. And that simply exposes the hypocrisy of the argument: by hiding behind a baroque electoral systems, smaller states want more power.
[Sun has] gotten so miffed with the slow Java adaptation of Java
that they view everything as a threat.
Slow Java adoption? What are you talking about? Java has been adopted more rapidly more widely than probably any other programming language in history.
But you can't outrun native code, no matter
how good your universal language is.
What do you mean by this. Java is "native": it's compiled to native code, and it has a set of native APIs that can be implemented very efficiently.
.NET has no advantage in that regard. If anything, it's way behind..NET's APIs are layered on top of decade old Windows cruft, and its runtime and compiler technology is both more primitive and less mature than Java's.
Sure, the electoral college increases the probability that an individual vote matters. But why stop there? We can increase it even further with the following procedure: have everybody vote, then randomly pick one person, and use only their choice to elect the president. Or, to save money, we can even dispense with the troublesome collecting of 100 million votes and pick that person randomly first and set up a voting booth just for that person (much cheaper). I somehow doubt that people would find that procedure very democratic.
Even if Natapoff were right and there were some magic sweet spot between popular elections and a random individual vote, it would seem to be mathematically better then to pick the blocs of voters that decide the electoral college at random rather than using the current geographical scheme.
Clearly, there are other issues involved in how to pick a president. Like democratic principles.
No matter what the folks at SDMI come up with, it will be circumventable: it is intrinsically impossible for watermarks to be secure.
The real problem I see is that SDMI will probably also get erased by accident by increasingly good compression technologies. What is going to happen then? Most like the music industry will scream "bloody murder" and be all up in arms about better compression standards (as if they weren't already), not just because they make distribution of music easier, but also because they erase the SDMI watermark.
In fact, a particularly cynical view of all of this would be that SDMI is intentionally weak in order to be able to have a future claim, based on DMCA, against the deployment of better, or at least alternative, audio compression techniques.
All of that is covered by your legal contract with your university. That may be a contract by which you buy educational services, or it may be an employment contract, or both. It may be a written piece of paper you sign at some point, or it may be just by convention and "university rules" (the latter would be easier to challenge). The university may also present you with choices halfway through: "well, it's your third year now, and here is our new intellectual property policy; sign it or leave".
How you got paid, or even if you got paid, doesn't intrinsically matter. Your contract might well have you pay for your education yourself and still assign all rights to your intellectual property to the university.
There are, indeed, situations where you cannot talk about your thesis research in public (e.g., if your thesis research was done as part of a collaborative project with industry). You'd probably know about that before hand.
If you release your thesis into the public domain, or do anything else with it that wasn't allowed for in your contract, what happens depends. The university certainly has no obligation to accept anything as a dissertation, so they could just refuse it. But (perhaps more importantly), you might be legally liable for breach of contract and damages. For example, if your thesis research is on the clinical effectiveness of some new drug and you release it to the press ahead of time, this may cost lots of people lots of money.
Having said all that, I don't approve of many of these things. But the only way to deal with them is to be informed, address them ahead of time, and make your choices accordingly. Either you attend the famous XYZ U. and buckle under to their intellectual property policies, either you take the lucrative biomedical research job that gives you a good thesis but requires you to keep your mouth shut, or you decide to go elsewhere. It's your choice; find out ahead of time and don't be naive about it.
The concept of "spare time" is pretty difficult to define for students or professionals, and many employment contracts explicitly don't recognize the notion.
In real life, if some software development is even vaguely related to your job, chances are your employer will claim that it was developed as part of your job, whether you did it at 3pm or 3am. And they probably will have a reasonably good chance of prevailing with that claim.
It is regrettable that universities are following suit (and they are, in my experience), trying to patent and copyright a lot of code and writings students produce while enrolled. But regrettable or not, legally, they probably have the same justification for doing it as any other employer.
I'm amazed they were able to slip that
into the bill since the intent of the bill was to get more cheap labor.
Perhaps your basic assumption is wrong: the politicians and companies that I know did not and do not consider H1Bs slave labor.
In fact, until 1998, INS processing was quick enough that people usually could change jobs within a year, even if they just started their greencard application. The current problems are entirely due to INS processing delays, and Congress seems to have that addressed quickly and efficiently.
As for your company, I'd change jobs in your position. If your company engages in such practices, it doesn't seem like it values its workers. This is not common practice in the industry.
But the "newcomer" always could change jobs. With INS inefficiencies, it became a bit more of a hassle and risk in recent years, and it's good that the H1B bill addresses this issue. But the notion that an H1B holder is "slave labor" paid "half the price" is a myth created by people with a political agenda.
That's an urban legend. H1B visa holders are paid reasonable wages. Even if the employer could somehow hold them responsible for the application fee for their visa after the employer already has paid it, the employee (or their new employer) could simply pay it off; $2500 is not a lot of money. Your suggestion that H1B holders are somehow indentured servants for several years is just wrong.
The increased portability of H1B's is nice, although I think portability was never such a big problem.
But the bill fixes some other problems that perhaps were much more serious. For example, H1B holders used to lose their job and had to leave the country if the INS didn't manage to process their greencard applications in a timely manner (even just getting an already approved green card issued now can take nearly 3 years). It also allows many greencard applicants to change jobs while the INS is sitting on those applications.
The problem with it all is that the new bill creates even more paperwork for the INS to handle: new H1B visas, new forms, new applications. If they couldn't handle the old volume of paperwork, how are they going to deal with this?
The farmer in Africa might not give a damn about HTML coding, but he probably cares a lot about being able to get weather data, get advice on how to install a well without endangering his family (biological or mineral contamination) or his crop (lowering the water level), get instant information on crop prices on the world market (to negotiate sales of his crops better), to get financial information, to get information about birth control and STDs, and similar issues.
That kind of information can be delivered effectively and cheaply by computers. It can't be delivered effectively and cheaply by mail, by telephone, or by aid workers.
And did I say anything about Linux? Why does it always have to come down to Linux vs. Windows for you? Clearly, both Linux and Windows are too hard to install and manage, and the PC architecture is hardly robust enough. People need devices that turn on and work, that can be run off batteries and solar power, and that can communicate reliably in rural areas.
Unfortunately, the self-righteous and simplistic view you voice is fairly common. But we have followed that road, more efficient production, for centuries, and it has only multiplied our problems. Instead of a few hundred million people in poverty, we now have billions. Without social change, no matter how much you produce, you will continue to have starvation, poverty, and wars.
In fact, the world doesn't even need more food, water, or shelter. We have ample of each to provide even for our current population.
The problems we are facing are economic and social. We need to distribute resources efficiently, limit population growth, and limit consumption.
The only solution to our problems lies in better education, better communication, better public health, and more efficient economic systems. And information technology is probably the best tool we have for that.
It's true that parts of Microsoft may develop that way, but that's unrelated to my point. You are confusing Microsoft's internal development methods with the development methods that they are marketing and targetting for their customers.
Microsoft's internal development style is atypical for the industry. In fact, many of the core groups in Microsoft don't use the bells and whistles of Microsoft's own tools. The industry buys Microsoft products because Microsoft promises them that they don't have to develop in the kind of style you advocate and that they use internally.
But, by all means, if you are Microsoft and you are out to "crush" a company like Netscape, and the consumer be damned, go ahead and adopt Microsoft management strategies. Most companies, however, aren't Microsoft, not in size, not in cash resources, not in distribution channels, not in ability to hack the OS, not in available stock options, and not in hiring possibilities, and most companies have different goals and competitors, so it is unlikely that adopting Microsoft-style management will work for them.
(Nevertheless, small teams and focus are, of course, important for successful development, and Netscape did make many mistakes.)
Much of the energy consumptions of laptops is the screen and the disk, so it isn't clear that even doing something significant with power usage in the processor is going to help battery life that much. And Crusoe seems like its software component might be prone to compatibility and installation problems.
Much of the power that Pentium requires is probably due to the complexity of the instruction set and the need for backwards compatibility. Particularly for non-Windows operating systems, just going with a simple, well-designed chip other than Pentium (ARM?) may give you the benefits of Crusoe without the potential complications. You can still emulate the x86 for compatibility.
In short, unless IBM demonstrates really very significant improvements in performance and battery life in actual laptops, I wouldn't rush out to buy one: either, I'd get a non-Pentium machine (WindowsCE, converted to Linux), or I'd just stick with Pentium or a direct clone. Compaq and IBM probably came to the conclusion that many potential customers think that way.
Slashdot Mirror
Relying on debuggers is a bad habit, and it is didactically bad for systems like Visual C++ to make it so easy. Very early on, beginning programmers may find program tracing educational, but programmers at such early stages shouldn't be using C++ to begin with.
The problem is that Compaq decides to do things differently with no apparent good reason. For example, on my desktop machine, there is no BIOS configuration screen. Instead, you are supposed to install a configuration system on the first partition of your hard disk. That thing turns out to be a Windows 3.1 derivative, complete with BSOD.
You got exactly what was advertised and what you bargained for: a low-cost system running a particular version of Windows that will probably never be really happy running anything else. And there is probably a good reason why it was so cheap: Compaq systems are always a pain, even running Windows.
Next time, if you want a Linux system, go out and configure and buy something that's compatible. Unless, of course, you enjoy fiddling around with oddball hardware, but if you do, don't complain about it.
And if you want to redeem your current situation, go out and invest maybe $100 in a new modem, a new Ethernet card, and a new graphics card, and your system probably will still work OK. If it uses a USB keyboard, you probably also should be running RedHat 7.0 or some other more recent distribution.
And if they think that learning to operate a vendor-specific IDE that will be obsolete in two years represents those skills they are either not very mature or not very smart.
UNIX jobs pay just fine, and there are lots of them out there.
But perhaps more importantly, in my experience, companies prefer people with a UNIX background even for Windows NT jobs. The reason is that when the going gets tough, NT is really much more like UNIX than like the GUI-based auto-magic system it pretends to be. Even though most of our users run Windows, almost everybody on our staff has a good grasp of UNIX, and most of them are running UNIX themselves on some machine.
It's really much like the old line "give someone a fish and you feed them for a day, give them a fishing rod and you'll feed them forever". NT and its color-by-the-numbers approach is giving someone a fish, but to really be able to survive in the long term, people need deeper skills.
That's fundamentally different from using GPL'ed software like gcc. If you start developing using gcc, your software doesn't automatically become GPL'ed and you can always switch to any of a number of other vendors.
With KDE/Qt, if you start developing for it, you are for practical purposes tied to the library and the company. If you ever want to make a commercial version of your software, you must license from that vendor and pay whatever they ask.
Choosing a complex library that falls under the GPL is a big step that you need to consider very carefully, since it closes off most of your options later on. My recommendation would be to stay away from KDE/Qt development, as well as from any library portions of Gnome/GTK that are covered by the GPL. Of course, there is no problem with using GPL'ed software as applications or tools.
It's also unnecessary to make that kind of commitment to a GPL'ed library when it comes to GUI libraries. wxWindows is a very complete C++ interface to several different toolkits, including Win32 and GTK, and if anybody cares to, it could be adapted to a Qt backend as well. And FLTK is a nice, simple cross-platform GUI library, good for many applications and much easier to deploy than either GTK or Qt.
But optical mark recognition, where you check boxes on paper, seems like a good compromise. It's easy to use (pencil and paper), keeps a permanent record that humans can recount if necessary, can be evaluated easily, it's cheap, and it can easily be used inside polling booths.
The only other change I would like to see is the adoption of a universal format for ballots: one column, candidates (or propositions) listed in 12 pt font on the left with big check boxes on the right. Candidates would be separated from one another by thick lines. Different ballots may have different sets of candidates and propositions, but they would be handled just by adding more pages.
With Internet or computer-based voting, there are all sorts of security problems. You can't just go back later and reexamine the original votes. And if you can vote over the Internet, unlike the voting you do in the privacy of the booth, you can be coerced by someone to vote the way they want.
If .NET is about cross platform programming, where are the specifications for the cross-platform runtime and the cross-platform APIs? Without those, .NET is merely a VisualBasic runtime on steroids--nice for Windows programmers and occasionally capable of running on non-Windows machines, but nothing more.
Will the Java runtime functionality matter in practice? That remains to be seen. Maybe Sun tried to do too much for the industry to swallow at once. Maybe .NET is better matched to the incremental needs of Windows programmers. But let's not compare apples and oranges. Java isn't just .NET for only one language, it is much more powerful than that.
There are many reasons for that. One is that for native Windows programs, the OS doesn't account for all the resources in the process size: shared libraries and other resources are not mentioned. Another is that supporting some of the functionality in Java requires more runtime support, like dynamic compilation and reflection. Those are very useful, but they aren't cheap. There are some parts of the Java libraries that ought to be optimized (more packed representations for images, for example), so if you are using a lot of images, your process might be larger than an equivalent Windows program. And memory management by the Java runtime may appears to use more memory than it actually does anyway.
If you want to, you can batch-compile Java just like you batch-compile C++ or .NET, and you get executables with similar size and similar behavior. But you also get similar limitations on dynamic loading and reflection as you would get in C++ and .NET.
Java process sizes already aren't a problem for most applications (in particular, server applications). In a few years, they'll seem miniscule, just like the humungous Windows executables from a few years ago are the lean and mean applications of today.
In fact, the only reason smaller states have more power is because they have disproportionate representations in the EC. If you wanted to preserve that principle, you could easily do so in a popular system: just weigh the votes from those states more heavily. Of course, trying to get support for that would probably be next to impossible. And that simply exposes the hypocrisy of the argument: by hiding behind a baroque electoral systems, smaller states want more power.
Slow Java adoption? What are you talking about? Java has been adopted more rapidly more widely than probably any other programming language in history.
What do you mean by this. Java is "native": it's compiled to native code, and it has a set of native APIs that can be implemented very efficiently.
Even if Natapoff were right and there were some magic sweet spot between popular elections and a random individual vote, it would seem to be mathematically better then to pick the blocs of voters that decide the electoral college at random rather than using the current geographical scheme.
Clearly, there are other issues involved in how to pick a president. Like democratic principles.
Apparently, a number of people (how many remains to be seen) did realize their error, asked for a new ballot, and were refused.
The real problem I see is that SDMI will probably also get erased by accident by increasingly good compression technologies. What is going to happen then? Most like the music industry will scream "bloody murder" and be all up in arms about better compression standards (as if they weren't already), not just because they make distribution of music easier, but also because they erase the SDMI watermark.
In fact, a particularly cynical view of all of this would be that SDMI is intentionally weak in order to be able to have a future claim, based on DMCA, against the deployment of better, or at least alternative, audio compression techniques.
How you got paid, or even if you got paid, doesn't intrinsically matter. Your contract might well have you pay for your education yourself and still assign all rights to your intellectual property to the university.
There are, indeed, situations where you cannot talk about your thesis research in public (e.g., if your thesis research was done as part of a collaborative project with industry). You'd probably know about that before hand.
If you release your thesis into the public domain, or do anything else with it that wasn't allowed for in your contract, what happens depends. The university certainly has no obligation to accept anything as a dissertation, so they could just refuse it. But (perhaps more importantly), you might be legally liable for breach of contract and damages. For example, if your thesis research is on the clinical effectiveness of some new drug and you release it to the press ahead of time, this may cost lots of people lots of money.
Having said all that, I don't approve of many of these things. But the only way to deal with them is to be informed, address them ahead of time, and make your choices accordingly. Either you attend the famous XYZ U. and buckle under to their intellectual property policies, either you take the lucrative biomedical research job that gives you a good thesis but requires you to keep your mouth shut, or you decide to go elsewhere. It's your choice; find out ahead of time and don't be naive about it.
In real life, if some software development is even vaguely related to your job, chances are your employer will claim that it was developed as part of your job, whether you did it at 3pm or 3am. And they probably will have a reasonably good chance of prevailing with that claim.
It is regrettable that universities are following suit (and they are, in my experience), trying to patent and copyright a lot of code and writings students produce while enrolled. But regrettable or not, legally, they probably have the same justification for doing it as any other employer.
Perhaps your basic assumption is wrong: the politicians and companies that I know did not and do not consider H1Bs slave labor.
In fact, until 1998, INS processing was quick enough that people usually could change jobs within a year, even if they just started their greencard application. The current problems are entirely due to INS processing delays, and Congress seems to have that addressed quickly and efficiently.
As for your company, I'd change jobs in your position. If your company engages in such practices, it doesn't seem like it values its workers. This is not common practice in the industry.
But the "newcomer" always could change jobs. With INS inefficiencies, it became a bit more of a hassle and risk in recent years, and it's good that the H1B bill addresses this issue. But the notion that an H1B holder is "slave labor" paid "half the price" is a myth created by people with a political agenda.
That's an urban legend. H1B visa holders are paid reasonable wages. Even if the employer could somehow hold them responsible for the application fee for their visa after the employer already has paid it, the employee (or their new employer) could simply pay it off; $2500 is not a lot of money. Your suggestion that H1B holders are somehow indentured servants for several years is just wrong.
(And pardon me for shouting.)
But the bill fixes some other problems that perhaps were much more serious. For example, H1B holders used to lose their job and had to leave the country if the INS didn't manage to process their greencard applications in a timely manner (even just getting an already approved green card issued now can take nearly 3 years). It also allows many greencard applicants to change jobs while the INS is sitting on those applications.
The problem with it all is that the new bill creates even more paperwork for the INS to handle: new H1B visas, new forms, new applications. If they couldn't handle the old volume of paperwork, how are they going to deal with this?
That kind of information can be delivered effectively and cheaply by computers. It can't be delivered effectively and cheaply by mail, by telephone, or by aid workers.
And did I say anything about Linux? Why does it always have to come down to Linux vs. Windows for you? Clearly, both Linux and Windows are too hard to install and manage, and the PC architecture is hardly robust enough. People need devices that turn on and work, that can be run off batteries and solar power, and that can communicate reliably in rural areas.
In fact, the world doesn't even need more food, water, or shelter. We have ample of each to provide even for our current population.
The problems we are facing are economic and social. We need to distribute resources efficiently, limit population growth, and limit consumption.
The only solution to our problems lies in better education, better communication, better public health, and more efficient economic systems. And information technology is probably the best tool we have for that.
Microsoft's internal development style is atypical for the industry. In fact, many of the core groups in Microsoft don't use the bells and whistles of Microsoft's own tools. The industry buys Microsoft products because Microsoft promises them that they don't have to develop in the kind of style you advocate and that they use internally.
But, by all means, if you are Microsoft and you are out to "crush" a company like Netscape, and the consumer be damned, go ahead and adopt Microsoft management strategies. Most companies, however, aren't Microsoft, not in size, not in cash resources, not in distribution channels, not in ability to hack the OS, not in available stock options, and not in hiring possibilities, and most companies have different goals and competitors, so it is unlikely that adopting Microsoft-style management will work for them.
(Nevertheless, small teams and focus are, of course, important for successful development, and Netscape did make many mistakes.)
Much of the power that Pentium requires is probably due to the complexity of the instruction set and the need for backwards compatibility. Particularly for non-Windows operating systems, just going with a simple, well-designed chip other than Pentium (ARM?) may give you the benefits of Crusoe without the potential complications. You can still emulate the x86 for compatibility.
In short, unless IBM demonstrates really very significant improvements in performance and battery life in actual laptops, I wouldn't rush out to buy one: either, I'd get a non-Pentium machine (WindowsCE, converted to Linux), or I'd just stick with Pentium or a direct clone. Compaq and IBM probably came to the conclusion that many potential customers think that way.