After learning how powerful and amazingly useful a hygienic macro system really is, it frustrates me to no end when I see new languages being created without some equivalent facility.
Hopefully someday the average programmer will realize what he's missing.
Have you ever used Lisp? And do you understand what 'multi-paradigm' means?
C++ was designed as an object oriented extension to C. It does imperative programming well, and object oriented programming fairly well.
Lisp was initially designed as a functional langauge, but modern lisps bear little resemblence to the first lisp beyond superficial appearance. Modern lisps fully support functional programming, imperative programming, object oriented programming, and to some extent, declarative programming. Additionally, while Lisp started as a functional language, and quickly added support for imperative programming, it was also the first language with ANSI standardized object oriented support.
In short, Lisp supports programming with multiple paradigms much better than C++, and even if you take lisp out of the mix, there are a dozen or two other programming langauges that multiple paradigms much better than C++.
As for the bit about 'hardware-close explicit memory managed language'. . . that isn't a pardigm. That's a comment on the language's level of abstraction. For example, both C and BASIC support the same programming *paradigm*, that of an imperative programming langauge. One of them is a low level langauge, the other is a much higher level langauge, but they're both imperative.
From what I understand of CVS, adding the features you mention would require such a huge overhaul of the backend, and likely the repository format, that you'd be better off simply starting over with a new versioning system.
I guess that's the part that I really don't understand. . . CVS has many architecture limitations and now that we have superior replacements, it seems like an odd choice to deliberately step backwards to reimplementing CVs.
Regarding your first question, I have to suggest that your scenario is rather unlikely. CVS is not something that could be easily integrated inside of an application, nor was it designed to be. Instead, programs that wish to make use of CVS tend to simply utilize it through it's command line interface. By using it in this way from your non-open source application, all you will be forced to make available is the code changes that are specific to CVS.
As for the rest. . . Okay, I can understand that, but if they're trying to build a better CVS, then why are they building on top of a flawed design model?
Especially when there are more advanced and superior options available, a la subversion, darcs, arch, PRCS, etc. You point out that CVS development has stalled. . . bu that isn't quite accurate. What happened is that CVS was largely abandoned by it's developers because it started approaching the limits of it's capabilities according to it's current design.
Most of the former CVS developers are now working on Subversion.
If OpenBSD wanted to fix bugs in CVS, they could do that by simply stepping up and maintaining GNU CVS. If they want to build a better CVS, they'd be much better off basing their work on a more advanced design such as those projects mentioned above.
Reimplementing CVS seems to be the least productive option from my perspective.
So the goal is to reimplement every piece of GPLed code, is that correct?
Let me know when they've finished with their GCC, Gnome, and KDE replacements. I'm looking forward to trying them out in 2012.
If you are not part of that "we" then the question is pointless.
Ah, that's helpful. All of a sudden, I'm reminded of why I've never cared much for OpenBSD.
You guys enjoy your "new" CVS. I'm going back to actually getting work done using the tools available to me, including new technology like Subversion, darcs, and arch, as well as legacy software like CVS.
Ideology is great, but once I reach the minimum required level of freedom (for my definition of free (which tends to closely parallel the DFSG)), I'm more interested in pragmatism and getting things done.
It's got nothing to do with evangelism, and all to do with practicality. You can't have bits and pieces of code GPLed and some not.
That's not exactly true. . . you can't necessarily mix licenses within a single piece of software, but you can definitely do so within a larger software distribution.
The OpenBSD rewrite of CVS seems to serve no real purpose in my mind, because CVS is a tool that you use for managing your code, not something that is generally directly integrated into a larger application. As such, using it has no affect at all on the license of the code your managing with it.
If it makes them happy to do this, then hey, it's their time they're waisting, but as I see it, it's still a waste of time.;-)
I'm all for developers choosing their own license, and I'll for making sure that license incompatibilities don't cause problems for software developers.
However, we're talking about a tool you use for development, not something that is traditionally integrated into an application. CVS is a solid piece of software, and Subversion fixes many of the minor issues with CVS, and if those aren't your cup of tea, there are a number of other interesting version management tools (darcs, arch, bitkeeper, etc).
Considering all of that, do we really need a CVS clone, where the only difference is the license?
Especially when development of CVS has essentially ceased, other than bug/security fixes, and there are superior alternatives being developed (even the CVS developers will readily admit that CVS has architectural deficiencies that can really only be solved by a design, which is why most of them have moved on to other versioning tools).
So, I'm left wondering. . . why? Why bother doing this? What exactly does this achieve? I mean, if the guy writing this gets his rocks off on reimplementing somewhat obsolete applications, then more power to him, but I can't help but think that he could find something more rewarding than this.
Yeah, I love the kid-friendly games that I play on my GameCube. Particularly kid-friendly favorites are Resident Evil, Resident Evil 0, Eternal Darkness: Sanity's Requiem, Bloodrayne, Hitman 2, Legacy of Kain: Blood Omen, Serious Sam, Hunter: The Reckoning, BMX XXX, Red Faction II, Dead to Rights, True Crime: Streets of L.A., and The Suffering.
I have to admit, there are times when I wish I could play a game with a little blood and violence, though.
I do get a lot of mail, yes. However, DSPAM is claimed to be capable of handling thousands of users, so it should be well prepared to handle that kind of e-mail load. I may get a lot of e-mail, but I sure as hell don't get more than a thousand average people do.
As for it's configuration, I used mostly default settings, although as I mentioned above, I tightened it's purge settings to try to reduce the DB size.
I've used a lot of different spam filters, including a bunch of bayesian style ones, and none of them have ever come close to generating a database the size of DSPAMs, especially not within just a few weeks.
*shrug*
I'm sorry, but I don't think blaming me for DSPAM's faults is the correct way to go about things. I mentioned previously that it is a neat system, in many ways, and it does have some very cool features.
But the issues I've run into are valid issues (a friend of mine experienced some similar, though not identical, problems when he tried out DSPAM (on my suggestion)), and until they're addressed, I don't plan to try DSPAM again.
Note again what I said: "my spam-data database got over 300MB within a couple of weeks".
The default purge settings won't even touch the database until tokens and signatures have been in there for at least 14 days. Even after tightening up the purge settings, the database was way too big. In fact, even without purching, the databse should not have been allowed to get that big. I mean, seriously, it processes some 20MB of e-mail, and the spam database from it is over 300MB? There's something wrong with that.
I used DSPAM for a while. I started using it with the Berkeley DB backend, and that worked reasonably well. . . it was fairly fast, but database corruption was almost impossible to avoid. I don't think I ever managed more than 3-4 weeks without my DB getting killed.
So, then I started using an SQL database. That worked great for a while, except it was slow. Now, admittedly, I'm running my mail server on an old machine (Dual Pentium Pro 200's, with 450MB RAM), but DSPAM was horrible. With more than half a dozen e-mails to process at a time, it would just choke. And the space issue. . . my spam-data database got over 300MB within a couple of weeks! And, yeah, I was processing a lot of mail, but come on. That's just not right.
Finally, I decided it just wasn't worth it. So, I tried an alternative that the DSPAM author has spoken fairly highly of, CRM114. That thing rocks! Within a few days, it was catching most of the spam, it runs much faster than DSPAM or SA, and it has fixed-sized spam token databases, so unless you explicitely increase the size, they won't grow past what you set them up for.
I can't see myself bothering with any other spam filter anytime soon.
As a number of other people have mentioned, Request Tracker (RT) is probably just about a perfect fit for your needs. I use it for a similar (but internal) setup, and it works like a charm. I'm currently using it on a Debian/Woody box with Apache, PostgreSQL, and Qmail.
Especially considering it's free (GPL), I don't know many better solutions.
For example, I recently bought True Crime: Streets of LA, because I found it on sale for $10. Right now, I'm pretty well backlogged in games, and I know I won't be playing it for at least a few months. But, I know I'll play it eventually, it's available cheap, and this way I'll have it when I'm ready for it.
Personally, i can't afford to buy games i don't plan on buying. And most of the time, i feel games aren't long enough, but maybe i only buy good games? Couldn't say really.
Pick your games carefully, and watch for sales.
I'm actually in the same sitaution as the article author. I bought a GameCube a little over a year ago, when it dropped to $100. Within a month or two, I had over a dozen really good games, because they'd all been out for a year or two. They may not be the newest games, but hell, I'd never played them, so they were new to me. And they are damn good games, including Zelda: Windwaker, Zelda: Ocarina of Time, True Crime, Beyond Good & Evil, Soul Calibur 2, Skies of Arcadia Legends, Pikmin, Burnout 2, Sphinx and the Cursed Mummy, and more.
Oh, yeah, and I only payed more than $20 for one of them.
By watching for good sales, I've managed to continue the same way. I buy games that have been out for 4-6 months, and have dropped down to $20-$30. Heck, a lot of times I'll find them for $10-$15.
At this point, I've got close to 40 games. Of those, I still have a significant amount of playing left to do on at least half of them. Now I just need to find some time to actually play them more.
Yes, you are correct. They generally don't provide quite enough flexibility to be used effectively for that (at least not without some additional support tools).
While it's not ideal as a final presentation, I find that something like FreeMind (or it's commercial bretheren) are invaluable during the preparation and organization stages of a presentation.
Use it initially for the brainstorming, then take your brainstorming results and clean it up, make any changes you need to, put that in a new mind map, and you've got most of your presentation planned out and done.
Unfortunately, it's a royal pain in the butt when you're a developer who does their development on PostgreSQL, and their deployment on Oracle and DB2. We've had to spend way too much time dealing with database issues because of the lack of a standard database independant interface.
Much as I'd prefer using PHP, we've actually ended up having ot use Perl for a number of projects, simply because it reduced the headache and development issues so much.
Oh, well. Maybe with PHP6, they'll pull their heads out of their butts long enough to fix this issue.
This reminds me of a question I've wanted to see answered for such a long time now. ..
Why isn't there a standard Database Independant Interface library yet?
There's been all this talk about the "new MySQL" crap, and that's nice an all (if you're a MySQL user), but I don't care about MySQL. What I do care about, is writing applications that are as portable as possible across databases.
With a little bit of work, it isn't that hard to write code that will work well across PostgreSQL, Oracle, and MySQL. . . at least, in Perl it isn't. Perl's had the extremely well done DBI library for years. So why has PHP repeatedly dropped the ball and not done something similar? Why do we have to go to third-party libraries (ADODB) to get something that should be a fairly standard part of the base language libraries?
There are tons of great applications out there written in Perl that can be made to work with almost any database that DBI supports, with minimal work. At the same time, there are tons of PHP applications that will work with. . . MySQL. And that's it.
When PHP4 was released, I had hopes that they'd wise up and take care of this. The closest thing was the PEAR DB class, which never really took off (and is considered to be inferior to ADODB by most people I know). In fact, the whole PEAR thing seems to have suffered from lack of direction, lack of documentation, and a very poor job on the part of the people behind it to explain what it is, and why people should care. Now PHP5 has come out, and we're still in the same boat as before.
Consider this. . . when was the last time you looked at a Perl application that *didn't* use the DBI library to talk to the database? Can anyone even remember any Perl applications that talk to the database directly?
I bought a GameCube about 8 months ago. I currently have a library of nearly 40 games, and I payed less than $20 for at least 85% of them.
Oh, and I've still got at least 15 that I play regularly and haven't yet completed. That last thing on my mind is lack of games, or difficulty in finding something to play. My only real problem is finding enough time to keep up!
As for future games. . . even if I wasn't seriously backlogged by the number of great games I already have, there's a ton of games I'm looking forward to getting:
Tales of Symphonia
Paper Mario 2
The new Zelda game
Prince of Persia 2
Metroid Prime 2
Geist
Second Sight
WWE DoR
Resident Evil 4
Star Fox
Baten Kaitos
Donkey Kong Jungle Beat
Viewtiful Joe 2 (Damn, after VJ, I can't wait for this)
Time Splitters: Future Perfect
Mario Kart: Double Dash! (I know this one isn't really new, but I haven't gotten it yet. . . too busy still playing F-Zero GX)
I know I'm forgetting a few, but damn, that's quite a few off the top of my head.
I don't know about you, but something tells me it will be a long time before I'm lacking games to play. If you're really having trouble with this, then you're not looking hard enough. If you *really* can't find anything, drop me an e-mail. I'll give you some suggestions.
Don't be assinine. A modern production environment is running at least 100MBit Ethernet, if not 1GBit. A HUGE query, say 2500 characters, is 2.5KBytes. Gee, thats pretty rough.
Erm. . . you must be dealing with some mighty tiny databases, tables, fields, and queries, if you think 2500 characters is a huge query. In this day and age, where more and more data is being stored in databases, 2500 characters is nothing.
Or, are you refering to the SQL query itself, as opposed to the result data it returns? Sure, a query might only be 2500 characters, but remember, often the data can be processed locally and reduced prior to transfer, and *that* can have a huge impact.
Depending on your application and requirements, I've seen situations where the query has to return multiple megabytes of data, which are then processed by the application into a usable format.
I'm personally familiar with a situation where a DBA was able to move that processing from the application to the database in the form of a stored procedure, reducing the bandwidth from an average of 6MB to about 4KB.
Oh, yeah, and the time it took for the database to process it directly was about 8% of the time required to transfer all of the data to the application, and then process it there.
Sorry, can't do that. I frequently use telnet out of workstations on my network to connect to port 25 on other machines to verify SMTP setups are correct there.
Okay, so you create exception rules for the *specific* machines that you will be working from. Either that, or you connect to one central machine and do the majority of your testing from there, by remote access (ssh, VNC, whatever).
Personally, I'd suggest the latter, as it allows you to easily set up automated testing scripts that can be run from anywhere.
I also use P2P software that has random port assignments, so a small proportion of the users I connect to with that will be on port 25, and I'd rather not interfere with it.
Any program that randomly binds to port 25 is BAD[1], and you should get rid of it in favor of a decent program. Applications that need a random port to use should take the first available port that is greater than 1024. On many operating systems, this is enforced by the OS.
I'd be curious as to which P2P software you're describing, so I can make sure I avoid it.
Even for LAN firewalls, this is, or should be, normal behavior.
I know I've had my firewall setup to block outgoing port 25 traffic that doesn't come from the mail server for a long time now. I also log outbound port 25 requests, and twice this has alerted me to when one of my users was infected with a mass-mailing trojan.
Anyone who runs a firewall and does not currently have it set up similar to this should block outgoing port 25 connections that do not originate from your mail server immediately.
If you're running any reasonably modern firewall (or using Linux and iptables for your firewall) this is fairly trivial to setup.
Come on, guys. Let's all do our part to stop spam. Every little bit helps.
For non-Debian users, download changetrack from SourceForge.
changetrack uses RCS as it's backend, not CVS (support for CVS is on the Todo list), but the end result is the same. It is specifically intended for tracking system files like those in/etc.
Slashdot Mirror
Well said, Sir!
After learning how powerful and amazingly useful a hygienic macro system really is, it frustrates me to no end when I see new languages being created without some equivalent facility.
Hopefully someday the average programmer will realize what he's missing.
Erm. . . no?
Have you ever used Lisp? And do you understand what 'multi-paradigm' means?
C++ was designed as an object oriented extension to C. It does imperative programming well, and object oriented programming fairly well.
Lisp was initially designed as a functional langauge, but modern lisps bear little resemblence to the first lisp beyond superficial appearance. Modern lisps fully support functional programming, imperative programming, object oriented programming, and to some extent, declarative programming. Additionally, while Lisp started as a functional language, and quickly added support for imperative programming, it was also the first language with ANSI standardized object oriented support.
In short, Lisp supports programming with multiple paradigms much better than C++, and even if you take lisp out of the mix, there are a dozen or two other programming langauges that multiple paradigms much better than C++.
As for the bit about 'hardware-close explicit memory managed language'. . . that isn't a pardigm. That's a comment on the language's level of abstraction. For example, both C and BASIC support the same programming *paradigm*, that of an imperative programming langauge. One of them is a low level langauge, the other is a much higher level langauge, but they're both imperative.
From what I understand of CVS, adding the features you mention would require such a huge overhaul of the backend, and likely the repository format, that you'd be better off simply starting over with a new versioning system.
I guess that's the part that I really don't understand. . . CVS has many architecture limitations and now that we have superior replacements, it seems like an odd choice to deliberately step backwards to reimplementing CVs.
Regarding your first question, I have to suggest that your scenario is rather unlikely. CVS is not something that could be easily integrated inside of an application, nor was it designed to be. Instead, programs that wish to make use of CVS tend to simply utilize it through it's command line interface. By using it in this way from your non-open source application, all you will be forced to make available is the code changes that are specific to CVS.
As for the rest. . . Okay, I can understand that, but if they're trying to build a better CVS, then why are they building on top of a flawed design model?
Especially when there are more advanced and superior options available, a la subversion, darcs, arch, PRCS, etc. You point out that CVS development has stalled. . . bu that isn't quite accurate. What happened is that CVS was largely abandoned by it's developers because it started approaching the limits of it's capabilities according to it's current design.
Most of the former CVS developers are now working on Subversion.
If OpenBSD wanted to fix bugs in CVS, they could do that by simply stepping up and maintaining GNU CVS. If they want to build a better CVS, they'd be much better off basing their work on a more advanced design such as those projects mentioned above.
Reimplementing CVS seems to be the least productive option from my perspective.
When the "we" is OpenBSD then the answer is yes.
So the goal is to reimplement every piece of GPLed code, is that correct?
Let me know when they've finished with their GCC, Gnome, and KDE replacements. I'm looking forward to trying them out in 2012.
If you are not part of that "we" then the question is pointless.
Ah, that's helpful. All of a sudden, I'm reminded of why I've never cared much for OpenBSD.
You guys enjoy your "new" CVS. I'm going back to actually getting work done using the tools available to me, including new technology like Subversion, darcs, and arch, as well as legacy software like CVS.
Ideology is great, but once I reach the minimum required level of freedom (for my definition of free (which tends to closely parallel the DFSG)), I'm more interested in pragmatism and getting things done.
It's got nothing to do with evangelism, and all to do with practicality. You can't have bits and pieces of code GPLed and some not.
;-)
That's not exactly true. . . you can't necessarily mix licenses within a single piece of software, but you can definitely do so within a larger software distribution.
The OpenBSD rewrite of CVS seems to serve no real purpose in my mind, because CVS is a tool that you use for managing your code, not something that is generally directly integrated into a larger application. As such, using it has no affect at all on the license of the code your managing with it.
If it makes them happy to do this, then hey, it's their time they're waisting, but as I see it, it's still a waste of time.
I'm all for developers choosing their own license, and I'll for making sure that license incompatibilities don't cause problems for software developers.
However, we're talking about a tool you use for development, not something that is traditionally integrated into an application. CVS is a solid piece of software, and Subversion fixes many of the minor issues with CVS, and if those aren't your cup of tea, there are a number of other interesting version management tools (darcs, arch, bitkeeper, etc).
Considering all of that, do we really need a CVS clone, where the only difference is the license?
Especially when development of CVS has essentially ceased, other than bug/security fixes, and there are superior alternatives being developed (even the CVS developers will readily admit that CVS has architectural deficiencies that can really only be solved by a design, which is why most of them have moved on to other versioning tools).
So, I'm left wondering. . . why? Why bother doing this? What exactly does this achieve? I mean, if the guy writing this gets his rocks off on reimplementing somewhat obsolete applications, then more power to him, but I can't help but think that he could find something more rewarding than this.
I moonlight doing random tech support stuff, and bartending.
The bartending in particular is a nice change from sitting at a computer all day long.
Yeah, I love the kid-friendly games that I play on my GameCube. Particularly kid-friendly favorites are Resident Evil, Resident Evil 0, Eternal Darkness: Sanity's Requiem, Bloodrayne, Hitman 2, Legacy of Kain: Blood Omen, Serious Sam, Hunter: The Reckoning, BMX XXX, Red Faction II, Dead to Rights, True Crime: Streets of L.A., and The Suffering.
I have to admit, there are times when I wish I could play a game with a little blood and violence, though.
Oh, well.
I do get a lot of mail, yes. However, DSPAM is claimed to be capable of handling thousands of users, so it should be well prepared to handle that kind of e-mail load. I may get a lot of e-mail, but I sure as hell don't get more than a thousand average people do.
As for it's configuration, I used mostly default settings, although as I mentioned above, I tightened it's purge settings to try to reduce the DB size.
I've used a lot of different spam filters, including a bunch of bayesian style ones, and none of them have ever come close to generating a database the size of DSPAMs, especially not within just a few weeks.
*shrug*
I'm sorry, but I don't think blaming me for DSPAM's faults is the correct way to go about things. I mentioned previously that it is a neat system, in many ways, and it does have some very cool features.
But the issues I've run into are valid issues (a friend of mine experienced some similar, though not identical, problems when he tried out DSPAM (on my suggestion)), and until they're addressed, I don't plan to try DSPAM again.
Note again what I said: "my spam-data database got over 300MB within a couple of weeks".
The default purge settings won't even touch the database until tokens and signatures have been in there for at least 14 days. Even after tightening up the purge settings, the database was way too big. In fact, even without purching, the databse should not have been allowed to get that big. I mean, seriously, it processes some 20MB of e-mail, and the spam database from it is over 300MB? There's something wrong with that.
I used DSPAM for a while. I started using it with the Berkeley DB backend, and that worked reasonably well. . . it was fairly fast, but database corruption was almost impossible to avoid. I don't think I ever managed more than 3-4 weeks without my DB getting killed.
So, then I started using an SQL database. That worked great for a while, except it was slow. Now, admittedly, I'm running my mail server on an old machine (Dual Pentium Pro 200's, with 450MB RAM), but DSPAM was horrible. With more than half a dozen e-mails to process at a time, it would just choke. And the space issue. . . my spam-data database got over 300MB within a couple of weeks! And, yeah, I was processing a lot of mail, but come on. That's just not right.
Finally, I decided it just wasn't worth it. So, I tried an alternative that the DSPAM author has spoken fairly highly of, CRM114. That thing rocks! Within a few days, it was catching most of the spam, it runs much faster than DSPAM or SA, and it has fixed-sized spam token databases, so unless you explicitely increase the size, they won't grow past what you set them up for.
I can't see myself bothering with any other spam filter anytime soon.
As a number of other people have mentioned, Request Tracker (RT) is probably just about a perfect fit for your needs. I use it for a similar (but internal) setup, and it works like a charm. I'm currently using it on a Debian/Woody box with Apache, PostgreSQL, and Qmail.
Especially considering it's free (GPL), I don't know many better solutions.
I do it frequently, if I find it cheap.
For example, I recently bought True Crime: Streets of LA, because I found it on sale for $10. Right now, I'm pretty well backlogged in games, and I know I won't be playing it for at least a few months. But, I know I'll play it eventually, it's available cheap, and this way I'll have it when I'm ready for it.
I'm always on the lookout for cheap good games.
Personally, i can't afford to buy games i don't plan on buying. And most of the time, i feel games aren't long enough, but maybe i only buy good games? Couldn't say really.
Pick your games carefully, and watch for sales.
I'm actually in the same sitaution as the article author. I bought a GameCube a little over a year ago, when it dropped to $100. Within a month or two, I had over a dozen really good games, because they'd all been out for a year or two. They may not be the newest games, but hell, I'd never played them, so they were new to me. And they are damn good games, including Zelda: Windwaker, Zelda: Ocarina of Time, True Crime, Beyond Good & Evil, Soul Calibur 2, Skies of Arcadia Legends, Pikmin, Burnout 2, Sphinx and the Cursed Mummy, and more.
Oh, yeah, and I only payed more than $20 for one of them.
By watching for good sales, I've managed to continue the same way. I buy games that have been out for 4-6 months, and have dropped down to $20-$30. Heck, a lot of times I'll find them for $10-$15.
At this point, I've got close to 40 games. Of those, I still have a significant amount of playing left to do on at least half of them. Now I just need to find some time to actually play them more.
Yes, you are correct. They generally don't provide quite enough flexibility to be used effectively for that (at least not without some additional support tools).
While it's not ideal as a final presentation, I find that something like FreeMind (or it's commercial bretheren) are invaluable during the preparation and organization stages of a presentation.
Use it initially for the brainstorming, then take your brainstorming results and clean it up, make any changes you need to, put that in a new mind map, and you've got most of your presentation planned out and done.
Yeah.
Unfortunately, it's a royal pain in the butt when you're a developer who does their development on PostgreSQL, and their deployment on Oracle and DB2. We've had to spend way too much time dealing with database issues because of the lack of a standard database independant interface.
Much as I'd prefer using PHP, we've actually ended up having ot use Perl for a number of projects, simply because it reduced the headache and development issues so much.
Oh, well. Maybe with PHP6, they'll pull their heads out of their butts long enough to fix this issue.
This reminds me of a question I've wanted to see answered for such a long time now. . .
Why isn't there a standard Database Independant Interface library yet?
There's been all this talk about the "new MySQL" crap, and that's nice an all (if you're a MySQL user), but I don't care about MySQL. What I do care about, is writing applications that are as portable as possible across databases.
With a little bit of work, it isn't that hard to write code that will work well across PostgreSQL, Oracle, and MySQL. . . at least, in Perl it isn't. Perl's had the extremely well done DBI library for years. So why has PHP repeatedly dropped the ball and not done something similar? Why do we have to go to third-party libraries (ADODB) to get something that should be a fairly standard part of the base language libraries?
There are tons of great applications out there written in Perl that can be made to work with almost any database that DBI supports, with minimal work. At the same time, there are tons of PHP applications that will work with. . . MySQL. And that's it.
When PHP4 was released, I had hopes that they'd wise up and take care of this. The closest thing was the PEAR DB class, which never really took off (and is considered to be inferior to ADODB by most people I know). In fact, the whole PEAR thing seems to have suffered from lack of direction, lack of documentation, and a very poor job on the part of the people behind it to explain what it is, and why people should care. Now PHP5 has come out, and we're still in the same boat as before.
Consider this. . . when was the last time you looked at a Perl application that *didn't* use the DBI library to talk to the database? Can anyone even remember any Perl applications that talk to the database directly?
Neither can I.
I bought a GameCube about 8 months ago. I currently have a library of nearly 40 games, and I payed less than $20 for at least 85% of them.
Oh, and I've still got at least 15 that I play regularly and haven't yet completed. That last thing on my mind is lack of games, or difficulty in finding something to play. My only real problem is finding enough time to keep up!
As for future games. . . even if I wasn't seriously backlogged by the number of great games I already have, there's a ton of games I'm looking forward to getting:
- Tales of Symphonia
- Paper Mario 2
- The new Zelda game
- Prince of Persia 2
- Metroid Prime 2
- Geist
- Second Sight
- WWE DoR
- Resident Evil 4
- Star Fox
- Baten Kaitos
- Donkey Kong Jungle Beat
- Viewtiful Joe 2 (Damn, after VJ, I can't wait for this)
- Time Splitters: Future Perfect
- Mario Kart: Double Dash! (I know this one isn't really new, but I haven't gotten it yet. . . too busy still playing F-Zero GX)
I know I'm forgetting a few, but damn, that's quite a few off the top of my head.I don't know about you, but something tells me it will be a long time before I'm lacking games to play. If you're really having trouble with this, then you're not looking hard enough. If you *really* can't find anything, drop me an e-mail. I'll give you some suggestions.
My point was that the poster I replied to either:
The fact is, the comments he made don't make sense in the context of this discussion, so I responded to both possibilities.
Please continue to add such insightful and helpful comments, though. I'm sure everyone is thoroughly enjoying them.
Don't be assinine. A modern production environment is running at least 100MBit Ethernet, if not 1GBit. A HUGE query, say 2500 characters, is 2.5KBytes. Gee, thats pretty rough.
Erm. . . you must be dealing with some mighty tiny databases, tables, fields, and queries, if you think 2500 characters is a huge query. In this day and age, where more and more data is being stored in databases, 2500 characters is nothing.
Or, are you refering to the SQL query itself, as opposed to the result data it returns? Sure, a query might only be 2500 characters, but remember, often the data can be processed locally and reduced prior to transfer, and *that* can have a huge impact.
Depending on your application and requirements, I've seen situations where the query has to return multiple megabytes of data, which are then processed by the application into a usable format.
I'm personally familiar with a situation where a DBA was able to move that processing from the application to the database in the form of a stored procedure, reducing the bandwidth from an average of 6MB to about 4KB.
Oh, yeah, and the time it took for the database to process it directly was about 8% of the time required to transfer all of the data to the application, and then process it there.
No offense, but these are rather poor excuses.
Sorry, can't do that. I frequently use telnet out of workstations on my network to connect to port 25 on other machines to verify SMTP setups are correct there.
Okay, so you create exception rules for the *specific* machines that you will be working from. Either that, or you connect to one central machine and do the majority of your testing from there, by remote access (ssh, VNC, whatever).
Personally, I'd suggest the latter, as it allows you to easily set up automated testing scripts that can be run from anywhere.
I also use P2P software that has random port assignments, so a small proportion of the users I connect to with that will be on port 25, and I'd rather not interfere with it.
Any program that randomly binds to port 25 is BAD[1], and you should get rid of it in favor of a decent program. Applications that need a random port to use should take the first available port that is greater than 1024. On many operating systems, this is enforced by the OS.
I'd be curious as to which P2P software you're describing, so I can make sure I avoid it.
[1] Broken As Designed
Even for LAN firewalls, this is, or should be, normal behavior.
I know I've had my firewall setup to block outgoing port 25 traffic that doesn't come from the mail server for a long time now. I also log outbound port 25 requests, and twice this has alerted me to when one of my users was infected with a mass-mailing trojan.
Anyone who runs a firewall and does not currently have it set up similar to this should block outgoing port 25 connections that do not originate from your mail server immediately.
If you're running any reasonably modern firewall (or using Linux and iptables for your firewall) this is fairly trivial to setup.
Come on, guys. Let's all do our part to stop spam. Every little bit helps.
changetrack uses RCS as it's backend, not CVS (support for CVS is on the Todo list), but the end result is the same. It is specifically intended for tracking system files like those in