The bigger question that comes to the forefront of my mind is:
For how much longer can Microsoft afford to re-invent Unix (badly), rather then starting to embrace and switch to open-source software for the underlying systems? Is it really in their investors' best interest to keep re-inventing the wheel?
Is the value of locking in customers to the Windows platform really worth what they're paying to write (poorly) operating systems like Vista?
Refurbishment makes sense for higher quality notebooks. My grab and go travel notebook is a loaded out (max memory, 80 gig HD) nearly 10 year old Compaq M300, it weighs in at 3.3 pounds has a magnesium case, and quality construction. The P3-500 is fast enough to browse the web, play youtube videos, and all that other basic stuff. Best yet I only have about $300 invested in it, so if it breaks I am not out much. Sure I could spend $1500 on a similared sized high quality replacement, but do I really need all those extra wasted clock cycles. And if I did spend $1500 on it, would I treat it like this grab and go, toss it around, leave it in the open in motel rooms while I am away, etc.
That pretty much covers it for me as well. I wouldn't pay to refurb a crappy consumer-level notebook, but and older Thinkpad is (almost) always worth upgrading. (The other issue is that any OEM software licenses are tied to the machine, so you'd have to repurchase that software unless you refurb. That's a cost that you need to factor into the decision.)
I ran a Toshiba Tecra 8100 into the ground recently. I bought it back in early 2002 and it was my main machine up until late 2007. Along the way, it had 3 hard drives, a new backlight, a new keyboard, new mouse buttons, and a new CD/DVD drive installed. Replacing the keyboard made it feel like a new machine for the last 18 months of its lifespan.
But after 5 1/2 years, it was definitely time for it to be put out to pasture. The single-core CPU made it very unresponsive at times. I think if it had a dual-core CPU, then I'd still be using it for at least one more year. But it was also blue-screening at random times when I'd take it into the office rather then leaving it sit on the dock at home.
You first need to decide whether you want a centralized model, like SVN, or a distributed model (git / mercurial / bzr?). And also consider tool support (SVN has very good tool support, others may not and require more hacking at a command line).
All of the products listed will handle 50 developers and 6 GB of source with no issues. Our biggest repository weighs in at 11GB with a few thousand revisions. Then we have repositories that are only 2GB, but with 50,000 revisions. Sometimes it's nice to have a monolithic repository (ease of use for less technical users), other times repositories for each project are better.
There are other advantages / disadvantages to each version control system.
You don't want to use svn with a large tree because it stores a second copy of only the revision you checked out (so that diffs are fast). Other systems like hg can typically store the entire repository, giving you access to all revisions, in less space (it's compressed) than svn can store just the working copy.
SVN works fine with large trees (whether that's measured as # of revisions, # of files, or # of bytes).
Yes, the working copy stores a "pristine" copy in the.svn folder for easy diffs. Which was designed to reduce the amount of server traffic. I'll agree that sometimes that's not always a good choice, but (for the most part) local disk space is inexpensive and the 2x space requirement on the local disk doesn't bother me.
There's been some talk about allowing the user to tell SVN (and tools built on top of the SVN libraries) that there may not always be a pristine local copy. The question, I think, is whether it could be done without breaking other design goals (the ability to be a WebDAV source comes to mind). Or without generating huge amounts of traffic (the anti-argument here is that if rsync can do it, svnserve should be able to).
I think there's also talk of putting the.svn folder in the root of the working copy and nowhere else.
But yes, I'm hoping that they'll switch to storing the pristine local copy in compressed format, which would save a good bit of space. I suspect the design was designed to be conservative with regards to beating on the CPU, and that there were a zillion other priorities to get working first. It's only been in the past year or two that I've seen more frequent mentions of improving the working copy design.
(Being able to have sparse checkouts will probably help us a lot with the local working copy size. It will at least make a dent in it.)
Your sample population needs to match the characteristics of the larger population. So if your larger population has a 55/45 split between the genders, make sure that you adjust your sample to be a 55/45 split as well if you want to make inferences based on gender.
That's an extremely small survey sample to try and draw relevant conclusions on. 30,000 might be a better indicator. Otherwise, you're talking too wide of a margin for error.
Like the others have said... a sample size of 30,000 doesn't necessarily get you more accuracy then a sample size of 3,000. Or at least, not enough additional accuracy that it's worth paying for. The other folks know the math better then me (I just do the IT support for the research eggheads), but the increase in accuracy falls off extremely rapidly for the first 500-1000 respondents.
Most researchers aim for response rates in the 500-1000 respondent range. Some go for larger sample size because there are sub-divisions within the study that they want to be able to draw conclusions about. Such as splitting the sample by gender / age / income and still having enough in each group to get valid results.
Sadly... reading slashdot to stay current isn't as useful as it was back in 2000-2004.
Back then, we had articles on different database systems, IDEs, different linux distros, with lots of commentary as to the details of why one might be better then another. Including specific tips or tricks of the trade or related tools. I used to struggle to find time in the evenings to read all of the informational articles and comments that were being posted. And I learned a hell of a lot in the process.
Now the articles with the biggest comment count are the "rile the masses" type articles. Or the ones with a heavy political bias.
When was the last time we saw an article discussing how to do hot-standby or clustering with linux/windows servers?
1) Networking with others is key. Try to maintain contact as much as possible with people at your old firm, especially anyone who is more technically inclined and is willing to answer questions. It's also a good way to find out what the new trends are and whether they are just flash-in-the-pan. That's one of the areas that I failed in when I moved from a really large company to the small company that I work for now. Which means that I've had to do a lot of the research myself.
2) Don't be afraid to cry "Uncle!" and hire someone on a short-term basis. Make sure that they show you their work so you can understand what they did. Black box systems are a no-no, as are consultants or support people who prefer to make their changes behind a curtain. As much as you may not want to be master of everything, in a smaller company you really need to become a jack-of-all-trades. Or at least be proficient enough to know when the staff or contact workers are blowing smoke up your ass.
3) Unless you absolutely hate reading (if so - you may be in the wrong job), try to read at least one technical book per month. And/Or take at least one 4 hour class per quarter. It keeps you in the game mentally and keeps you from ending up in a dead-end because you let all your skills get rusty. However you choose to do it - continuing education is key if you want to be self-reliant to a large degree.
I started working at my current firm about 8 years ago (and telecommuted for the first 7 years). There are still a few parts of the operation that aren't under my control (the PBX), but otherwise I have my finger on the pulse of everything else. I do a lot of experimenting on the side (it took 2 years for us to put Linux into production use). I work crazy hours some weeks. But, on the flip side, because it's a small company - I can set my own schedule to a very large degree. I'll gladly take flexibility, very little politics (I speak directly to the CEO and have the power to make purchases/decisions), and goal-oriented environment (make it work - keep the clients happy) and lower salary over being paid big bucks at a big firm.
The biggest tools that help me keep my sanity:
1) Nagios - or any other monitoring system. Knowing that something is broken before anyone else notices is a big advantage. You get a reputation for keeping the ship running smoothly without people having to scream to get something fixed. A lot of the people will think that you're psychic at times.
2) Wiki or Version Control System for internal documentation of systems. Network maps, rack layouts, what cable goes where on the back of a rack, pictures of equipment, etc. are very important. There are a lot of times where I've pulled up pictures of equipment in order to walk a regular employee at the office through restarting something (instead of having to drive in - or wait for a technical employee to be there). Get a good, small camera, and take lots of photos. Scratch notes on the back of a napkin and scan those in. Just have some sort of central location where your staff can look for information. I call it "just in case I (or you) get hit by a bus" documentation.
3) Automatic configuration change tracking. You can do this by hand, trying to track changes on an internal blog or a spreadsheet, or a text file, but automated tools are better. If you run Linux servers, use something like FSVS to shove all of your configuration files into a Subversion repository. That way, you can go back and look at what changes were made to the server along with why they were made. You can also do things like using rsync or looking through old backups, but I prefer to use an actual version control system designed for the purpose. Get your staff in the habit of using the tool when they make changes.
I suspect if we ever switch away from SVN, Mercurial is a strong contender.
But for us, we don't currently place a high value on distributed and decentralized. Mostly because it's easier to be constantly connected then it was 5 years ago, but also because our users are not especially technically inclined.
Getting them to understand update/check-in and keeping their local disk in sync with the server is challenging enough (even with TortoiseSVN).
The other strong selling point for us is the broad adoption of SVN across multiple platforms and that it works with a lot of different tools. Combine that with being actively developed and improved, and it's head and shoulders above what we used before.
(Note: We don't do a lot of branching and merging. We're more excited about sparse checkouts.)
Dude, SVN is ***EIGHT YEARS*** old. It is hardly the craze of the week.
Just one minor point of note, at least for our experience. It may be 8 years old, but it really wasn't suitable for our use until 1.3 (and we waited until 1.4 was done to actually do our rollout).
We wanted to use it earlier (started looking at it back in the pre-1.0 days), but we didn't switch until 2006. Shortly after the 1.4 release.
Out of interest, why do you use multiple clients on the same working copy? Isn't that somewhat unusual?
Absolutely not unusual. I use both the SVN command line client and TortoiseSVN's client on my windows boxes.
TSVN is great for working with individual files and doing the normal tasks of updating a single directory, or checking in files, or doing diffs, browsing the repository, or looking at change logs. Basically, we use TSVN for all of the interactive grunt work that goes on during our normal working day.
The SVN command line client, OTOH, is great for scripted things. Like running "svn update" on all of my working copies at 2am overnight - so that I have the latest changes from everyone else when I start working in the morning. If anyone added huge bulky files to the repository yesterday, they get downloaded overnight without my having to wait. And it speeds things up the next day so that when I use TSVN update, odds are good that I'll already have the latest revisions on my hard disk.
The change in working copy also happened when SVN went from 1.3 to 1.4 - so it's not a new issue. We all had to wait for our tools to be compatible with 1.4 back then as well. I think there were also changes on server-side back then, so if the server spoke 1.4, you had to use a 1.4 client. But you could leave the server at 1.3 and use 1.4 clients (backwards compatible), and then upgrade the server to 1.4 once you were done with client upgrades.
For a more realistic take on hardware, I offer my gaming system: a 1680 * 1050 22" LCD (which is large, but not near as huge as a 30"), an 8800GT video card, and an E6300 processor.
That's nearly identical to my gaming setup, except I went with (2) 8800 GT 512MB cards in SLI mode and I'm running an AMD Athlon64 X2 5600+. Those 8800GT 512MB cards are probably the best bang for the buck at the moment (mine are 6 months old). It's a good kit, definitely medium-upper range, but you can build one for about $1000-$1500.
(I need a faster CPU... Oblivion is CPU-limited. *sigh* But I'm not sure I want to put a 125W beast into this box.)
The 22" 1680x1050 displays are a great size. Not overly large (a bit wider then a standard keyboard), with good resolution and size without paying a bundle. Unlike the 19" 1680x1050 displays, the pixels are still large enough on the 22" that you won't be squinting.
I'm sure I'll move up to the 24-25" 1900x1200 displays at some point...
My biggest beef with flash drives thus far is with the flimsy construction. I have owned three flash drives. The first was a 64 byte drive back in the day when that was sizeable. I think it was an Iomega drive. It was really tiny which is why I liked it. But after only about a dozen gentle insertions (no jokes please), it developed a crack in the housing which soon threatened to cause the whole device to fall apart. Iomega was kind enough to replace it for free (it was still under warrantly, less than 6 months old) with a 128 Megabyte version. That was drive #2. I think I lost that one.
Sandisk Cruzer Titanium - Which is a wonderful little USB flash drive that can take a beating. Mine has been hanging off a keyring for most of a year and is holding up very well. Great size, sleek form factor.
Patriot XPorter (PEF4G200USB) - Nice rubber shell. Not as sleek or handy as the little Cruzer, but suitable for daily wear and tear. Assuming you don't lose the rubber cap, this unit can probably take a heavy beating.
Frankly, there is no better choice then Jabber/XMPP.
Lots of server implementations, lots of clients, and it's an open protocol. And you (unless you choose to) have to track licenses or manage connection count limits or other such nonsense.
No they have not. Just because you've got crappy eyes doesn't mean the rest of us want to suffer through pixelated text.
I really wonder when was the last time you looked at one of the modern e-book readers? I'm not talking the first or second generation screens with either black/white or 2-bit greyscale.
I'm speaking of the 3rd generation screens which have 16(?) greyscale levels. Where, unless you break out a magnifying glass, you're not going to be able to identify individual pixels. The only way that I (or most people) is under 2x or 4x magnification.
If it was only 86-96 ppi, like most modern screens, you would be right. It would look horrid. But at 175 dpi, you'll be hard-pressed to see the individual pixels unless you have extremely above average vision. What matters more is the contrast ratio, which is better in the 3rd generation screens. The additional grayscale levels just make it easier to do a bit of unnoticeable anti-aliasing.
It's great that the resolution hurdle has been overcome.
Even the current 175dpi screens (greyscale) have overcome the resolution hurdle. I've had a Sony PRS-505 for about 6 months now, and it is excellent for reading fiction. A 300+ dpi screen would simply be icing on the cake.
I think readers will get more and more popular as they get the price farther below $280 and boost the resolution. And frankly, I think the price is the bigger issue that will determine how fast they get adopted.
I know that Google took it over and still makes Usenet content searchable, but a part of me pines for the simple days when it was Usenet that contained the useful technical information we needed, and when Dejanews was the best way to get to it.
Mmmm... I still miss CompuServe from the mid-late 80s. Prior to the mass adoption of the internet via dial-up in the early-90s.
Back then, nearly every hardware / software maker had a forum or at least a section of a forum on CIS. It was a moderated environment, with excellent message threading, and with TapCIS / Recon you could pull down the messages to read at your leisure. I spent a lot of $$$ pulling down software and messages from CIS.
USENET, by comparision, was spammy and noise-filled. Even in the early 90s.
Nowadays, USENET is nowhere near as spam filled, because most people have gone elsewhere. So there are a few useful groups out there. But there's still no good newsreaders (MicroPlanet's Gravity was the tops - Thunderbird is a poor replacement).
We had a huge number of orders from Alaska. I wondered why this was and checked out the orders. They were all mostly for 50 lb bags of dog food. And we offered free shipping. To Alaska. For 50 lb bags. I mentioned to someone that the shipping costs as much as the dog food. They stopped doing that.
That... right there... is how I used to figure out whether various internet only companies who were delivering products via UPS / FedEx / DHL / USPS were clued in. Did they offer free shipping? What was the size / weight / value of their product?
Hint: Large, heavy, low-value objects are not cheap to ship.
Delivery of things like $500 jewelry? Easy and you can probably make a profit in your S&H fees. Bigger, bulkier items, that consumers prefer to buy the cheap stuff? There was no way that pets.com was going to survive unless they drastically raised their S&H fees.
It makes me suspect that the people who came up with the idea probably lived in Manhattan or some other dense urban area. With no clue as to how rural and spread out much of the USA is. While I didn't live out in the middle of nowhere, I did at least work for UPS in a non-metro district where drivers had to travel 60-70 minutes just to get to the START of their delivery route.
Seriously, We are looking at setting up SVN for our source code management.
Basically, you need to decide how much you value distributed development (using git or the others like Hg) as opposed to more centralized SCM tools like Subversion.
For us, SVN is the natural fit when moving from VSS/SourceOffSite to something better. A centralized repository is a strong feature for us as it simplifies management, is easily understood by less technical end-users, and we don't do a lot of merging. Plus we work with a lot of binary files (50-200MB at times), which SVN handles very cleanly and efficiently. Our users pick up TortoiseSVN very quickly, and there are options such as WebDAV or other ways to access the repository.
(And merging is getting better treatment in the 1.5 revision of SVN which is due out any day now. The SVN team just notified the user base of Release Candidate #8 for v1.5 this week. There are more plans in 1.6 for continuing to improve merge functionality.)
Our major complaints with SVN are (mostly) being addressed in the upcoming 1.5 release.
Rebuild times scale up as the number of disks in the array increases. Which means that as you RAID5 over more disks, your recovery window (during which a 2nd failure will kill the array) grows increasingly larger.
Which also leads to issues that as the array rebuilds, it puts extra wear and tear on the other drives in the array (as it frantically attempts to recalculate parity bits for the new hot spare). Since your recovery window is a lot larger, and you're exercising all of the disks in the array to do the rebuild, your chance of a 2nd failure goes up.
Now, some (most?) of that is addressed with RAID6, which can handle a double-drive failure.
(Personally, I prefer RAID10, where the recovery window is based on the size of an individual drive and not the size of the array.)
Even though I'm a firm believer in normalization, there are specific cases where you will end up with 1000+ attributes for a single object/entity. Sure, you could refactor that into a single-many join into a new table, but that can often be unnecessarily complex.
For example, an entity with a few hundred attributes, all of which are of slightly different data types (some are single byte, some are 2-byte integers, some are varchar). To create a single-many sub-table to store those attributes, there are no clean solutions. Either you setup your sub-table with multiple fields of the different data types and then make a business rule that you can only write one of the multiple fields. Or else you create multiple sub-tables.
The first method burns a lot of extra disk space (4 or 8 bytes for the primary key plus the sizes of the unused data columns), the second method is ugly and overly complex (and still burns 4-8 bytes for the primary key for each attribute).
This becomes an even bigger issue when you're doing on-off projects where each project defines the entities out with wildly different sets of attributes. So you end up simply creating multiple tables, all with the same primary key, and spread the few hundred attributes across multiple tables. Which also makes a lot of types of reporting and filtering a whole lot simpler.
For example, show me the entities who matched attribute criteria X, Y and Z. Including those where attributes A+B+C added up to 42. Excluding those with attributes Q. Which is an easy query to write if all the attributes are in the same table (or view), but a real pain if you have to do sub-selects or pivot the table.
Limitations like 2048 bytes per row or the max # of fields in a table/query are definitely a PITA at times.
In summary, there are times when having lots and lots of fields is a valid design choice (the lesser of multiple evils).
I believe Edgar Dijkstra said it well: "Premature optimization is the root of all evil."
Pretty much spot-on. When designing / developing a system, you should work as fast as possible without doing anything stupid (like using a bubble sort). Get it working, make it faster later.
The art lies in knowing when to do which method (quick and dirty vs smart and efficient) so that you don't end up with something so slow as to be a project-killer.
What I like about SSDs is that you have multiple chips and only the interface is a single point of failure. So, it shouldn't be cost prohibitive to do RAID 5 inside the drive between multiple banks of Flash.
Still better to do RAID outside of the individual drives. It's a lot easier to replace whole drives when they fail rather then individual chips inside a drive.
Hitachi's perpendicular storage might increase density by 4 or 8 times, or more; imagine a 2TiB disk and then you have 8 or 16TiB.
Um... those 750GB and 1TB drives that have been selling for the last 12-18 months? Those are already using Perpendicular Recording. All of the Barracudas since 7200.10 are PR drives.
The expectation is that PR only gets you about a 4-5x increase in density over the older longitudinal recording. So if you could get a 500GB drive in the old days, that puts the upper limit at between 2-4TB down the road for a 3.5" form factor hard drive. Probably closer to 4TB theoretical if Seagate is able to finally ship a 2TB production drive.
And I'm betting, that like the OLD 500GB drives which had 4-6 platters in them, those 3-4TB drives will also end up with 4-6 platters inside. Which is a bad thing, because it means lots of energy required to spin them up along with increased heat generation.
(I'm not sure if there is anything past perpendicular recording in the pipeline. The old GMR technology never achieved its theoretical maximum either, or else we would have seen 1-2TB drives without the need to shift over to PR drives.)
Slashdot Mirror
The bigger question that comes to the forefront of my mind is:
For how much longer can Microsoft afford to re-invent Unix (badly), rather then starting to embrace and switch to open-source software for the underlying systems? Is it really in their investors' best interest to keep re-inventing the wheel?
Is the value of locking in customers to the Windows platform really worth what they're paying to write (poorly) operating systems like Vista?
Refurbishment makes sense for higher quality notebooks. My grab and go travel notebook is a loaded out (max memory, 80 gig HD) nearly 10 year old Compaq M300, it weighs in at 3.3 pounds has a magnesium case, and quality construction. The P3-500 is fast enough to browse the web, play youtube videos, and all that other basic stuff. Best yet I only have about $300 invested in it, so if it breaks I am not out much. Sure I could spend $1500 on a similared sized high quality replacement, but do I really need all those extra wasted clock cycles. And if I did spend $1500 on it, would I treat it like this grab and go, toss it around, leave it in the open in motel rooms while I am away, etc.
That pretty much covers it for me as well. I wouldn't pay to refurb a crappy consumer-level notebook, but and older Thinkpad is (almost) always worth upgrading. (The other issue is that any OEM software licenses are tied to the machine, so you'd have to repurchase that software unless you refurb. That's a cost that you need to factor into the decision.)
I ran a Toshiba Tecra 8100 into the ground recently. I bought it back in early 2002 and it was my main machine up until late 2007. Along the way, it had 3 hard drives, a new backlight, a new keyboard, new mouse buttons, and a new CD/DVD drive installed. Replacing the keyboard made it feel like a new machine for the last 18 months of its lifespan.
But after 5 1/2 years, it was definitely time for it to be put out to pasture. The single-core CPU made it very unresponsive at times. I think if it had a dual-core CPU, then I'd still be using it for at least one more year. But it was also blue-screening at random times when I'd take it into the office rather then leaving it sit on the dock at home.
You first need to decide whether you want a centralized model, like SVN, or a distributed model (git / mercurial / bzr?). And also consider tool support (SVN has very good tool support, others may not and require more hacking at a command line).
All of the products listed will handle 50 developers and 6 GB of source with no issues. Our biggest repository weighs in at 11GB with a few thousand revisions. Then we have repositories that are only 2GB, but with 50,000 revisions. Sometimes it's nice to have a monolithic repository (ease of use for less technical users), other times repositories for each project are better.
There are other advantages / disadvantages to each version control system.
You don't want to use svn with a large tree because it stores a second copy of only the revision you checked out (so that diffs are fast). Other systems like hg can typically store the entire repository, giving you access to all revisions, in less space (it's compressed) than svn can store just the working copy.
.svn folder for easy diffs. Which was designed to reduce the amount of server traffic. I'll agree that sometimes that's not always a good choice, but (for the most part) local disk space is inexpensive and the 2x space requirement on the local disk doesn't bother me.
.svn folder in the root of the working copy and nowhere else.
SVN works fine with large trees (whether that's measured as # of revisions, # of files, or # of bytes).
Yes, the working copy stores a "pristine" copy in the
There's been some talk about allowing the user to tell SVN (and tools built on top of the SVN libraries) that there may not always be a pristine local copy. The question, I think, is whether it could be done without breaking other design goals (the ability to be a WebDAV source comes to mind). Or without generating huge amounts of traffic (the anti-argument here is that if rsync can do it, svnserve should be able to).
I think there's also talk of putting the
But yes, I'm hoping that they'll switch to storing the pristine local copy in compressed format, which would save a good bit of space. I suspect the design was designed to be conservative with regards to beating on the CPU, and that there were a zillion other priorities to get working first. It's only been in the past year or two that I've seen more frequent mentions of improving the working copy design.
(Being able to have sparse checkouts will probably help us a lot with the local working copy size. It will at least make a dent in it.)
Ah, I forgot the most important part.
Your sample population needs to match the characteristics of the larger population. So if your larger population has a 55/45 split between the genders, make sure that you adjust your sample to be a 55/45 split as well if you want to make inferences based on gender.
That's an extremely small survey sample to try and draw relevant conclusions on. 30,000 might be a better indicator. Otherwise, you're talking too wide of a margin for error.
Like the others have said... a sample size of 30,000 doesn't necessarily get you more accuracy then a sample size of 3,000. Or at least, not enough additional accuracy that it's worth paying for. The other folks know the math better then me (I just do the IT support for the research eggheads), but the increase in accuracy falls off extremely rapidly for the first 500-1000 respondents.
Most researchers aim for response rates in the 500-1000 respondent range. Some go for larger sample size because there are sub-divisions within the study that they want to be able to draw conclusions about. Such as splitting the sample by gender / age / income and still having enough in each group to get valid results.
Sadly... reading slashdot to stay current isn't as useful as it was back in 2000-2004.
Back then, we had articles on different database systems, IDEs, different linux distros, with lots of commentary as to the details of why one might be better then another. Including specific tips or tricks of the trade or related tools. I used to struggle to find time in the evenings to read all of the informational articles and comments that were being posted. And I learned a hell of a lot in the process.
Now the articles with the biggest comment count are the "rile the masses" type articles. Or the ones with a heavy political bias.
When was the last time we saw an article discussing how to do hot-standby or clustering with linux/windows servers?
Damn kids, get the hell off of my lawn!
1) Networking with others is key. Try to maintain contact as much as possible with people at your old firm, especially anyone who is more technically inclined and is willing to answer questions. It's also a good way to find out what the new trends are and whether they are just flash-in-the-pan. That's one of the areas that I failed in when I moved from a really large company to the small company that I work for now. Which means that I've had to do a lot of the research myself.
2) Don't be afraid to cry "Uncle!" and hire someone on a short-term basis. Make sure that they show you their work so you can understand what they did. Black box systems are a no-no, as are consultants or support people who prefer to make their changes behind a curtain. As much as you may not want to be master of everything, in a smaller company you really need to become a jack-of-all-trades. Or at least be proficient enough to know when the staff or contact workers are blowing smoke up your ass.
3) Unless you absolutely hate reading (if so - you may be in the wrong job), try to read at least one technical book per month. And/Or take at least one 4 hour class per quarter. It keeps you in the game mentally and keeps you from ending up in a dead-end because you let all your skills get rusty. However you choose to do it - continuing education is key if you want to be self-reliant to a large degree.
I started working at my current firm about 8 years ago (and telecommuted for the first 7 years). There are still a few parts of the operation that aren't under my control (the PBX), but otherwise I have my finger on the pulse of everything else. I do a lot of experimenting on the side (it took 2 years for us to put Linux into production use). I work crazy hours some weeks. But, on the flip side, because it's a small company - I can set my own schedule to a very large degree. I'll gladly take flexibility, very little politics (I speak directly to the CEO and have the power to make purchases/decisions), and goal-oriented environment (make it work - keep the clients happy) and lower salary over being paid big bucks at a big firm.
The biggest tools that help me keep my sanity:
1) Nagios - or any other monitoring system. Knowing that something is broken before anyone else notices is a big advantage. You get a reputation for keeping the ship running smoothly without people having to scream to get something fixed. A lot of the people will think that you're psychic at times.
2) Wiki or Version Control System for internal documentation of systems. Network maps, rack layouts, what cable goes where on the back of a rack, pictures of equipment, etc. are very important. There are a lot of times where I've pulled up pictures of equipment in order to walk a regular employee at the office through restarting something (instead of having to drive in - or wait for a technical employee to be there). Get a good, small camera, and take lots of photos. Scratch notes on the back of a napkin and scan those in. Just have some sort of central location where your staff can look for information. I call it "just in case I (or you) get hit by a bus" documentation.
3) Automatic configuration change tracking. You can do this by hand, trying to track changes on an internal blog or a spreadsheet, or a text file, but automated tools are better. If you run Linux servers, use something like FSVS to shove all of your configuration files into a Subversion repository. That way, you can go back and look at what changes were made to the server along with why they were made. You can also do things like using rsync or looking through old backups, but I prefer to use an actual version control system designed for the purpose. Get your staff in the habit of using the tool when they make changes.
I suspect if we ever switch away from SVN, Mercurial is a strong contender.
But for us, we don't currently place a high value on distributed and decentralized. Mostly because it's easier to be constantly connected then it was 5 years ago, but also because our users are not especially technically inclined.
Getting them to understand update/check-in and keeping their local disk in sync with the server is challenging enough (even with TortoiseSVN).
The other strong selling point for us is the broad adoption of SVN across multiple platforms and that it works with a lot of different tools. Combine that with being actively developed and improved, and it's head and shoulders above what we used before.
(Note: We don't do a lot of branching and merging. We're more excited about sparse checkouts.)
Dude, SVN is ***EIGHT YEARS*** old. It is hardly the craze of the week.
Just one minor point of note, at least for our experience. It may be 8 years old, but it really wasn't suitable for our use until 1.3 (and we waited until 1.4 was done to actually do our rollout).
We wanted to use it earlier (started looking at it back in the pre-1.0 days), but we didn't switch until 2006. Shortly after the 1.4 release.
Out of interest, why do you use multiple clients on the same working copy? Isn't that somewhat unusual?
Absolutely not unusual. I use both the SVN command line client and TortoiseSVN's client on my windows boxes.
TSVN is great for working with individual files and doing the normal tasks of updating a single directory, or checking in files, or doing diffs, browsing the repository, or looking at change logs. Basically, we use TSVN for all of the interactive grunt work that goes on during our normal working day.
The SVN command line client, OTOH, is great for scripted things. Like running "svn update" on all of my working copies at 2am overnight - so that I have the latest changes from everyone else when I start working in the morning. If anyone added huge bulky files to the repository yesterday, they get downloaded overnight without my having to wait. And it speeds things up the next day so that when I use TSVN update, odds are good that I'll already have the latest revisions on my hard disk.
The change in working copy also happened when SVN went from 1.3 to 1.4 - so it's not a new issue. We all had to wait for our tools to be compatible with 1.4 back then as well. I think there were also changes on server-side back then, so if the server spoke 1.4, you had to use a 1.4 client. But you could leave the server at 1.3 and use 1.4 clients (backwards compatible), and then upgrade the server to 1.4 once you were done with client upgrades.
For a more realistic take on hardware, I offer my gaming system: a 1680 * 1050 22" LCD (which is large, but not near as huge as a 30"), an 8800GT video card, and an E6300 processor.
That's nearly identical to my gaming setup, except I went with (2) 8800 GT 512MB cards in SLI mode and I'm running an AMD Athlon64 X2 5600+. Those 8800GT 512MB cards are probably the best bang for the buck at the moment (mine are 6 months old). It's a good kit, definitely medium-upper range, but you can build one for about $1000-$1500.
(I need a faster CPU... Oblivion is CPU-limited. *sigh* But I'm not sure I want to put a 125W beast into this box.)
The 22" 1680x1050 displays are a great size. Not overly large (a bit wider then a standard keyboard), with good resolution and size without paying a bundle. Unlike the 19" 1680x1050 displays, the pixels are still large enough on the 22" that you won't be squinting.
I'm sure I'll move up to the 24-25" 1900x1200 displays at some point...
My biggest beef with flash drives thus far is with the flimsy construction. I have owned three flash drives. The first was a 64 byte drive back in the day when that was sizeable. I think it was an Iomega drive. It was really tiny which is why I liked it. But after only about a dozen gentle insertions (no jokes please), it developed a crack in the housing which soon threatened to cause the whole device to fall apart. Iomega was kind enough to replace it for free (it was still under warrantly, less than 6 months old) with a 128 Megabyte version. That was drive #2. I think I lost that one.
Sandisk Cruzer Titanium - Which is a wonderful little USB flash drive that can take a beating. Mine has been hanging off a keyring for most of a year and is holding up very well. Great size, sleek form factor.
Patriot XPorter (PEF4G200USB) - Nice rubber shell. Not as sleek or handy as the little Cruzer, but suitable for daily wear and tear. Assuming you don't lose the rubber cap, this unit can probably take a heavy beating.
Frankly, there is no better choice then Jabber/XMPP.
Lots of server implementations, lots of clients, and it's an open protocol. And you (unless you choose to) have to track licenses or manage connection count limits or other such nonsense.
No they have not. Just because you've got crappy eyes doesn't mean the rest of us want to suffer through pixelated text.
I really wonder when was the last time you looked at one of the modern e-book readers? I'm not talking the first or second generation screens with either black/white or 2-bit greyscale.
I'm speaking of the 3rd generation screens which have 16(?) greyscale levels. Where, unless you break out a magnifying glass, you're not going to be able to identify individual pixels. The only way that I (or most people) is under 2x or 4x magnification.
If it was only 86-96 ppi, like most modern screens, you would be right. It would look horrid. But at 175 dpi, you'll be hard-pressed to see the individual pixels unless you have extremely above average vision. What matters more is the contrast ratio, which is better in the 3rd generation screens. The additional grayscale levels just make it easier to do a bit of unnoticeable anti-aliasing.
It's great that the resolution hurdle has been overcome.
Even the current 175dpi screens (greyscale) have overcome the resolution hurdle. I've had a Sony PRS-505 for about 6 months now, and it is excellent for reading fiction. A 300+ dpi screen would simply be icing on the cake.
I think readers will get more and more popular as they get the price farther below $280 and boost the resolution. And frankly, I think the price is the bigger issue that will determine how fast they get adopted.
(Goes back to reading on his Sony Reader...)
Take whatever resolution you currently have on a full-color LCD, and triple it for each axis. There's your mono rez.
Not quite. Typically the dots on a LCD screen are arranged as a 2x2 grid (blue, green, red, with doubled up of one of the colors... green?).
So if you were only doing greyscale pixels, you could get approximately double today's LCD resolution (so around 250-260ppi).
I know that Google took it over and still makes Usenet content searchable, but a part of me pines for the simple days when it was Usenet that contained the useful technical information we needed, and when Dejanews was the best way to get to it.
Mmmm... I still miss CompuServe from the mid-late 80s. Prior to the mass adoption of the internet via dial-up in the early-90s.
Back then, nearly every hardware / software maker had a forum or at least a section of a forum on CIS. It was a moderated environment, with excellent message threading, and with TapCIS / Recon you could pull down the messages to read at your leisure. I spent a lot of $$$ pulling down software and messages from CIS.
USENET, by comparision, was spammy and noise-filled. Even in the early 90s.
Nowadays, USENET is nowhere near as spam filled, because most people have gone elsewhere. So there are a few useful groups out there. But there's still no good newsreaders (MicroPlanet's Gravity was the tops - Thunderbird is a poor replacement).
We had a huge number of orders from Alaska. I wondered why this was and checked out the orders. They were all mostly for 50 lb bags of dog food. And we offered free shipping. To Alaska. For 50 lb bags. I mentioned to someone that the shipping costs as much as the dog food. They stopped doing that.
That... right there... is how I used to figure out whether various internet only companies who were delivering products via UPS / FedEx / DHL / USPS were clued in. Did they offer free shipping? What was the size / weight / value of their product?
Hint: Large, heavy, low-value objects are not cheap to ship.
Delivery of things like $500 jewelry? Easy and you can probably make a profit in your S&H fees. Bigger, bulkier items, that consumers prefer to buy the cheap stuff? There was no way that pets.com was going to survive unless they drastically raised their S&H fees.
It makes me suspect that the people who came up with the idea probably lived in Manhattan or some other dense urban area. With no clue as to how rural and spread out much of the USA is. While I didn't live out in the middle of nowhere, I did at least work for UPS in a non-metro district where drivers had to travel 60-70 minutes just to get to the START of their delivery route.
such as what?
Seriously, We are looking at setting up SVN for our source code management.
Basically, you need to decide how much you value distributed development (using git or the others like Hg) as opposed to more centralized SCM tools like Subversion.
For us, SVN is the natural fit when moving from VSS/SourceOffSite to something better. A centralized repository is a strong feature for us as it simplifies management, is easily understood by less technical end-users, and we don't do a lot of merging. Plus we work with a lot of binary files (50-200MB at times), which SVN handles very cleanly and efficiently. Our users pick up TortoiseSVN very quickly, and there are options such as WebDAV or other ways to access the repository.
(And merging is getting better treatment in the 1.5 revision of SVN which is due out any day now. The SVN team just notified the user base of Release Candidate #8 for v1.5 this week. There are more plans in 1.6 for continuing to improve merge functionality.)
Our major complaints with SVN are (mostly) being addressed in the upcoming 1.5 release.
The bigger issue with RAID5:
Rebuild times scale up as the number of disks in the array increases. Which means that as you RAID5 over more disks, your recovery window (during which a 2nd failure will kill the array) grows increasingly larger.
Which also leads to issues that as the array rebuilds, it puts extra wear and tear on the other drives in the array (as it frantically attempts to recalculate parity bits for the new hot spare). Since your recovery window is a lot larger, and you're exercising all of the disks in the array to do the rebuild, your chance of a 2nd failure goes up.
Now, some (most?) of that is addressed with RAID6, which can handle a double-drive failure.
(Personally, I prefer RAID10, where the recovery window is based on the size of an individual drive and not the size of the array.)
Even though I'm a firm believer in normalization, there are specific cases where you will end up with 1000+ attributes for a single object/entity. Sure, you could refactor that into a single-many join into a new table, but that can often be unnecessarily complex.
For example, an entity with a few hundred attributes, all of which are of slightly different data types (some are single byte, some are 2-byte integers, some are varchar). To create a single-many sub-table to store those attributes, there are no clean solutions. Either you setup your sub-table with multiple fields of the different data types and then make a business rule that you can only write one of the multiple fields. Or else you create multiple sub-tables.
The first method burns a lot of extra disk space (4 or 8 bytes for the primary key plus the sizes of the unused data columns), the second method is ugly and overly complex (and still burns 4-8 bytes for the primary key for each attribute).
This becomes an even bigger issue when you're doing on-off projects where each project defines the entities out with wildly different sets of attributes. So you end up simply creating multiple tables, all with the same primary key, and spread the few hundred attributes across multiple tables. Which also makes a lot of types of reporting and filtering a whole lot simpler.
For example, show me the entities who matched attribute criteria X, Y and Z. Including those where attributes A+B+C added up to 42. Excluding those with attributes Q. Which is an easy query to write if all the attributes are in the same table (or view), but a real pain if you have to do sub-selects or pivot the table.
Limitations like 2048 bytes per row or the max # of fields in a table/query are definitely a PITA at times.
In summary, there are times when having lots and lots of fields is a valid design choice (the lesser of multiple evils).
I believe Edgar Dijkstra said it well: "Premature optimization is the root of all evil."
Pretty much spot-on. When designing / developing a system, you should work as fast as possible without doing anything stupid (like using a bubble sort). Get it working, make it faster later.
The art lies in knowing when to do which method (quick and dirty vs smart and efficient) so that you don't end up with something so slow as to be a project-killer.
What I like about SSDs is that you have multiple chips and only the interface is a single point of failure. So, it shouldn't be cost prohibitive to do RAID 5 inside the drive between multiple banks of Flash.
Still better to do RAID outside of the individual drives. It's a lot easier to replace whole drives when they fail rather then individual chips inside a drive.
Hitachi's perpendicular storage might increase density by 4 or 8 times, or more; imagine a 2TiB disk and then you have 8 or 16TiB.
Um... those 750GB and 1TB drives that have been selling for the last 12-18 months? Those are already using Perpendicular Recording. All of the Barracudas since 7200.10 are PR drives.
The expectation is that PR only gets you about a 4-5x increase in density over the older longitudinal recording. So if you could get a 500GB drive in the old days, that puts the upper limit at between 2-4TB down the road for a 3.5" form factor hard drive. Probably closer to 4TB theoretical if Seagate is able to finally ship a 2TB production drive.
And I'm betting, that like the OLD 500GB drives which had 4-6 platters in them, those 3-4TB drives will also end up with 4-6 platters inside. Which is a bad thing, because it means lots of energy required to spin them up along with increased heat generation.
(I'm not sure if there is anything past perpendicular recording in the pipeline. The old GMR technology never achieved its theoretical maximum either, or else we would have seen 1-2TB drives without the need to shift over to PR drives.)