But, the bottom line is that if you don't profile your code (and unit test it, and integration test it, and...), you are not writing good code.
That's hardly true. Certainly you shouldn't waste time optimizing code until you know where the bottlenecks are. But it a lot of cases--I'd even venture to say most cases--code gets written and is fast enough. In such cases, profiling is a waste of time. Profiling is only indicated if there's a legitimate performance problem.
To a lesser extent, the same is true of unit testing and integration testing. If you're writing some code to convert one image to a GIF and you run it successfully to get the GIF, there's no reason to unit test. Even if the code has horrible bugs on some inputs, the job is done. One-off code isn't (unfortunately) uncommon. Prototype code is also very common and often you don't need to do extensive testing on it, either. Any code where the total cost of code failure is lower than the cost of QA probably doesn't need to be QA'd (which is not to say that you should spend an amount on QA equal to the failure cost; if spending $1000 on QA reduces the chance of failure by 99.999% and spending $1000000 reduces the chance of failure by 99.9999%, the $1000 expenditure suffices in all but the most demanding applications)
You could argue that with good up front design, you'll know in advance what 10% of the code to focus on, but I don't think that works that well in practice. At best, you're making educated guesses about where bottlenecks will appear
And a lot of smart people, from Knuth and Kernighan to Linus and Guido, will freely admit that predicting what to optimize is nearly impossible. Even people at that level of programming prowess are often surprised by where the bottlenecks appear (and where they don't appear). You certainly want to design for flexible optimization from the start, but you'll often discover that the stupid O(n) scan you put in is good enough for now and that you better optimize the I/O system before you think about replacing it with a tree or hash table or whatever.
Profiling in general certainly isn't useless. I'll usually write new code primarily in a high-level, high-productivity language (e.g. Python), and if it's too slow I'll profile it and rewrite applicable parts in C. Some projects require a lower level (C) approach from the start, though those are pretty rare. Without profiling you'll spend a lot of time optimizing code that isn't a bottleneck.
Remember the words of Knuth: "Premature optimization is the root of all evil." Without profiling, you don't know what optimization is really needed and what isn't.
That said... BEGIN RANT I've used gprof successfully with plenty of recent code. It works perfectly fine in non-threaded code, which _should_ be the majority (99%+) of code out there. Yes, that includes big network servers (the last one I wrote just recently passed the 6 billion requests served mark without blinking). Threads are a really nasty programming rathole that should be applied in a limited way; they take much of the time and effort spent developing protected memory OSes and toss it out the window. They also tend to encourage highly synchronized executions instead of decoupled execution, which often makes things both slower and more bug-prone (locking issues are _tough_ to get right when they become more than 1-level) and slower to implement than a well-designed multiprocess solution with an appropriate I/O paradigm. Just because two popular platforms (Windows and Java) make good non-threaded programming difficult doesn't mean you should cave in. END RANT
Talk to a lawyer (perhaps after looking up that section of the U.S. Code to see if you think it's worth it).
Oh, and bookmark that link. Keep it around. It's the law of the land, worth knowing about. You can't just read it in a vacuum (parts of it aren't at all enforceable because of Court rulings, executive orders, the Constitution, or for other legal reasons), but it's worth knowing about if you live in the U.S.
Telemarketing to a number where the recipient has to pay by the minute is illegal under the Telephone Consumer Protection Act. See the U.S. Code, Title 47, Chapter 5, Subchapter II, Part I, Sec 227.
I got rid of my land line 3 years ago in favor of a cell phone and haven't had a single telemarketing call since then. I'm pretty surprised that you have; they're liable for a $500 fine for each such call placed.
check YOUR sources first. Mastercard and Visa may cover that but a LOT of financial institutions issue cards of their own that are not affiliated with V/MC. and some regions/states do not allow for limitations on losses.
The EFTA is federal law. See, in particular, the U.S. Code Title 15, Chapter 41, Subchapter VI, Section 1693g, "Consumer liability". and the rest of 15.41.VI.
In the U.S., "regions" or states can't override it, it applies everywhere and limits debit/check card liability as stated (for all cards, Visa/Mastercard or not).
The Visa/Mastercard policy obviously only applies to cards affiliated with those institutions.
Please, do a little research before you use a debit card or check card, for any purchases! While federal U.S. law limits your liability for fraudulent credit card purchases to $50, there is no legal limit for fraudulent use of your debit/check card.
Please do a little research of your own--the Electronic Funds Transfer Act limits consumer liability for ATM, debit, or check cards to 1) $50 if the card is lost or stolen and reported as such within 2 days; 2) $500 if the card is lost or stolen and reported as such within 60 days; 3) $500 for fraudulent purchases if they are reported within 60 days.
Moreover, Mastercard and Visa both limit check-card losses to the same $50 max as credit cards as a matter of corporate policy.
HR 445 is a bill in congress to limit liability to $50 in all cases of fraud; it's been tabled since 1999 as far as I know.
If you run chroot, a root exploit will have limited impact
That's not true. root can easily break out of a chroot jail (this is intentional). It's not meant to contain a malicious root user (there are too many other ways for root to affect the outside world anyway, iopl() comes to mind).
e.g. compile the follwing as "breakout", chroot yourself to somewhere (e.g./tmp) where you have a statically linked copy of "breakout", and run it. You'll be back to the real root (you may need more periods in the chdir call there, but a loop can fix that pretty well).
In general all IP protection mechanisms (copyright, patents, trademarks) are supposed to cover implementations, not ideas.
Not true, at least in the United States or Europe. Patents are--and always have been--allowed to cover a process, art, or method. See e.g. Title 35, part II, chapter 10 of the US Code, "Patentability of Inventions" for the legislative authority to cover this. This wording is basically unchanged for over a century--though in 1952 wording was added forbidding patents on things that are "obvious to a skilled practitioner of the art" (the courts had been enforcing a similar prohibition since a Court ruling in 1850). Going back into history, European governments routinely granted method patents since at least the mid 1500s.
_Business_ method patents are new, but patenting ideas and methods rather than implementations isn't anything new.
Copyright and trademark, on the other hand, are supposed to cover particular expressions of an idea (and with trademarks that expression is limited to how it is used in a particular field).
For instance, in my organization, we use instant messaging to communicate about projects without leaving our workspaces, which can lead to further distractions and reduce productivity.
You discuss company-sensitive information over a plaintext protocol on the Internet?
Did he say that? Believe it or not, at most places there's a great deal of useful communication that can be public without harming the business. I used to work at a large company where IM was a major tool for the tech staff (who were in several locations). And public IM has the huge advantage of letting me get answers from other programmers I know who may not work with me.
"What's the URL for ElectricFence?" "Is there a function to do X in Python?" "Joe's not answering his phone--is he down there with you all?" "Where'd you put that log file?" "Any idea why I can't see the database server right now?" "Is Frank out at the NOC?" "Do you know Dale's extension?" "I created that account for you--gimme a call when you get a sec and I'll tell you the password".
Sure, some of those might be sensitive at some companies, but most places it just doesn't matter if the competion knows that Printer A is down so you should use Printer B. And it's a lot easier to IM someone a URL or command-line than spell it out over the phone--even if I'm sitting in the same room as someone, I'll often say "I just IM'd you the URL". We knew what we should and shouldn't say on IM and it worked great.
How the heck can I write good when I am hardly told what the application is supposed to do? So I write something, it doesn't take into account the missing details that I asked about. Those get defined two weeks after the thing is supposed to be done. The app turns out terrible and then the powers that be want to know why it has problems. It is incredibly frustrating.
Requirements change. Users don't know how to specify things. They often don't want what they think they want, and even when they do it may be obsolete or of secondary importance before you're done implementing it.
Your #1 job as a programmer is to write useful code--code that helps your customer/business/department--which usually (in my experience) means that your skill in determining requirements and working with the customer to refine them is far more important than your actual programming chops. Relying on an external project manager to gather requirements and define scope is usually disastrous.
This is a major part of the XP ethos and especially the agile programming philosophy ("Welcome changing requirements, even late in development" is one of their primary principles...). The sooner you develop softare practices that realize this and plan for it, the better off you'll be.
Anyway, these figures are spurious: I occasionally submit bug reports, fixes and enhancements to dev team on sourceforge projects, but I don't join the teams, because I can't commit the effort. But I did review the code, there's just no metrics that capture it.
Damn straight. I think what the author wanted was a quick and easy way to get at some 'real' numbers. Unfortunately due to the nature of the 'community', that just doesn't exist. The author would have to spend months looking through mailing list logs to see who submitted what, and how much weight to give that 'code author', based on what his/her patch did for the project.
Double damn straight. And even going through mailing list logs wouldn't be much of a help. 95% of the projects I've fixed bugs in it's been a quick email to the author to fix a segfault or an innapropriate strcpy call, something trivial like that for a project I'm not really involved with and just want to fix up so I can use it. No point even subscribing to a mailing list, just drop an email to the author.
I want you to shut up about open source...Good principles of software design are relevant in both models!
That isn't necessarily true.
One of the fundamental tenets of _some_ (not all) OSS developers is that "release early and often" is good policy and "many eyes make all bugs shallow"--in essence, the thought is that the primary developer should NOT do second-round QA or bug hunting since disclosure of code and an involved community are a more efficient means of fixing local/implementation (and in some cases, global/design) bugs.
This is a software design principle highly relevant to the topic at hand. It relies heavily on an open-source style community; it remains to be seen whether 1) it is a VALID design principle; and 2) The same effect can be captured in shared-source systems (Java, Microsoft shared source), internal dogfooding programs at huge companies (as per Sun and SGI especially), widespread public betas, etc. If 1) is a yes and 2) is a no then your assertion above isn't right.
Turning back from OSS-specific design principles, look at the other point I raised: the reason people put up with bugs is because the software is useful. If adding features increases productivity more than multiround bug fixing (as I believe is often the case), then you're doing the user a disservice by channeling resources into the less productive venue. Eventually you'll reach a point of diminished returns where bug-fixing becomes the area of best ROI, especially in well-understood problem domains (like the word processor I mentioned). But bug-fixing is expensive, and especially when a project's feature set is still evolving you need to recognize that time spent fixing bugs in a feature that may not exist in the next product iteration is potentially wasted.
If you want to put a name and a more formal writeup on this, google for "Agile Manifesto" and take a look at the articles on the Agile Alliance web site. One tenet thereof: quality is negotiable. It costs money. Customers shouldn't be forced to pay for quality they don't need. Time spent improving quality beyond what is necessary is time that could better be spent elsewhere.
The methodology certainly doesn't advocate slipshod products or shipping bug-laden code, but it does raise a lot of points about how to best deliver software that helps the end users get their work done in the most efficient way possible.
We're not out of touch with reality. You're just grounded in a very specific part of reality - the OSS CSS war. Many closed source shops produce crap code - thus, open source provides an alternative. Open source, however, only guarantees correctness for large projects which hackers are willing to throw thier eyes at. Small projects don't magically fix thier problems just because they're open source
But I can fix problems that bite me. I can only sometimes fix problems in closed-source software, and then it's a kludge, and the fix still often isn't incorporated by the vendor.
Example: We had a closed-source server product running on Linux that wasn't working in our configuration. With a combination of ltrace and strace I was able to figure out the problem, and I wrote a small shared library to LD_PRELOAD which worked around it. I then sent a bug report in basically telling the vendor which line to fix and how to fix it. They opened a tracking number and haven't been heard from since. No fix and as far as I can tell they don't intend to fix it.
When I fixed a number of buffer overflows and a tmp file problem in gaim (a couple years ago), the maintainers took them in immediately.
The difference is huge.
For the purposes of this discussion, however, we don't care either way - we want better principles of design, that can be used for open source and closed source projects.
That would be nice. However, software is changing rapidly. The article is a bit disingenuous in pointing at more static industries. As it points out, we put up with buggy software because it's so useful. By including new features quickly, software can become more useful quickly. There reaches a point of diminished returns--there aren't too many new word processor features that would improve productivity more than some bug fixing.
But applying a rigorous engineering discipline to software development does slow things down, and it's often hopeless because the only way I know of to get useful software is to do iterative development until you arrive at what the user wants and not what they initially said they want. Requirements change so much that you really need an engineering process that recognizes that.
But really, if all you need from a library is one function, or ten functions, and the code works, and the project has no bearing on Gnome- take the code, as the license allows you, stick it in your header file, and be done with it.
And then all of a sudden every application has a copy, so memory use is up. New bug fixes aren't picked up or need to be applied many times.
Cut and paste coding is evil. You can mitigate maintenance hassles by linking statically (you'll still have multiple copies in RAM, but that's often okay), but duplicating code is a major programming sin.
Actually, someone else pointed out that it was Aristotle.
His actual quote is: "We can never have too much of a good thing."
More likely the temple of Apollo at the Oracle at Delphi, which had the two (among others) famous inscriptions "Know Thyself" and "Nothing in Excess". The 2nd is often translated as "Everything in Moderation", which changes the meaning significantly.
"Everything in moderation" is inscribed in Apollo's Delphi in Greece.
Fucktard. The message at the Oracle at Delphi reads "Know Thyself."
Uh, the temple of Apollo at the Oracle at Delphi has many inscriptions. One of them is, indeed, "Know Thyself". Another is literally "Nothing in Excess", but "Everything in Moderation" is a common translation.
Sumner
Re:Differences appear minor
on
Gnome 2.0 RC1
·
· Score: 5, Insightful
From a development standpoint, GNOME is ugly as sin...I would much rather use Qt than everything under the GNOME sun for development, and C++ rather than C
Not meant to be flamebait, but there is a large set of developers out there who greatly prefer C to C++; this is especially true on a Unix-like platform, given the close history of the two. Saying that "from a development standpoint, GNOME is ugly as sin" is _definitely_ an opinion. C++ and Qt are out there if you want to use them. Personally I think that the language difference has had a huge impact on the high-level goals and progress of the two projects, and that sort of diversity is a good thing.
GNOME and Ximian could do many good things for developers and system maintainers by consolidating a lot of those little libs into big lib packages.
Likewise here. On many occasions I've used just one small library from GNOME in a completely non-GNOME (often not graphical at all) project, and I love that it's easy to pull out small pieces (glib, libunicode, parts of the gcal ical implementation) and use them.
Depends on how you set it up. You can use the vncserver on the local machine w/ vncviewer, I do this a lot at work. Makes it convenient to either 1) go home, realize something needs to be fixed, connect to the running desktop from home 2) kibbitz with a cow-orker by letting them connect to the desktop with you and trace through a problem.
It's a lot slower than running a regular X session, which matters a lot for some apps and not at all for others. A snoopish office could set it up that way or do similar more subtle tricks with a frame buffer X server. Or just read the video RAM on certain cards.
I'm curious how you setup a ramdisk root partition? What operating system etc... How much memory is required
initrd Linux 2.4 Not much, I have 256 MB in the machine but it was doing the same w/ 128 MB. You just need to be careful about what you pick for the root partition so you have enough for your apps.
I'm not sure which Seagates *you're* using, but the spin noise on my Barracuda IV 80gig is almost unnoticable. The seeks are audible, but they're really not too bad. Maybe you got one out of a "bad" batch?
I'm also using a Barracuda IV 80 gig. The rest of the machine is virtually silent, using a Siemens mobo that keeps the cooling fans off unless the heat rises (Golden Orb heat sinks keep the CPU fan off pretty much all the time, a custom low-heat convected power supply likewise keeps the power supply fan off) and it has a fanless video card. The room has no other noise sources in it and is fairly well insulated acoustically. While the Barracuda is quieter than the IBM drive by a long shot, it's not that much quieter than the Maxtor except for seeks where the Seagate wins out handily.
It's all relative, in a typical home environment the Barracuda IV would be great. In my environment I throw it in a molex SilentDrive enclosure and have a Stealth Armsystems acoustically shielded case for the computer, and I still try to keep it spun down as much as possible--it's far and away the loudest piece of the system. The SilentDrive enclosure kills almost all seek noise but isn't as effective at cutting down the spin noise (it does help some). You really need to keep the room cool if you're going to put an 80GB drive in a SilentDrive, but I do that anyway to keep the other fans off.
Seagate drives are currently considered the "quietest" though, so take that into consideration if buying a new drive. I believe they're even quieter than the Maxtor liquid bearing drives.
I tried Seagate, Maxtor, and IBM drives when putting together my quiet PC. The Seagates are the quietest, but they're not really quiet (even in a Molex SilentDrive enclosure, which helps significantly). I've wound up putting a lot of effort into building a ramdisk root partition and doing heavy readahead into RAM so that the hard drive is almost always spun down.
Really, the Seagate's seeks are extremely quiet but the standard hard drive spin noise isn't that much more quiet than the others.
This is actually pretty good. They will as a practical matter be bound in many cases, because there is a legal rule called "estoppel" which will prevent them from changing their mind on someone after they have acted in reliance on this policy. The permission given here should actually be pretty difficult to shake off.
I am not a lawyer, this is not legal advice.
As far as I understand it, estoppel as it applies to patents is limited to admissions before the PTO and the courts. Essentially, if you file for patent A and tell the PTO, "this doesn't apply to B" then you can't later prosecute someone for infringement of "B" even if the "it doesn't apply to B" clause isn't written in the patent anywhere.
It's basically to prevent you from pulling a fast one to get something by the PTO (though in this day and age it seems like you don't need a fast one, they'll grant anything).
In other words, I think it would be difficult to argue to a court that they've created a legal estoppel here; not impossible, but it's definitely not a given.
Also see (but read the rest of this paragraph) their description of "Prosecution History Estoppel". The latter (Prosecution History Estoppel) is a broader restriction but the linked page says "a strong appeal of that decision to the U.S. Supreme Court is currently (early 2001) under way". In fact, the Court rendered its verdict earlier this week refusing to apply the doctrine of equivalents to prosecution history estoppel, which takes a lot of the teeth out of PHE. So don't rely on that one unless you have a very good understanding of the law and the Court's decision. (also note that in this context "prosecution" doesn't relate to patent enforcement but rather to the process of applying for the patent).
Again, I'm not a lawyer. Consult a lawyer if you need legal advice.
Undefended trademarks are lost. Patents are often submarined (ie not defended for years until the patented idea is in widespread use, then you can sue more people for money), the canonical example is what Unisys did with the GIF patent.
I am not a lawyer. Consult a lawyer if you need legal advice.
Slashdot Mirror
But, the bottom line is that if you don't profile your code (and unit test it, and integration test it, and...), you are not writing good code.
That's hardly true. Certainly you shouldn't waste time optimizing code until you know where the bottlenecks are. But it a lot of cases--I'd even venture to say most cases--code gets written and is fast enough. In such cases, profiling is a waste of time. Profiling is only indicated if there's a legitimate performance problem.
To a lesser extent, the same is true of unit testing and integration testing. If you're writing some code to convert one image to a GIF and you run it successfully to get the GIF, there's no reason to unit test. Even if the code has horrible bugs on some inputs, the job is done. One-off code isn't (unfortunately) uncommon. Prototype code is also very common and often you don't need to do extensive testing on it, either. Any code where the total cost of code failure is lower than the cost of QA probably doesn't need to be QA'd (which is not to say that you should spend an amount on QA equal to the failure cost; if spending $1000 on QA reduces the chance of failure by 99.999% and spending $1000000 reduces the chance of failure by 99.9999%, the $1000 expenditure suffices in all but the most demanding applications)
Sumner
You could argue that with good up front design, you'll know in advance what 10% of the code to focus on, but I don't think that works that well in practice. At best, you're making educated guesses about where bottlenecks will appear
And a lot of smart people, from Knuth and Kernighan to Linus and Guido, will freely admit that predicting what to optimize is nearly impossible. Even people at that level of programming prowess are often surprised by where the bottlenecks appear (and where they don't appear). You certainly want to design for flexible optimization from the start, but you'll often discover that the stupid O(n) scan you put in is good enough for now and that you better optimize the I/O system before you think about replacing it with a tree or hash table or whatever.
Sumner
Profiling in general certainly isn't useless. I'll usually write new code primarily in a high-level, high-productivity language (e.g. Python), and if it's too slow I'll profile it and rewrite applicable parts in C. Some projects require a lower level (C) approach from the start, though those are pretty rare. Without profiling you'll spend a lot of time optimizing code that isn't a bottleneck.
Remember the words of Knuth: "Premature optimization is the root of all evil." Without profiling, you don't know what optimization is really needed and what isn't.
That said...
BEGIN RANT
I've used gprof successfully with plenty of recent code. It works perfectly fine in non-threaded code, which _should_ be the majority (99%+) of code out there. Yes, that includes big network servers (the last one I wrote just recently passed the 6 billion requests served mark without blinking). Threads are a really nasty programming rathole that should be applied in a limited way; they take much of the time and effort spent developing protected memory OSes and toss it out the window. They also tend to encourage highly synchronized executions instead of decoupled execution, which often makes things both slower and more bug-prone (locking issues are _tough_ to get right when they become more than 1-level) and slower to implement than a well-designed multiprocess solution with an appropriate I/O paradigm. Just because two popular platforms (Windows and Java) make good non-threaded programming difficult doesn't mean you should cave in.
END RANT
Does this apply to per-minute ISDN?
Talk to a lawyer (perhaps after looking up that section of the U.S. Code to see if you think it's worth it).
Oh, and bookmark that link. Keep it around. It's the law of the land, worth knowing about. You can't just read it in a vacuum (parts of it aren't at all enforceable because of Court rulings, executive orders, the Constitution, or for other legal reasons), but it's worth knowing about if you live in the U.S.
Sumner
Telemarketing to a number where the recipient has to pay by the minute is illegal under the Telephone Consumer Protection Act. See the U.S. Code, Title 47, Chapter 5, Subchapter II, Part I, Sec 227.
I got rid of my land line 3 years ago in favor of a cell phone and haven't had a single telemarketing call since then. I'm pretty surprised that you have; they're liable for a $500 fine for each such call placed.
Sumner
check YOUR sources first. Mastercard and Visa may cover that but a LOT of financial institutions issue cards of their own that are not affiliated with V/MC. and some regions/states do not allow for limitations on losses.
The EFTA is federal law. See, in particular, the U.S. Code Title 15, Chapter 41, Subchapter VI, Section 1693g, "Consumer liability". and the rest of 15.41.VI.
In the U.S., "regions" or states can't override it, it applies everywhere and limits debit/check card liability as stated (for all cards, Visa/Mastercard or not).
The Visa/Mastercard policy obviously only applies to cards affiliated with those institutions.
Sumner
Please, do a little research before you use a debit card or check card, for any purchases! While federal U.S. law limits your liability for fraudulent credit card purchases to $50, there is no legal limit for fraudulent use of your debit/check card.
Please do a little research of your own--the Electronic Funds Transfer Act limits consumer liability for ATM, debit, or check cards to 1) $50 if the card is lost or stolen and reported as such within 2 days; 2) $500 if the card is lost or stolen and reported as such within 60 days; 3) $500 for fraudulent purchases if they are reported within 60 days.
Moreover, Mastercard and Visa both limit check-card losses to the same $50 max as credit cards as a matter of corporate policy.
HR 445 is a bill in congress to limit liability to $50 in all cases of fraud; it's been tabled since 1999 as far as I know.
Sumner
If you run chroot, a root exploit will have limited impact
/tmp) where you have a statically linked copy of "breakout", and run it. You'll be back to the real root (you may need more periods in the chdir call there, but a loop can fix that pretty well).
That's not true. root can easily break out of a chroot jail (this is intentional). It's not meant to contain a malicious root user (there are too many other ways for root to affect the outside world anyway, iopl() comes to mind).
e.g. compile the follwing as "breakout", chroot yourself to somewhere (e.g.
#include
int main(void)
{
mkdir("foo", 0700);
chroot("foo");
chdir("../../..");
chroot(".");
system("sh");
}
Sumner
In general all IP protection mechanisms (copyright, patents, trademarks) are supposed to cover implementations, not ideas.
Not true, at least in the United States or Europe. Patents are--and always have been--allowed to cover a process, art, or method. See e.g. Title 35, part II, chapter 10 of the US Code, "Patentability of Inventions" for the legislative authority to cover this. This wording is basically unchanged for over a century--though in 1952 wording was added forbidding patents on things that are "obvious to a skilled practitioner of the art" (the courts had been enforcing a similar prohibition since a Court ruling in 1850). Going back into history, European governments routinely granted method patents since at least the mid 1500s.
_Business_ method patents are new, but patenting ideas and methods rather than implementations isn't anything new.
Copyright and trademark, on the other hand, are supposed to cover particular expressions of an idea (and with trademarks that expression is limited to how it is used in a particular field).
Sumner
For instance, in my organization, we use instant messaging to communicate about projects without leaving our workspaces, which can lead to further distractions and reduce productivity.
You discuss company-sensitive information over a plaintext protocol on the Internet?
Did he say that? Believe it or not, at most places there's a great deal of useful communication that can be public without harming the business. I used to work at a large company where IM was a major tool for the tech staff (who were in several locations). And public IM has the huge advantage of letting me get answers from other programmers I know who may not work with me.
"What's the URL for ElectricFence?" "Is there a function to do X in Python?" "Joe's not answering his phone--is he down there with you all?" "Where'd you put that log file?" "Any idea why I can't see the database server right now?" "Is Frank out at the NOC?" "Do you know Dale's extension?" "I created that account for you--gimme a call when you get a sec and I'll tell you the password".
Sure, some of those might be sensitive at some companies, but most places it just doesn't matter if the competion knows that Printer A is down so you should use Printer B. And it's a lot easier to IM someone a URL or command-line than spell it out over the phone--even if I'm sitting in the same room as someone, I'll often say "I just IM'd you the URL". We knew what we should and shouldn't say on IM and it worked great.
Sumner
How the heck can I write good when I am hardly told what the application is supposed to do? So I write something, it doesn't take into account the missing details that I asked about. Those get defined two weeks after the thing is supposed to be done. The app turns out terrible and then the powers that be want to know why it has problems. It is incredibly frustrating.
Requirements change. Users don't know how to specify things. They often don't want what they think they want, and even when they do it may be obsolete or of secondary importance before you're done implementing it.
Your #1 job as a programmer is to write useful code--code that helps your customer/business/department--which usually (in my experience) means that your skill in determining requirements and working with the customer to refine them is far more important than your actual programming chops. Relying on an external project manager to gather requirements and define scope is usually disastrous.
This is a major part of the XP ethos and especially the agile programming philosophy ("Welcome changing requirements, even late in development" is one of their primary principles...). The sooner you develop softare practices that realize this and plan for it, the better off you'll be.
see e.g. the Agile Alliance article repository for stuff to think about.
Sumner
Anyway, these figures are spurious: I occasionally submit bug reports, fixes and enhancements to dev team on sourceforge projects, but I don't join the teams, because I can't commit the effort. But I did review the code, there's just no metrics that capture it.
Damn straight. I think what the author wanted was a quick and easy way to get at some 'real' numbers. Unfortunately due to the nature of the 'community', that just doesn't exist. The author would have to spend months looking through mailing list logs to see who submitted what, and how much weight to give that 'code author', based on what his/her patch did for the project.
Double damn straight. And even going through mailing list logs wouldn't be much of a help. 95% of the projects I've fixed bugs in it's been a quick email to the author to fix a segfault or an innapropriate strcpy call, something trivial like that for a project I'm not really involved with and just want to fix up so I can use it. No point even subscribing to a mailing list, just drop an email to the author.
Sumner
I want you to shut up about open source...Good principles of software design are relevant in both models!
That isn't necessarily true.
One of the fundamental tenets of _some_ (not all) OSS developers is that "release early and often" is good policy and "many eyes make all bugs shallow"--in essence, the thought is that the primary developer should NOT do second-round QA or bug hunting since disclosure of code and an involved community are a more efficient means of fixing local/implementation (and in some cases, global/design) bugs.
This is a software design principle highly relevant to the topic at hand. It relies heavily on an open-source style community; it remains to be seen whether 1) it is a VALID design principle; and 2) The same effect can be captured in shared-source systems (Java, Microsoft shared source), internal dogfooding programs at huge companies (as per Sun and SGI especially), widespread public betas, etc. If 1) is a yes and 2) is a no then your assertion above isn't right.
Turning back from OSS-specific design principles, look at the other point I raised: the reason people put up with bugs is because the software is useful. If adding features increases productivity more than multiround bug fixing (as I believe is often the case), then you're doing the user a disservice by channeling resources into the less productive venue. Eventually you'll reach a point of diminished returns where bug-fixing becomes the area of best ROI, especially in well-understood problem domains (like the word processor I mentioned). But bug-fixing is expensive, and especially when a project's feature set is still evolving you need to recognize that time spent fixing bugs in a feature that may not exist in the next product iteration is potentially wasted.
If you want to put a name and a more formal writeup on this, google for "Agile Manifesto" and take a look at the articles on the Agile Alliance web site. One tenet thereof: quality is negotiable. It costs money. Customers shouldn't be forced to pay for quality they don't need. Time spent improving quality beyond what is necessary is time that could better be spent elsewhere.
The methodology certainly doesn't advocate slipshod products or shipping bug-laden code, but it does raise a lot of points about how to best deliver software that helps the end users get their work done in the most efficient way possible.
Sumner
We're not out of touch with reality. You're just grounded in a very specific part of reality - the OSS CSS war. Many closed source shops produce crap code - thus, open source provides an alternative. Open source, however, only guarantees correctness for large projects which hackers are willing to throw thier eyes at. Small projects don't magically fix thier problems just because they're open source
But I can fix problems that bite me. I can only sometimes fix problems in closed-source software, and then it's a kludge, and the fix still often isn't incorporated by the vendor.
Example: We had a closed-source server product running on Linux that wasn't working in our configuration. With a combination of ltrace and strace I was able to figure out the problem, and I wrote a small shared library to LD_PRELOAD which worked around it. I then sent a bug report in basically telling the vendor which line to fix and how to fix it. They opened a tracking number and haven't been heard from since. No fix and as far as I can tell they don't intend to fix it.
When I fixed a number of buffer overflows and a tmp file problem in gaim (a couple years ago), the maintainers took them in immediately.
The difference is huge.
For the purposes of this discussion, however, we don't care either way - we want better principles of design, that can be used for open source and closed source projects.
That would be nice. However, software is changing rapidly. The article is a bit disingenuous in pointing at more static industries. As it points out, we put up with buggy software because it's so useful. By including new features quickly, software can become more useful quickly. There reaches a point of diminished returns--there aren't too many new word processor features that would improve productivity more than some bug fixing.
But applying a rigorous engineering discipline to software development does slow things down, and it's often hopeless because the only way I know of to get useful software is to do iterative development until you arrive at what the user wants and not what they initially said they want. Requirements change so much that you really need an engineering process that recognizes that.
Sumner
But really, if all you need from a library is one function, or ten functions, and the code works, and the project has no bearing on Gnome- take the code, as the license allows you, stick it in your header file, and be done with it.
And then all of a sudden every application has a copy, so memory use is up. New bug fixes aren't picked up or need to be applied many times.
Cut and paste coding is evil. You can mitigate maintenance hassles by linking statically (you'll still have multiple copies in RAM, but that's often okay), but duplicating code is a major programming sin.
Sumner
Actually, someone else pointed out that it was Aristotle.
His actual quote is: "We can never have too much of a good thing."
More likely the temple of Apollo at the Oracle at Delphi, which had the two (among others) famous inscriptions "Know Thyself" and "Nothing in Excess". The 2nd is often translated as "Everything in Moderation", which changes the meaning significantly.
Sumner
"Everything in moderation" is inscribed in Apollo's Delphi in Greece.
Fucktard. The message at the Oracle at Delphi reads "Know Thyself."
Uh, the temple of Apollo at the Oracle at Delphi has many inscriptions. One of them is, indeed, "Know Thyself". Another is literally "Nothing in Excess", but "Everything in Moderation" is a common translation.
Sumner
From a development standpoint, GNOME is ugly as sin...I would much rather use Qt than everything under the GNOME sun for development, and C++ rather than C
Not meant to be flamebait, but there is a large set of developers out there who greatly prefer C to C++; this is especially true on a Unix-like platform, given the close history of the two. Saying that "from a development standpoint, GNOME is ugly as sin" is _definitely_ an opinion. C++ and Qt are out there if you want to use them. Personally I think that the language difference has had a huge impact on the high-level goals and progress of the two projects, and that sort of diversity is a good thing.
GNOME and Ximian could do many good things for developers and system maintainers by consolidating a lot of those little libs into big lib packages.
Likewise here. On many occasions I've used just one small library from GNOME in a completely non-GNOME (often not graphical at all) project, and I love that it's easy to pull out small pieces (glib, libunicode, parts of the gcal ical implementation) and use them.
Sumner
Depends on how you set it up. You can use the vncserver on the local machine w/ vncviewer, I do this a lot at work. Makes it convenient to either
1) go home, realize something needs to be fixed, connect to the running desktop from home
2) kibbitz with a cow-orker by letting them connect to the desktop with you and trace through a problem.
It's a lot slower than running a regular X session, which matters a lot for some apps and not at all for others. A snoopish office could set it up that way or do similar more subtle tricks with a frame buffer X server. Or just read the video RAM on certain cards.
Sumner
VNC ect.. won't work for me as I run "Special" software that only runs on Linux ;)
VNC works fine on Linux, client and server.
Sumner
I'm curious how you setup a ramdisk root partition?
What operating system etc...
How much memory is required
initrd
Linux 2.4
Not much, I have 256 MB in the machine but it was doing the same w/ 128 MB. You just need to be careful about what you pick for the root partition so you have enough for your apps.
Sumner
I'm not sure which Seagates *you're* using, but the spin noise on my Barracuda IV 80gig is almost unnoticable. The seeks are audible, but they're really not too bad. Maybe you got one out of a "bad" batch?
I'm also using a Barracuda IV 80 gig. The rest of the machine is virtually silent, using a Siemens mobo that keeps the cooling fans off unless the heat rises (Golden Orb heat sinks keep the CPU fan off pretty much all the time, a custom low-heat convected power supply likewise keeps the power supply fan off) and it has a fanless video card. The room has no other noise sources in it and is fairly well insulated acoustically. While the Barracuda is quieter than the IBM drive by a long shot, it's not that much quieter than the Maxtor except for seeks where the Seagate wins out handily.
It's all relative, in a typical home environment the Barracuda IV would be great. In my environment I throw it in a molex SilentDrive enclosure and have a Stealth Armsystems acoustically shielded case for the computer, and I still try to keep it spun down as much as possible--it's far and away the loudest piece of the system. The SilentDrive enclosure kills almost all seek noise but isn't as effective at cutting down the spin noise (it does help some). You really need to keep the room cool if you're going to put an 80GB drive in a SilentDrive, but I do that anyway to keep the other fans off.
Sumner
Seagate drives are currently considered the "quietest" though, so take that into consideration if buying a new drive. I believe they're even quieter than the Maxtor liquid bearing drives.
I tried Seagate, Maxtor, and IBM drives when putting together my quiet PC. The Seagates are the quietest, but they're not really quiet (even in a Molex SilentDrive enclosure, which helps significantly). I've wound up putting a lot of effort into building a ramdisk root partition and doing heavy readahead into RAM so that the hard drive is almost always spun down.
Really, the Seagate's seeks are extremely quiet but the standard hard drive spin noise isn't that much more quiet than the others.
Sumner
This is actually pretty good. They will as a practical matter be bound in many cases, because there is a legal rule called "estoppel" which will prevent them from changing their mind on someone after they have acted in reliance on this policy. The permission given here should actually be pretty difficult to shake off.
I am not a lawyer, this is not legal advice.
As far as I understand it, estoppel as it applies to patents is limited to admissions before the PTO and the courts. Essentially, if you file for patent A and tell the PTO, "this doesn't apply to B" then you can't later prosecute someone for infringement of "B" even if the "it doesn't apply to B" clause isn't written in the patent anywhere.
It's basically to prevent you from pulling a fast one to get something by the PTO (though in this day and age it seems like you don't need a fast one, they'll grant anything).
In other words, I think it would be difficult to argue to a court that they've created a legal estoppel here; not impossible, but it's definitely not a given.
See e.g. the baypents glossary entry for estoppel.
Also see (but read the rest of this paragraph)
their description of "Prosecution History Estoppel". The latter (Prosecution History Estoppel) is a broader restriction but the linked page says "a strong appeal of that decision to the U.S. Supreme Court is currently (early 2001) under way". In fact, the Court rendered its verdict earlier this week refusing to apply the doctrine of equivalents to prosecution history estoppel, which takes a lot of the teeth out of PHE. So don't rely on that one unless you have a very good understanding of the law and the Court's decision. (also note that in this context "prosecution" doesn't relate to patent enforcement but rather to the process of applying for the patent).
Again, I'm not a lawyer. Consult a lawyer if you need legal advice.
Sumner
Undefended patents are lost
No they aren't.
Undefended trademarks are lost. Patents are often submarined (ie not defended for years until the patented idea is in widespread use, then you can sue more people for money), the canonical example is what Unisys did with the GIF patent.
I am not a lawyer. Consult a lawyer if you need legal advice.
Sumner