You obviously have never done ANY sort of high availability clustering. This is an extraordinarily common and important concept that many people pay LOTS of money to get. Veritas Cluster File System (and the other components of the Veritas Cluster suite) do exactly this (and more) at a serious premium.
This is the way people with real uptime requirements do it. I know, because I've got systems that do this, and I've interviewed I can't tell you how many sysadmin candidates with the same experience.
As for networking, your points are all completely wrong and irrelevant for serious high performance, high availability applications. Ethernet has far too high an overhead (at least with any commonly available file service protocols. iSCSI *might* change all that, but it remains to be seen), scalability at the # of transactions per second IS LOWER over these protocols, and LAN parties aren't any kind of interest for people running serious databases.
As for why you think it's a bad idea, all of them are what the various software packages out there are for. I won't get into the IDE v. SCSI v. FireWire argument.
Please, stop assuming the desktop is where computing ends. It isn't.
...stay out of the data center. While I can't backup with studies, or any hard scientific evidence, I can support that with experience. A real server room will have hot spots, sometimes 20+ degrees over the mean temperature the room (especially poorly ventilated ones. Big ACs don't equal good ventilation, btw.)
These hot spots can (and are often) murder for server farms. Take a page from the experts (i.e. big colo firms): keep your data center cold, and have lots of airflow near the racks.
This isn't necessarily always true, and a small data center can probably afford to not be frigid. But if you've got a lot of money in your data center which would you prefer: big, expenive AC bills or more expensive outages on very expensive hardware?
you are doomed to repeat it. Very few people remember that in the 80s (or was it early 90s) Apple sued MS over the Windows interface, among other things, because it too closely resembled mac. Then there were the suits over the Lotus 123 interface ripping off (I think) SuperCalc.
The courts decided back then that a UI is not something that can be copyrighted. They claimed it'd be like copyrighting the interface to a car, and thus would be bad for the industry.
But, then again, that was eons ago.
(I'd have to go digging to find links for this, but I'm sure there are duly motivated people who will research this and/or correct my flawed memory.)
I like and use perforce. It's a great system, and there are mac clients (both OS X and otherwise) although those come with some extra restrictions (on file names and the like, due to mac platform issues.)
However, it's not cheap. It's about US$600-700 per user to start and goes down as you add more users. It's worth it, but if you can't afford it...
Subversion promises to be good, but it isn't there yet and I don't know if their client runs on windows or mac (or if there are any plans to port).
There's a host of others, but I'm not familiar with them and thus won't comment.
I used sawfish for a long time. It's not a bad window manager by any stretch of the imagination. However it has the following obvious flaws:
1) Heavily lisp based. This is a great thing for lipsers (emacs lovers, especially.) but it doesn't make it light. Trust me, sawfish is not nearly as efficient as the less configurable WMs written in compiled languages. It does, however, make it flexible.
2) No longer maintained by John Harper
3) Flaky here and there. I had lots of problems with windows "randomly" moving themselves and the like.
4) Too configurable. Someone else said it best, who wants to configure the %age from the left bezel that your pointer warps to? There are people who say they want it BUT the wmx mantra reigns supreme: "Most people can get used to either." (admittedly the quote is in the context of sloppy foucs versus click to focus.)
5) Poor understanding of its base language. This is related to #1, but the fact of the matter is most people are not comfortable with Lisp. This may seem cruel and unfair to LISP lovers, but if your talent pool is shallow, then your bug pool will be deep. And there is almost nothing worse than a flaky window manager.
I think sawfish has a place, and it's definitely got a great community. But, I am anxiously awaiting metacity's evolution for the reasons above and others.
In opening, what is wrong with CVS? If it's such a big piece of shit, where are CVS' authors to address the problem?
Well, for one, some of CVS's "authors" (karl fogel is a big name in CVS circles) are the very same people that started subversion to solve CVS's problems. There are a number.
The biggest 3 problems, in my experience, with CVS are binary files, [lack of] atomic commits, and branching.
Binary files, for better or for worse, get checked in all the time. Having to tell CVS that it's a binary file (and having it hose the binary if you forget) is a PITA. It's much better to assume everything that isn't immediately recognizable as text is a binary. (this is what perforce and subversion try to do, and they both do a good job from what I've seen.)
Anyone who's ever done CVS style branches and then tried doing it the way perforce and subversion do it will tell you that the latter is far preferable. If you aren't familiar, perforce and subversion both work by doing brances as lazy copies (with history pointers) in the filesystem namespace. This make life easier. It also simplifies file revision #'s.
Atomic commits aren't a big deal when there's only one developer (or one developer per given piece of code.) But as soon as several people start developing it can get messy. With atomic commits, since an entire set of changes succeeds or fails, you eliminate the hassle of corrupted code for the most part.
I, for one, really like perforce and can't wait for subversion to be released. It looks to have the best of both worlds.
In all honesty, I've been hearing and reading this particular myth since the early 90s when I was looking into mathematics as a potential career. While it may finally be coming true, I'd recommend remaining skeptical.
(My favorite example was the text for my sociology course stating this almost verbatim. The book was copyright 1995 or there abouts.)
is get a job as a mathematician. I speak from experience. I graduated Magna Cum Laude with distinction in 2000 from Boston University with a degree in mathematics (I also received the College Prize in mathematics.) Further, I was awarded a full scholarship to Brown University to study mathematics as a Phd student.
I attended Brown for a semester, and had to leave. (I had grown weary of certain distasteful aspects of the field, and subsequently could not commit to the level of effort required of a grad student. It's a shame really, because I understood most of the material and it was truly beautiful.)
Mathematics is an intensely rigorous, very narrow-minded and extraordinarily challenging field. It is also extremely isolating, and highly distancing. At the same time is in incredibly fascinating and richly (intellectually) rewarding.
However the job outlook for mathematicians is not good last I looked. Old faculty have been "about to retire" for the better part of a decade and only in very recent years has there been anything like a good year for academic hiring. Both BU and Brown (which are both considered Tier 1 Private Universities for mathematics by the AMS last time I checked) had several extremely talented grad students who were on repeated post docs because they couldn't find positions at other universities.
I won't go into my personal philosophical differences with how mathematical research is done today, as that would be more biased than the above diatribe, but I will tell you what is right with the field. First off, given the above, the field generally rewards extremely talented and diligent members of its community. If you work very hard and are incredibly brilliant then the job market (more than likely) won't matter. (this is of course, assuming you can avoid getting embroiled in the math.) In my personal experience talent can even get you past the politics. (I've seen professors express loathing for certain other faculty but at the same time give them respect for the quality of their work.)
I guess what I'm trying to say is that if you truly love the field and if the people around you (your teachers and mentors) think you have what it takes then go for it. The worst case scenario is that you end up with an undergrad degree in mathematics and have to go get a job. Math students are very highly prized in the technical job market as they have excellent thinking, reasoning and analytical skills. They also tend to be ruthlessly efficient. (okay, that last bit was blatant self-promotion, shoot me.)
It's by no means an easy feat, but the following should probably get you there.
First, you need to consider how the data is getting to your backup server. This looks like a job for gig-e. (since you don't really want to run you DBs on the same machine as your backup server.) You should use multiple streams. (either break it into multiple smaller jobs or enable the multiple streams option in your backup software if it has one. Many do.) It's hard to flood even a 10base network with a single TCP/IP connection. (your bandwidth utilization decreases in inverse proportion with your latency. I forget the exact formula though.)
Next there's how you're getting it to tape. I recommend running the backups to disk first if you can. This means you won't stall a network connection if you change tapes, or the like. But it does mean you need a lot of storage on the bkup server. Also, if that's a 2h from DB to tape window, this might not be useful. However, barring using a SAN and snapshots (or the like) your only other option is to go straight to tape.
To go straight to tape you'll need at least 6 DLT drives, assuming you can keep the tape streaming and get 6Mbytes/s, and you balance them across a wide enough SCSI and PCI bus(or whatever system bus you choose) This will give you N+1 redundancy and meet your bandwidth requirement of 28Mbytes/s.
As for the LTO/DLT trade off. We're moving to an LTO solution where I work, and it generally seems to be the way to go. It's worth evaluating, but I don't think your choice of tape either way should be your restricting factor. And there is something to be said for the reliability of DLT.
You're of course overlooking the other reason people in the high-end do RAID 0+1 (as it's called): performance. RAID5 relies on the storage of parity to disk. Computing that parity (whether in hardware or software) takes CPU. This typically makes RAID5 arrays slower for read and write than a mirror or a stripe. Now if you build a stripe of mirrored drives... You get serious capability. Writes are massively fast (writing across multiple spindles.) Reads are also faster as you have 2 spindles to pull from.
We use this on our DB servers whenever performancs is critical. It's just amazing the throughput you can get.
But,somehow, I don't see myself affording several Sun D1Ks for my home server.
Back a few years ago there was a pretty famous article detailing how an admin at Cisco had implemented samba as the print infrastructure at all of cisco (and detailed some of the advantages and problems to it, as well as the problems inherent in the SMB protocol.)
Apparently it worked really well. You might want to try googling around for it. It's a pretty good read, but I can't remember who published it. I'm fairly certain it was one of the Linux only webzines though.
For me, it's sort of a bred-in response. I grew up around computers (learned BASIC at 6, C at 13, C++ at 15, and a whole slew of others later.) I studied math in college. But I adminned a couple research labs as a student job. My initial exposure came through Linux, like most people these days. It was cheap, available and it ran on my PC.
After that, I dropped out of grad school, and found a job. My years of experience doing it for research labs gave me a great foothold, and I was able to prove I knew my stuff.
Technical degrees and experience help - but if you need to break in, look to education and small shops.
I'm not sure physical link status is enough. In a failure you may not lose link (which is a purely electrical phenomenon) but you may lose network connectivity. It's definitely a good criterion, but I sure wouldn't rely on it as my sole means of detection.
That being said it would hurt to detect physical link failure, but I wouldn't rely on it as a single method. Also, realize that if you lose link, you should at the very least experience persistent packet loss. And that's a sure sign of a failure somewhere. (it'd be nice if the kernel could be configured to return Dest. Unreachable messages if link was down, but alas...)
Do a search on freshmeat.net for apd. (the alternate pathing daemon.) I'm using it quite successfully on linux and solaris 7 (in test bed only right now though). It's not bad.
It's unlikely that any digital conversion device(s) would be able to handle the input from 1000+ cameras and then be able to get that data to a central storage location through a local network.... the bandwidth needed for something like that would be incredible (90 MB/s ??), perhaps even requiring it's own seperate gigabit fibre network. Even in a high-end server with several devices connected to it you'd be lucky to capture 20fps.
You're thinking too centrally. Each camera (in a setup such as this) is likely distributed. The cameras can likely be grouped into clusters with a local digitizing system for each. These can transmit back to a central server for archival via a standard switched 100MB/s network (since the total aggregate bandwidth is 90MB/s, the local nodes can't reach that.) Assuming 10 cluster distributed homogeneously, you get 9MB/s from client to server. You still have to deal with the aggregate bandwidth at the server, but the network is no longer clogged (most switches have backbones around 12Gbps+). I'd go with either fiber Gig-E to the server, or channel bonded Fast Ethernet (4 channels should do it, yielding 400MB/s local bandwidth at the server.)
But if you were able to get it done, storage options would probably consist of some type of RAID array (with a HUGE number of disks to be able to hold 8TB/day).
Storing that much data indefinately would require enormous rooms dedicated to storage devices, which may not be feasible. Storing data for a week or even a month would be a challenge in itself.
Not really. Rooms dedicated to tape archival maybe. But for the most part it could be done with several large tape cabinets and off-site storage for tapes older than about 5 days.
A suitably large DLT library with a fairly large number of drives would probably do this. Couple it with some HSM (Hierarchical Storage Management software) and you're probably all set.
In terms of sizing, assuming you get 6MB/s per DLT drive, you'll need at least 15 drives. Go for 20. This gives you room to do cutovers, and the like. I'd recommend fronting this with a LARGE disk for scratch space (preferably solid state, but if that's not in the budget, a big old SCSI disk'll do.) You'll need a pretty hefty server to handle all this (at least a pair of Sun E450s for redundancy). You'll also chew through at least 200 tapes a day at a native capacity of 40G/tape.
HOWEVER, this is by no means cheap. The virtue of the fact that you're talking about 8 terabytes a day should be a clue to that. The sort of tape archive, tape supply, and tape library you'll need is... vast. You're talking very high-end hardware here. You'll need a good cataloging system, and some serious software to maintain all this. You'll need to keep about 75% of your drives streaming all day every day. Tape costs alone will run to about 10k/day, let alone electricity, storage, maintenance and initial outlay. I'd venture a project like this is probably a $15 million dollar outlay to do it right, with at least 2 full time support staff and budget on the order of $40k/day . But if you've got the money, go for it.
If apple sues they are on some mighty thin legal ice. Maybe a lot of you don't remember these law suits, but Microsoft was sued by Apple in the 80s (or was it early 90s) for emulating the Mac Look&Feel too closely. There was also a lawsuit about this with regard to spreadsheets (lotus and excel if I recall correctly). The courts ruled in both cases that a look&feel (i.e. an interface) is not a copyrightable or otherwise protectable asset. It'd be liking a car company protecting where the shifter and steering wheel go in a car.
Since Apple has already lost at least one law suit in this exact arena, they can sue all they want. Unless they can prove that their actually intellectual property was stolen (i.e. their images used directly without permission) then they'll have a tough case ahead of them. A judge may even dismiss the case imeediately due to lack of merit (although IANAL, I just do a lot of reading.)
In most cases these Mac OSX like themes have committed 1 of 2 crimes: Using apple images or using apple names. Liquid doesn't appear to do either. Which means apple would have one hell of a time fighting it legally.
About 18 months ago a couple friends of mine went on tour with an industrial band (as supporting members) in Germany. (Which is one of few places industrial bands can actually make money... but I digress.)
They brought back with them moorhuhn. A sickeningly catchy and amazingly addictive little game. The whole premise is to blow this bird out of the sky with a gun. There's even a music video and a song. My friend has the CD and I have to admit it is catchy.
Apparently in Germany Moorhuhn was (if it isn't any longer I can't say.) a major hit. It's quite the pop phenomenon. And it's definitely worth playing at least twice.
(Note: all of the below refers to servers from the Dell product line. It's what I use, because it's what my company buys. Other vendors are just as suitable, for the most part)
Hmm... I'd say no. We have a cluster of 8 quads, plus a bunch of smaller, older duals. They're beautiful clusters, but I'd rather have dual processor machines. Here's why:
1) A quad processor box is 4U of rackspace. I've never seen one smaller. They may be larger still.
2) I can buy a 1U dual processor box. This means 2x the CPU per Unit of rack. Hence greater compute density.
3) A quad processor box has greater bus contention than a dual.
4) If you lose a node, you lose a larger chunk of processing power, and it costs more to replace.
In my mind the ideal node size, at least with commodity hardware, is dual. (If you start talking really custom gear, then it's another story entirely...) However, YMMV.
Quite a bit actually. BSD used to tout the vast superioirty of their TCP stack over Linux. That's less true today than it once was. BSD folks love (loved?) to tout the superiority of ipf over ipfwadm and ipchains (rightly so), but I think iptables (new for 2.4) has it pretty well matched.
You'd need to read the linux-kernel mailing
list archives for a while to realize there's actually a fair amount of synergy going on there, and the core developers do occassionally discuss.
A while back, as another example, BSD analyzed Linux's VM system (and criticized as well as complimented it where necessary). A lot of those criticisms were taken to heart.
As for Hurd... I don't know enough about Hurd to tell you whether it even contributes to the community with new, interesting ideas. And darwin is just FreeBSD with apple sauce.
This is troubling. Considering that the biodiversity when this bacterium evolved, and the
environment it was adapted to, there is NO telling
what would/will happen if/when it gets released
into our ecosystem.
Imagine all the problems introducing foreign
specieis into ecosystems has caused. cats, dogs
and pigs made the dodo extinct. Who knows, maybe
ancient bacteria will make us extinct.
Please, you're killing me!! This is the funniest thing I've read all day. The idea of a single configuration file for an entire OS is ludicrous. What happens if you corrupt one tiny portion? Do you really want your FTP and NFS servers to fail because you mistyped (or somehow fscked up) the VirtualHost directives for your web server? Do you want your email delivery to fail because you mis-spelled a module name?
Further, the registry is the single largest cause of problems in Windows, in my experience. What happens when you screw up your registry? Well, unless you really know your Windows (and most people don't) or were fortunate to have a backup copy of the registry just lying around, it's reinstall time. Hell, half the NT admins I know encourage a reinstall even in the above cases.
Please, read Linux-Kernel, there was a thread about this a few months ago IIRC, and why it's such a bad idea. I like my many config files. Now what would be GOOD is a common configuration grammar. Until then, I'll keep making money as a UNIX admin.
Being an experienced admin, I've seen what simple DOS's can do. There's no such thing as standing up to a DDOS, otherwise it wouldn't be one. Think about it this way: if CNN.com, aol.com, amazon.com and others, all with clearly professional admin staffs, got taken down my one, can we really expect slashdot to fare much better?
Slashdot Mirror
You obviously have never done ANY sort of high availability clustering. This is an extraordinarily common and important concept that many people pay LOTS of money to get. Veritas Cluster File System (and the other components of the Veritas Cluster suite) do exactly this (and more) at a serious premium.
This is the way people with real uptime requirements do it. I know, because I've got systems that do this, and I've interviewed I can't tell you how many sysadmin candidates with the same experience.
As for networking, your points are all completely wrong and irrelevant for serious high performance, high availability applications. Ethernet has far too high an overhead (at least with any commonly available file service protocols. iSCSI *might* change all that, but it remains to be seen), scalability at the # of transactions per second IS LOWER over these protocols, and LAN parties aren't any kind of interest for people running serious databases.
As for why you think it's a bad idea, all of them are what the various software packages out there are for. I won't get into the IDE v. SCSI v. FireWire argument.
Please, stop assuming the desktop is where computing ends. It isn't.
...stay out of the data center. While I can't backup with studies, or any hard scientific evidence, I can support that with experience. A real server room will have hot spots, sometimes 20+ degrees over the mean temperature the room (especially poorly ventilated ones. Big ACs don't equal good ventilation, btw.)
These hot spots can (and are often) murder for server farms. Take a page from the experts (i.e. big colo firms): keep your data center cold, and have lots of airflow near the racks.
This isn't necessarily always true, and a small data center can probably afford to not be frigid. But if you've got a lot of money in your data center which would you prefer: big, expenive AC bills or more expensive outages on very expensive hardware?
you are doomed to repeat it. Very few people remember that in the 80s (or was it early 90s) Apple sued MS over the Windows interface, among other things, because it too closely resembled mac. Then there were the suits over the Lotus 123 interface ripping off (I think) SuperCalc.
The courts decided back then that a UI is not something that can be copyrighted. They claimed it'd be like copyrighting the interface to a car, and thus would be bad for the industry.
But, then again, that was eons ago.
(I'd have to go digging to find links for this, but I'm sure there are duly motivated people who will research this and/or correct my flawed memory.)
I like and use perforce. It's a great system, and there are mac clients (both OS X and otherwise) although those come with some extra restrictions (on file names and the like, due to mac platform issues.)
However, it's not cheap. It's about US$600-700 per user to start and goes down as you add more users. It's worth it, but if you can't afford it...
Subversion promises to be good, but it isn't there yet and I don't know if their client runs on windows or mac (or if there are any plans to port).
There's a host of others, but I'm not familiar with them and thus won't comment.
I used sawfish for a long time. It's not a bad window manager by any stretch of the imagination. However it has the following obvious flaws:
1) Heavily lisp based. This is a great thing for lipsers (emacs lovers, especially.) but it doesn't make it light. Trust me, sawfish is not nearly as efficient as the less configurable WMs written in compiled languages. It does, however, make it flexible.
2) No longer maintained by John Harper
3) Flaky here and there. I had lots of problems with windows "randomly" moving themselves and the like.
4) Too configurable. Someone else said it best, who wants to configure the %age from the left bezel that your pointer warps to? There are people who say they want it BUT the wmx mantra reigns supreme: "Most people can get used to either." (admittedly the quote is in the context of sloppy foucs versus click to focus.)
5) Poor understanding of its base language. This is related to #1, but the fact of the matter is most people are not comfortable with Lisp. This may seem cruel and unfair to LISP lovers, but if your talent pool is shallow, then your bug pool will be deep. And there is almost nothing worse than a flaky window manager.
I think sawfish has a place, and it's definitely got a great community. But, I am anxiously awaiting metacity's evolution for the reasons above and others.
You can't. The 2nd law of thermodynamics forbids it.
Well, for one, some of CVS's "authors" (karl fogel is a big name in CVS circles) are the very same people that started subversion to solve CVS's problems. There are a number.
The biggest 3 problems, in my experience, with CVS are binary files, [lack of] atomic commits, and branching.
Binary files, for better or for worse, get checked in all the time. Having to tell CVS that it's a binary file (and having it hose the binary if you forget) is a PITA. It's much better to assume everything that isn't immediately recognizable as text is a binary. (this is what perforce and subversion try to do, and they both do a good job from what I've seen.)
Anyone who's ever done CVS style branches and then tried doing it the way perforce and subversion do it will tell you that the latter is far preferable. If you aren't familiar, perforce and subversion both work by doing brances as lazy copies (with history pointers) in the filesystem namespace. This make life easier. It also simplifies file revision #'s.
Atomic commits aren't a big deal when there's only one developer (or one developer per given piece of code.) But as soon as several people start developing it can get messy. With atomic commits, since an entire set of changes succeeds or fails, you eliminate the hassle of corrupted code for the most part.
I, for one, really like perforce and can't wait for subversion to be released. It looks to have the best of both worlds.
In all honesty, I've been hearing and reading this particular myth since the early 90s when I was looking into mathematics as a potential career. While it may finally be coming true, I'd recommend remaining skeptical.
(My favorite example was the text for my sociology course stating this almost verbatim. The book was copyright 1995 or there abouts.)
is get a job as a mathematician. I speak from experience. I graduated Magna Cum Laude with distinction in 2000 from Boston University with a degree in mathematics (I also received the College Prize in mathematics.) Further, I was awarded a full scholarship to Brown University to study mathematics as a Phd student.
I attended Brown for a semester, and had to leave.
(I had grown weary of certain distasteful aspects of the field, and subsequently could not commit to the level of effort required of a grad student. It's a shame really, because I understood most of the material and it was truly beautiful.)
Mathematics is an intensely rigorous, very narrow-minded and extraordinarily challenging field. It is also extremely isolating, and highly distancing. At the same time is in incredibly fascinating and richly (intellectually) rewarding.
However the job outlook for mathematicians is not good last I looked. Old faculty have been "about to retire" for the better part of a decade and only in very recent years has there been anything like a good year for academic hiring. Both BU and Brown (which are both considered Tier 1 Private Universities for mathematics by the AMS last time I checked) had several extremely talented grad students who were on repeated post docs because they couldn't find positions at other universities.
I won't go into my personal philosophical differences with how mathematical research is done today, as that would be more biased than the above diatribe, but I will tell you what is right with the field. First off, given the above, the field generally rewards extremely talented and diligent members of its community. If you work very hard and are incredibly brilliant then the job market (more than likely) won't matter. (this is of course, assuming you can avoid getting embroiled in the math.) In my personal experience talent can even get you past the politics. (I've seen professors express loathing for certain other faculty but at the same time give them respect for the quality of their work.)
I guess what I'm trying to say is that if you truly love the field and if the people around you (your teachers and mentors) think you have what it takes then go for it. The worst case scenario is that you end up with an undergrad degree in mathematics and have to go get a job. Math students are very highly prized in the technical job market as they have excellent thinking, reasoning and analytical skills. They also tend to be ruthlessly efficient. (okay, that last bit was blatant self-promotion, shoot me.)
It's by no means an easy feat, but the following should probably get you there.
First, you need to consider how the data is getting to your backup server. This looks like a job for gig-e. (since you don't really want to run you DBs on the same machine as your backup server.) You should use multiple streams. (either break it into multiple smaller jobs or enable the multiple streams option in your backup software if it has one. Many do.) It's hard to flood even a 10base network with a single TCP/IP connection. (your bandwidth utilization decreases in inverse proportion with your latency. I forget the exact formula though.)
Next there's how you're getting it to tape. I recommend running the backups to disk first if you can. This means you won't stall a network connection if you change tapes, or the like. But it does mean you need a lot of storage on the bkup server. Also, if that's a 2h from DB to tape window, this might not be useful. However, barring using a SAN and snapshots (or the like) your only other option is to go straight to tape.
To go straight to tape you'll need at least 6 DLT drives, assuming you can keep the tape streaming and get 6Mbytes/s, and you balance them across a wide enough SCSI and PCI bus(or whatever system bus you choose) This will give you N+1 redundancy and meet your bandwidth requirement of 28Mbytes/s.
As for the LTO/DLT trade off. We're moving to an LTO solution where I work, and it generally seems to be the way to go. It's worth evaluating, but I don't think your choice of tape either way should be your restricting factor. And there is something to be said for the reliability of DLT.
You're of course overlooking the other reason people in the high-end do RAID 0+1 (as it's called): performance. RAID5 relies on the storage of parity to disk. Computing that parity (whether in hardware or software) takes CPU. This typically makes RAID5 arrays slower for read and write than a mirror or a stripe. Now if you build a stripe of mirrored drives... You get serious capability. Writes are massively fast (writing across multiple spindles.) Reads are also faster as you have 2 spindles to pull from.
We use this on our DB servers whenever performancs is critical. It's just amazing the throughput you can get.
But,somehow, I don't see myself affording several Sun D1Ks for my home server.
Back a few years ago there was a pretty famous article detailing how an admin at Cisco had implemented samba as the print infrastructure at all of cisco (and detailed some of the advantages and problems to it, as well as the problems inherent in the SMB protocol.)
Apparently it worked really well. You might want to try googling around for it. It's a pretty good read, but I can't remember who published it. I'm fairly certain it was one of the Linux only webzines though.
For me, it's sort of a bred-in response. I grew up around computers (learned BASIC at 6, C at 13, C++ at 15, and a whole slew of others later.) I studied math in college. But I adminned a couple research labs as a student job. My initial exposure came through Linux, like most people these days. It was cheap, available and it ran on my PC.
After that, I dropped out of grad school, and found a job. My years of experience doing it for research labs gave me a great foothold, and I was able to prove I knew my stuff.
Technical degrees and experience help - but if you need to break in, look to education and small shops.
I'm not sure physical link status is enough. In a failure you may not lose link (which is a purely electrical phenomenon) but you may lose network connectivity. It's definitely a good criterion, but I sure wouldn't rely on it as my sole means of detection.
That being said it would hurt to detect physical link failure, but I wouldn't rely on it as a single method. Also, realize that if you lose link, you should at the very least experience persistent packet loss. And that's a sure sign of a failure somewhere. (it'd be nice if the kernel could be configured to return Dest. Unreachable messages if link was down, but alas...)
Do a search on freshmeat.net for apd. (the alternate pathing daemon.) I'm using it quite successfully on linux and solaris 7 (in test bed only right now though). It's not bad.
You're thinking too centrally. Each camera (in a setup such as this) is likely distributed. The cameras can likely be grouped into clusters with a local digitizing system for each. These can transmit back to a central server for archival via a standard switched 100MB/s network (since the total aggregate bandwidth is 90MB/s, the local nodes can't reach that.) Assuming 10 cluster distributed homogeneously, you get 9MB/s from client to server. You still have to deal with the aggregate bandwidth at the server, but the network is no longer clogged (most switches have backbones around 12Gbps+). I'd go with either fiber Gig-E to the server, or channel bonded Fast Ethernet (4 channels should do it, yielding 400MB/s local bandwidth at the server.)
Not really. Rooms dedicated to tape archival maybe. But for the most part it could be done with several large tape cabinets and off-site storage for tapes older than about 5 days.
A suitably large DLT library with a fairly large number of drives would probably do this. Couple it with some HSM (Hierarchical Storage Management software) and you're probably all set.
In terms of sizing, assuming you get 6MB/s per DLT drive, you'll need at least 15 drives. Go for 20. This gives you room to do cutovers, and the like. I'd recommend fronting this with a LARGE disk for scratch space (preferably solid state, but if that's not in the budget, a big old SCSI disk'll do.) You'll need a pretty hefty server to handle all this (at least a pair of Sun E450s for redundancy). You'll also chew through at least 200 tapes a day at a native capacity of 40G/tape.
HOWEVER, this is by no means cheap. The virtue of the fact that you're talking about 8 terabytes a day should be a clue to that. The sort of tape archive, tape supply, and tape library you'll need is... vast. You're talking very high-end hardware here. You'll need a good cataloging system, and some serious software to maintain all this. You'll need to keep about 75% of your drives streaming all day every day. Tape costs alone will run to about 10k/day, let alone electricity, storage, maintenance and initial outlay. I'd venture a project like this is probably a $15 million dollar outlay to do it right, with at least 2 full time support staff and budget on the order of $40k/day . But if you've got the money, go for it.
If apple sues they are on some mighty thin legal ice. Maybe a lot of you don't remember these law suits, but Microsoft was sued by Apple in the 80s (or was it early 90s) for emulating the Mac Look&Feel too closely. There was also a lawsuit about this with regard to spreadsheets (lotus and excel if I recall correctly). The courts ruled in both cases that a look&feel (i.e. an interface) is not a copyrightable or otherwise protectable asset. It'd be liking a car company protecting where the shifter and steering wheel go in a car.
Since Apple has already lost at least one law suit in this exact arena, they can sue all they want. Unless they can prove that their actually intellectual property was stolen (i.e. their images used directly without permission) then they'll have a tough case ahead of them. A judge may even dismiss the case imeediately due to lack of merit (although IANAL, I just do a lot of reading.)
In most cases these Mac OSX like themes have committed 1 of 2 crimes: Using apple images or using apple names. Liquid doesn't appear to do either. Which means apple would have one hell of a time fighting it legally.
About 18 months ago a couple friends of mine went on tour with an industrial band (as supporting members) in Germany. (Which is one of few places industrial bands can actually make money... but I digress.)
They brought back with them moorhuhn. A sickeningly catchy and amazingly addictive little game. The whole premise is to blow this bird out of the sky with a gun. There's even a music video and a song. My friend has the CD and I have to admit it is catchy.
Apparently in Germany Moorhuhn was (if it isn't any longer I can't say.) a major hit. It's quite the pop phenomenon. And it's definitely worth playing at least twice.
(Note: all of the below refers to servers from the Dell product line. It's what I use, because it's what my company buys. Other vendors are just as suitable, for the most part)
Hmm... I'd say no. We have a cluster of 8 quads, plus a bunch of smaller, older duals. They're beautiful clusters, but I'd rather have dual processor machines. Here's why:
1) A quad processor box is 4U of rackspace. I've never seen one smaller. They may be larger still.
2) I can buy a 1U dual processor box. This means 2x the CPU per Unit of rack. Hence greater compute density.
3) A quad processor box has greater bus contention than a dual.
4) If you lose a node, you lose a larger chunk of processing power, and it costs more to replace.
In my mind the ideal node size, at least with commodity hardware, is dual. (If you start talking really custom gear, then it's another story entirely...) However, YMMV.
Here's how I set it in /etc/profile on all my boxen:
/home/jeh/foo/bar/bletch)
/usr/local/lib/perl/5.6.1)
case $USER in
root)
PS1="(\# \u \h \w)\n>> "
;;
*)
PS1="(\# \u \h \w)\n> "
;;
esac
export PS1
This means that my prompt looks like this if I'm a user:
(1 jeh myhost
>
and as root
(1 root myhost
>>
So I can tell at a glance exactly who and where I am, and still have nearly a full screen width for commandline editing.
Quite a bit actually. BSD used to tout the vast superioirty of their TCP stack over Linux. That's less true today than it once was. BSD folks love (loved?) to tout the superiority of ipf over ipfwadm and ipchains (rightly so), but I think iptables (new for 2.4) has it pretty well matched.
You'd need to read the linux-kernel mailing list archives for a while to realize there's actually a fair amount of synergy going on there, and the core developers do occassionally discuss.
A while back, as another example, BSD analyzed Linux's VM system (and criticized as well as complimented it where necessary). A lot of those criticisms were taken to heart.
As for Hurd... I don't know enough about Hurd to tell you whether it even contributes to the community with new, interesting ideas. And darwin is just FreeBSD with apple sauce.
Imagine all the problems introducing foreign specieis into ecosystems has caused. cats, dogs and pigs made the dodo extinct. Who knows, maybe ancient bacteria will make us extinct.
Scary thought.
Further, the registry is the single largest cause of problems in Windows, in my experience. What happens when you screw up your registry? Well, unless you really know your Windows (and most people don't) or were fortunate to have a backup copy of the registry just lying around, it's reinstall time. Hell, half the NT admins I know encourage a reinstall even in the above cases.
Please, read Linux-Kernel, there was a thread about this a few months ago IIRC, and why it's such a bad idea. I like my many config files. Now what would be GOOD is a common configuration grammar. Until then, I'll keep making money as a UNIX admin.
I think not.