Re: E-commerce payment systems for apache/mod_perl
On 2 Jul 2002, David Dyer-Bennet wrote: Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? There are a few 'clearing house' type services to which one can subscribe that do the actual cybercash-type transaction for you. it can be expensive and prohibitively complicated to set up the services yourself. For small sites, I have fired off perl scripts that use openssl to connect to a serice we hired, passing the info they need, and waiting for a response that i parse and display to the user, as i write it to our db2 db as well with dbd-dbi.. Damned if i can remember the name of the service we used. i wrote it for the 1998 superbowl. I can only imagine that the number of such services has proliferated since then, but i havent checked lately. ive been out of e-commerce since 2000. Ive had a devil of a time running the cybercash (and similar) services for myself as every option seemed to be expensive, buggy, or lacking on customer support when the end customer inevitably asked questions i couldnt answer. maybe they have improved in the last 2 years, butfiring it off to someone else (the classic SEP or 'somebody elses problem' theorem), waiting for a nice pleasant order number to be returned over ssl, and printing it to the screen branded as if my site did it all by itself is worth a small charge per transaction that youre going to end up paying anyway even if you do it all yourself. Do you have a particular company doing your order fulfillment? If so, they may have such an arrangement or service already in place. a lot i ran into did. -- gedanken
Re: [OT] Better Linux server platform: Redhat or SuSe?
perl: Any iussues with perl/modperl? Besides modperl I will be running a perl application with a few hundred thousend lines of code... Wow. For reference last time I looked at slashcode it was about 25.000 lines I think. I wonder what kind of application would require more than that amount of Perl code :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: E-commerce payment systems for apache/mod_perl
hi, I use two services for payment proccessing. One for digital money www.cyphermint.com/epay/ (quite complex for initial installing, i don't like it) and the second for cc processing (much more simple) you can just give them info about your contract (say id, price, amount) and redirect user on their site for payment processing (http://www.assist.ru/eng/about/cardpayments/) I don't thunk these services are suitable for, but you read some help on it and understand what exactly you need. -vlad Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: [OT] Better Linux server platform: Redhat or SuSe?
On Wed, 3 Jul 2002 11:40:44 +0100, Jean-Michel Hiver wrote: perl: Any iussues with perl/modperl? Besides modperl I will be running a perl application with a few hundred thousend lines of code... Wow. For reference last time I looked at slashcode it was about 25.000 lines I think. I wonder what kind of application would require more than that amount of Perl code :-) I'm sure someone else will post a bigger number, but my application (IOP Electronic Journals) has 55000 lines of code (including the odd blank line and comment, of course). And we're always adding new stuff, so it only ever gets bigger. -- Peter Haworth [EMAIL PROTECTED] We don't care how they do it in New York.
Re: [OT] Better Linux server platform: Redhat or SuSe?
Since everyone's become distracted by the lines of code number, I answered a few of the questions that I feel I can answer. Apache/modperl installation and updates: I assume installation is straight forward, how about keeping current? As those are remotely administered platforms, chances are the OS may not be kept current. So is it still easy to deal with security updates (Apache, sshd, bind etc) when the platform is a couple of years old? With FreeBSD this has become somewhat harder lately (still running 3.x, but the ports system doesn't support 3.x any longer). You're talking about using their packages? I suspect most people on this list build their own apache/mod_perl binaries. Remote maintability: Is it possible to remotely upgrade between OS versions for either of those platforms (not a must, but would be a plus)? I would be afraid to do that remotely, since it normally involved a kernel change as well. Sendmail: Does the system make it easy to replace sendmail with another mailer of choice (qmail in my case)? I don't know about Red Hat, but it's certainly easy in SuSE. Footprint: Is it easy to weed out unused system components to have a smaller footprint of the OS? Or does that mean fighting the installer left and right? I don't know if Red Hat is getting any better, but I've always found it difficult to do a minimal install. SuSE has options for a very minimal install which is what I use for server installs. perl: Any iussues with perl/modperl? Besides modperl I will be running a perl application with a few hundred thousend lines of code... My current project: http://www.better-investing.org runs on Red Hat. I'm not aware of any perl/mod_perl issues, but I built perl and the apache binaries myself. I don't use their RPMs. Security: Is it easy to 'tie down' the system? The web site is behind a firewall and load balancers, so the web servers themselves don't have ipchains, etc. but they also aren't running any services available to the outside except http and ssh. Software-based RAID 1: Is it usable (only for a data partition, not required for the root partition)? Is it easy to recover from a broken disk? Robustness: While almost all systems I have are/will be on UPSs, they still tend to occasionally be 'unplugged' (not shut down cleanly), be it due to an empty or dead UPS battery, someone tripping over or accidentaly unplugging the power cable etc. etc. Does the system tend to survive the then due fsck without manual intervention? Better yet, would it be possible to mount / and /usr read-only, and have a /var partition that (if the worst should happen) can be recreated on the fly? Can't help you on RAID, but I have found SuSE with ext3 or ReiserFS to be VERY recoverable. -- Barry Hoggard Tristan Media LLC e: [EMAIL PROTECTED] p: 212-627-1596 aim: hoggardb
Re: [OT] Better Linux server platform: Redhat or SuSe?
-- Barry Hoggard [EMAIL PROTECTED] on 07/03/02 11:52:21 -0400 You're talking about using their packages? I suspect most people on this list build their own apache/mod_perl binaries. Nearly always a good idea since it's (a) remarkably simple to do and (b) ensures that the current perl's options are used for mod_perl. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Apache::LogFile, rotatelogs, and line breaks
I've been running Apache::LogFile to create a piped log through rotatelogs
and have experienced some problems.
I created a log file that had 2271 entries in it for one hour.
Out of these 2271 entries, 622 of them occured on the same second and wrote
to the log properly (one entry per line).
However, there were 5 entries in the file where two entries from the same
second had no line break in between them.
I was wondering if anyone had similair experiences with Apache::LogFile or
rotatelogs.
Thanks for the help!
Jim Spath
--
push@J,[($)x70]for 0..20;sub p{$J[$q][$p]=$_;print\e[H\e[J;print@$_,$/for@J
;$J[$q][$p]=$}sub f{sprintf%.f,pop}for('Just another Perl hacker.'=~/./g){$
t=/ /and$J[20][$X++]=$_,next;{$x=70+$t*($X-70)*.8;$y=20-63.25*$t+50*$t**2;last
if$x$X;$p=f$x;p$q=f$y;$t+=.1;select$,,$,,$,,.1;redo}$J[20][$X++]=$_}p
Re[2]: E-commerce payment systems for apache/mod_perl
We have been using ECHO for over 5 years and they have been an excellent company. They are strictly a credit card processing company - no order fulfillment. They also do online check processing and a whole bunch of other services. They are the only processing company that I have seen that really actively supports Open Source. From their website: ECHO's Free, Open Source, GPL Secure Payment Gateway ECHO is the only company on the Internet to provide both a Merchant Account AND Secure Payment Gateway services for only $19.95/month in fixed account fees!* We actually give away our real time processing software modules and gateway access. Even our Merchant Account's $19.95/month fixed account fee is waived for months with no activity. http://www.echo-inc.com/ http://www.openecho.com/ http://www.openecho.com/perl/example.pl http://www.openecho.com/download_files.html HTH, Christopher Taranto WWWarehouse, Inc. At 10:43 PM 7/2/02 -0500, you wrote: Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: E-commerce payment systems for apache/mod_perl
On Tue, Jul 02, 2002 at 10:43:14PM -0500, David Dyer-Bennet wrote: Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? http://interchange.redhat.com/ - it's mature - we wrote our own but i'd use it instead if I had to start over http://www.ipaymentinc.com/ - reseller for authorize.net http://authorize.net/ - big transaction provider - supported cpan module (simple/trivial) http://www.dhl.com/ - we get really cheap rates for dhl's next day shipping service world wide (1-2 days continential us $6) (3-4 days door2door to pakistan from indianapolis $21) ... much, much cheaper than even the cheapest ups-residential-ground - ups has well developed xml API's, dhl dosn't Ed
Re: E-commerce payment systems for apache/mod_perl
Gedanken [EMAIL PROTECTED] writes: On 2 Jul 2002, David Dyer-Bennet wrote: Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? There are a few 'clearing house' type services to which one can subscribe that do the actual cybercash-type transaction for you. it can be expensive and prohibitively complicated to set up the services yourself. Yes, that's what I've been half-expecting. [snip] I can only imagine that the number of such services has proliferated since then, but i havent checked lately. ive been out of e-commerce since 2000. Ive had a devil of a time running the cybercash (and similar) services for myself as every option seemed to be expensive, buggy, or lacking on customer support when the end customer inevitably asked questions i couldnt answer. maybe they have improved in the last 2 years, butfiring it off to someone else (the classic SEP or 'somebody elses problem' theorem), waiting for a nice pleasant order number to be returned over ssl, and printing it to the screen branded as if my site did it all by itself is worth a small charge per transaction that youre going to end up paying anyway even if you do it all yourself. I'm hoping I can sell the client this idea; it certainly matches *my* idea of easier. Do you have a particular company doing your order fulfillment? If so, they may have such an arrangement or service already in place. a lot i ran into did. New client (not hooked yet), but I don't believe they're likely to have anything in place from what I know so far. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: Re[2]: E-commerce payment systems for apache/mod_perl
Christopher Taranto [EMAIL PROTECTED] writes: We have been using ECHO for over 5 years and they have been an excellent company. They are strictly a credit card processing company - no order fulfillment. They also do online check processing and a whole bunch of other services. They are the only processing company that I have seen that really actively supports Open Source. This looks very promising, thanks for the specific pointer. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: E-commerce payment systems for apache/mod_perl
On Wed, 3 Jul 2002, Vlad Safronov wrote: hi, I use two services for payment proccessing. One for digital money www.cyphermint.com/epay/ (quite complex for initial installing, i don't like it) and the second for cc processing (much more simple) you can just give them info about your contract (say id, price, amount) and redirect user on their site for payment processing (http://www.assist.ru/eng/about/cardpayments/) I don't thunk these services are suitable for, but you read some help on it and understand what exactly you need. -vlad Any obvious choices for a relatively small-scale e-commerce payment processing system for a server running apache / mod_perl? -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info So does anyone have any recommendations for an epay (Pay-pal) system? -- ~~ Doug Silver Network Manager Urchin Software Corp. http://www.urchin.com ~~
Re: [OT] Better Linux server platform: Redhat or SuSe?
I'm using RedHat on my servers; can't do comparison to SuSe since I don't know it, but I'll comment on the RedHat side. I got into RedHat because of the RPM utility, around 4.2 I think, and have stayed with it because nothing has yet annoyed me enough to switch. Gerd Knops [EMAIL PROTECTED] writes: Besides general observations I am specifically interested in answers to these questions: Apache/modperl installation and updates: I assume installation is straight forward, how about keeping current? As those are remotely administered platforms, chances are the OS may not be kept current. So is it still easy to deal with security updates (Apache, sshd, bind etc) when the platform is a couple of years old? With FreeBSD this has become somewhat harder lately (still running 3.x, but the ports system doesn't support 3.x any longer). I'm still with RPMs for these components, and am hoping intensely to be able to stay there because it's *so* easy to keep up to date. Remote maintability: Is it possible to remotely upgrade between OS versions for either of those platforms (not a must, but would be a plus)? Yes. I'm assuming you understand it's always dangerous to do this; do you at least have people who you can call on the phone to push the reset button if you screw up? With the GRUB loader that's appeared in recent RedHat's, the biggest easy mistake has gone away (you no longer have to do the equivalent of running lilo before rebooting). Of course if the new kernel itself doesn't boot, you're sunk (need somebody at the console to select an alternate boot kernel). The last umpteen kernel upgrades I've made, I've never screwed up badly enough to need to use the reset button, and since the systems are physically right in front of me I haven't been all that careful. I haven't done this, but it looks like it's possible to configure a RedHat system to boot with serial console. If you have the sort of facilities I consider normal for a multi-continental WAN, can you tie the serial port of your server machine to a terminal server and get remote access to the console? That would work around most of the problems with remote maintenance. Sendmail: Does the system make it easy to replace sendmail with another mailer of choice (qmail in my case)? Not as easy as it should be, but perfectly possible. I'm installing qmail from source, so I have to override the dependencies in several RPMs for mailerdaemon. An alternative would be to build your own qmail rpms and have them provide that dependency. So far I've found that you can't make redhat install new without sendmail, but it's easy to rip out once the new install is done. I haven't found it appearing on upgrades, anyway. (I'm also using qmail). Footprint: Is it easy to weed out unused system components to have a smaller footprint of the OS? Or does that mean fighting the installer left and right? For initial installs, you can pick each package individually. Of course that's a very long list to review. After the initial install, you can remove packages very easily (one of the great benefits of RPM). On upgrades, it only upgrades packages already installed (and may ask to bring in dependencies, if they've changed). perl: Any iussues with perl/modperl? Besides modperl I will be running a perl application with a few hundred thousend lines of code... I'm not stressing it hard enough to tell. The RPM version is working fine for me, but I'm new to mod_perl, don't have much using it yet. Security: Is it easy to 'tie down' the system? No harder than any other system, anyway. The /etc/rc.d/init.d structure for controlling subsystems is very useful; that and xinetd are the two places anything is likely to be started. And tools like netstat are around (I like to check and make sure nothing I don't know about is listening to ports, for example, as a sanity check that I've really limited it to the things I want.) Software-based RAID 1: Is it usable (only for a data partition, not required for the root partition)? Is it easy to recover from a broken disk? I'm using it on my primary web server for the user/web partition, seems to work fine. I've survived a broken disk and a broken controller, I think. (With today's prices, I tend to discard questionable components rather than pursuing diagnosis in detail.) Robustness: While almost all systems I have are/will be on UPSs, they still tend to occasionally be 'unplugged' (not shut down cleanly), be it due to an empty or dead UPS battery, someone tripping over or accidentaly unplugging the power cable etc. etc. Does the system tend to survive the then due fsck without manual intervention? Better yet, would it be possible to mount / and /usr read-only, and have a /var partition that (if the worst should happen) can be recreated on the fly? If you're doing a new install, use EXT3 (standard in RH7.2 and up at least), which is a journaling extension to EXT2. Doesn't have the
[JOB] Junior Mod_Perl Developer - New York City
(Note: Address to send resumes to is at bottom of this description; any resumes sent to my personal address will be ignored per company policy) TheMuniCenter is seeking an Apache/mod_perl developer to work on its next generation bond trading system. We are seeking an intelligent, dynamic candidate capable of thinking outside of the box, working under stress and meeting deadlines. The ideal candidate should have demonstrable project experience working with Apache/mod_perl. TheMuniCenter is NOT ANOTHER DOT COM! We have an established, award winning bond trading system backed by some of the biggest players in the Financial Industry. We are looking for another developer to help bring us to the next level! We are seeking someone with all or most of the following: - In depth knowledge of Perl programming, with recent experience using 5.6 or higher in projects - A reasonable understanding of regular expressions and their usage. - Solid knowledge of Apache and its configuration and usage. - Reasonable knowledge of mod_perl. This includes the API, pitfalls and benefits. - Good programming skills. These include logic, reasoning, problem solving and proper application design. - Web application development experience. This includes a fair knowledge of HTML (recent versions [4.x) and JavaScript, as well as good UI design. - Knowledge of SQL. - Knowledge of Perl's DBI libraries for Database access. In addition, we are always seeking candidates who also have the following skills on top of those listed above: - Java (Applets, servlets, JSP) - J2EE (EJB) - Weblogic 6 - Fixed Income Experience (Municipal Corporate bonds, especially!) - Database Experience - Sybase Oracle. Do you have what it takes to join one of the most dynamic development teams on Wall Street? Send resumes, with cover letter to [EMAIL PROTECTED] Serious applicants ONLY!
RE: [JOB] Junior Mod_Perl Developer - New York City
Did he say out of the box ? -Original Message- From: Brendan W. McAdams [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 03, 2002 1:50 PM To: [EMAIL PROTECTED] Subject: [JOB] Junior Mod_Perl Developer - New York City (Note: Address to send resumes to is at bottom of this description; any resumes sent to my personal address will be ignored per company policy) TheMuniCenter is seeking an Apache/mod_perl developer to work on its next generation bond trading system. We are seeking an intelligent, dynamic candidate capable of thinking outside of the box, working under stress and meeting deadlines. The ideal candidate should have demonstrable project experience working with Apache/mod_perl. TheMuniCenter is NOT ANOTHER DOT COM! We have an established, award winning bond trading system backed by some of the biggest players in the Financial Industry. We are looking for another developer to help bring us to the next level! We are seeking someone with all or most of the following: - In depth knowledge of Perl programming, with recent experience using 5.6 or higher in projects - A reasonable understanding of regular expressions and their usage. - Solid knowledge of Apache and its configuration and usage. - Reasonable knowledge of mod_perl. This includes the API, pitfalls and benefits. - Good programming skills. These include logic, reasoning, problem solving and proper application design. - Web application development experience. This includes a fair knowledge of HTML (recent versions [4.x) and JavaScript, as well as good UI design. - Knowledge of SQL. - Knowledge of Perl's DBI libraries for Database access. In addition, we are always seeking candidates who also have the following skills on top of those listed above: - Java (Applets, servlets, JSP) - J2EE (EJB) - Weblogic 6 - Fixed Income Experience (Municipal Corporate bonds, especially!) - Database Experience - Sybase Oracle. Do you have what it takes to join one of the most dynamic development teams on Wall Street? Send resumes, with cover letter to [EMAIL PROTECTED] Serious applicants ONLY!
RE: [JOB] Junior Mod_Perl Developer - New York City
No, I believe I said 'outside of the box' =) -Original Message- From: Levon Barker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 03, 2002 1:58 PM To: [EMAIL PROTECTED] Subject: RE: [JOB] Junior Mod_Perl Developer - New York City Did he say out of the box ? -Original Message- From: Brendan W. McAdams [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 03, 2002 1:50 PM To: [EMAIL PROTECTED] Subject: [JOB] Junior Mod_Perl Developer - New York City (Note: Address to send resumes to is at bottom of this description; any resumes sent to my personal address will be ignored per company policy) TheMuniCenter is seeking an Apache/mod_perl developer to work on its next generation bond trading system. We are seeking an intelligent, dynamic candidate capable of thinking outside of the box, working under stress and meeting deadlines. The ideal candidate should have demonstrable project experience working with Apache/mod_perl. TheMuniCenter is NOT ANOTHER DOT COM! We have an established, award winning bond trading system backed by some of the biggest players in the Financial Industry. We are looking for another developer to help bring us to the next level! We are seeking someone with all or most of the following: - In depth knowledge of Perl programming, with recent experience using 5.6 or higher in projects - A reasonable understanding of regular expressions and their usage. - Solid knowledge of Apache and its configuration and usage. - Reasonable knowledge of mod_perl. This includes the API, pitfalls and benefits. - Good programming skills. These include logic, reasoning, problem solving and proper application design. - Web application development experience. This includes a fair knowledge of HTML (recent versions [4.x) and JavaScript, as well as good UI design. - Knowledge of SQL. - Knowledge of Perl's DBI libraries for Database access. In addition, we are always seeking candidates who also have the following skills on top of those listed above: - Java (Applets, servlets, JSP) - J2EE (EJB) - Weblogic 6 - Fixed Income Experience (Municipal Corporate bonds, especially!) - Database Experience - Sybase Oracle. Do you have what it takes to join one of the most dynamic development teams on Wall Street? Send resumes, with cover letter to [EMAIL PROTECTED] Serious applicants ONLY!
Re: [OT] Better Linux server platform: Redhat or SuSe?
lol... We're running a little over 175000 lines of (mod)perl code, currently running on a mix of RedHat 7.1, 7.2, 7.3 and Advanced Server. Next? On Wed, 2002-07-03 at 09:41, Peter Haworth wrote: On Wed, 3 Jul 2002 11:40:44 +0100, Jean-Michel Hiver wrote: perl: Any iussues with perl/modperl? Besides modperl I will be running a perl application with a few hundred thousend lines of code... Wow. For reference last time I looked at slashcode it was about 25.000 lines I think. I wonder what kind of application would require more than that amount of Perl code :-) I'm sure someone else will post a bigger number, but my application (IOP Electronic Journals) has 55000 lines of code (including the odd blank line and comment, of course). And we're always adding new stuff, so it only ever gets bigger. -- Peter Haworth [EMAIL PROTECTED] We don't care how they do it in New York. Owen -- USMail: InterGuide Communications, 230 Lyn Anne Court, Ann Arbor, MI 48103 Phone:+1 734 997-0922 FAX:+1 734 661-0324 mailto:[EMAIL PROTECTED] http://www.interguide.com/~osm/
Re: Apache::LogFile, rotatelogs, and line breaks
On Wednesday 03 July 2002 12:25 pm, Jim Spath wrote: I've been running Apache::LogFile to create a piped log through rotatelogs and have experienced some problems. I have narrowed the problem down to the use of piped logging and Apache::LogFile. When I use Apache::LogFile to write directly to a file, this problem does not occur, but when I pipe the output to a file (through cat), I run into the same problem with intermittent missing line breaks. I'd still appreciate some fedback on this, but I think I may just print a line break to the file deal with the fact that there will be double line breaks most of the time. I created a log file that had 2271 entries in it for one hour. Out of these 2271 entries, 622 of them occured on the same second and wrote to the log properly (one entry per line). However, there were 5 entries in the file where two entries from the same second had no line break in between them. I was wondering if anyone had similair experiences with Apache::LogFile or rotatelogs. Thanks for the help! Jim Spath
Re: [OT] Better Linux server platform: Redhat or SuSe?
Software-based RAID 1: Is it usable (only for a data partition, not required for the root partition)? Is it easy to recover from a broken disk? If possible, consider using hardware RAID, like Mylex ones; they are quite expensive, because of SCSI disks, but you gain cpu cycles; I've used Mylex cards on four Red Hat boxes for four years without a problem, and monitored hw status using /proc file system. There are also IDE motherboards with RAID, I own one of them, but I use the eight devices feature instead of raid. Consider also the use of kickstart utility shipped with RH, it makes possible to build your own installation disks; of course, Debian also is very powerful at this. I never used RH RPMs for Apache and mod_perl, mostly because of DSO issues. You can also build a card to operate reset buttons remotely. Double power line is a plus ;) Ciao, Valerio Valerio Paolini, http://130.136.3.200/~paolini -- what is open-source about? Learn, and then give back
Re: [OT] Better Linux server platform: Redhat or SuSe?
Maybe that depends on the project. We have a powerful BBS system, which contains: read/post messages, public and member sign ups, messages cached to disk or memory, email notification, fast sorting of message threads and follow-ups, and a number of other features. It consists of 5 modules and each module has only 100 - 300 lines. Well, we use HTML::Template that helps to separate the HTML codes from the modules. Having HTML in perl programs makes a big difference. Peter Bi - Original Message - From: Owen Scott Medd [EMAIL PROTECTED] To: Peter Haworth [EMAIL PROTECTED] Cc: Jean-Michel Hiver [EMAIL PROTECTED]; Gerd Knops [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, July 03, 2002 11:53 AM Subject: Re: [OT] Better Linux server platform: Redhat or SuSe? lol... We're running a little over 175000 lines of (mod)perl code, currently running on a mix of RedHat 7.1, 7.2, 7.3 and Advanced Server. Next? On Wed, 2002-07-03 at 09:41, Peter Haworth wrote: On Wed, 3 Jul 2002 11:40:44 +0100, Jean-Michel Hiver wrote: perl: Any iussues with perl/modperl? Besides modperl I will be running a perl application with a few hundred thousend lines of code... Wow. For reference last time I looked at slashcode it was about 25.000 lines I think. I wonder what kind of application would require more than that amount of Perl code :-) I'm sure someone else will post a bigger number, but my application (IOP Electronic Journals) has 55000 lines of code (including the odd blank line and comment, of course). And we're always adding new stuff, so it only ever gets bigger. -- Peter Haworth [EMAIL PROTECTED] We don't care how they do it in New York. Owen -- USMail: InterGuide Communications, 230 Lyn Anne Court, Ann Arbor, MI 48103 Phone:+1 734 997-0922 FAX: +1 734 661-0324 mailto:[EMAIL PROTECTED] http://www.interguide.com/~osm/
Re: [OT] Better Linux server platform: Redhat or SuSe?
Valerio_Valdez Paolini [EMAIL PROTECTED] writes: Software-based RAID 1: Is it usable (only for a data partition, not required for the root partition)? Is it easy to recover from a broken disk? If possible, consider using hardware RAID, like Mylex ones; they are quite expensive, because of SCSI disks, but you gain cpu cycles; But my box isn't short of CPU cycles, so I'd be paying that price for no gain. Obviously hardware RAID will save CPU cycles somewhat, and SCSI disks of the right type will increase IO bandwidth somewhat, but if you're not short of those things and still want the added security of mirroring, I think the software RAID is a viable option. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: [OT] Better Linux server platform: Redhat or SuSe?
David Dyer-Bennet writes: Obviously hardware RAID will save CPU cycles somewhat, and SCSI disks of the right type will increase IO bandwidth somewhat, but if you're not short of those things and still want the added security of mirroring, I think the software RAID is a viable option. Harware RAID is usually hotswappable, which is quite nice. Rob
Re: [OT] Better Linux server platform: Redhat or SuSe?
On Wed, 3 Jul 2002, Rob Nagler wrote: David Dyer-Bennet writes: Obviously hardware RAID will save CPU cycles somewhat, and SCSI disks of the right type will increase IO bandwidth somewhat, but if you're not short of those things and still want the added security of mirroring, I think the software RAID is a viable option. Harware RAID is usually hotswappable, which is quite nice. More, you can make redundant RAID and even have disks shared by two boxes :) Ciao, Valerio Valerio Paolini, http://130.136.3.200/~paolini -- what is open-source about? Learn, and then give back
Re: [OT] Better Linux server platform: Redhat or SuSe?
From: Barry Hoggard [EMAIL PROTECTED] Date: Wed, 03 Jul 2002 11:52:21 -0400 Remote maintability: Is it possible to remotely upgrade between OS versions for either of those platforms (not a must, but would be a plus)? I would be afraid to do that remotely, since it normally involved a kernel change as well. We have an internal distribution which is kinda mostly a redhat system gets various RPMs updated remotely including kernel RPMs, but I'm *very* careful with kernel RPMs and do multiple installs on non-remote systems before I do any remote systems. Sendmail: Does the system make it easy to replace sendmail with another mailer of choice (qmail in my case)? I don't know about Red Hat, but it's certainly easy in SuSE. Build your own RPM from one of the SRPMs out there and qmail will work fine. Footprint: Is it easy to weed out unused system components to have a smaller footprint of the OS? Or does that mean fighting the installer left and right? I don't know if Red Hat is getting any better, but I've always found it difficult to do a minimal install. SuSE has options for a very minimal install which is what I use for server installs. We created our own comps file for our custom configs. perl: Any iussues with perl/modperl? Besides modperl I will be running a perl application with a few hundred thousend lines of code... My current project: http://www.better-investing.org runs on Red Hat. I'm not aware of any perl/mod_perl issues, but I built perl and the apache binaries myself. I don't use their RPMs. I use a mix of RedHat RPMS, my own RPMs and other people's RPMs. My perl and apache RPMs are all currently from Mandrake. (I seem to be gradually migrating towards Mandrake.) Chris -- Chris Garrigues http://www.DeepEddy.Com/~cwg/ virCIO http://www.virCIO.Com 716 Congress, Suite 200 Austin, TX 78701 +1 512 374 0500 What are you really trying to do. msg28758/pgp0.pgp Description: PGP signature
Re: [OT] Better Linux server platform: Redhat or SuSe?
We wrote our own templating system (back when modperl was still just a puppy) as we have over 200 sites running off the same code instance distributed across the server farm. Everybody wants their submit buttons to say something slightly different, we were forced early on to remove all hardcoded html from the code. The reason for all that code is that there is just a lot of functionality there (text analysis, vectorspace matching, billing, customer management, message system). Much of it has been migrating into our java-based backend system (I'm sure a year ago the number of lines of code would have been substantially higher) as we retire all the business logic that was embedded in the modperl frontend and maintain only the java version which runs in the backend. Owen On Wed, 3 Jul 2002, Peter Bi wrote: Maybe that depends on the project. We have a powerful BBS system, which contains: read/post messages, public and member sign ups, messages cached to disk or memory, email notification, fast sorting of message threads and follow-ups, and a number of other features. It consists of 5 modules and each module has only 100 - 300 lines. Well, we use HTML::Template that helps to separate the HTML codes from the modules. Having HTML in perl programs makes a big difference. Peter Bi - Original Message - From: Owen Scott Medd [EMAIL PROTECTED] To: Peter Haworth [EMAIL PROTECTED] Cc: Jean-Michel Hiver [EMAIL PROTECTED]; Gerd Knops [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, July 03, 2002 11:53 AM Subject: Re: [OT] Better Linux server platform: Redhat or SuSe? lol... We're running a little over 175000 lines of (mod)perl code, currently running on a mix of RedHat 7.1, 7.2, 7.3 and Advanced Server. Next? On Wed, 2002-07-03 at 09:41, Peter Haworth wrote: On Wed, 3 Jul 2002 11:40:44 +0100, Jean-Michel Hiver wrote: perl: Any iussues with perl/modperl? Besides modperl I will be running a perl application with a few hundred thousend lines of code... Wow. For reference last time I looked at slashcode it was about 25.000 lines I think. I wonder what kind of application would require more than that amount of Perl code :-) I'm sure someone else will post a bigger number, but my application (IOP Electronic Journals) has 55000 lines of code (including the odd blank line and comment, of course). And we're always adding new stuff, so it only ever gets bigger. -- Peter Haworth [EMAIL PROTECTED] We don't care how they do it in New York. Owen -- USMail: InterGuide Communications, 230 Lyn Anne Court, Ann Arbor, MI 48103 Phone:+1 734 997-0922 FAX: +1 734 661-0324 mailto:[EMAIL PROTECTED] http://www.interguide.com/~osm/ -- USMail: InterGuide Communications, 230 Lyn Anne Court, Ann Arbor, MI 48103 phone:+1 734 997-0922 fax:+1 734 661-0324 mailto:[EMAIL PROTECTED] http://www.interguide.com/~osm/ [ Sometimes wrong. Never in doubt. ]
