Please Link to ACCU Book Reviews Section
on
General IT Books?
·
· Score: 5, Informative
Everyone, I'd like to strongly urge that when you mention a programming book online, not just in this discussion, but in any web page you write or even in email or the Usenet News, that you check the
Association of C and C++ Users
Book Reviews section, and if you find that the book is in there, provide a link to its review.
The ACCU makes review copies of books available to its members for free, and then the members write reviews that are printed first in the members' magazines, and then archived on the web for all to see. Because these reviews are written by working engineers, they tend to be pretty direct, to the point, and best of all they make it really clear when they recommend against a bad book.
To save you some clicking, here are some links to some of its sections:
The ACCU welcomes programmers in "any language the uses curly braces" (like C# and Java) and the reviews cover books on a wide variety of subjects, even awk and astronomy, so do check there even if your book is not on C or C++.
John Lakos: Large Scale C++ Software Design
on
General IT Books?
·
· Score: 3, Informative
While of course much of it is C++ specific, there is a great deal of information that applies to nearly any language. Most notable are his discussions of analyzing dependencies, and extensive discussion on resolving circular dependencies, and software "Design for Testability" (Unit Testing discussed much earlier than eXtreme Programming came along, as well as "White Box" testing.)
Lakos used to work for Mentor Graphics, an electronic CAD software vendor. Mentor was one of the first companies to adopt C++ for the development of large production systems back in the 80's, and their first attempts were collosal disasters. But surprisingly they didn't give up, instead they worked out a detailed methodology for doing successful and productive C++ development.
It has helped me immensely in my work, and I am on a quiet campaign to get all of my client's programmers to read it.
My page
Avoiding Unnecessary Header File Inclusion is based on the ideas in Lakos book, if you want a detailed example of why this is worthwhile reading. (That part is C++ specific, though.)
About dependencies:
A well-designed program will have a "dependency graph" that has no cycles in it. This allows components of the programs to stand on their own, depending on at most a few other modules. This aids comprehension by developers, and also aids testing.
What this means is that many components of a program will depend either on nothing else at all, or at most on standard libraries. Then at the next level up, there will be some components that depend only on the components at the first level or the zeroth level (the standard libraries). You can continue up this way, with components depending only on levels below them.
This aids both reusability and unit testing. Reusability because a component can be taken elsewhere and only requires the few components it depends on to work, and unit testing because you can build test executables by linking in only a few dependencies. It also aids testing because you can be sure a component is tested if you have a test for the component directly, and tests for each of its dependencies.
Poorly designed (and all-too-common) programs have dependency cycles. That is, the graph of module dependencies is not acycling, and you cannot link a module in its own test harness without taking a lot of junk with it. Maybe it even requires the entire program. Really bad programs will have a great many cycles in their dependency graphs.
There are quite a few techniques for managing these dependencies, a few C++ specific but many of them language-independent. Lakos catalogs many of them.
About unit testing:
Probably most people here are at least passingly familiar with unit testing. But Lakos has a strategy for making the effort to write tests manageble while still getting good test coverage.
First, you "levelize" your program (that is, create an acyclic dependency graph for your program).
Then, for each module, you make the assumption that the dependencies are already tested, and write the test for the module itself so that it only intentionally tests the code which is actually part of the module under test. You don't try to test the dependencies "through" a module that is at a layer above them.
This makes the amount of test code scale linearly with the number of modules, and also moderates the requirements for the effort a test must make.
While complete test coverage requires a unit test for each module, it is not really necessary to write the tests for the lowest levels first (although that is probably the best strategy).
In an automated test run, though, one should generally run the lowest level tests first.
Finally, Lakos discusses how one could write automated tools for doing dependency analysis. One can do this for C++ by basing it on Open Source tools like mkdep.
Well I don't have an answer to your question, but I can relate some relevant information.
Someone posted on the accu-general@accu.org list a few weeks ago (the
Association of C and C++ Users) that he'd been studying the demand for various job skills at employment websites in the U.K.
Suprisingly he found that the demand for C++ programmers was dramatically higher than that for Java programmers, and further that the pay scales offerred for Java programmers were very low.
This is in sharp contrast to the situation at the height of Tulipomania. Sometime in 2000 someone lamented on a post to a C++ newsgroup or list or something that it appeared that the hourly rates available to Java consultants was twice as much as those available to C++ consultants - as much as $250/hour. This despite the fact that C++ is a much more difficult language to master.
I think one thing this indicates is that the market for web server programming has fallen off the edge of the earth. But I'm not sure what all those C++ programmers are being hired for.
News of this study came as a relief to me because I've been doing mostly C++ the last few years, and although I know Java I haven't really put much effort into it. At some points I wondered if I had made a big mistake. But I've gotten very good at programming in C++, and enjoy it a great deal now, and in fact I'm finding demand for my
consulting work is starting to pick up noticably.
I don't know how the U.K. results could apply to other countries, but you could check it for the U.S. by searching for various job skills at
DICE and counting the number of hits you get for each.
You could do this more systematically by having a robot browse each of the job descriptions on DICE and scraping keywords and payrates out of each of them.
I can't post a link to the ACCU archive because the archives are only available to ACCU members and I'm afraid I let my membership lapse.:-/
Here's Colleen Rowley's contact info. The news reports and her letter indicate she works at the Minneapolis FBI field office, so I guess anything sent to the address or fax number listed on
their contact page should reach her.
Federal Bureau of Investigation
111 Washington Avenue South, Suite 1100
Minneapolis, MN 55401
Phone: (612) 376-3200 Fax: (612) 376-3249
Email:
minneapolis@fbi.gov
I'm going to write a brief letter with the above speech included and fax it to her later today.
A helpful reader named Jon Doyle wrote in to tell me I had a big HTML error in
Why
You Should use Encryption that caused half the page to be one big link. I hadn't noticed that because it didn't occur in the browsers I'd tried it with.
I ran it through the
W3C HTML validator and found quite a few problems with the HTML, and have fixed them. The page now validates as HTML 4.01 transitional.
Also I have long had a bad link to a page called "Email Encryption Made Simple", and several people have written in over the last couple years to give me an updated URL, but I never got around to fixing it. Now the link works.
Finally, I urge the use of PGP on the page. But Network Associates no longer supports PGP. I thought it would be helpful to mention GNU Privacy Guard, which is actually what I use these days. I added links to it and will try to elaborate on it in the discussion sometime in the next week or so.
What the heck, I'll just post the speech here, it's not that long:
When I was asked to make this address I wondered what I had to say to you boys who are graduating. And I think I have one thing to say. If you wish to be useful, never take a course that will silence you. Refuse to learn anything that implies collusion, whether it be a clerkship or a curacy, a legal fee or a post in a university. Retain the power of speech no matter what other power you may lose. If you can take this course, and in so far as you take it, you will bless this country. In so far as you depart from this course, you become dampers, mutes, and hooded executioners.
As a practical matter, a mere failure to speak out upon occassions where no statement is asked or expect from you, and when the utterance of an uncalled for suspicion is odious, will often hold you to a concurrence in palpable iniquity. Try to raise a voice that will be heard from here to Albany and watch what comes forward to shut off the sound. It is not a German sergeant, nor a Russian officer of the precinct. It is a note from a friend of your father's, offering you a place at his office. This is your warning from the secret police. Why, if you any of young gentleman have a mind to make himself heard a mile off, you must make a bonfire of your reputations, and a close enemy of most men who would wish you well.
I have seen ten years of young men who rush out into the world with their messages, and when they find how deaf the world is, they think they must save their strength and wait. They believe that after a while they will be able to get up on some little eminence from which they can make themselves heard. "In a few years," reasons one of them, "I shall have gained a standing, and then I shall use my powers for good." Next year comes and with it a strange discovery. The man has lost his horizon of thought, his ambition has evaporated; he has nothing to say. I give you this one rule of conduct. Do what you will, but speak out always. Be shunned, be hated, be ridiculed, be scared, be in doubt, but don't be gagged. The time of trial is always. Now is the appointed time.
John J. Chapman Commencement Address to the Graduating Class of Hobart College, 1900
I found Chapman's speech quoted in the printed edition of The Cluetrain Manifesto, and from the moment I read it, I was unable to rest until I had up on my website at the above URL.
It's not easy to speak out about what you believe in, but if more people did, the world would be a better place.
You would be suprised how easy it is to get access to the data you transmit over the Internet, and how many people are in a position to easily access it.
I don't have a citation for you, but I have read the california statute that specifically states that reverse engineering is legal.
You might be suprised to hear that. But consider what the point of the structure of patents is set up for - if you invent something, and you disclose your invention to the patent office, with instructions clear enough that someone "skilled in the art" can reproduce your invention, then you can be granted a patent.
Part of the idea is that once the patent expires, it goes into the public domain, along with explicit instructions for how to make your invention. Thus society as a whole ultimately benefits from the granting of a temporary monopoly.
Trade secrets are not legally protected monopolies, specifically because they don't provide the public benefit of putting the invention into the public domain.
What protection trade secrets have is a matter of keeping people honest. Someone who has signed a nondisclosure agreement is not allowed to disclose the invention, you can't steal it or bribe someone who knows it or whatever.
But reverse engineering is specifically allowed by california state law, and the law of all the other states as far as I know, in part because it provides a reason for inventors to patent stuff rather than keeping it secret - because that's the only way they can be granted a legal monopoly, and there is no protection from reverse engineering.
At least there wasn't before the DMCA, and I would argue the constitution makes the DMCA illegal, because it only allows for monopolies to be granted by the patent system. Copyrights are a form of monopoly too, but the constitution doesn't provide legal ground for maintaining copyrights by forbidding devices that can copy, it only forbids actually making copies without permission.
If you are new to compiling your own kernel, or you would like information on how to more effectively test development kernels (or stable kernels, before putting them into production), these two articles may be helpful to you:
Also check out the
Open Source Development Lab's
Scalable Test Platform. You can use STP to run your kernel patches and test code that you upload to OSDL's big iron hardware, or you can download the STP source code so you can use it as a test harness on your own machine.
(I should add the STP to my article but haven't gotten around to doing so yet).
I believe the best treatment for hate speech (on the Internet or otherwise) is more speech. Here's a couple of pieces, one that I wrote, the other a quote of a speech made 102 years ago that's as valid today as the day it was written:
Linux isn't the only one who holds copyrights in the Linux kernel. Each kernel developer who has done much work at all holds a copyright to some source file in there, so the whole of the kernel probably has hundreds of copyright owners.
Even if Linus were to do that (and even Richard Stallman says one can do such things) he'd have to get the agreement of all the other kernel developers, something I don't think can happen.
I had heard that 10,000 RPM drives were really noisy so I was anxious about ever using one since my office is already very noisy (4 computers).
But I wanted good performance for a machine I was converting to a dedicated fileserver for my home office (finally a machine I could leave running Linux all the time, without having to reboot, running Samba, Netatalk and NFS for all my machines). So I decided to try the Atlas 10k III.
The one I ordered was a Quantum, but I guess they got bought out by Maxtor, or something, anyway Quantum is still around but only sells tape drives now.
I read somewhere that the 10k III's were quieter than previous 10,000 RPM drives so I was pretty hopeful.
My first drive didn't work. I tried it at first in my mac on an adaptec 29160, but the 29160 didn't
detect it. I thought it wasn't spinning up
because I couldn't hear it.
Maxtor sent me an advance RMA (secured by a credit card) and I got the new drive today. I
have 30 days to return the broken drive or else
they'll charge my card.
The web page
above says they are Ultra320 but the drive I
have is labeled Ultra160. No matter, really, I
don't think one drive can sustain a 320 MB/sec
transfer rate - these high transfer rates are
most useful for RAIDs.
I was distressed when I put the new drive in
my PC on an adaptec 39160, because I couldn't
hear it at all! There is another drive in the
box, an old 2 GB IDE drive with Windows 2000, and
the old drive completely covers up any sound
coming out of the 10kIII.
I was really upset until I went into the Adaptec SCSI utility to test and format the drive, which
checked out fine.
I'm really impressed. My wife wants me to get
these for all our machines.
I'm installing just the bare essentials of Debian potato on it as I write these, and then I'm going to use debian's go-woody script to update it to woody.
Enterprise server admins might be skeptical of running beta software on a fileserver, but I've been running unstable (sid) on my Mac for months
with few problems. My only concern is which
kernel is the best, I want to run a 2.4 kernel
on it and I'm not sure which I should use.
I have great ambitions for the Linux Quality Database which are so far mostly unfulfilled, but for now I have some articles which you may find worthwhile reading:
I'm building my own telescope, an 8 inch (wide) reflector. You can build a telescope too, very inexpensively and with modest materials.
It's very interesting and enjoyable. Try it! Maybe you'll discover a comet too someday.
True, to purchase an 8 inch reflector isn't that bad anymore, but with the skill you gain from building a small telescope you would become able to build a much larger telescope affordably; to buy one, say a 20 inch, would be beyond the financial reach of most working people, but you could reasonably build one. Many people do.
The amateur telescope making mailing list will be glad to help you out. Mel Bartels has a lot of
telescope making links.
At the advice of a friend I recently tried the
Intel VTune performance analyzer on a Windows program I'm developing for my client (it has a 30-day free evaluation, with free tech support even during the eval).
I am extremely impressed with it and right away I was able to make my code much faster, faster even than getting a better compiler would have been able to do.
The 5.0 release version is windows only, but the
VTune 6.0 Beta will profile code running on both Windows and Linux. You still need a Windows host to run the UI on, but you can profile on a Linux box across the network. I think they supply kernel patches to put some performance monitoring tools in the kernel.
If just a few key free software developer had this tool, it would make a tremendous difference. For the most part, the suggestions it gives you are applicable to any processor, not just x86. Yes, the code coach will tell you to put in SIMD instructions but you don't need to do that, you can pay attention to when it tells you there is a hidden temporary in C++, for example.
If the profiling were applied to libraries like the XLib, Gnome libraries, KDE libraries, glibc and so on it would benefit all platforms.
Also you can profile cross-platform code on Windows, like AbiWord, the Gimp or Mozilla and help out code on Linux.
I'm using an eval copy now but I'm planning on purchasing a licensed copy soon. I think it will make a huge difference to the results I can produce for my consulting business, and I plan to use the tool to contribute to free software products as well.
I realized I hadn't checked the links in the article for nearly a year, and knew that some of them were out of date. All the links are now fixed, and I added memtester, a user-mode RAM test for Unix-like systems.
A few months before 2.4.0 was released, I inquired on the linux-kernel mailing if there was any organized QA effort for the new kernels. Read my post
Organized Linux QA?
The response I received from a number of kernel developers was that there wasn't such a thing really but it would be great if I did the work of organizing it.
What my plan was, and is, to organize serious QA efforts among people other than the normal kernel
developers, in support of the developers, so they can get faster and more thorough feedback on their code.
Unfortunately, my consulting work has always been very hectic, and so I have not been able to do the work on this that I want to, at least not yet. Things are getting a little more rational in my business, so I have high hopes for resuming my work on it sometime soon.
There is something of value on the site that can help everyone though, I wrote a few
articles on the topic of linux kernel and
web application quality. The articles of interest to kernel testing are:
I placed these under the GNU Free Documentation License in hopes that they would get widely distributed, perhaps included with distros. I plan to write a lot more articles - I like to write when I have the time.
I was happy to see that the
Open Source
Development Lab took advantage of the GFDL on
the articles and reproduced them at its own site
here.
Some might ask why I don't use an existing bug
database such as bugzilla. I may well adapt bugzilla, I'm still trying to figure out what to do, but a central part of what I plan is a bug
database optimized for tracking kernel bugs.
A database user will be able to enter in the configurations of the machines they have at their disposal, drawing on a database of known hardware, and give names to particular configurations.
When they report a bug, they can report the bug
against selections from a list or menu of the
configurations they have previously configured.
Also, they can upload the kernel.config file used in the kernel build.
Doing this will allow developers who are researching bugs to determine whether their code has been used on certain hardware, or to do boolean searches on both hardware and.config options to find out about interactions of kernel code with hardware.
I think bugzilla could be expanded to do this, or another bug database, but this is not a capability in any bug database I've used so far, either open source or proprietary ones at companies I've worked for.
Slashdot Mirror
The ACCU makes review copies of books available to its members for free, and then the members write reviews that are printed first in the members' magazines, and then archived on the web for all to see. Because these reviews are written by working engineers, they tend to be pretty direct, to the point, and best of all they make it really clear when they recommend against a bad book.
To save you some clicking, here are some links to some of its sections:
-
Reviews arranged by subject
-
Reviews arranged by Title
-
Reviews arranged by author
-
Reviews of Highly Recommended Books
-
Highly Recommended books on Advanced C
-
Highly Recommended books on Java
Here is a review of a book that is "Not Recommended" so you can see the value the ACCU reviews will have in helping you avoid bad books.The ACCU welcomes programmers in "any language the uses curly braces" (like C# and Java) and the reviews cover books on a wide variety of subjects, even awk and astronomy, so do check there even if your book is not on C or C++.
While of course much of it is C++ specific, there is a great deal of information that applies to nearly any language. Most notable are his discussions of analyzing dependencies, and extensive discussion on resolving circular dependencies, and software "Design for Testability" (Unit Testing discussed much earlier than eXtreme Programming came along, as well as "White Box" testing.)
Lakos used to work for Mentor Graphics, an electronic CAD software vendor. Mentor was one of the first companies to adopt C++ for the development of large production systems back in the 80's, and their first attempts were collosal disasters. But surprisingly they didn't give up, instead they worked out a detailed methodology for doing successful and productive C++ development.
It has helped me immensely in my work, and I am on a quiet campaign to get all of my client's programmers to read it.
My page Avoiding Unnecessary Header File Inclusion is based on the ideas in Lakos book, if you want a detailed example of why this is worthwhile reading. (That part is C++ specific, though.)
About dependencies:
A well-designed program will have a "dependency graph" that has no cycles in it. This allows components of the programs to stand on their own, depending on at most a few other modules. This aids comprehension by developers, and also aids testing.
What this means is that many components of a program will depend either on nothing else at all, or at most on standard libraries. Then at the next level up, there will be some components that depend only on the components at the first level or the zeroth level (the standard libraries). You can continue up this way, with components depending only on levels below them.
This aids both reusability and unit testing. Reusability because a component can be taken elsewhere and only requires the few components it depends on to work, and unit testing because you can build test executables by linking in only a few dependencies. It also aids testing because you can be sure a component is tested if you have a test for the component directly, and tests for each of its dependencies.
Poorly designed (and all-too-common) programs have dependency cycles. That is, the graph of module dependencies is not acycling, and you cannot link a module in its own test harness without taking a lot of junk with it. Maybe it even requires the entire program. Really bad programs will have a great many cycles in their dependency graphs.
There are quite a few techniques for managing these dependencies, a few C++ specific but many of them language-independent. Lakos catalogs many of them.
About unit testing:
Probably most people here are at least passingly familiar with unit testing. But Lakos has a strategy for making the effort to write tests manageble while still getting good test coverage.
First, you "levelize" your program (that is, create an acyclic dependency graph for your program).
Then, for each module, you make the assumption that the dependencies are already tested, and write the test for the module itself so that it only intentionally tests the code which is actually part of the module under test. You don't try to test the dependencies "through" a module that is at a layer above them.
This makes the amount of test code scale linearly with the number of modules, and also moderates the requirements for the effort a test must make.
While complete test coverage requires a unit test for each module, it is not really necessary to write the tests for the lowest levels first (although that is probably the best strategy).
In an automated test run, though, one should generally run the lowest level tests first.
Finally, Lakos discusses how one could write automated tools for doing dependency analysis. One can do this for C++ by basing it on Open Source tools like mkdep.
Someone posted on the accu-general@accu.org list a few weeks ago (the Association of C and C++ Users) that he'd been studying the demand for various job skills at employment websites in the U.K.
Suprisingly he found that the demand for C++ programmers was dramatically higher than that for Java programmers, and further that the pay scales offerred for Java programmers were very low.
This is in sharp contrast to the situation at the height of Tulipomania. Sometime in 2000 someone lamented on a post to a C++ newsgroup or list or something that it appeared that the hourly rates available to Java consultants was twice as much as those available to C++ consultants - as much as $250/hour. This despite the fact that C++ is a much more difficult language to master.
I think one thing this indicates is that the market for web server programming has fallen off the edge of the earth. But I'm not sure what all those C++ programmers are being hired for.
News of this study came as a relief to me because I've been doing mostly C++ the last few years, and although I know Java I haven't really put much effort into it. At some points I wondered if I had made a big mistake. But I've gotten very good at programming in C++, and enjoy it a great deal now, and in fact I'm finding demand for my consulting work is starting to pick up noticably.
I don't know how the U.K. results could apply to other countries, but you could check it for the U.S. by searching for various job skills at DICE and counting the number of hits you get for each.
You could do this more systematically by having a robot browse each of the job descriptions on DICE and scraping keywords and payrates out of each of them.
I can't post a link to the ACCU archive because the archives are only available to ACCU members and I'm afraid I let my membership lapse. :-/
Mike
I ran it through the W3C HTML validator and found quite a few problems with the HTML, and have fixed them. The page now validates as HTML 4.01 transitional.
Also I have long had a bad link to a page called "Email Encryption Made Simple", and several people have written in over the last couple years to give me an updated URL, but I never got around to fixing it. Now the link works.
Finally, I urge the use of PGP on the page. But Network Associates no longer supports PGP. I thought it would be helpful to mention GNU Privacy Guard, which is actually what I use these days. I added links to it and will try to elaborate on it in the discussion sometime in the next week or so.
It's not easy to speak out about what you believe in, but if more people did, the world would be a better place.
-
Why You Should Use Encryption
You would be suprised how easy it is to get access to the data you transmit over the Internet, and how many people are in a position to easily access it.When you're done with that, consider also reading Is This the America I Love?
Thank you for your attention.
You might be suprised to hear that. But consider what the point of the structure of patents is set up for - if you invent something, and you disclose your invention to the patent office, with instructions clear enough that someone "skilled in the art" can reproduce your invention, then you can be granted a patent.
Part of the idea is that once the patent expires, it goes into the public domain, along with explicit instructions for how to make your invention. Thus society as a whole ultimately benefits from the granting of a temporary monopoly.
Trade secrets are not legally protected monopolies, specifically because they don't provide the public benefit of putting the invention into the public domain.
What protection trade secrets have is a matter of keeping people honest. Someone who has signed a nondisclosure agreement is not allowed to disclose the invention, you can't steal it or bribe someone who knows it or whatever.
But reverse engineering is specifically allowed by california state law, and the law of all the other states as far as I know, in part because it provides a reason for inventors to patent stuff rather than keeping it secret - because that's the only way they can be granted a legal monopoly, and there is no protection from reverse engineering.
At least there wasn't before the DMCA, and I would argue the constitution makes the DMCA illegal, because it only allows for monopolies to be granted by the patent system. Copyrights are a form of monopoly too, but the constitution doesn't provide legal ground for maintaining copyrights by forbidding devices that can copy, it only forbids actually making copies without permission.
Also check out the Open Source Development Lab's Scalable Test Platform. You can use STP to run your kernel patches and test code that you upload to OSDL's big iron hardware, or you can download the STP source code so you can use it as a test harness on your own machine.
(I should add the STP to my article but haven't gotten around to doing so yet).
Even if Linus were to do that (and even Richard Stallman says one can do such things) he'd have to get the agreement of all the other kernel developers, something I don't think can happen.
Only U.S. Citizens need apply. Relocation to the Washington D.C. area is required.
They prefer you apply online!
Thank you for your attention.
But I wanted good performance for a machine I was converting to a dedicated fileserver for my home office (finally a machine I could leave running Linux all the time, without having to reboot, running Samba, Netatalk and NFS for all my machines). So I decided to try the Atlas 10k III.
The one I ordered was a Quantum, but I guess they got bought out by Maxtor, or something, anyway Quantum is still around but only sells tape drives now.
I read somewhere that the 10k III's were quieter than previous 10,000 RPM drives so I was pretty hopeful.
My first drive didn't work. I tried it at first in my mac on an adaptec 29160, but the 29160 didn't detect it. I thought it wasn't spinning up because I couldn't hear it.
Maxtor sent me an advance RMA (secured by a credit card) and I got the new drive today. I have 30 days to return the broken drive or else they'll charge my card.
The web page above says they are Ultra320 but the drive I have is labeled Ultra160. No matter, really, I don't think one drive can sustain a 320 MB/sec transfer rate - these high transfer rates are most useful for RAIDs.
I was distressed when I put the new drive in my PC on an adaptec 39160, because I couldn't hear it at all! There is another drive in the box, an old 2 GB IDE drive with Windows 2000, and the old drive completely covers up any sound coming out of the 10kIII.
I was really upset until I went into the Adaptec SCSI utility to test and format the drive, which checked out fine.
I'm really impressed. My wife wants me to get these for all our machines.
I'm installing just the bare essentials of Debian potato on it as I write these, and then I'm going to use debian's go-woody script to update it to woody.
Enterprise server admins might be skeptical of running beta software on a fileserver, but I've been running unstable (sid) on my Mac for months with few problems. My only concern is which kernel is the best, I want to run a 2.4 kernel on it and I'm not sure which I should use.
-
Why We Should All Test the New Linux Kernel
-
Using Test Suites to Validate the Linux Kernel
-
Use Validators and Load Generators to Test Your Web Applications
Also if you program in C++, these articles may be useful:It's very interesting and enjoyable. Try it! Maybe you'll discover a comet too someday.
True, to purchase an 8 inch reflector isn't that bad anymore, but with the skill you gain from building a small telescope you would become able to build a much larger telescope affordably; to buy one, say a 20 inch, would be beyond the financial reach of most working people, but you could reasonably build one. Many people do.
The amateur telescope making mailing list will be glad to help you out. Mel Bartels has a lot of telescope making links.
Yes, I post the link to this here all the time, I think it's useful to people.
I am extremely impressed with it and right away I was able to make my code much faster, faster even than getting a better compiler would have been able to do.
The 5.0 release version is windows only, but the VTune 6.0 Beta will profile code running on both Windows and Linux. You still need a Windows host to run the UI on, but you can profile on a Linux box across the network. I think they supply kernel patches to put some performance monitoring tools in the kernel.
If just a few key free software developer had this tool, it would make a tremendous difference. For the most part, the suggestions it gives you are applicable to any processor, not just x86. Yes, the code coach will tell you to put in SIMD instructions but you don't need to do that, you can pay attention to when it tells you there is a hidden temporary in C++, for example.
If the profiling were applied to libraries like the XLib, Gnome libraries, KDE libraries, glibc and so on it would benefit all platforms.
Also you can profile cross-platform code on Windows, like AbiWord, the Gimp or Mozilla and help out code on Linux.
I'm using an eval copy now but I'm planning on purchasing a licensed copy soon. I think it will make a huge difference to the results I can produce for my consulting business, and I plan to use the tool to contribute to free software products as well.
Again, the test suite article is here.
Thank you for your attention.
The response I received from a number of kernel developers was that there wasn't such a thing really but it would be great if I did the work of organizing it.
SunSITE.dk seemed to be the best site of the many kind folks who offerred to host it, and so was born The Linux Quality Database.
What my plan was, and is, to organize serious QA efforts among people other than the normal kernel developers, in support of the developers, so they can get faster and more thorough feedback on their code.
Unfortunately, my consulting work has always been very hectic, and so I have not been able to do the work on this that I want to, at least not yet. Things are getting a little more rational in my business, so I have high hopes for resuming my work on it sometime soon.
There is something of value on the site that can help everyone though, I wrote a few articles on the topic of linux kernel and web application quality. The articles of interest to kernel testing are:
-
Why We Should All Test the New Linux Kernel
-
Using Test Suites to Validate the Linux Kernel
I placed these under the GNU Free Documentation License in hopes that they would get widely distributed, perhaps included with distros. I plan to write a lot more articles - I like to write when I have the time.I was happy to see that the Open Source Development Lab took advantage of the GFDL on the articles and reproduced them at its own site here.
Some might ask why I don't use an existing bug database such as bugzilla. I may well adapt bugzilla, I'm still trying to figure out what to do, but a central part of what I plan is a bug database optimized for tracking kernel bugs.
A database user will be able to enter in the configurations of the machines they have at their disposal, drawing on a database of known hardware, and give names to particular configurations.
When they report a bug, they can report the bug against selections from a list or menu of the configurations they have previously configured.
Also, they can upload the kernel .config file used in the kernel build.
Doing this will allow developers who are researching bugs to determine whether their code has been used on certain hardware, or to do boolean searches on both hardware and .config options to find out about interactions of kernel code with hardware.
I think bugzilla could be expanded to do this, or another bug database, but this is not a capability in any bug database I've used so far, either open source or proprietary ones at companies I've worked for.
I've written my first article in a planned regular column there, Writing Cross-Platform Software - Getting Started.
While it will be a while, I do plan a number of articles on virtual machines.
You can get books telling how to make telescopes from Willman-Bell and ask for help on the Amateur Telescope Maker's mailing list. Dan Cassaro can sell you a reasonably priced mirror grinding kit.
You can find many products for amateur astronomers at the Astronomy Mall.
Clear Skies!
Google Search.