Which is both a blessing and a curse. In CVS (or even VSS which had a "destroy" option), a rogue developer could kill off large amounts of project history which might go unnoticed for long periods. In SVN, it's simply not possible. In VSS, we had an extremely limited subset of people who were allowed to "destroy".
Our old VSS server's repository was around 20-30GB after close to 5 years of use. Lots and lots of binary files in there, which ate up tremendous amounts of disk space due to inefficient storage of binaries.
In SVN, because binaries are stored efficiently (compression + deltas), we're not seeing anywhere near the rate of growth that I was seeing with VSS. And we're not even bothering to compress easily compressed binaries anymore (such as MDBs or huge DOC files).
(With SVN, there's always the option to do a dump/restore of your SVN repository, where you filter things out during the restore, resulting in a smaller repository. Probably not much worse then the old VSS Archive/Restore tedium.)
That's certainly true. It's tolerable when I'm on the LAN with the server. When I'm working via VPN from home, I get up and watch some TV when doing a full checkout of my system. (Some of that is the binaries, though much is just the sheer number of files and the latencies caused by the SSH.)
Our solution is that the main trunk is always kept up-to-date on the workstations. I have a script that runs at 4am each morning that does a "svn up" on that part of the repository tree. When I'm ready to use my laptop a few hours later, I have very few worries that I don't already have the latest. And when I do a quick "svn up" on a particular section that I'm working on, odds are high that I already have the latest. I have yet to see "svn up" do something bad to my local working copy. In cases whre there are conflicts, it brings down the conflicting revision as a new file (with the rev# tacked onto the end). Other users run a "svn up" as soon as they login at the start of the day.
I also don't find that SSH introduces much latency (we're using SSH pub keys, Pagaent and TortoiseSVN). It takes about a few seconds to setup the initial connection for a TSVN update command (or a "svn up" at the command line), after which it runs at full tilt until finished. On a busy day, I might do around a dozen commits and a small handful of "svn up" commands (since I pull everything down daily).
Now, as I said before, we're an odd shop. We don't really use SVN to do traditional development work. We're almost more of a service bureau where each person works on half a dozen jobs where they do 99% of the work on each job. The main reason we use SVN (and previously, VSS+SourceOffSite) is to keep in sync with each other (and to have a file history). So that if a project director has a question on a project, I can go look in my working copy (maybe do a quick "svn up") and see what is checked in. Or I can provide assistance to another person by looking at their project files.
Back when we used VSS+SourceOffSite (all traffic went through SOS, which kept our repository from getting damaged), we would zip up our.MDB (MSAccess database files) prior to checking them in. VSS/SOS was extremely inefficient at storing binaries (every time you checked in a 20MB binary, the repository size would increase by 20MB), so zip'ing the files saved us a lot of space. Plus SOS didn't do a very good job of over-the-wire compression, so a zip'd MDB would download a lot faster then storing the MDB natively.
In SVN, we no longer bother to zip up our MDBs (or other large, easily compressed, binary files). Adding a 20MB MDB to a SVN repository only adds a few MB to the total size and transmits exceedingly quickly. Especially on subsequent check-ins where it can do a diff and only store / transmit a delta. Pulling down a 500MB MDB where you know someone changed a single record is no longer a big deal if you have a recent version in your local working copy.
Same thing for other binary formats (AVI, MPEG, JPG, TIFF). We simply don't bother trying to zip them up. It's a hassle that we're happy to no longer have to deal with.
My "server" is my desktop machine, AMD Athlon XP 2000+. 30mb files take around 12 minutes or so to checkout.
You *really* need to examine your setup to find out why that is happening.
A 300 MB checkout (maybe a few dozen files) should only take about a minute to prep and then however long it takes to move over the wire. Since we're using svn+ssh, things are extremely efficient (SSH pub-keys restricted to running the svnserver tool in tunnel mode combined with PuTTY and TortoiseSVN). Our largest repository is a few gigabytes with close to 100,000 files (but I haven't counted lately).
Our server is simply a 4-disk RAID10 system, 2GHz Athlon64 X2 CPU, and we're running inside a Xen DomU. Last time I looked, I think we're only giving the SVN DomU around 512MB of RAM. We're using the FS-based repository format instead of the BerkelyDB.
Most of the time, our bottleneck is the WAN connection. And Xen's network performance (in that version of Xen) isn't all that great to write home about either. But we get a good 2-3 MBps across the gigabit connection which is good enough for now. Since most of our users are on the far side of a T1 line (which is only 150KBps) it's not an urgent issue.
The idiot put 35 megs of logs into the repository.
SVN actually works pretty well at storing log files (it's very efficient at it - both storing and sending the changes). Especially for distribution of said log files and secure storage of the log files. Because SVN doesn't support purge, it makes a good WORM-style solution for logs. And with svn+ssh and restricting the commands that can be run with a particular SSH key make it fairly secure from tampering.
Yeah, it's probably overkill. But it's a legitimate use of the tool for cases where you want to transport log files quickly and securely to an offsite location. Our servers push the log files once an hour.
But with subversion, I just found it disgusting (and hard to manage) how it left all these invisible files all over my system and if I copied a directory, for example, there would be two copies linked to the same place in the repository. Also, some actions that I do directly to the files are very difficult to reconcile with the repository.
That's actually a very strong advantage of SVN. Working copies do not have to map 1:1 with repositories. But it was a big change compared to how Visual SourceSafe works. In fact, svn:externals makes heavy use of this.
Now, for us, we prefer to keep things very similar across our workstations. For instance, we have a "company-jobs" repository that we use to store our projects. That repository is always checked out to C:\Company\Jobs and we pull down the entire repository (we even have a "svn up" batch file that runs when you login to make sure you're in sync). Below that point, our structure is/svn/company-jobs/prefix/projectnumber/ - where "prefix" is the 3 character company code and "projectnumber" is the billing code and project name.
We also have a standard set of folders that we create in each project (one of these days, I'll script this). Such as "docs/", "data/", "media/", etc.
Now, I have a love/hate relationship with the.svn/_svn folders being stored in the working copy tree. I like it because I can easily backup a working copy, or move it to another folder, and not have to remember what the SVN checkout path was. It's also fairly resilient. In SourceOffSite, we had a bad issue where SOS would trash its record of what you had checked out, losing status. In SVN, when part of the working copy gets corrupted, we delete those folders and re-do a SVN update (in cases where "svn cleanup" fails).
Honestly, if you think Subversion is the wave of the future, you haven't been paying much attention. It fixes some fundamental flaws in CVS, which is nice, but elsewhere there's exciting stuff like Monotone, darcs and many others. It seems people aren't looking hard enough for source control options, when they'll go wild over things like SVN, or more recently GIT.
It may or may not be the wave of the future, but after looking at version control systems for almost 2 years before switching to SVN last year, it has a good bit of momentum.
- Needed to work with multiple client OSs (Win32, OS X, Linux, etc)
- Open-source tools
- Easy to use (which is why we like TortoiseSVN)
- Efficient network traffic
- Efficient storage of binary files
- Command-line tools in addition to GUI tools
After almost 9 months of solid use, we're pretty happy with it and are looking forward to v1.5 and v1.6 to fix some things we don't like still.
Now, we're an oddball shop, because 90% of what we use SVN for is not development work, but for keeping documents & project files synchronized across people working in multiple locations. Once v1.5/v1.6 allow for sparse/partial working copies, we will probably move towards getting rid of our central file server.
That's pretty surprising that you see performance issues. We run a few tens of thousand files in one of our repositories (a 10-20GB working copy, but only 3GB in the repository). We find performance in SVN to be quite good. Lots and lots of binaries (and SVN is a darned sight better then VSS/SourceOffSite at storing those).
All told, our total repository space is 20GB spread over about 2 dozen repositories (the 3GB one is the largest and where most work occurs).
It's working exceeding well for us. We run svn+ssh connections using TSVN+pagaent. There are a few things that I wish it did better (such as partial working copy checkouts or making the working copies smaller at the expense of more network/server traffic).
Considering Intel invented x86 decades ago and AMD just copied that, I'd consider them even. Intel unsuccessfully tried to move the world off of the ancient x86 instruction set, and lazy companies like Microsoft decided to put their weight behind the 64-bit x86 hack that AMD offered. Now we get to suffer another 20 years of working around x86.
Nothing lazy about it.
Intel offered up the Itanium. A 64bit platform that ran existing 32bit code in slow-motion mode. Folks making purchase decisions looked at that, realized that 32bit apps wouldn't be rewritten overnight for Itanium and decided that a move to Itanium was too risky (and expensive).
AMD comes out with their 64bit chips... which run existing 32bit apps at normal speed, plus provide a seamless upgrade path to 64bit computing down the road. We all look at it and decided it was a much more sensible approach and bought it in droves. There were even rumors that existing 32bit code ran faster on the Athlon64 chips. AMD provided a nearly risk-free migration path towards 64bit computing (and Intel finally climbed on board).
If Itanium had been able to run existing 32bit x86 code at close to native speed, we might have shifted that way. The performance hit was simply too large, so the market said "meh, not gonna switch".
Yes, x86 is a PITA, and a kludge on top of a kludge, and other various slurs... but for 90%+ of applications, it works and is fast enough.
However with all manufacturers I learned not to rush to buy new board because many of them have headaches the first few months/revisions.
The real lesson you should've learned is to always buy CPU+MB+RAM in bundled form. Where the retailer has already put the 3 components together and guarantees that they work. (MWave charges all of $9 for the service.) With a motherboard bundle, you eliminate all of the guesswork and you're sure to get a working setup. Some places call this an "assemble & test" option.
(I started buying motherboard bundles about 2 years ago. I'll never, except in a pinch, go back to buying the components separately. Saves me about 15-30 minutes of assembly time and hours of research time. For the most part, the cost is the same as individual parts, except for a small assembly fee.)
I'm still looking for a good retailer who does Opteron motherboard bundles...
Swapping out user's machines is a PITA. Making sure that you have all the user's programs installed, moving data over, etc is a hassle in a small company.
Our planned lifespan for desktops is at *least* 5 years. (Hell, I'm still trying to retire some machines from 1998-1999.) The new machines (dual-core, 2GB, RAID1) will probably last us close to 10 years. Figure in year 5 or so, we'll boost the RAM up to 4GB, but otherwise those machines should be fine for general office work for the duration. The dual-core will probably be the key, even if one of the cores is busy processing, the system should remain responsive. We got in early on the AM2 socket, so we should have plenty of upgrade options in 2009-2011 (AM3 chips are supposed to be pluggable into AM2 sockets).
(PC performance increases have basically flatlined since 2002. It used to be that machine power doubled every 1.0 to 1.5 years. Now it takes more like 3-5 years for power to double. The dual-core and quad-core machines shake that up a bit.)
Except that if we try to keep our models standardized so we can load standard images, changing hardware can create problems. Sure, the connectors are the same, but I don't want, 3 years down the road, to have every computer existing with a different patchwork of replacement parts and the driver hell that can go with that.
Integrated everything in the motherboard fixes a lot of ills. Especially the NVIDIA chipsets. A motherboard based on NVIDIA chipset NNN can generally be swapped out for any other motherboard that is also based on that chipset.
A recent example. I took a WinXP box that was running on an old Opteron 940 pin motherboard (either VIA or NVIDIA chipset) that died, pulled the motherboard and swapped in an Asus NVIDIA 939 pin motherboard. The system came right back up. I might have had to put in drivers for the different NIC. I was using a PCI soundcard, so I didn't have to muck with soundcard drivers.
Modern OSs like WinXP, Linux, etc, generally don't freak out if you change out the underlying hardware. (The main exception is probably single-core vs dual-core hardware as WinXP cares about that at a very low level.)
As for the rest of the hardware - DVD drives and hard drives don't require unique drivers.
That's why we build our own. Being able to get components from just about anywhere and knowing that there are zero proprietary parts inside is a real nice feeling.
My favorite build right now for office machines is:
Motherboard bundle from MWave (AMD Athlon X2 AM2 3600+, Asus M2NPV-VM, Kingston 2GB DDR2 667MHz, Assembly + Test), Antec Sonata II case, DVD writer, floppy, (2) 250GB HDs running in RAID1. For someone who needs a bit more CPU power, we spend another $100 and upgrade to an Athlon64 X2 5000+ (or thereabouts). I haven't built one in a month or two, so I'm not sure what the base cost is ($550-$700 range). Add in OEM versions of WinXP Pro and Office 2003 Pro for around $435.
We have a standard drive image that we use that just needs sysprep and re-entry of the WinXP key. We've even swiped a user's 2nd HD (out of the RAID1 set) and used it to build or rebuild another user's machine (in cases where our drive image was out of date).
The only semi-proprietary component inside is the Asus motherboard based on the NVIDIA GeForce 6150 chipset. But we could probably get a similar motherboard using that chipset from other manufacturers, or switch to using the Asus M2N-E motherboard and adding in an inexpensive PCIe video card for $45.
(I like the Asus motherboards because they don't have any fans cooling the chipset, it's all passive cooling. Less fans = less things that can go wrong.)
For a quality build, buying the business class systems from Dell (Optiplex), you can generally beat Dell's price by about 20% or so.
Our current white box systems are dual-core, 2GB RAM, 2x250GB RAID1, integrated video, DVD-writer boxes w/ Win XP Pro and Office 2003 Pro. Cost for us is around $1150, including shipping compared to around $1300-$1500 from Dell. Assembly & base software install (restore a standard image, sysprep it, re-enter keys) is around 2-3 hours. The WinXP / Office costs are around $430 of the total cost, so the base units are only $700 or so.
We could probably shave another $50-$100 if we went cheap on parts / cases. But the users really like the machines (and the cases) and we like running on top of RAID1. So we'll just keep seeing the units get less expensive as dual-core CPU and RAM prices continue to drop.
So, do we save money over the long run? Maybe. The big reason for us is that if Dell goes out of business tomorrow, we don't care. All of our components are commodity items, nothing proprietary, so we can source replacements from just about anywhere. When we upgrade the internals on these machines in 5 years or so, there's a good chance that the case / PSU / misc parts can be reused. (As opposed to Dell's proprietary and over-designed cases / PSUs.)
But it really only works for programmers. On the infrastructure side, you really have to be on site for a lot of things (correct me if I am wrong.) I work in a small company where I wear many hats so sometimes I need to interrupt a maintenance task or project to fix someone's PC. I'd love a telecommuting position but that would mean a radical change. I'd really like to find a telecommuting help desk analyst position. It would be worth even a small pay cut for having such flexibility
I wear the sysadmin hat (in addition to many others), and I spend 99% of my days offsite, about 5-6 hours away from the office. The key items IMO are:
1. Remote control software on every desktop. We used to use e/pop Professional (chat software + remote control) but are switching over to RealVNC + Jabber. Being able to see the user's screen makes it less likely that I'll have to take a drive.
2. Reliable hardware. Plan for failure. We build our own desktops with RAID1 and using commodity parts. We've had 1 hard drive fail in the past few years, and if it had been one of the newer ones with RAID1, it would've been a cakewalk. I'm still working on keeping a library of drive images for quick restoration. The cost of a 2nd drive and imaging software pays for itself pretty quickly when you have a user's machine go down.
3. Periodic trips into the office. Once I move in a few months, I plan on going in about once every week or every other week. Most technical issues can wait a few days to be resolved. We also have a semi-technical person who works in the office a few days a week who can act as a "pair of hands". But I also have other users who are smarter then the average bear who can reboot servers or read off status information. Other years, I've done 3 weeks home 1 week at the office.
4. In-house IM system. Saves a lot on phone calls. Easier to give someone technical information such as a URL. We're even able to connect to our IM system (Wildfire jabber server) from our cell phones.
Things I still want to do:
- TCP/IP controlled power plugs on the server rack
- TCP/IP KVM for the server rack
Unless you're spending $20k-$50k per server on hardware, VMWare pricing will seem very expensive (in the $3-$4k range per server is what I was quoted a few months ago). For smaller shops that have a few $6k-$10k servers and a small SAN, the VMWare costs make it a very hard sell (almost better to order another server).
I agree. Virtulization is penetrating every aspect of computing from servers to desktops. I wouldn't be surprised to see it in limited form on mobile devices. I would say 90% of companies are using virtulization (in production/dev/qa) and the remaining 10% are using it in dev/qa, or at the very least have a plan to implement it. The hardware/power/cooling cost savings and reduction in management overhead are to great to ignore by even the smallest shops.
90% is too high a figure. Unless you're counting by percentage of market cap or something that skews the statistic towards large companies.
Smaller companies (under $5M/year gross revenue) would probably like to use virtualization, but it's just getting on their radar. And it won't be a quick process. Our company is a bit larger then that and we started 1 year ago with a plan to finish migration after about 4-5 years.
The major bottlenecks (server virtualization):
- Developing a business case for a SAN
- Finding the money for said SAN
- Switches and interface cards
- Redundancy
- Buying and setting up application servers
If you spent $10,000 a year ago on a file server, you're not going to just throw that out the window and deploy virtualized servers and a SAN. But migrating over a 3-5 year period makes more sense. The payoff will be in a few years from now when downtime only occurs due to gross failure, rather then the glitch of a single machine.
The speed of migration also depends on the business that you're in. There's still a lot of businesses that only have a handful (maybe just one) server supporting a few dozen workers.
I have a 22" 1680x1050 (16:10). One option for running Oblivion that may work better for you then me is to run at 1280x720 (16:9) and let the monitor scale it up to 1920x1050 (also 16:9). If I were to do that, everything gets slightly stretched vertically.
From what I've read, a single 8800 is equivalent in performance to a dual-7950 setup. So there's hope... It's just that I setup this SLI rig (Athlon64 X2 5000+, 2GB RAM, pair of 7950s) only 6 months ago and I want to wait until at least next summer to upgrade the video cards again.
Now I just get to wait for the 8800 speed demon cards to drop below $200... (where's my time machine?).
how fast things change, 15 years ago nobody had one and behold, we did live and not worse than we do now
15 years ago, there were a lot more pay phones around. Most of them even allowed incoming calls (so you could page someone and have them call you back). So it was easier to get away with not having a cell phone.
OTOH, my job is now easier in some ways due to having a cell phone on me full-time. I can waltz out the door to lunch and even run a few errands without coming back to someone fuming and camping my office door. Often due to a problem that would've taken a two minute phone call to fix or postpone. I no longer have to go scurrying for a pay phone when my numeric pager goes off, only to find out that it was something trivial. And if it's something really urgent, I can cut my lunch hour / errand running short while I get balls rolling on fixing the situation.
(For me, the decision to own a cell phone is easier because work is willing to pick up the tab.)
If the worm still propagated by random probes, its growth rate would decrease by a factor of ~ 2^96 -- to essentially nil.
It's probably a lot lower then 2^96.
From my (vague) understandings of the IP6 address structure, there are a lot more "unused" areas. So that may cut it down to 2^80 or even as low as 2^64. And if all of the older devices live in the IP6 to IP4 conversion address range... a non-discriminating infecter may choose to start there first.
The other half of the equation is that we're no longer in the days of 56kbit leased lines. Now, a lot of infected machines have much larger pipes (512kbit up to 5mbit), which means that they can scan 10-100 times faster then in the old days (which is another 2^6 off of the 2^96 number).
I think most cable/DSL users (at home) have their computer connected directly to Internet, with *maybe* a software firewall (such as the one built-in to XP). If it is possible in any way for them to connect multiple devices (laptop, PDA, phone, desktop) into their adsl/cable modem without a firewall, *THEY WILL FIND A WAY*.
A lot of the more modern Cable/DSL modems have built-in NAT/Firewalls now, which means you don't always need a Linksys (or other) NAT/Firewall device. So a goodly number of those users are no longer directly connected. And they can simply add a switch to the mix to service multiple machines.
I'd say, offhand, that I first started seeing built-in NATs in the cable modems about 2 years ago. Four to five years ago it was rare, but it seems a lot more common occurrence now.
Yes, because maybe by then we'll be able to run the damned thing at a decent framerate.:P
Sad but true... even with a pair of GeForce 7950 in SLI mode at 1280x720, it's tough to get reasonable framerates. Maybe once those super-fast 8800s drop in price next year I'll upgrade and try again.
As a huge fan of MOO and MOO2, I tried Galactic Civilizations 2. Honestly, it doesn't do anything for me. I tried with the original, and I tried again when the expansion was released, but I could never get into it. It's sort of flat and lifeless, and there's too much micromanagement.
GalCiv is still on my to-play list. My understanding was that it's more like the Civilization series rather then a MOO2 clone.
(But I've been a big fan of StarDock since they were one of the few developers who
made games for OS/2.)
Slashdot Mirror
It exists forever in SVN.
Which is both a blessing and a curse. In CVS (or even VSS which had a "destroy" option), a rogue developer could kill off large amounts of project history which might go unnoticed for long periods. In SVN, it's simply not possible. In VSS, we had an extremely limited subset of people who were allowed to "destroy".
Our old VSS server's repository was around 20-30GB after close to 5 years of use. Lots and lots of binary files in there, which ate up tremendous amounts of disk space due to inefficient storage of binaries.
In SVN, because binaries are stored efficiently (compression + deltas), we're not seeing anywhere near the rate of growth that I was seeing with VSS. And we're not even bothering to compress easily compressed binaries anymore (such as MDBs or huge DOC files).
(With SVN, there's always the option to do a dump/restore of your SVN repository, where you filter things out during the restore, resulting in a smaller repository. Probably not much worse then the old VSS Archive/Restore tedium.)
That's certainly true. It's tolerable when I'm on the LAN with the server. When I'm working via VPN from home, I get up and watch some TV when doing a full checkout of my system. (Some of that is the binaries, though much is just the sheer number of files and the latencies caused by the SSH.)
Our solution is that the main trunk is always kept up-to-date on the workstations. I have a script that runs at 4am each morning that does a "svn up" on that part of the repository tree. When I'm ready to use my laptop a few hours later, I have very few worries that I don't already have the latest. And when I do a quick "svn up" on a particular section that I'm working on, odds are high that I already have the latest. I have yet to see "svn up" do something bad to my local working copy. In cases whre there are conflicts, it brings down the conflicting revision as a new file (with the rev# tacked onto the end). Other users run a "svn up" as soon as they login at the start of the day.
I also don't find that SSH introduces much latency (we're using SSH pub keys, Pagaent and TortoiseSVN). It takes about a few seconds to setup the initial connection for a TSVN update command (or a "svn up" at the command line), after which it runs at full tilt until finished. On a busy day, I might do around a dozen commits and a small handful of "svn up" commands (since I pull everything down daily).
Now, as I said before, we're an odd shop. We don't really use SVN to do traditional development work. We're almost more of a service bureau where each person works on half a dozen jobs where they do 99% of the work on each job. The main reason we use SVN (and previously, VSS+SourceOffSite) is to keep in sync with each other (and to have a file history). So that if a project director has a question on a project, I can go look in my working copy (maybe do a quick "svn up") and see what is checked in. Or I can provide assistance to another person by looking at their project files.
Back when we used VSS+SourceOffSite (all traffic went through SOS, which kept our repository from getting damaged), we would zip up our .MDB (MSAccess database files) prior to checking them in. VSS/SOS was extremely inefficient at storing binaries (every time you checked in a 20MB binary, the repository size would increase by 20MB), so zip'ing the files saved us a lot of space. Plus SOS didn't do a very good job of over-the-wire compression, so a zip'd MDB would download a lot faster then storing the MDB natively.
In SVN, we no longer bother to zip up our MDBs (or other large, easily compressed, binary files). Adding a 20MB MDB to a SVN repository only adds a few MB to the total size and transmits exceedingly quickly. Especially on subsequent check-ins where it can do a diff and only store / transmit a delta. Pulling down a 500MB MDB where you know someone changed a single record is no longer a big deal if you have a recent version in your local working copy.
Same thing for other binary formats (AVI, MPEG, JPG, TIFF). We simply don't bother trying to zip them up. It's a hassle that we're happy to no longer have to deal with.
My "server" is my desktop machine, AMD Athlon XP 2000+. 30mb files take around 12 minutes or so to checkout.
You *really* need to examine your setup to find out why that is happening.
A 300 MB checkout (maybe a few dozen files) should only take about a minute to prep and then however long it takes to move over the wire. Since we're using svn+ssh, things are extremely efficient (SSH pub-keys restricted to running the svnserver tool in tunnel mode combined with PuTTY and TortoiseSVN). Our largest repository is a few gigabytes with close to 100,000 files (but I haven't counted lately).
Our server is simply a 4-disk RAID10 system, 2GHz Athlon64 X2 CPU, and we're running inside a Xen DomU. Last time I looked, I think we're only giving the SVN DomU around 512MB of RAM. We're using the FS-based repository format instead of the BerkelyDB.
Most of the time, our bottleneck is the WAN connection. And Xen's network performance (in that version of Xen) isn't all that great to write home about either. But we get a good 2-3 MBps across the gigabit connection which is good enough for now. Since most of our users are on the far side of a T1 line (which is only 150KBps) it's not an urgent issue.
The idiot put 35 megs of logs into the repository.
SVN actually works pretty well at storing log files (it's very efficient at it - both storing and sending the changes). Especially for distribution of said log files and secure storage of the log files. Because SVN doesn't support purge, it makes a good WORM-style solution for logs. And with svn+ssh and restricting the commands that can be run with a particular SSH key make it fairly secure from tampering.
Yeah, it's probably overkill. But it's a legitimate use of the tool for cases where you want to transport log files quickly and securely to an offsite location. Our servers push the log files once an hour.
But with subversion, I just found it disgusting (and hard to manage) how it left all these invisible files all over my system and if I copied a directory, for example, there would be two copies linked to the same place in the repository. Also, some actions that I do directly to the files are very difficult to reconcile with the repository.
/svn/company-jobs/prefix/projectnumber/ - where "prefix" is the 3 character company code and "projectnumber" is the billing code and project name.
.svn/_svn folders being stored in the working copy tree. I like it because I can easily backup a working copy, or move it to another folder, and not have to remember what the SVN checkout path was. It's also fairly resilient. In SourceOffSite, we had a bad issue where SOS would trash its record of what you had checked out, losing status. In SVN, when part of the working copy gets corrupted, we delete those folders and re-do a SVN update (in cases where "svn cleanup" fails).
That's actually a very strong advantage of SVN. Working copies do not have to map 1:1 with repositories. But it was a big change compared to how Visual SourceSafe works. In fact, svn:externals makes heavy use of this.
Now, for us, we prefer to keep things very similar across our workstations. For instance, we have a "company-jobs" repository that we use to store our projects. That repository is always checked out to C:\Company\Jobs and we pull down the entire repository (we even have a "svn up" batch file that runs when you login to make sure you're in sync). Below that point, our structure is
We also have a standard set of folders that we create in each project (one of these days, I'll script this). Such as "docs/", "data/", "media/", etc.
Now, I have a love/hate relationship with the
Honestly, if you think Subversion is the wave of the future, you haven't been paying much attention. It fixes some fundamental flaws in CVS, which is nice, but elsewhere there's exciting stuff like Monotone, darcs and many others. It seems people aren't looking hard enough for source control options, when they'll go wild over things like SVN, or more recently GIT.
It may or may not be the wave of the future, but after looking at version control systems for almost 2 years before switching to SVN last year, it has a good bit of momentum.
- Needed to work with multiple client OSs (Win32, OS X, Linux, etc)
- Open-source tools
- Easy to use (which is why we like TortoiseSVN)
- Efficient network traffic
- Efficient storage of binary files
- Command-line tools in addition to GUI tools
After almost 9 months of solid use, we're pretty happy with it and are looking forward to v1.5 and v1.6 to fix some things we don't like still.
Now, we're an oddball shop, because 90% of what we use SVN for is not development work, but for keeping documents & project files synchronized across people working in multiple locations. Once v1.5/v1.6 allow for sparse/partial working copies, we will probably move towards getting rid of our central file server.
That's pretty surprising that you see performance issues. We run a few tens of thousand files in one of our repositories (a 10-20GB working copy, but only 3GB in the repository). We find performance in SVN to be quite good. Lots and lots of binaries (and SVN is a darned sight better then VSS/SourceOffSite at storing those).
All told, our total repository space is 20GB spread over about 2 dozen repositories (the 3GB one is the largest and where most work occurs).
It's working exceeding well for us. We run svn+ssh connections using TSVN+pagaent. There are a few things that I wish it did better (such as partial working copy checkouts or making the working copies smaller at the expense of more network/server traffic).
Considering Intel invented x86 decades ago and AMD just copied that, I'd consider them even. Intel unsuccessfully tried to move the world off of the ancient x86 instruction set, and lazy companies like Microsoft decided to put their weight behind the 64-bit x86 hack that AMD offered. Now we get to suffer another 20 years of working around x86.
Nothing lazy about it.
Intel offered up the Itanium. A 64bit platform that ran existing 32bit code in slow-motion mode. Folks making purchase decisions looked at that, realized that 32bit apps wouldn't be rewritten overnight for Itanium and decided that a move to Itanium was too risky (and expensive).
AMD comes out with their 64bit chips... which run existing 32bit apps at normal speed, plus provide a seamless upgrade path to 64bit computing down the road. We all look at it and decided it was a much more sensible approach and bought it in droves. There were even rumors that existing 32bit code ran faster on the Athlon64 chips. AMD provided a nearly risk-free migration path towards 64bit computing (and Intel finally climbed on board).
If Itanium had been able to run existing 32bit x86 code at close to native speed, we might have shifted that way. The performance hit was simply too large, so the market said "meh, not gonna switch".
Yes, x86 is a PITA, and a kludge on top of a kludge, and other various slurs... but for 90%+ of applications, it works and is fast enough.
However with all manufacturers I learned not to rush to buy new board because many of them have headaches the first few months/revisions.
The real lesson you should've learned is to always buy CPU+MB+RAM in bundled form. Where the retailer has already put the 3 components together and guarantees that they work. (MWave charges all of $9 for the service.) With a motherboard bundle, you eliminate all of the guesswork and you're sure to get a working setup. Some places call this an "assemble & test" option.
(I started buying motherboard bundles about 2 years ago. I'll never, except in a pinch, go back to buying the components separately. Saves me about 15-30 minutes of assembly time and hours of research time. For the most part, the cost is the same as individual parts, except for a small assembly fee.)
I'm still looking for a good retailer who does Opteron motherboard bundles...
Swapping out user's machines is a PITA. Making sure that you have all the user's programs installed, moving data over, etc is a hassle in a small company.
Our planned lifespan for desktops is at *least* 5 years. (Hell, I'm still trying to retire some machines from 1998-1999.) The new machines (dual-core, 2GB, RAID1) will probably last us close to 10 years. Figure in year 5 or so, we'll boost the RAM up to 4GB, but otherwise those machines should be fine for general office work for the duration. The dual-core will probably be the key, even if one of the cores is busy processing, the system should remain responsive. We got in early on the AM2 socket, so we should have plenty of upgrade options in 2009-2011 (AM3 chips are supposed to be pluggable into AM2 sockets).
(PC performance increases have basically flatlined since 2002. It used to be that machine power doubled every 1.0 to 1.5 years. Now it takes more like 3-5 years for power to double. The dual-core and quad-core machines shake that up a bit.)
Except that if we try to keep our models standardized so we can load standard images, changing hardware can create problems. Sure, the connectors are the same, but I don't want, 3 years down the road, to have every computer existing with a different patchwork of replacement parts and the driver hell that can go with that.
Integrated everything in the motherboard fixes a lot of ills. Especially the NVIDIA chipsets. A motherboard based on NVIDIA chipset NNN can generally be swapped out for any other motherboard that is also based on that chipset.
A recent example. I took a WinXP box that was running on an old Opteron 940 pin motherboard (either VIA or NVIDIA chipset) that died, pulled the motherboard and swapped in an Asus NVIDIA 939 pin motherboard. The system came right back up. I might have had to put in drivers for the different NIC. I was using a PCI soundcard, so I didn't have to muck with soundcard drivers.
Modern OSs like WinXP, Linux, etc, generally don't freak out if you change out the underlying hardware. (The main exception is probably single-core vs dual-core hardware as WinXP cares about that at a very low level.)
As for the rest of the hardware - DVD drives and hard drives don't require unique drivers.
That's why we build our own. Being able to get components from just about anywhere and knowing that there are zero proprietary parts inside is a real nice feeling.
My favorite build right now for office machines is:
Motherboard bundle from MWave (AMD Athlon X2 AM2 3600+, Asus M2NPV-VM, Kingston 2GB DDR2 667MHz, Assembly + Test), Antec Sonata II case, DVD writer, floppy, (2) 250GB HDs running in RAID1. For someone who needs a bit more CPU power, we spend another $100 and upgrade to an Athlon64 X2 5000+ (or thereabouts). I haven't built one in a month or two, so I'm not sure what the base cost is ($550-$700 range). Add in OEM versions of WinXP Pro and Office 2003 Pro for around $435.
We have a standard drive image that we use that just needs sysprep and re-entry of the WinXP key. We've even swiped a user's 2nd HD (out of the RAID1 set) and used it to build or rebuild another user's machine (in cases where our drive image was out of date).
The only semi-proprietary component inside is the Asus motherboard based on the NVIDIA GeForce 6150 chipset. But we could probably get a similar motherboard using that chipset from other manufacturers, or switch to using the Asus M2N-E motherboard and adding in an inexpensive PCIe video card for $45.
(I like the Asus motherboards because they don't have any fans cooling the chipset, it's all passive cooling. Less fans = less things that can go wrong.)
For a quality build, buying the business class systems from Dell (Optiplex), you can generally beat Dell's price by about 20% or so.
Our current white box systems are dual-core, 2GB RAM, 2x250GB RAID1, integrated video, DVD-writer boxes w/ Win XP Pro and Office 2003 Pro. Cost for us is around $1150, including shipping compared to around $1300-$1500 from Dell. Assembly & base software install (restore a standard image, sysprep it, re-enter keys) is around 2-3 hours. The WinXP / Office costs are around $430 of the total cost, so the base units are only $700 or so.
We could probably shave another $50-$100 if we went cheap on parts / cases. But the users really like the machines (and the cases) and we like running on top of RAID1. So we'll just keep seeing the units get less expensive as dual-core CPU and RAM prices continue to drop.
So, do we save money over the long run? Maybe. The big reason for us is that if Dell goes out of business tomorrow, we don't care. All of our components are commodity items, nothing proprietary, so we can source replacements from just about anywhere. When we upgrade the internals on these machines in 5 years or so, there's a good chance that the case / PSU / misc parts can be reused. (As opposed to Dell's proprietary and over-designed cases / PSUs.)
But it really only works for programmers. On the infrastructure side, you really have to be on site for a lot of things (correct me if I am wrong.) I work in a small company where I wear many hats so sometimes I need to interrupt a maintenance task or project to fix someone's PC. I'd love a telecommuting position but that would mean a radical change. I'd really like to find a telecommuting help desk analyst position. It would be worth even a small pay cut for having such flexibility
I wear the sysadmin hat (in addition to many others), and I spend 99% of my days offsite, about 5-6 hours away from the office. The key items IMO are:
1. Remote control software on every desktop. We used to use e/pop Professional (chat software + remote control) but are switching over to RealVNC + Jabber. Being able to see the user's screen makes it less likely that I'll have to take a drive.
2. Reliable hardware. Plan for failure. We build our own desktops with RAID1 and using commodity parts. We've had 1 hard drive fail in the past few years, and if it had been one of the newer ones with RAID1, it would've been a cakewalk. I'm still working on keeping a library of drive images for quick restoration. The cost of a 2nd drive and imaging software pays for itself pretty quickly when you have a user's machine go down.
3. Periodic trips into the office. Once I move in a few months, I plan on going in about once every week or every other week. Most technical issues can wait a few days to be resolved. We also have a semi-technical person who works in the office a few days a week who can act as a "pair of hands". But I also have other users who are smarter then the average bear who can reboot servers or read off status information. Other years, I've done 3 weeks home 1 week at the office.
4. In-house IM system. Saves a lot on phone calls. Easier to give someone technical information such as a URL. We're even able to connect to our IM system (Wildfire jabber server) from our cell phones.
Things I still want to do:
- TCP/IP controlled power plugs on the server rack
- TCP/IP KVM for the server rack
The bigger issue with VMWare is licensing costs.
Unless you're spending $20k-$50k per server on hardware, VMWare pricing will seem very expensive (in the $3-$4k range per server is what I was quoted a few months ago). For smaller shops that have a few $6k-$10k servers and a small SAN, the VMWare costs make it a very hard sell (almost better to order another server).
I never had an issue with multiple drives in Xen.
What drives me up the wall at the moment is bonded interfaces. The Xen scripts flat out suck for doing any sort of ethernet bonding in domain0.
When we've all got 16+ megabit Internet connections (~the amount needed for streaming HDTV)
MPEG2 streaming of HDTV is 16-24 Mbps.
But if you use a more modern video codec, you can drop that to as little as 2.5 Mbps with 3.0-3.5 Mbps being more likely.
I agree. Virtulization is penetrating every aspect of computing from servers to desktops. I wouldn't be surprised to see it in limited form on mobile devices. I would say 90% of companies are using virtulization (in production/dev/qa) and the remaining 10% are using it in dev/qa, or at the very least have a plan to implement it. The hardware/power/cooling cost savings and reduction in management overhead are to great to ignore by even the smallest shops.
90% is too high a figure. Unless you're counting by percentage of market cap or something that skews the statistic towards large companies.
Smaller companies (under $5M/year gross revenue) would probably like to use virtualization, but it's just getting on their radar. And it won't be a quick process. Our company is a bit larger then that and we started 1 year ago with a plan to finish migration after about 4-5 years.
The major bottlenecks (server virtualization):
- Developing a business case for a SAN
- Finding the money for said SAN
- Switches and interface cards
- Redundancy
- Buying and setting up application servers
If you spent $10,000 a year ago on a file server, you're not going to just throw that out the window and deploy virtualized servers and a SAN. But migrating over a 3-5 year period makes more sense. The payoff will be in a few years from now when downtime only occurs due to gross failure, rather then the glitch of a single machine.
The speed of migration also depends on the business that you're in. There's still a lot of businesses that only have a handful (maybe just one) server supporting a few dozen workers.
I have a 22" 1680x1050 (16:10). One option for running Oblivion that may work better for you then me is to run at 1280x720 (16:9) and let the monitor scale it up to 1920x1050 (also 16:9). If I were to do that, everything gets slightly stretched vertically.
From what I've read, a single 8800 is equivalent in performance to a dual-7950 setup. So there's hope... It's just that I setup this SLI rig (Athlon64 X2 5000+, 2GB RAM, pair of 7950s) only 6 months ago and I want to wait until at least next summer to upgrade the video cards again.
Now I just get to wait for the 8800 speed demon cards to drop below $200... (where's my time machine?).
how fast things change, 15 years ago nobody had one and behold, we did live and not worse than we do now
15 years ago, there were a lot more pay phones around. Most of them even allowed incoming calls (so you could page someone and have them call you back). So it was easier to get away with not having a cell phone.
OTOH, my job is now easier in some ways due to having a cell phone on me full-time. I can waltz out the door to lunch and even run a few errands without coming back to someone fuming and camping my office door. Often due to a problem that would've taken a two minute phone call to fix or postpone. I no longer have to go scurrying for a pay phone when my numeric pager goes off, only to find out that it was something trivial. And if it's something really urgent, I can cut my lunch hour / errand running short while I get balls rolling on fixing the situation.
(For me, the decision to own a cell phone is easier because work is willing to pick up the tab.)
If the worm still propagated by random probes, its growth rate would decrease by a factor of ~ 2^96 -- to essentially nil.
It's probably a lot lower then 2^96.
From my (vague) understandings of the IP6 address structure, there are a lot more "unused" areas. So that may cut it down to 2^80 or even as low as 2^64. And if all of the older devices live in the IP6 to IP4 conversion address range... a non-discriminating infecter may choose to start there first.
The other half of the equation is that we're no longer in the days of 56kbit leased lines. Now, a lot of infected machines have much larger pipes (512kbit up to 5mbit), which means that they can scan 10-100 times faster then in the old days (which is another 2^6 off of the 2^96 number).
IMHO...
I think most cable/DSL users (at home) have their computer connected directly to Internet, with *maybe* a software firewall (such as the one built-in to XP). If it is possible in any way for them to connect multiple devices (laptop, PDA, phone, desktop) into their adsl/cable modem without a firewall, *THEY WILL FIND A WAY*.
A lot of the more modern Cable/DSL modems have built-in NAT/Firewalls now, which means you don't always need a Linksys (or other) NAT/Firewall device. So a goodly number of those users are no longer directly connected. And they can simply add a switch to the mix to service multiple machines.
I'd say, offhand, that I first started seeing built-in NATs in the cable modems about 2 years ago. Four to five years ago it was rare, but it seems a lot more common occurrence now.
Yes, because maybe by then we'll be able to run the damned thing at a decent framerate. :P
Sad but true... even with a pair of GeForce 7950 in SLI mode at 1280x720, it's tough to get reasonable framerates. Maybe once those super-fast 8800s drop in price next year I'll upgrade and try again.
As a huge fan of MOO and MOO2, I tried Galactic Civilizations 2. Honestly, it doesn't do anything for me. I tried with the original, and I tried again when the expansion was released, but I could never get into it. It's sort of flat and lifeless, and there's too much micromanagement.
GalCiv is still on my to-play list. My understanding was that it's more like the Civilization series rather then a MOO2 clone.
(But I've been a big fan of StarDock since they were one of the few developers who made games for OS/2.)