The GPL allows you to charge for the software: "You may charge a fee for the physical act of transferring a copy,..." (section 1, paragraph 2). You can charge any fee you want. The GPL limits the fee you can charge for distributing the source code, IF you don't distribute the source code with the application (section 3b).
Was that a troll? In case it wasn't: Forth is not a subset of Fortran, nor a superset. Fortran is a second-generation language. Forth was intended to be (and perhaps is) a fourth-generation language (hence its name). They have essentially no common ancestry and are completely different syntactically.
The Mythical Man Month is a good book, but it's not gospel. It can be superceded.
Regarding "debugging in pairs": you PROGRAM in pairs. Debugging is part of programming, but you do all your programming in pairs. You'll spend less time debugging because pair programming is equivalent to continuous peer review. You'll also spend less time debugging because comprehensive unit tests help prevent anyone from breaking code accidentally.
Regarding throwing one away: XP doesn't foreclose the possibility of creating a prototype. However, XP is also all about constant redesign. Every programmer on the team has the responsibility of fixing the design if it's broken.
Regarding unwarranted assumptions: XP requires that you change the way you approach requirements gathering and scheduling. But it's not about ignoring experience. It advocates avoiding doing work until you need it, but it doesn't say you should design yourself into a corner.
Too bad a signed customer specification (or requirements document) doesn't work. I've seen this many times at several companies. The problem is that the initial reqs/specs are almost always incomplete, erroneous, or infeasible. If you insist on delivering that anyway, you get a customer who doesn't want to pay. Would you rather spend your time and money in court or in the lab? Another possibility is that the customer pays, but doesn't like you. You get no more business from that customer, no reference for your corporate resume, and (depending on how much networking goes on in the customer's industry and/or locale) a bad reputation.
XP makes a trade-off: for every module, you have a bunch of people who know the code (ideally every programmer on the project). So no one is a bottleneck.
If you have individual code ownership, then when the person who owns module A is busy, no changes can be made to module A. The owner becomes a bottleneck.
Other XP practices lessen the impact of moving programmers around: pair programming, programming standards, unit tests, refactoring.
If all the machines in the DNS rotation are on the same physical network, then when one of them dies, you just add an IP alias for the dead machine on one of the live machines, flush ARP caches as necessary, and the live machine picks up the traffic.
The preamble of the Constitution of the United States says that our government exists, among other reasons, to "promote the general welfare". It does not say "to protect a free market". The market exists only for the benefit of the people of the United States, and it is the government's duty to see that the market operates to maximize that benefit. Historically, Congress apparently decided that a regulated market is more beneficial than a free market, because monopolies can cripple the ability of a free market to benefit consumers. Hence, antitrust law.
I, for one, think that the ultimate goal of a civilization should be to benefit its citizens. The establishment of a market, free or regulated, is a means to that end. What type of market to establish depends, I suppose, on your beliefs as to what most benefits the citizens. The evidence I've seen (and I'm not specifically talking about MSFT or this trial) leads me to believe that a regulated market can be of greater benefit than a completely free market.
That's exactly the kind of comment that should never be written. First, it's incredibly easy for the comment to become wrong - if one of your numbers changes and someone only changes the code and not the comment. Second, you've hard-coded (in your comment, at least) numbers that should clearly be named constants.
If I have constants defined like this, then I can't imagine ever needing to write a comment like that:
public interface BusinessRuleConstants { public static final int MaxPackagesPerBox = 28; public static final int BoxesPerRow = 8; public static final int RowsPerShelf = 4; }
Also, I wouldn't call the statement in your comment a business rule. A business rule in my experience is more like, "If the number of packages in a box is less than 5, order more packages." And that rule could easily be expressed as a language construct, with no comment needed, if the data structures and constants have been given clear, correct names. And if they haven't, maybe you can refactor so they have.
Okay, here are three real, technical problems with X. Some, maybe all, could be solved by extensions to X, but not without at least requiring support from the window manager and applications.
X does not support font anti-aliasing. There are many that claim that font anti-aliasing is bad, but there is enough demand for it that it should be supported. This would require changes to applications.
X has lousy multiple-screen support. The Macintosh has its share of problems, BUT, since 1986, you can connect multiple screens to a Macintosh and have the following features:
Windows can straddle multiple screens, even if the monitors are of different resolutions and bit-depths. (XINERAMA pales in comparison to this.)
You can change the multi-screen layout on the fly.
You can change the resolution and bit-depth of any screen on the fly.
Supporting these features in X would require allowing the root window to be shaped and allowing resize/reshape events on the root window, would require support from the window manager (to ensure that windows don't end up off the screen on a geometry change), and would completely break the X color model. I don't know how we could extend X to support changing the color model on the fly without breaking compatibility with existing clients (or making the X server real slow).
X clients have no way of being notified when the colormap changes. If I write a program that shows nice pictures, and I want it to be smart enough to redither the pictures each time the colormap changes, so that the pictures will always look nice, I can't, because there is no way to ask the X server to tell me when the colormap changes, or to find out what colormap is currently installed.
I'm using the ZoomAIR-4000 (PCMCIA) on my Thinkpad 770Z and the ZoomAIR-4005 (ISA) on my server to send this reply, so it definitely works.
The ISA version is an ISA/PCMCIA adapter card with one PCMCIA slot, plus the PCMCIA card. So you have to install PCMCIA card services on your server. You need pcmcia-cs version 3.0.9 (or later I suppose) to use wlan driver 0.2.6.
As for price - the ZoomAIR is by far the cheapest IEEE 802.11 solution I've seen. It uses the Harris PRISM chipset, and several other vendors also use that chipset, so there should be good interoperability. I know there are cheaper wireless network cards out there, but they're not 802.11 and I think they only do 1 Mbps. And I don't know if there are Linux drivers.
One more note - I believe Harris is supposed to start shipping the PRISM II chipset in quantity this month, which is supposed to support longer range, lower power, and 11 Mbps (instead of 2 Mbps). So you might want to wait a month or two and see if Zoom releases a new version. I'm okay with 2 Mbps because it's still 16x faster than my ISDN line.
Maybe you're not doing it right. CD-ROM drives aren't perfect, so you should use a program that compensates for drive errors - cdparanoia for example. And the program you use to encode the MP3 and the bit rate also matter. (Most people encode at 128 kbps. I encode my MP3s at 192 kbps.)
Slashdot Mirror
The GPL allows you to charge for the software: "You may charge a fee for the physical act of transferring a copy, ..." (section 1, paragraph 2). You can charge any fee you want. The GPL limits the fee you can charge for distributing the source code, IF you don't distribute the source code with the application (section 3b).
Was that a troll? In case it wasn't: Forth is not a subset of Fortran, nor a superset. Fortran is a second-generation language. Forth was intended to be (and perhaps is) a fourth-generation language (hence its name). They have essentially no common ancestry and are completely different syntactically.
I must ask, have you even read the XP book?
The Mythical Man Month is a good book, but it's not gospel. It can be superceded.
Regarding "debugging in pairs": you PROGRAM in pairs. Debugging is part of programming, but you do all your programming in pairs. You'll spend less time debugging because pair programming is equivalent to continuous peer review. You'll also spend less time debugging because comprehensive unit tests help prevent anyone from breaking code accidentally.
Regarding throwing one away: XP doesn't foreclose the possibility of creating a prototype. However, XP is also all about constant redesign. Every programmer on the team has the responsibility of fixing the design if it's broken.
Regarding unwarranted assumptions: XP requires that you change the way you approach requirements gathering and scheduling. But it's not about ignoring experience. It advocates avoiding doing work until you need it, but it doesn't say you should design yourself into a corner.
Too bad a signed customer specification (or requirements document) doesn't work. I've seen this many times at several companies. The problem is that the initial reqs/specs are almost always incomplete, erroneous, or infeasible. If you insist on delivering that anyway, you get a customer who doesn't want to pay. Would you rather spend your time and money in court or in the lab? Another possibility is that the customer pays, but doesn't like you. You get no more business from that customer, no reference for your corporate resume, and (depending on how much networking goes on in the customer's industry and/or locale) a bad reputation.
XP makes a trade-off: for every module, you have a bunch of people who know the code (ideally every programmer on the project). So no one is a bottleneck.
If you have individual code ownership, then when the person who owns module A is busy, no changes can be made to module A. The owner becomes a bottleneck.
Other XP practices lessen the impact of moving programmers around: pair programming, programming standards, unit tests, refactoring.
If all the machines in the DNS rotation are on the same physical network, then when one of them dies, you just add an IP alias for the dead machine on one of the live machines, flush ARP caches as necessary, and the live machine picks up the traffic.
The preamble of the Constitution of the United States says that our government exists, among other reasons, to "promote the general welfare". It does not say "to protect a free market". The market exists only for the benefit of the people of the United States, and it is the government's duty to see that the market operates to maximize that benefit. Historically, Congress apparently decided that a regulated market is more beneficial than a free market, because monopolies can cripple the ability of a free market to benefit consumers. Hence, antitrust law.
I, for one, think that the ultimate goal of a civilization should be to benefit its citizens. The establishment of a market, free or regulated, is a means to that end. What type of market to establish depends, I suppose, on your beliefs as to what most benefits the citizens. The evidence I've seen (and I'm not specifically talking about MSFT or this trial) leads me to believe that a regulated market can be of greater benefit than a completely free market.
Both Oracle and Solid have MVCC support (though they don't call it that). Do they count as high-dollar databases?
That's exactly the kind of comment that should never be written. First, it's incredibly easy for the comment to become wrong - if one of your numbers changes and someone only changes the code and not the comment. Second, you've hard-coded (in your comment, at least) numbers that should clearly be named constants.
If I have constants defined like this, then I can't imagine ever needing to write a comment like that:
public interface BusinessRuleConstants {
public static final int MaxPackagesPerBox = 28;
public static final int BoxesPerRow = 8;
public static final int RowsPerShelf = 4;
}
Also, I wouldn't call the statement in your comment a business rule. A business rule in my experience is more like, "If the number of packages in a box is less than 5, order more packages." And that rule could easily be expressed as a language construct, with no comment needed, if the data structures and constants have been given clear, correct names. And if they haven't, maybe you can refactor so they have.
Too bad the PostgreSQL documentation is so misleading about commercial databases not having this feature. Oracle has it. So does Solid.
- Windows can straddle multiple screens, even if the monitors are of different resolutions and bit-depths. (XINERAMA pales in comparison to this.)
- You can change the multi-screen layout on the fly.
- You can change the resolution and bit-depth of any screen on the fly.
Supporting these features in X would require allowing the root window to be shaped and allowing resize/reshape events on the root window, would require support from the window manager (to ensure that windows don't end up off the screen on a geometry change), and would completely break the X color model. I don't know how we could extend X to support changing the color model on the fly without breaking compatibility with existing clients (or making the X server real slow).I'm using the ZoomAIR-4000 (PCMCIA) on my Thinkpad 770Z and the ZoomAIR-4005 (ISA) on my server to send this reply, so it definitely works.
The ISA version is an ISA/PCMCIA adapter card with one PCMCIA slot, plus the PCMCIA card. So you have to install PCMCIA card services on your server. You need pcmcia-cs version 3.0.9 (or later I suppose) to use wlan driver 0.2.6.
As for price - the ZoomAIR is by far the cheapest IEEE 802.11 solution I've seen. It uses the Harris PRISM chipset, and several other vendors also use that chipset, so there should be good interoperability. I know there are cheaper wireless network cards out there, but they're not 802.11 and I think they only do 1 Mbps. And I don't know if there are Linux drivers.
One more note - I believe Harris is supposed to start shipping the PRISM II chipset in quantity this month, which is supposed to support longer range, lower power, and 11 Mbps (instead of 2 Mbps). So you might want to wait a month or two and see if Zoom releases a new version. I'm okay with 2 Mbps because it's still 16x faster than my ISDN line.
Drivers are at www.absoval.com .
www.qmail.org
I especially love this feature mentioned on the web page:
"Drastically increases overall quality & value of the entire system."
iNux.
Maybe you're not doing it right. CD-ROM drives aren't perfect, so you should use a program that compensates for drive errors - cdparanoia for example. And the program you use to encode the MP3 and the bit rate also matter. (Most people encode at 128 kbps. I encode my MP3s at 192 kbps.)