You *can* do this in Bugzilla, but you need to enable the contributed Bugzilla Mail Interface in contrib/. That contributed package is in some need of maintenance, however.
Check here or here for details.
If you already have Tinderbox running, I would see no reason to upgrade to Tinderbox2 (and neither does the Mozilla team at the moment). The biggest deal is that T2 is relatively easy to customize for third-party developers outside of mozilla.org. Eventually, I think Tinderbox2 development will surpass the original Tinderbox. Tinderbox(1) has a whole lot of mozilla-specific stuff in the way it works. T2 is a whole lot more generic, and seems quite expandable. I encourage you to give it a shot, but if yours isn't broke...
I've used it as such. We had our IT, UNIX Admin, and product engineering staff all using Bugzilla at my former employer. Each group had their own projects, and the IT and Systems Administration support staff made heavy use of the Bugzilla email interface so that their tracking system was transparent to other staff. I have a couple custom hacks to support this currently in B.M.O. (look for bugs submitted by barnboy@trilobyte.net) which allow user account creation at bug submission (an open bug receiver, like GNATS) and command-line specification of product/component depending upon email address it was sent to. The hacks are pretty ugly (but dead simple!), though, which is why I haven't put them into CVS.
It worked well for us. I'd love to go back and revisit this some in the future, though, since it's a commonly-requested feature and more documentation on how to do it is probably necessary.
I'm the doc maintainer for Bugzilla, I guess I'd better get busy!
I sympathize with your plight. I've succeeded in persuading a lot of people to use Bugzilla instead of some closed-source bug-tracker, but the pointy-haired boss contingent continues to fight it.
I've replaced some very expensive systems with Bugzilla, too. For programmers, Bugzilla is great. For managers, it's scary. Welcome to open source : )
Some proprietary systems have reasonable niche markets. For instance, if you require integrated inventory tracking, IT trouble-ticket tracking, moderated discussion forums, and tech support telephony integration, Bugzilla may not be the right tool for you. I've used it successfully for two out of the three (just takes a little user retraining and some trivial Bugzilla source hacking), but it's really important to decide if it has what you really need in your corporate environment.
Me, I say use Bugzilla for software development, then write a plug-in to your other systems using its XML or HTTP API's so they can communicate; that way you're using the best tool for the job!
Have you tried the Bugzilla Helper? It really helps newbies write a quality bug report; I highly recommend adapting it to your needs at your site if you wish to run a local Bugzilla where you work. However, it's a bit of a maintenance problem right now; I'd love to see this page automated and cached to allow a user-friendly front-end to bug reporting which tracks the database as it changes, rather than requiring manual updates.
Great comment!
True that probably half the 100,000 bugs are duplicates. B.M.O. also tracks feature requests.
There are actually a whole suite of webtools for users to check out, including Bonsai, Tinderbox/Tinderbox2, a rip-off of an old version of LXR, automated build scripts, and some miscellaneous stat-tracking stuff. However, behind Mozilla, Bugzilla is far and away the most popular product at mozilla.org. We very recently changed it from being part of the Webtools product to its own product entirely, and since the 2.12 release its popularity has just exploded.
I'd love more people to start using the other webtools as well! Where I work, we're using Tinderbox2 and Bonsai. Tinderbox2 is email-based automated build tracking which integrates with CVS, while Bonsai is a MySQL-based CVS query front-end. Bonsai is quite similar to CVSweb, but offers powerful query features and some automated tracking (it doesn't handle spaces,though -- if you try it, you've been warned!). If you have a need for powerful CVS queries and automated build tracking, give them a shot.
Tinderbox2 and Bonsai are available via CVS, like the very latest Bugzilla. To check it out on a UNIX system:
$ export CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
$ cvs login
password: (anything works here)
$ cvs checkout mozilla/webtools
or for just CVS Bugzilla:
$ cvs checkout mozilla/webtools/bugzilla
More than just a checkbox on the bug, really. You have an entire user preferences dialog for each user where you can indicate your preferences on bugmail for various states of the bug, whether you're on the CC list or you reported it, that kind of thing. It works pretty well.
One unused feature of Bugzilla at bugzilla.mozilla.org is the ability to reply to bugmail and have it tacked into the database. Many others use this feature, however; you can find the Bugzilla email interface and associated documentation in the contrib/ directory when you download the Bugzilla 2.14 tarball.
However, be warned that the email reply feature is not as thoroughly tested as the web interface. This is another reason for it not to be in use at B.M.O. There are currently a couple of notable problems with it:
1. Even if a user account is disabled, they can still add comments to bugs, or create new ones, by sending email to the bugmail reply address.
2. It's case-sensitive on usernames, so if your capitalization isn't correct on your From: header it will refuse to update the bug.
3. You can't currently change parameters of the bug through bugmail (ergo: setting @priority=1 in the mail doesn't work).
It would be great to have a new developer help improve the Bugzilla Mail Interface. Nobody's paid much attention to it for about a year, since Seth Landsman stopped maintaining it. Any takers?
It is, unfortunately, true that Bugzilla is fairly easily swamped by massive traffic. We encourage the use of mod_throttle on Apache for just this reason. Often, web spiders attempt to index publicly-available Bugzilla sites, and that can basically amount to a denial-of-service attack.
I think you'll find this is true with most heavily dynamic, database-driven web sites. I'd ultimately love to get better scalability than Slashdot out of Bugzilla, but in the near-term we're trying to avoid dependencies on mod_perl and certain other areas of performance enhancement because they cause dependencies on certain types of web servers.
There is some heavy discussion going on amongst the Bugzilla developers about using some kind of caching method to prevent slashdotting of Bugzilla in the future, but for now it's not there. Contributions welcome!
I think it's very possible that mozilla.org may become better known for Bugzilla than Mozilla : ) Bugzilla is already the premier open-source bug-tracking system; I consider it a really good point in the favor of any company if they are using it.
However, I must caution that it's still a real pain to install on Microsoft Windows, and requires non-trivial UNIX knowledge to make work on a UNIX platform. Also, it's heavily geared towards Apache web server, since that's what B.M.O. uses and most of those admins running Bugzilla use it. AFAIK it still works fine on iPlanet and IIS, but you need to implement your own security to protect certain critical files from remote inspection. There's a file we use called "localconfig" which contains your database password; that file must not be readable by web users!
If you're an admin for an enterprise looking for a high-quality bug tracker, I highly recommend Bugzilla. If all you're looking to do is track bugs on a very small product, or if you're not an experienced admin on your platform of choice for Bugzilla, a mailing list is probably much more the thing for you. I love Bugzilla, but like most other enterprise-class software, it can be difficult to get up and configured correctly, particularly if you don't already have the necessary prerequisite packages already installed.
Bugzilla is tracking 100,000 bugs. However, each bug tracks the following states:
Product
Component
Status
Resolution
Assigned_to
QA Contact
URL
Summary
Status Whiteboard
Keywords
Platform
OS
Version
Priority
Severity
Unlimited CC's
Attachments
Dependencies
Votes
Comments
History
At a bare minimum, there are at least 20 fields associated with each bug. In general, though, there are several large user comments, attachments containing patches, etc. for each bug. Figure 25 fields as a nice round number. 100,000 Bugzilla bugs >= 2.5 million individual records. Bugzilla.mozilla.org may not be in the 20 or 30 million league, but it's certainly getting there.
I use Bugzilla on a daily basis, and am also the documentation maintainer for the project. After using it since shortly after it was released, I can say without equivocation that it is more feature-rich, easier to use, and scalable than any other bug-tracking system I've seen. As the first full-featured open-source bug-tracking system released, it has a lot of first-mover support from developers and documentors, and is getting enormously better with each new release.
Go check it out, pre-populate 20 million bugs in your own database, and see what you think! I think you'll be impressed.
Sorry if this is too glowing a review; you should expect a biased opinion from those who have used Bugzilla for any length of time : )
Don't laugh. That's exactly the solution we're considering in #mozwebtools right now!
I'm personally a fan of using some sort of caching algorithm, but how to do that without fubaring security on Bugzilla is still in questions.
I'm just the documenter for the project, though. I can count the number of lines of source code I've contributed to Bugzilla on the fingers of both hands.
I must admit, I'm biased by a very bad experience with ObjectStore. Here's the story.
I used to work for Excite@Home, in their E-Business Services unit (now defunct; those left are just an engineering adjunct to Excite@Home). We created a web-based store hosting product based entirely upon ObjectStore as the back-end using Java for dynamic page generation getting results from C++ query servers.
Unfortunately, the site became very popular, and with all the orders, order information, store products, etc. stored in the database, had hundreds of millions of objects (in some cases, very large objects) in the data store.
We began running up against the 32-bit barrier for address space within ObjectStore. At the time, there was no 64-bit version of ObjectStore (and I don't know if there is now). We would watch performance steadily degrade on our C++ queries over the course of 2 or 3 months, until finally it would nearly grind to a halt because of lack of address space and we would be forced into a 12-14 hour defragmentation routine. Each time we went through this cycle, it would start again, but performance would erode even faster.
Admittedly, we were doing some pretty bizarre stuff. ObjectStore didn't support on-the-fly schema changes, so we hacked some utilities which allowed us to do that (and which ate address space). We also stored all the product orders in the database, and we never fully deleted orders until we defragmented. But fundamentally, ObjectStore had a problem with scalability for extremely large databases (billions of objects).
We went to Oracle, and the problems disappeared. Hello, 64-bit world, hello nearly unlimited address space, bye-bye constant database defragmentation. I'm not saying Oracle is a panacea -- it's not, and is quirky as hell -- but it blew the crap out of ObjectStore in this case.
I must disagree with your statement "No common text editor has a decent 'go to the end of the block' function." I use an exceptionally common editor (emacs) and in Python major mode skipping to the end of the block is as easy as "C-M-e". Also I *never* have a problem with Emacs in Python mode -- all my indentation is handled completely transparently. It sees that I'm starting a block and handles my indentation automatically, and leaving the block is as simple as hitting the backspace key.
If I understand correctly, the PythonWin IDE for MS Windows also includes this functionality. Your first argument is a straw man and factually incorrect.
Your second argument regarding spacing problems simply happens very rarely in Python. There is one indentation style (with the exception that the number of spaces is variable), and using such simple tools as Tab Nanny nips them in the bud. Just like C programmers remember to curly brace correctly, Python programmers indent correctly.
Anyway, interesting language war thread. I use Python and Perl extensively in my work, and find Python eminently more readable. It is also far easier to maintain, and is my language of choice for prototyping most new applications these days.
This is a very well-formed, easily understood argument against software patents.
Now if only it wasn't the hands of big business holding the reins of politics in the U.S., maybe we could make some progress.
Patents are here to promote inventiveness, but lately they do far more o discourage it.
Yes, this is the situation we face in Tooele, UT. Population is a little under 20,000 residents; AT&T@Home has no plans for rolling cable modem service out here, and DSL will only be provided by non-major players (QWorst isn't interested in running DSL out here because there aren't enough people to justify their cost).
If you're a Mom&Pop ISP in the right market (small town, rural), you can do very well for yourself. Until your town becomes big enough to make it onto the national players' radar screens.
The chances of us getting back to the original 28-year copyright are slim to none. The United States is bound by treaties requiring we adhere to international copyright standards, which require a copyright be valid for at least 50 years after the death of the last living author.
Thanks largely to the efforts of major copyright holders, the U.S. requires an additional twenty years beyond that and grants 120-year copyright on works made for hire.
It makes me physically ill to realize that Socialist France dictated national copyright policy to the land of the free and the home of the brave; the leaders of the land (when I was 5 years old, in 1978) did nothing to prevent it, and the current representatives are moving to strengthen the poorly-crafted dictates of earlier misguided legislators.
If you're interested in knowing what really happened to fair use in the USA and form an intelligent opinion regarding the legality of these technological measures to discourage fair use, I strongly recommend you consult some resources linked from http://fairuse.stanford.edu, particularly A History of Copyright in the U.S..
One advantage of Zope is easy access to the database via FTP. Although this isn't a true "UNIX file system", it can demonstrate the value of using a DB filesystem -- you FTP files up, and with built-in versioning you can view any number of versions via the Zope interface.
I believe that is one of the goals of ReiserFS as well -- that database vendors use file systems to store data instead of having to use raw disk partitions, or deal with file system overhead plus database overhead...
"(i'd also like to note that Word's inability to properly handle complex documents has nothing to do with the file format, so i don't really know how you got onto that tangent talking about file formats.)"
With FrameMaker and Microsoft Word, you are nearly incapable of separating the tool to create your documents from the documents themselves. You are tied to one platform to create and maintain your documents. Are there any free software alternatives that handle FrameMaker *well* (I don't know of any, but that doesn't mean they don't exist)? Are there any free software alternatives that handle Microsoft.doc *well*? I've used StarOffice, and although it does an admirable job of importing Word.doc files, it is nowhere near perfect, even on MS Windows. Other importers are quite spartan in their layout if they figure out the formatting at all.
If you're going to use.doc formats, all of your users must use Microsoft Word in order to avoid messing up the formatting. There is no standard for the format. And, if I understand correctly, we suffer the same problem with FrameMaker: everyone uses the same tool.
I'm *complaining* about my Product Management group choosing MS word for PRD's. It stinks, and everyone knows it, but they are not willing to make the jump into SGML/XML with DocBook, which is *perfect* for Product Requirement Documents. It's a good learning curve, and until a company makes it policy that they do it the right way, people will choose the only way they understand.
I don't agree the FrameMaker is the best tool for the job of Documentation, regardless of the proprietary file format. Distinguishing the file format (XML/SGML) from the document structure (DocBook DTD) from the presentation (some kind of SL, like Norman Walsh's excellent DSSSL) allows the utmost flexibility in your documentation. You can compile the code into anything your DSL/XSL can handle, and it is trivial to update documentation.
Anyway, back to the basic issue I had with your post: In most cases, it is very difficult to discuss file formats without discussing the tools you use to manipulate them.
The key issue, IMHO, this company needs to decide is what they want most from documentation: presentation or content.
Microsoft.doc format (and StarOffice's.sdw format) are very presentation-centric. The only thing that matters to it is how the printed page will be. PDF, PS, and many other formats share this limitation. Ideally one should focus on the content of the documentation, and allow it to expand without massively reformatting the page every time.
My company has run into this issue already. We open up our Product Requirement Documentation to modification as needed, and thereby lose all the formatting the Product Management staff has worked hard to get in there. Ever tried adding a paragraph on a page with an image anchored to a page position in MS Word? You get my drift.
If you choose to use the DocBook DTD (Document Type Definition) with XML (Extensible Markup Language) or SGML (Standard Generalized Markup Language), you can use an off-the-shelf DSSSL (Document Style Sheet Specification Language [I think]) or create your own to customize how the "compiled" raw SGML/XML should look.
An earlier poster said there is no good documentation on DocBook and SGML/XML. Bull Hockey, there's a full-fledged guide on how you can create standards-compliant, flexible DocBook available as the "LDP Author's Guide" at http://www.linuxdoc.org.
I must add my hearty approval. As the maintainer of the Bugzilla Guide (http://www.trilobyte.net/barnsons) I am immensely enjoying writing documentation in SGML instead of some lame proprietary format.
Another positive benefit of using SGML: All Department of Defense (IIRC) documentation must be SGML. So if you're ever going to have to maintain government documents, SGML is a great choice!
My gateway machine at home is a Pentium 133 with 128 MB RAM. I downloaded.6 last night before the news appeared on Slashdot; although rendering speed is not quite as fast as Netscape, start-up time is noticeably faster. Also lots of visual glitches with Netscape on Linux are gone. The Preferences screen on a 133 is pretty slow, but not intolerably so as it was in previous releases. There are some noticeable weirdnesses comparing Mozilla on my faster machine versus this, but I cannot say with authority that it is due to the speed difference.
Wireless *can* be extremely reliable; if your providers tower keeps going down, something is totally whacky with your provider. My problems are rarely related to my wireless link; they are usually due to DOS attacks on my ISP or one of their T-3's going down.
802.11 latency is typically 10ms, usually 3-5ms. 30ms would be a worst-case scenario; the WaveLAN card uses a collision avoidance algorithm. Latency to the rest of the world depends on your ISP; I regularly get game time pings of less than 100ms.
Trees are not an obstruction with any decent wattage and reasonable range. My antenna is in my attic, and punches through the attic walls regardless of snow. Wireless antennas need not be like satellite dishes: they are a grid of widely-spaced metal bars that do not collect much snow if mounted out-of-doors.
You are *almost* correct saying that if you can't see the antenna, you can't get great service. If there is a large hill in the way, you are sunk. If it's a small hill or houses, trees, etc. that is no problem at all for 2.4GHz wireless at sufficient wattage. Just sticking an unamplified PCMCIA card on your computer, though, you are certainly right; it has barely enough power to make it through the walls of your house out to a few hundred feet.
I'd have to agree, maintaining a big antenna would stink. My ISP stuck a 20 foot antenna on the roof of their building; they are uphill from most of town, but not enormously so. Works great.
Slashdot Mirror
Here's Google's cache of the page. It's kind of tough to slashdot google : )w ww.sans.org/top20.htm+&hl=en
http://www.google.com/search?q=cache:dbJlh35mihk:
Remember, check those links, you don't want to be goatse'd....
You *can* do this in Bugzilla, but you need to enable the contributed Bugzilla Mail Interface in contrib/. That contributed package is in some need of maintenance, however.
Check here or here for details.
If you already have Tinderbox running, I would see no reason to upgrade to Tinderbox2 (and neither does the Mozilla team at the moment). The biggest deal is that T2 is relatively easy to customize for third-party developers outside of mozilla.org. Eventually, I think Tinderbox2 development will surpass the original Tinderbox. Tinderbox(1) has a whole lot of mozilla-specific stuff in the way it works. T2 is a whole lot more generic, and seems quite expandable. I encourage you to give it a shot, but if yours isn't broke...
I've used it as such. We had our IT, UNIX Admin, and product engineering staff all using Bugzilla at my former employer. Each group had their own projects, and the IT and Systems Administration support staff made heavy use of the Bugzilla email interface so that their tracking system was transparent to other staff. I have a couple custom hacks to support this currently in B.M.O. (look for bugs submitted by barnboy@trilobyte.net) which allow user account creation at bug submission (an open bug receiver, like GNATS) and command-line specification of product/component depending upon email address it was sent to. The hacks are pretty ugly (but dead simple!), though, which is why I haven't put them into CVS.
It worked well for us. I'd love to go back and revisit this some in the future, though, since it's a commonly-requested feature and more documentation on how to do it is probably necessary.
I'm the doc maintainer for Bugzilla, I guess I'd better get busy!
I sympathize with your plight. I've succeeded in persuading a lot of people to use Bugzilla instead of some closed-source bug-tracker, but the pointy-haired boss contingent continues to fight it.
I've replaced some very expensive systems with Bugzilla, too. For programmers, Bugzilla is great. For managers, it's scary. Welcome to open source : )
Some proprietary systems have reasonable niche markets. For instance, if you require integrated inventory tracking, IT trouble-ticket tracking, moderated discussion forums, and tech support telephony integration, Bugzilla may not be the right tool for you. I've used it successfully for two out of the three (just takes a little user retraining and some trivial Bugzilla source hacking), but it's really important to decide if it has what you really need in your corporate environment.
Me, I say use Bugzilla for software development, then write a plug-in to your other systems using its XML or HTTP API's so they can communicate; that way you're using the best tool for the job!
Have you tried the Bugzilla Helper? It really helps newbies write a quality bug report; I highly recommend adapting it to your needs at your site if you wish to run a local Bugzilla where you work. However, it's a bit of a maintenance problem right now; I'd love to see this page automated and cached to allow a user-friendly front-end to bug reporting which tracks the database as it changes, rather than requiring manual updates.
Great comment!
: /cvsroot
True that probably half the 100,000 bugs are duplicates. B.M.O. also tracks feature requests.
There are actually a whole suite of webtools for users to check out, including Bonsai, Tinderbox/Tinderbox2, a rip-off of an old version of LXR, automated build scripts, and some miscellaneous stat-tracking stuff. However, behind Mozilla, Bugzilla is far and away the most popular product at mozilla.org. We very recently changed it from being part of the Webtools product to its own product entirely, and since the 2.12 release its popularity has just exploded.
I'd love more people to start using the other webtools as well! Where I work, we're using Tinderbox2 and Bonsai. Tinderbox2 is email-based automated build tracking which integrates with CVS, while Bonsai is a MySQL-based CVS query front-end. Bonsai is quite similar to CVSweb, but offers powerful query features and some automated tracking (it doesn't handle spaces,though -- if you try it, you've been warned!). If you have a need for powerful CVS queries and automated build tracking, give them a shot.
Tinderbox2 and Bonsai are available via CVS, like the very latest Bugzilla. To check it out on a UNIX system:
$ export CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org
$ cvs login
password: (anything works here)
$ cvs checkout mozilla/webtools
or for just CVS Bugzilla:
$ cvs checkout mozilla/webtools/bugzilla
Have fun!
More than just a checkbox on the bug, really. You have an entire user preferences dialog for each user where you can indicate your preferences on bugmail for various states of the bug, whether you're on the CC list or you reported it, that kind of thing. It works pretty well.
One unused feature of Bugzilla at bugzilla.mozilla.org is the ability to reply to bugmail and have it tacked into the database. Many others use this feature, however; you can find the Bugzilla email interface and associated documentation in the contrib/ directory when you download the Bugzilla 2.14 tarball.
However, be warned that the email reply feature is not as thoroughly tested as the web interface. This is another reason for it not to be in use at B.M.O. There are currently a couple of notable problems with it:
1. Even if a user account is disabled, they can still add comments to bugs, or create new ones, by sending email to the bugmail reply address.
2. It's case-sensitive on usernames, so if your capitalization isn't correct on your From: header it will refuse to update the bug.
3. You can't currently change parameters of the bug through bugmail (ergo: setting @priority=1 in the mail doesn't work).
It would be great to have a new developer help improve the Bugzilla Mail Interface. Nobody's paid much attention to it for about a year, since Seth Landsman stopped maintaining it. Any takers?
It is, unfortunately, true that Bugzilla is fairly easily swamped by massive traffic. We encourage the use of mod_throttle on Apache for just this reason. Often, web spiders attempt to index publicly-available Bugzilla sites, and that can basically amount to a denial-of-service attack.
I think you'll find this is true with most heavily dynamic, database-driven web sites. I'd ultimately love to get better scalability than Slashdot out of Bugzilla, but in the near-term we're trying to avoid dependencies on mod_perl and certain other areas of performance enhancement because they cause dependencies on certain types of web servers.
There is some heavy discussion going on amongst the Bugzilla developers about using some kind of caching method to prevent slashdotting of Bugzilla in the future, but for now it's not there. Contributions welcome!
I think it's very possible that mozilla.org may become better known for Bugzilla than Mozilla : ) Bugzilla is already the premier open-source bug-tracking system; I consider it a really good point in the favor of any company if they are using it.
However, I must caution that it's still a real pain to install on Microsoft Windows, and requires non-trivial UNIX knowledge to make work on a UNIX platform. Also, it's heavily geared towards Apache web server, since that's what B.M.O. uses and most of those admins running Bugzilla use it. AFAIK it still works fine on iPlanet and IIS, but you need to implement your own security to protect certain critical files from remote inspection. There's a file we use called "localconfig" which contains your database password; that file must not be readable by web users!
If you're an admin for an enterprise looking for a high-quality bug tracker, I highly recommend Bugzilla. If all you're looking to do is track bugs on a very small product, or if you're not an experienced admin on your platform of choice for Bugzilla, a mailing list is probably much more the thing for you. I love Bugzilla, but like most other enterprise-class software, it can be difficult to get up and configured correctly, particularly if you don't already have the necessary prerequisite packages already installed.
Bugzilla is tracking 100,000 bugs. However, each bug tracks the following states:
Product
Component
Status
Resolution
Assigned_to
QA Contact
URL
Summary
Status Whiteboard
Keywords
Platform
OS
Version
Priority
Severity
Unlimited CC's
Attachments
Dependencies
Votes
Comments
History
At a bare minimum, there are at least 20 fields associated with each bug. In general, though, there are several large user comments, attachments containing patches, etc. for each bug. Figure 25 fields as a nice round number. 100,000 Bugzilla bugs >= 2.5 million individual records. Bugzilla.mozilla.org may not be in the 20 or 30 million league, but it's certainly getting there.
I use Bugzilla on a daily basis, and am also the documentation maintainer for the project. After using it since shortly after it was released, I can say without equivocation that it is more feature-rich, easier to use, and scalable than any other bug-tracking system I've seen. As the first full-featured open-source bug-tracking system released, it has a lot of first-mover support from developers and documentors, and is getting enormously better with each new release.
Go check it out, pre-populate 20 million bugs in your own database, and see what you think! I think you'll be impressed.
Sorry if this is too glowing a review; you should expect a biased opinion from those who have used Bugzilla for any length of time : )
Don't laugh. That's exactly the solution we're considering in #mozwebtools right now!
I'm personally a fan of using some sort of caching algorithm, but how to do that without fubaring security on Bugzilla is still in questions.
I'm just the documenter for the project, though. I can count the number of lines of source code I've contributed to Bugzilla on the fingers of both hands.
I used to work for Excite@Home, in their E-Business Services unit (now defunct; those left are just an engineering adjunct to Excite@Home). We created a web-based store hosting product based entirely upon ObjectStore as the back-end using Java for dynamic page generation getting results from C++ query servers.
Unfortunately, the site became very popular, and with all the orders, order information, store products, etc. stored in the database, had hundreds of millions of objects (in some cases, very large objects) in the data store.
We began running up against the 32-bit barrier for address space within ObjectStore. At the time, there was no 64-bit version of ObjectStore (and I don't know if there is now). We would watch performance steadily degrade on our C++ queries over the course of 2 or 3 months, until finally it would nearly grind to a halt because of lack of address space and we would be forced into a 12-14 hour defragmentation routine. Each time we went through this cycle, it would start again, but performance would erode even faster.
Admittedly, we were doing some pretty bizarre stuff. ObjectStore didn't support on-the-fly schema changes, so we hacked some utilities which allowed us to do that (and which ate address space). We also stored all the product orders in the database, and we never fully deleted orders until we defragmented. But fundamentally, ObjectStore had a problem with scalability for extremely large databases (billions of objects).
We went to Oracle, and the problems disappeared. Hello, 64-bit world, hello nearly unlimited address space, bye-bye constant database defragmentation. I'm not saying Oracle is a panacea -- it's not, and is quirky as hell -- but it blew the crap out of ObjectStore in this case.
My two cents.
Matt Barnson
If I understand correctly, the PythonWin IDE for MS Windows also includes this functionality. Your first argument is a straw man and factually incorrect.
Your second argument regarding spacing problems simply happens very rarely in Python. There is one indentation style (with the exception that the number of spaces is variable), and using such simple tools as Tab Nanny nips them in the bud. Just like C programmers remember to curly brace correctly, Python programmers indent correctly.
Anyway, interesting language war thread. I use Python and Perl extensively in my work, and find Python eminently more readable. It is also far easier to maintain, and is my language of choice for prototyping most new applications these days.
Matt Barnson
Now if only it wasn't the hands of big business holding the reins of politics in the U.S., maybe we could make some progress.
Patents are here to promote inventiveness, but lately they do far more o discourage it.
Matt Barnson
If you're a Mom&Pop ISP in the right market (small town, rural), you can do very well for yourself. Until your town becomes big enough to make it onto the national players' radar screens.
Matt Barnson
Thanks largely to the efforts of major copyright holders, the U.S. requires an additional twenty years beyond that and grants 120-year copyright on works made for hire.
It makes me physically ill to realize that Socialist France dictated national copyright policy to the land of the free and the home of the brave; the leaders of the land (when I was 5 years old, in 1978) did nothing to prevent it, and the current representatives are moving to strengthen the poorly-crafted dictates of earlier misguided legislators.
If you're interested in knowing what really happened to fair use in the USA and form an intelligent opinion regarding the legality of these technological measures to discourage fair use, I strongly recommend you consult some resources linked from http://fairuse.stanford.edu, particularly A History of Copyright in the U.S..
Matt Barnson
I believe that is one of the goals of ReiserFS as well -- that database vendors use file systems to store data instead of having to use raw disk partitions, or deal with file system overhead plus database overhead...
Matt Barnson
"(i'd also like to note that Word's inability to properly handle complex documents has nothing to do with the file format, so i don't really know how you got onto that tangent talking about file formats.)"
With FrameMaker and Microsoft Word, you are nearly incapable of separating the tool to create your documents from the documents themselves. You are tied to one platform to create and maintain your documents. Are there any free software alternatives that handle FrameMaker *well* (I don't know of any, but that doesn't mean they don't exist)? Are there any free software alternatives that handle Microsoft
If you're going to use
I'm *complaining* about my Product Management group choosing MS word for PRD's. It stinks, and everyone knows it, but they are not willing to make the jump into SGML/XML with DocBook, which is *perfect* for Product Requirement Documents. It's a good learning curve, and until a company makes it policy that they do it the right way, people will choose the only way they understand.
I don't agree the FrameMaker is the best tool for the job of Documentation, regardless of the proprietary file format. Distinguishing the file format (XML/SGML) from the document structure (DocBook DTD) from the presentation (some kind of SL, like Norman Walsh's excellent DSSSL) allows the utmost flexibility in your documentation. You can compile the code into anything your DSL/XSL can handle, and it is trivial to update documentation.
Anyway, back to the basic issue I had with your post: In most cases, it is very difficult to discuss file formats without discussing the tools you use to manipulate them.
Matt Barnson
Microsoft
Matt Barnson
Another positive benefit of using SGML: All Department of Defense (IIRC) documentation must be SGML. So if you're ever going to have to maintain government documents, SGML is a great choice!
Matt Barnson
Matt Barnson
Matt Barnson
802.11 latency is typically 10ms, usually 3-5ms. 30ms would be a worst-case scenario; the WaveLAN card uses a collision avoidance algorithm. Latency to the rest of the world depends on your ISP; I regularly get game time pings of less than 100ms.
Matt Barnson
You are *almost* correct saying that if you can't see the antenna, you can't get great service. If there is a large hill in the way, you are sunk. If it's a small hill or houses, trees, etc. that is no problem at all for 2.4GHz wireless at sufficient wattage. Just sticking an unamplified PCMCIA card on your computer, though, you are certainly right; it has barely enough power to make it through the walls of your house out to a few hundred feet.
I'd have to agree, maintaining a big antenna would stink. My ISP stuck a 20 foot antenna on the roof of their building; they are uphill from most of town, but not enormously so. Works great.
Matt Barnson