Having used CVS quite a bit, I sympatize. However, I have never heard of anything like you want.
In general there are a few thing to make remove CVS over slower connections a bit better. While not always possible, $(subject) is a good idea (making large commits into smaller commits). In addition, using the -z (compression) option (say, -z3 or -z4) can make commits much faster over slower. Of course, working/committing on a remote box with a fast connection also works:)
Contrary to almost every other Linux distribution out there, we have a functional source-based Linux 'distro' using a single source tree (ala BSD). Instead of having to untar/configure/make/install, a single command allows us to rebuild the entire system. In addition, system coherency is greatly enhanced when the entire system is built and maintained in a common tree.
Unfortunately, the Linux community as a whole does not seem interested in a system like this. The closest 'main-stream' distribution to do anything like this is perhaps Rock Linux, though they still use tarballs and scripts to extract/configure/build/etc. Otherwise, binary distros are the norm.
BTW, yggdrasil hasn't had an offering since '95 or '96. If you are still using an original yggdrasil distribution, you are probably complete out-of-date. Hell, you might as well be using SLS.
The links above are your best bet for basic cvs server configuration. Once you have a pserver set up, you may consider using cvs via ssh. All you need to do is the following:
1) Have ssh and sshd set up on the client and server machines 2) Set CVSROOT="joe@example.com:/home/ncvs" 3) Set CVS_RSH="/usr/local/bin/ssh" 4) Use cvs normally (Obviously, insert the proper host/paths above)
You can also set up cvs/ssh to not need a password every time (similiar to an initial 'cvs login'):
1) run ssh-keygen on client machine using no passphrase. 2) copy/add ~/.ssh/identity.pub on the client to ~/.ssh/authorized_keys on the server (man ssh for more details)
The main reason I mention this is: I couldn't find any real information regarding this in any of the docs/tutorials; it's much more secure then using rsh/pserver connections; and it's cool:)
Yes, especially compared to that one version of SuSE, Slackware, Redhat, Debian, Stampede, Mandrake, MkLinux, TurboLinux, RockLinux, Caldera, DLX, Yggdrasil, Alzzalinux, Apokalypse, Bastille, BeroLinux, Best Linux, Connectiva Linux, Delix, DLD, SLS, EasyLinux, Enoch, Esware, Freenix, Khoeps, KSI Linux, Linux MX, LinuxGT, LST, LunetlX, LaetOS, Macmillan, Nomad, OpenShare, Phat, Prosa Debian, Pygmy, slinux, Storm Linux, Turkauz, Vendova Linux, Yellow Dog Linux, et. al. Yes, I see your point, 3 BSD's are definitely too many. See http://www.linuxlinks.com/Distributions for the above links.
And since FreeBSD can run most Linux binaries (Word Perfect 8, Quake I, II, and III-test, Oracle 8, Netscape, etc.) along with being able to compile most source-based applications including KDE and GNOME apps out of the box, how much of an edge does Linux really have?
I'm pretty sure I read somewhere that FreeBSD was their main development platform, but I sure as hell cannot find it now (though I will continue to look). OTOH, according to Netcraft'ssurvey, the majority of their systems are FreeBSD.
Even though I have very little respect for AC's on Slashdot, I will take that as a compliment. It's almost fun to watch the flame (read: dick-size) wars...though it tends to get old quick.
Through simple (and more complex) testing, we found what works best. Personally, I wanted both servers to be FreeBSD, but we found that Linux had a significant advantage when used as the SQL server (see some basic test results here).
You don't need a PhD to figure out that you should use what works best. I trust FreeBSD implicitly with the web-serving because of it's stability and speed WRT web-serving. OTOH, I trust Linux for the SQL server due to it's stability and speed WRT the SQL server. As stupid as it may sound...use the best tool for the job. Both OS's have their strengths; people should be emphasizing what each *CAN* do instead of bickering over what the other can't.
Yes, you can get them precompiled from TcX. I was referring to the binaries precompiled from Redhat (I have no idea if they are TcX's or not). My sole purpose was to emphasize the performance gains you can achieve using pgcc and having the server statically linked. In addition, you may get even better optimization using a newer version of pgcc than TcX used. OTOH, I'm sure that the binaries from TcX are probably fully optimized and would be the best source if you didn't want to or are unable to compile them yourself.
Yes, I forgot about www.apache.org. Indeed, their server run FreeBSD. In addition, FreeBSD is (or at least was the last time I checked) their main development platform. As for that M$-owned company, I did not include it due to flamers/ac's/etc.
I'm sure the laptops have at least one serial port. *BSD, Solaris, Linux >= 2.1.x, and most other Unices have serial console support in some respect. Why waste $$$ on new monitors and keyboards for those servers... Install Linux or *BSD on the laptop, install minicom, and away you go:)
First of all: IMO, if you have to ask how to optimize your company's equipment in a forum such as this, you need some real help (perhaps of the mental variety). There are a plethora of web sites on optimizing systems. OTOH, I might as well share our experiences.
Our company uses Apache, MySQL, and PHP extensively (and exclusively). You can't beat the price/performance ($0.00 / excellent == great value). Thorough our research, we settled with the following combination:
Web Server: FreeBSD 3.2-STABLE with Apache 1.3.9 / PHP 3.0.9 on a PII-400 w/128 Meg RAM, IBM 4.55G U2W Drive. Due to FreeBSD's proven track record for Web/Network performance, stability, and security (e.g. Yahoo, wcarchive, and others), it's a natural.
SQL Server: Linux 2.2.x with MySQL 3.22.25 on a PII-400 w/256 Meg RAM, IBM 4.55G U2W System Drive and a Mylex AcceleRAID 250 w/4 IBM 4.55G U2W Drives in a RAID-5 configuration. Linux was the obvious choice when considering MySQL performance and driver availability wrt RAID controllers.
Optimization suggestions:
Apache: Ensure you have adequate spare servers to handle the connections (StartServers, MaxSpareServers, MaxClients, and MaxRequestsPerClient in the config); nothing sucks more than clients not being able to connect. Also, if you are using embedded script of some sort (PHP, Perl, etc.), use modules compiled into Apache (mod_perl, etc.); this should significantly increase speed and decrease the overhead of reloading the module for each access.
MySQL: Tweak the applicable setting as appropriate. We increased (usually doubled in most cases) the following: Join Buffer, Key Buffer, Max Connections, Max Join Size, Max Sort Length, Sort Buffer, and Sort Buffer). If possible, depending on the amount of data, get as much memory in the system as possible. If the OS can maintain frequently used data cached, disk access won't be required which significantly increases the speed of queries, etc. In addition, get rid of that pre-compiled MySQL and compile it yourself. If possible, optimize using egcs/pgcc for your platform. Also, compile mysqld statically; this will increase it's memory overhead a bit but can increase it's speed by 5 - 10% by not using shared libraries.
Storage: For optimum speed, use SCSI (of course). For our data, we require RAID 5 for redundancy. If that is not required, RAID 0 (striping) can be used for increased speed. The optimal way is to use hardware RAID (external RAID or RAID controller). Luckily, Linux has drivers for quite a few different RAID controllers that are available for a reasonable price.
Linux: Beware of Redhat's security problems, disable all unnecessary services, et. al. Seek out security-oriented and Linux performance-tuning sites for more suggestions.
General: Don't skimp on hardware. A cheap component, be it a drive, network card, motherboard, or whatever, if it fails, will cause unrecoverable downtime. We decided on Intel NL440BX boards (serial console/BIOS support is nice), PII-400's, and IBM SCSI drives in both boxes. If one box were to have a catastrophic failure, the other is able to perform both webserver and SQL server functions if necessary. We can also simply replace a failed component with one pulled from a similarly-configured non-production (test) box, or just swap boxes altogether.
Both Apache and MySQL have good sections on performance tuning. Do not be afraid to RTFM.
Any questions/comments can be directed to me. Flames directed to/dev/null.
Although MySQL lacks some features the Postgres has, MySQL is fully threaded whereas Postgres is not. In short, Postgres cannot perform parallel operations; MySQL can operate on different tables simultaneously.
Does anyone remember the programming contest sponsored by some west-coast university that banned Perl? Apparently, using Perl, a student completely thrashed the competition; therefore, Perl is now a no-no.
Well, I for one am glad that Redhat created X for us 'Linux/Unix' users. ${DIETY} forbid MIT should create such an entity back before Linux gained its popularity.
In addition, it seems that someone forgot to include those cool GUI administration tools with my FreeBSD version of X. Hmmm...should I email Redhat about this?:)
----- You can ISO9001 certify the process of shooting yourself in the foot, so long as the process is documented and reliably produces the proper result.
Once you've heard The Who's 'Live at Leeds', you will never go back! The 'dueling' between Pete Townsends guitar and John Entwistle's Bass cannot be beat.
Slashdot Mirror
Hmmm, Linux gets a splash screen on boot. And only a few years after FreeBSD.
Having used CVS quite a bit, I sympatize. However, I have never heard of anything like you want.
:)
In general there are a few thing to make remove CVS over slower connections a bit better. While not always possible, $(subject) is a good idea (making large commits into smaller commits). In addition, using the -z (compression) option (say, -z3 or -z4) can make commits much faster over slower. Of course, working/committing on a remote box with a fast connection also works
Contrary to almost every other Linux distribution out there, we have a functional source-based Linux 'distro' using a single source tree (ala BSD). Instead of having to untar/configure/make/install, a single command allows us to rebuild the entire system. In addition, system coherency is greatly enhanced when the entire system is built and maintained in a common tree.
Unfortunately, the Linux community as a whole does not seem interested in a system like this. The closest 'main-stream' distribution to do anything like this is perhaps Rock Linux, though they still use tarballs and scripts to extract/configure/build/etc. Otherwise, binary distros are the norm.
BTW, yggdrasil hasn't had an offering since '95 or '96. If you are still using an original yggdrasil distribution, you are probably complete out-of-date. Hell, you might as well be using SLS.
Wow. Can you say FUD? I knew you could.
Yet another war, BSD vs GPL, BSD vs Linux, ad nauseum. How about something new.
The links above are your best bet for basic cvs server configuration. Once you have a pserver set up, you may consider using cvs via ssh. All you need to do is the following:
:)
1) Have ssh and sshd set up on the client and server machines
2) Set CVSROOT="joe@example.com:/home/ncvs"
3) Set CVS_RSH="/usr/local/bin/ssh"
4) Use cvs normally
(Obviously, insert the proper host/paths above)
You can also set up cvs/ssh to not need a password every time (similiar to an initial 'cvs login'):
1) run ssh-keygen on client machine using no passphrase.
2) copy/add ~/.ssh/identity.pub on the client to ~/.ssh/authorized_keys on the server
(man ssh for more details)
The main reason I mention this is: I couldn't find any real information regarding this in any of the docs/tutorials; it's much more secure then using rsh/pserver connections; and it's cool
Just my $0.02.
A system's security is only as good as it's administrator.
Yes, especially compared to that one version of SuSE, Slackware, Redhat, Debian, Stampede, Mandrake, MkLinux, TurboLinux, RockLinux, Caldera, DLX, Yggdrasil, Alzzalinux, Apokalypse, Bastille, BeroLinux, Best Linux, Connectiva Linux, Delix, DLD, SLS, EasyLinux, Enoch, Esware, Freenix, Khoeps, KSI Linux, Linux MX, LinuxGT, LST, LunetlX, LaetOS, Macmillan, Nomad, OpenShare, Phat, Prosa Debian, Pygmy, slinux, Storm Linux, Turkauz, Vendova Linux, Yellow Dog Linux, et. al.
Yes, I see your point, 3 BSD's are definitely too many.
See http://www.linuxlinks.com/Distributions for the above links.
And since FreeBSD can run most Linux binaries (Word Perfect 8, Quake I, II, and III-test, Oracle 8, Netscape, etc.) along with being able to compile most source-based applications including KDE and GNOME apps out of the box, how much of an edge does Linux really have?
I'm pretty sure I read somewhere that FreeBSD was their main development platform, but I sure as hell cannot find it now (though I will continue to look). OTOH, according to Netcraft's survey, the majority of their systems are FreeBSD.
Even though I have very little respect for AC's on Slashdot, I will take that as a compliment. It's almost fun to watch the flame (read: dick-size) wars...though it tends to get old quick.
Through simple (and more complex) testing, we found what works best. Personally, I wanted both servers to be FreeBSD, but we found that Linux had a significant advantage when used as the SQL server (see some basic test results here).
You don't need a PhD to figure out that you should use what works best. I trust FreeBSD implicitly with the web-serving because of it's stability and speed WRT web-serving. OTOH, I trust Linux for the SQL server due to it's stability and speed WRT the SQL server. As stupid as it may sound...use the best tool for the job. Both OS's have their strengths; people should be emphasizing what each *CAN* do instead of bickering over what the other can't.
Yes, you can get them precompiled from TcX. I was referring to the binaries precompiled from Redhat (I have no idea if they are TcX's or not). My sole purpose was to emphasize the performance gains you can achieve using pgcc and having the server statically linked. In addition, you may get even better optimization using a newer version of pgcc than TcX used.
OTOH, I'm sure that the binaries from TcX are probably fully optimized and would be the best source if you didn't want to or are unable to compile them yourself.
Yes, I forgot about www.apache.org. Indeed, their server run FreeBSD. In addition, FreeBSD is (or at least was the last time I checked) their main development platform. As for that M$-owned company, I did not include it due to flamers/ac's/etc.
And how many NT servers do they need to handle the load?
Are you a moron. You can easily download the source code, it's just not under the GNU Public Virus^WLicense.
What does that matter when Linux chokes on file > 2GB?
I'm sure the laptops have at least one serial port. *BSD, Solaris, Linux >= 2.1.x, and most other Unices have serial console support in some respect. Why waste $$$ on new monitors and keyboards for those servers... Install Linux or *BSD on the laptop, install minicom, and away you go :)
Our company uses Apache, MySQL, and PHP extensively (and exclusively). You can't beat the price/performance ($0.00 / excellent == great value). Thorough our research, we settled with the following combination:
- Web Server: FreeBSD 3.2-STABLE with Apache 1.3.9 / PHP 3.0.9 on a PII-400 w/128 Meg RAM, IBM 4.55G U2W Drive. Due to FreeBSD's proven track record for Web/Network performance, stability, and security (e.g. Yahoo, wcarchive, and others), it's a natural.
- SQL Server: Linux 2.2.x with MySQL 3.22.25 on a PII-400 w/256 Meg RAM, IBM 4.55G U2W System Drive and a Mylex AcceleRAID 250 w/4 IBM 4.55G U2W Drives in a RAID-5 configuration. Linux was the obvious choice when considering MySQL performance and driver availability wrt RAID controllers.
Optimization suggestions:- Apache: Ensure you have adequate spare servers to handle the connections (StartServers, MaxSpareServers, MaxClients, and MaxRequestsPerClient in the config); nothing sucks more than clients not being able to connect. Also, if you are using embedded script of some sort (PHP, Perl, etc.), use modules compiled into Apache (mod_perl, etc.); this should significantly increase speed and decrease the overhead of reloading the module for each access.
- MySQL: Tweak the applicable setting as appropriate. We increased (usually doubled in most cases) the following: Join Buffer, Key Buffer, Max Connections, Max Join Size, Max Sort Length, Sort Buffer, and Sort Buffer). If possible, depending on the amount of data, get as much memory in the system as possible. If the OS can maintain frequently used data cached, disk access won't be required which significantly increases the speed of queries, etc. In addition, get rid of that pre-compiled MySQL and compile it yourself. If possible, optimize using egcs/pgcc for your platform. Also, compile mysqld statically; this will increase it's memory overhead a bit but can increase it's speed by 5 - 10% by not using shared libraries.
- Storage: For optimum speed, use SCSI (of course). For our data, we require RAID 5 for redundancy. If that is not required, RAID 0 (striping) can be used for increased speed. The optimal way is to use hardware RAID (external RAID or RAID controller). Luckily, Linux has drivers for quite a few different RAID controllers that are available for a reasonable price.
- Linux: Beware of Redhat's security problems, disable all unnecessary services, et. al. Seek out security-oriented and Linux performance-tuning sites for more suggestions.
- General: Don't skimp on hardware. A cheap component, be it a drive, network card, motherboard, or whatever, if it fails, will cause unrecoverable downtime. We decided on Intel NL440BX boards (serial console/BIOS support is nice), PII-400's, and IBM SCSI drives in both boxes. If one box were to have a catastrophic failure, the other is able to perform both webserver and SQL server functions if necessary. We can also simply replace a failed component with one pulled from a similarly-configured non-production (test) box, or just swap boxes altogether.
Both Apache and MySQL have good sections on performance tuning. Do not be afraid to RTFM.Any questions/comments can be directed to me. Flames directed to
Redhat is full of clueful hackers? Guess you haven't read BugTraq for the past couple years.
Although MySQL lacks some features the Postgres has, MySQL is fully threaded whereas Postgres is not. In short, Postgres cannot perform parallel operations; MySQL can operate on different tables simultaneously.
There is a link on the main page of The Perl Journal.
Does anyone remember the programming contest sponsored by some west-coast university that banned Perl? Apparently, using Perl, a student completely thrashed the competition; therefore, Perl is now a no-no.
Well, I for one am glad that Redhat created X for us 'Linux/Unix' users. ${DIETY} forbid MIT should create such an entity back before Linux gained its popularity.
:)
In addition, it seems that someone forgot to include those cool GUI administration tools with my FreeBSD version of X. Hmmm...should I email Redhat about this?
-----
You can ISO9001 certify the process of shooting
yourself in the foot, so long as the process is
documented and reliably produces the proper
result.
Once you've heard The Who's 'Live at Leeds', you will never go back! The 'dueling' between Pete Townsends guitar and John Entwistle's Bass cannot be beat.
Unfortunately, no one could ever replace Keith Moon (${DIETY} rest his soul).