Yeah I agree that it doesn't look good. I've done a lot of Sun stuff in my time - they've always been my favorite among commercial unix vendors - but I think they've failed to respond to the situation Linux has presented them.
And yes, IBM Mainframes are truly fault-tolerant environments, where you can trust a "single machine" full of redundant internal components to not go down short of geographical disasters. I still think I'd rather acheive the same uptime with a cluster of smaller systems, but the IBM zSeries type things are looking very nice too.
IBM's salvation in the long run is that they've dealth with the Linux issue well.
I get $12,285 adding the FC card and making them 4G ram to make the numbers somewhat comparable again. Don't forget those are IIIi CPUs now with 1MB cache, which are a drop in horsepower over the previous config. For the matter at hand the Athlon will probably own them by a decent margin.
And the whole point of Penguin vs Sun is that if you're building a redundant cluster, individual system uptime starts not being worth the cost.
I assume by "direct attach" you mean a fiber loop between the nodes, which is basically the same thing. SAN is a buzzword to me, FCAL loops are just mini-SANs:) If the storage was really just direct to the individual host you wouldnt be able to make a OPS/RAC-ish styled cluster, and then you're back in the other world of "failover".
Oracle's stuff does scale very well though - although yes for some SQL statements having single-box horsepower matters. I generally think of transactional systems where each statement is small and the total volume of incoming statements is the problem.
In anycase, you should really check out the recent (10 days ago?) video oracle put out. www.oracle.com -> Linux -> "Merrill Lynch" link in the middle of the page. It's a "1 year later" report from an ML IT Exec - he discusses in very business terms how one year later their migration to linux/RAC based Oracle solutions has been "astounding". 100.00% uptime for the first year even through upgrades, at 5x the performance for 1/6th the cost - doing 100's of millions of transactions per day. It's about 15 minutes long, but it's a very good presentation.
I might add as a disclaimer that the 32 node figure was what I pulled outta my @$$ to compare with 2x6800's earlier. Now that I think about it, I've never actually built or seen a RAC cluster with that many nodes, so I don't know how practical that scaling is, or if it's even possible. In any case, if it were scaled down to 8 or 16 or whatever nodes, the percentage markup would remain the same, so the point it still valid even if the configuration might not be:)
You're right, it would be a better comparison to use 280s or 480s. Let me do some price shopping here and make a more precise comparison using that (note this is all retail - everyone offers discounts and programs and all):
SunFire 280R configured from store.sun.com with: 2x 1Ghz UltraSparc III Cu Dual 10K RPM internal FC drives 4GB RAM Built-in 10/100 Eth Addon Dual-Channel Fiber Channel interface Cost: $30,188
Penguin Computing Altus 140 2x Athlon MP 2600+ Dual 10K RPM internal SCSI drives 4GB RAM Built in Dual 10/100 Ethernet + JNI dual FC card (64/66 PCI) found on random reseller website ($2,066) Cost: $6,088
They're not exactly equivalent (what can be given the vast arch difference?), but they're close enough for comparison.
So for 32 nodes into this oracle cluster.. You've got $194,816 to do with Linux/x86, or $966,106 for the Sun way. That's about a 396% markup to get Sun/Solaris support - both solutions are equally reliable in the long run (in either case a node fails and you replace it at your leisure). When you consider that every 3 years or so at most you'll be replacing this setup with whatever's new at the time, doesn't it make sense to not take the 396% markup for Sun's name?:)
As before, the new Matrix will be all about kick ass action scenes and photography, and the plot will be like a comic book come to life. If you can suspend disbelief and zone into their comic book mindset, I'm sure the movie will be at least as good as the first.
I'm pretty sure Compaq and others already have hot-swap for cards, and support terabytes of storage (which is really just a matter of having enough FC bandwidth for whatever you're doing and plugging into the same standard storage arrays the Sun can).
Hot-swapping CPUs and RAM is trickier, but Sun only offers that on high end models which have no direct counterpart in the PC marketplace. Even then, it's a dicey situation at best.
With the E10K generation, you can hotswap CPU boards (there's 16 of them, each holding up to 4 processors, 4G ram, and two I/O busses (4x Sbus cards or 2x PCI cards). Thus you very much have to plan ahead to make sure you can "swap out" a given board without losing anything (oops, the failed memory is on the board with the only controller for this scsi disk over here, or the only one with this gigabit network connection). Assuming you built the machine right so that no single board is a single point of failure, you hit the next problem: If a CPU or memory module were to actually fail during runtime, it is still just as likely to cause an OS crash. The advantage is that in most cases the offending peice of hardware (1 CPU, 1 bank of RAM, etc) will be blacklisted and not used at all when the machine reboots from the panic (now you have a 15 CPU machine instead of 16). Then after that reboot, you can go about hot-swapping in a replacement with the OS online. You run some commands which basically tell the scheduler to stop scheduling on those CPUs, and tell the VM to not allocate any more physical ram in a certain region - then it goes about paging all the allocated RAM off to other ram or swap until it has emptied the board - then you can swap in the new stuff and re-add the CPU/mem into the OS.
On the newer SunFire architecture (3800s, 6800's, 15K, etc), they finally split the I/O boards from the CPU/Mem boards to make this a bit less painful, thank god. Still, in either case, you dont get a 4-way that scales to 64. You could buy a 64-capable machine (or higher now with SunFire architecture), and only populate it with 4 CPUs because you expect growth - but an E10K with just 4 CPUs in is a huge waste of cash - we're talking at least several hundred thousand dollars, for the hardware equivalent of what other companies sell for just a few thousand dollars. I think at one point a few years ago my company bought one 1/4 configured (16 CPU 16 GB ram) and left the other 3/4 open for expansion, and the cost was on the order of around $1,300,000. Do you really want to pay 50x+ over the same hardware capacity of a top end x86 just to be able to expand and have better support?
And in any case - these solutions, ultimately, may have slightly better sigma numbers on uptime, but they are still riddled with single points of failure, and ultimately no Sun solution is truly reliable with resorting to redundant clustering of oen sort or another. Once you resort to a redundant cluster, you're saying "I don't care if the hardware fails occasionally, my cluster will handle it while we do the maintenance". At that point, are you going to spend that much more money to make the difference between 99.9% and 99.999%?
Lets make a rough real example - a 24/7 Oracle database. In the Sun world, to get 24/7 uptime, you'd build out two machines of appropriate power (let's say 2x 6800s), and drop Oracle's OPS or RAC (or whatever they call the next generation) on it for a fully fault-tolerant cluster. You'd attach it to an FC SAN of appropriately configured redundant storage.
On the x86 side, you'd rack up the equivalent in I/O and CPU horsepower worth of 1U boxes (let's say 32x 1U dual processor large-ram crap-reliability boxes from Penguin Computing or something).
Either one is going to be very reliable because of Oracle's nonstop clustering stuff. You'll experience more failures/year on the x86 solution, but losing one of 32 machines is no biggie for a few hours while you drop in a spare.
Two fully loaded 6800's is gonna run you about $2.0 million. 32 high end-ish (lets say 10K a pop) 1U machines is gonna run you $0.32 million. You do the math.
I think people are blowing over the privacy issue wrt to parents. Let's face it, for one legally you don't get any privacy from your parents until you're of age. Two, these grades are *supposed* to beknown by parents. That's why they send home report cards, etc. It's not a matter of the grades being your private data your parents shouldn't know, it's a matter of the fact that most kids don't want their parents to see the grades and hide/alter them, and this is a way for parents to get back to the truth and know how their kids are doing.
You should be able to be open with your parents on a simple thing like your grades, and work through whatever issues that brings up. If you can't work through that with them, god help you on the more troubling aspects of teenage/parent relations.
The system is a good idea overall, and I think every school should be moving this way.
Now on the other hand, there's the issue of their completely lax security. 6/7 social digits plus 5 digits of last name is just too easy. Anyone can get that. This is a serious privacy concern. You have to fix it without making the system cumbersome for the parents though. Probably the only really reliable way would be to have the parents come up to the school and register for the site physically and get a real username/pass - that way the person setting them up can actually verify who they are. I don't think it's too mcuh to ask the parents to care enough to show up at school once in their lifetime to establish a password for something like this. There's probably more creative schemes involving snail-mailing randomly-generated security numbers to parents' mailing addresses to authorize them for their kids and stuff, but the simple walk-in is probably easier to digest for an average school district.
For a development shop, I should think that all you really need is to make sure you've got secure, recent, usable backups of your source code and important licensing/contract data.
Unless you live in an area prone to a certain type of natural disaster, the types of things that cause real contigency plans to go into effect have a statistically small chance of ever happening to you. It's just not worth the money and effort to go to great lengths to make sure the company is running full speed the next day rather than two to three weeks down the road. As long as your data is safe, you should be ok. Just take good backups in duplicate - put one set in a fire safe onsite and ship one to a secure offsite location, perhaps using a service provider like Iron Mountain (although I'd encrypt that tape before I gave it to some random Iron Mountain driver if I were you).
Some businesses have to worry about 24/7 production operations that can't be allowed to stop. Typical examples of extreme uptime environments are stock exchanges, utility/telco companies, various emergency services, etc. In a lot of these sorts of cases, it's actually justifuable to double or even quadruple the cost of your implementations and the ongoing maintenance and salary costs just to make sure than when a 1:1,000,000 chance event occurs, you experience a 10 second performance hiccup rather than a serious outage. In some cases a one hour outage simply cannot be tolerated at any cost. These are the environments that really have a hard time pushing the bleeding edge of engineering geographically redundant "systems", where systems includes the machines, the networks, and the people using them. A development house, in contrast, is a pretty easy problem.
The fact that it contains more transistors is a matter of scale, not complexity. In a similar sense, the individual problems of a decade or two ago are now occuring on multiple levels, which increases the "depth" of the problem and the problem solving. However, in a meta-sense, the problems have not changed. It's not a truly more complex problem. We haven't moved from Algebra 1 to Differential Calculus, we've just moved from one-liner algebra problems to multi-page-long algebra problems.
Well, I suppose things could be different at the MIT AI Labs or something - but my experiences at a state college, and others' at "normal" colleges I have heard, are exactly what I described. Professors who couldn't do jack if presented with a real problem in the business world today, teaching courses in obsolete languages. You would still gain some theory, but you can gain that from a few good books and practical experience.
Motivated geeks do their work away from the pointy haired boss environment by getting hired somewhere that the bosses aren't so pointy haired and/or doing what they love on their own time, at home.
Now of course, there are some wonderful geeks out there with degrees, and there are some universities with great programs - but overall, in a statistical sense, I've observed that degreed CS people don't often know what they're doing and don't "get it".
And no, the job wasn't shelf stacking, it was software research and development at a major telecom company.
Yeah, listen up. Computers haven't gotten any more complex, you've just gotten dumber. Computer's don't develop neurosis, but it might make a cool catchphrase to sell a book, especially to someone who's incapable of diagnosing the real problems. Those real problems haven't changed in many years. Sure, there's a few more layers now, but they're pretty easy to peel away in your head.
It has been my experience for the past 9 years out here in the unixy sysadmin/developer world, that having a degree is a fairly accurate predictor that the person won't "get it". At my last job where I actually did some hiring and interviewing, I specifically avoided resumes with degrees. There's not much you can learn from a course in Pascal programming taught by someone who's only ever written dorky recipe-reminder programs on their own PC, that you can't pick up on your own if you're a motivated geek who gets it.
In another study I conducted recently, I noticed that states which have the largest ratio of non-mustached to mustached males have the highest average salaries. Therefore if you are male and have a mustache, you should shave your mustache to get richer.
Actually I wasn't all here mentally when I posted that comment, so I apologize if I offended anyone. However, please take a look again at the article, and think from the point of view of someone who couldn't give a rat's ass about anime. It just sounds really silly. Here's a different translation that's not as offensive: "Great, a cartoon is coming, and let me expound upon my knowledge of some even more obscure related cartoons so that I sound cool to other people into this fad". It's not really news for nerds, it's news for some nerds who like anime, with some personal ego-push attached to the end.
MoeMoe writes "Well I was just watching Cartoon Network and it looks like Trigun will begin airing in just a couple of weeks. The CN website gives a brief description here" Trigun is among my favorite anime series. It gets a little crazy by the end, but for the most part it's pretty lighthearted fun, with some great action. CN sure seems to love the Anime Sci Fi Westerns. I wonder if they'll carry some of the fluffier stuff besides Tenchi. Love Hina would be a fun choice. Or Excel Saga.
Translation: My social life is dead. I got excited last week when a girl smiled at me, but it was the girl at the mcdonald's counter, and they're paid to smile to help sell $1.99 hamburgers. Maybe if I throw out some of my knowledge of anime people will dig me, maybe.
Hey, guys, it's a fscking cartoon, get over it.
At one point I was a staunch supporter of tcsh as a login shell. I had read about and experienced the ugliness of *csh for scripting, but I still preferred tcsh's immensely good interactive interface.
But every now and then, I want to do a quick loop or some other simple scripting construct right there on the commandline, and I would actually run some bourne derivatite from my tcsh commandline just to do it and then drop back. Eventually I got more and more annoyed with that, and along the way Bash picked up a lot of the really good features (like advanced context-sensitive command completion) that tcsh had, so it only made sense to give up and go bash.
Well yes that's true in general, but it doesn't work out well in the programmer field. I consider myself fairly talented. I know a few other people in my area that are also on the "pretty damn talented list", and all of us have had serious job/money troubles in the past couple years at one time or another due to the job market. I gaurantee we're in whatever top X percent constitutes being good enough that you shouldn't have to worry, but we're still getting hit.
Part of this can be explained away with the notion that a few good people will always be lost in such a major wash, and that they'll recover hopefully (and I did recover, so have most of the others). But another part of it, I think, is in the nature of good programmers... A large number of the good programmers out there are the geeky-introvert type, and a large amount of the mediocre to crappy programmers out there are regular extravert joes with social skills. So when the job market squeezes, guess who makes all the good connections with the suits, and guess who's sitting on their ass at home with their 1 friend, a bottle of mountain dew, and their dwindling bank account as comfort? In a highly competitive scare-job time, the lower end programmers have superior job-seeking and people-networking skills to leverage over our heads.
Using water to boost engine power has been a well-known trick of racers for a long, long time. It is no secret that very small amounts of water vaporized into the air/fuel mixture will increase horsepower. I have heard anecdoctal tales dating back to the 60's and earlier of home-brew systems for drag race cars, very similar to some current strap-on NO2 injection systems, which allowed the driver to apply short controlled bursts of water mist into the intake manifold.
The primary benefits are in lowering intake mixture temperature, increasing the thermal conductivity of the pre-burn intake mixture and the post-burn exhaust mix, and and most important, increasing the effective compression ratio due to the fact that water is uncompressable. Any drop of water inserted into the cylinder before firing will not compress, and essentially has an effect similar to shaving the heads down to remove the same volume from the cylinder.
Of course, this is a very dangerous practice. A little too much water will cause all sorts of general failure, up to and including rods and even larger parts to come flying out of your engine block. There's probably also some extra maintenance steps neccesary that get taken care of during normal racing engine maintenance/rebuild to keep an engine subjected to this running safely. In other words, please don't go do this to your Civic because you saw my post here.
Considering this is a response to mutual trust between employee, employer, and client being a central idea in the backdoors discussion, a relation of how a seemingly trustworthy corporate situation is anything but irrelevant, but thanks for playing the mod game.
I did some research on this a while back, with the intent to purchase or build some LED lighting systems. As it turns out, for practical, normal household use, LEDs aren't as efficient as some would have you think. You're better off with some form of flourescent lighting. Where LEDs shine is in spot-lighting situations - such as desk lamps, or small spotlights that go under the bottoms of cabinets to light up counters, and that sort of thing.
They provide more light per watt of energy consumed to a small focused area than other technologies, which spread their light in all directions and are masked/reflected to give light to only one direction. But for a main light source illuminating a room in all directions, they're somewhere in the same neighboorhood as incandescents in efficiency, and soundly beaten by flourescents.
His situation mirrors one I was in a few years back with Worldcom. In my case, I was in a "long term" permanent position, with stock options being given to me every year, which each matured (became available to exercise) in 3 years and were valid for another 7 years. Given that stocks hsitory at the time, and the likelyhood that I would still be there after 10 years, it seemed like a really good deal.
Right about when I reach the 3 year mark and my first set of options became available was right about when the stock peaked for good, though I didn't know it at the time. By the 4 year mark, the stock was pretty obviously on a downward trend, but the management line was "you guys are valuable coders, you're here for the long term, the options will recover before their 10 years are up".
Sure enoughm, at around 4.5 years into the job, the options had reached zero value, and our whole building, irrespective of job function or worth to the company, was summarily laid off.
Yeah outbound traffic is easy, it's the inbound he's having a problem with I'm sure. The problem with two sets of addresses and DNS switching is the caching. Even if you set your records to expire in 30 seconds or something crazy like that, at various levels the records *will* get cached much longer than that, and it will "problematic" at best.
This question is truly worthy of Ask Slashdot, which is a first in a long time. I have yet to see a good answer for someone who wanst truly redundant internet connectivity and has too small an address space to really do BGP peering.
I thought of one solution at the ISP end of things, which would require partnerships between ISPs. Two distinct competing ISPs could grab a decent-sized netblock and share it. They sell these IPs to customers wanting dual-homed access from both ISPs, and split the money. In this type of scenario the customer can BGP to both ISPs, who in turn BGP with each other and the real backbone, and you can get all the redundancy you need in case of ISP or wan-link failure.
I agree. I still think books like this one are interesting to read, as they help you think about the problem, but essentially the Software Development problem comes down to these simple points, IMHO:
1) Talent - Get talented guys. Programming talent almost really can't be taught, find the "naturals". If you can't find talented programmers, and you're left with the random industry jerkoffs, then resign yourself to a slow process with buggy software.
2) Make them happy - Programmers who are asked to work 80 hour weeks for 40 hour salaries while expecting a layoff at any time between tommorow and 6 months out don't do good work. Increase their quality of life, and they do better.
Other than that, you can spout all the techno-babble you want about software development and it doesn't change a damn thing.
IMHO, SMB2 was a big letdown. SMB3 was superior to SMB2, but it was a bit too complex for being the best side-scroller. They were almost leaning in towards the rpg side of the side-scroller world with the complexity. I still think the original Super Mario Brothers was the best side-scroller ever. Simple, and done just right.
Slashdot Mirror
Yeah I agree that it doesn't look good. I've done a lot of Sun stuff in my time - they've always been my favorite among commercial unix vendors - but I think they've failed to respond to the situation Linux has presented them.
And yes, IBM Mainframes are truly fault-tolerant environments, where you can trust a "single machine" full of redundant internal components to not go down short of geographical disasters. I still think I'd rather acheive the same uptime with a cluster of smaller systems, but the IBM zSeries type things are looking very nice too.
IBM's salvation in the long run is that they've dealth with the Linux issue well.
I get $12,285 adding the FC card and making them 4G ram to make the numbers somewhat comparable again. Don't forget those are IIIi CPUs now with 1MB cache, which are a drop in horsepower over the previous config. For the matter at hand the Athlon will probably own them by a decent margin.
And the whole point of Penguin vs Sun is that if you're building a redundant cluster, individual system uptime starts not being worth the cost.
I assume by "direct attach" you mean a fiber loop between the nodes, which is basically the same thing. SAN is a buzzword to me, FCAL loops are just mini-SANs
Oracle's stuff does scale very well though - although yes for some SQL statements having single-box horsepower matters. I generally think of transactional systems where each statement is small and the total volume of incoming statements is the problem.
In anycase, you should really check out the recent (10 days ago?) video oracle put out. www.oracle.com -> Linux -> "Merrill Lynch" link in the middle of the page. It's a "1 year later" report from an ML IT Exec - he discusses in very business terms how one year later their migration to linux/RAC based Oracle solutions has been "astounding". 100.00% uptime for the first year even through upgrades, at 5x the performance for 1/6th the cost - doing 100's of millions of transactions per day. It's about 15 minutes long, but it's a very good presentation.
I might add as a disclaimer that the 32 node figure was what I pulled outta my @$$ to compare with 2x6800's earlier. Now that I think about it, I've never actually built or seen a RAC cluster with that many nodes, so I don't know how practical that scaling is, or if it's even possible. In any case, if it were scaled down to 8 or 16 or whatever nodes, the percentage markup would remain the same, so the point it still valid even if the configuration might not be
You're right, it would be a better comparison to use 280s or 480s. Let me do some price shopping here and make a more precise comparison using that (note this is all retail - everyone offers discounts and programs and all):
SunFire 280R configured from store.sun.com with:
2x 1Ghz UltraSparc III Cu
Dual 10K RPM internal FC drives
4GB RAM
Built-in 10/100 Eth
Addon Dual-Channel Fiber Channel interface
Cost: $30,188
Penguin Computing Altus 140
2x Athlon MP 2600+
Dual 10K RPM internal SCSI drives
4GB RAM
Built in Dual 10/100 Ethernet
+ JNI dual FC card (64/66 PCI) found on random reseller website ($2,066)
Cost: $6,088
They're not exactly equivalent (what can be given the vast arch difference?), but they're close enough for comparison.
So for 32 nodes into this oracle cluster.. You've got $194,816 to do with Linux/x86, or $966,106 for the Sun way. That's about a 396% markup to get Sun/Solaris support - both solutions are equally reliable in the long run (in either case a node fails and you replace it at your leisure). When you consider that every 3 years or so at most you'll be replacing this setup with whatever's new at the time, doesn't it make sense to not take the 396% markup for Sun's name?
As before, the new Matrix will be all about kick ass action scenes and photography, and the plot will be like a comic book come to life. If you can suspend disbelief and zone into their comic book mindset, I'm sure the movie will be at least as good as the first.
I'm pretty sure Compaq and others already have hot-swap for cards, and support terabytes of storage (which is really just a matter of having enough FC bandwidth for whatever you're doing and plugging into the same standard storage arrays the Sun can).
Hot-swapping CPUs and RAM is trickier, but Sun only offers that on high end models which have no direct counterpart in the PC marketplace. Even then, it's a dicey situation at best.
With the E10K generation, you can hotswap CPU boards (there's 16 of them, each holding up to 4 processors, 4G ram, and two I/O busses (4x Sbus cards or 2x PCI cards). Thus you very much have to plan ahead to make sure you can "swap out" a given board without losing anything (oops, the failed memory is on the board with the only controller for this scsi disk over here, or the only one with this gigabit network connection). Assuming you built the machine right so that no single board is a single point of failure, you hit the next problem: If a CPU or memory module were to actually fail during runtime, it is still just as likely to cause an OS crash. The advantage is that in most cases the offending peice of hardware (1 CPU, 1 bank of RAM, etc) will be blacklisted and not used at all when the machine reboots from the panic (now you have a 15 CPU machine instead of 16). Then after that reboot, you can go about hot-swapping in a replacement with the OS online. You run some commands which basically tell the scheduler to stop scheduling on those CPUs, and tell the VM to not allocate any more physical ram in a certain region - then it goes about paging all the allocated RAM off to other ram or swap until it has emptied the board - then you can swap in the new stuff and re-add the CPU/mem into the OS.
On the newer SunFire architecture (3800s, 6800's, 15K, etc), they finally split the I/O boards from the CPU/Mem boards to make this a bit less painful, thank god. Still, in either case, you dont get a 4-way that scales to 64. You could buy a 64-capable machine (or higher now with SunFire architecture), and only populate it with 4 CPUs because you expect growth - but an E10K with just 4 CPUs in is a huge waste of cash - we're talking at least several hundred thousand dollars, for the hardware equivalent of what other companies sell for just a few thousand dollars. I think at one point a few years ago my company bought one 1/4 configured (16 CPU 16 GB ram) and left the other 3/4 open for expansion, and the cost was on the order of around $1,300,000. Do you really want to pay 50x+ over the same hardware capacity of a top end x86 just to be able to expand and have better support?
And in any case - these solutions, ultimately, may have slightly better sigma numbers on uptime, but they are still riddled with single points of failure, and ultimately no Sun solution is truly reliable with resorting to redundant clustering of oen sort or another. Once you resort to a redundant cluster, you're saying "I don't care if the hardware fails occasionally, my cluster will handle it while we do the maintenance". At that point, are you going to spend that much more money to make the difference between 99.9% and 99.999%?
Lets make a rough real example - a 24/7 Oracle database. In the Sun world, to get 24/7 uptime, you'd build out two machines of appropriate power (let's say 2x 6800s), and drop Oracle's OPS or RAC (or whatever they call the next generation) on it for a fully fault-tolerant cluster. You'd attach it to an FC SAN of appropriately configured redundant storage.
On the x86 side, you'd rack up the equivalent in I/O and CPU horsepower worth of 1U boxes (let's say 32x 1U dual processor large-ram crap-reliability boxes from Penguin Computing or something).
Either one is going to be very reliable because of Oracle's nonstop clustering stuff. You'll experience more failures/year on the x86 solution, but losing one of 32 machines is no biggie for a few hours while you drop in a spare.
Two fully loaded 6800's is gonna run you about $2.0 million. 32 high end-ish (lets say 10K a pop) 1U machines is gonna run you $0.32 million. You do the math.
I think people are blowing over the privacy issue wrt to parents. Let's face it, for one legally you don't get any privacy from your parents until you're of age. Two, these grades are *supposed* to beknown by parents. That's why they send home report cards, etc. It's not a matter of the grades being your private data your parents shouldn't know, it's a matter of the fact that most kids don't want their parents to see the grades and hide/alter them, and this is a way for parents to get back to the truth and know how their kids are doing.
You should be able to be open with your parents on a simple thing like your grades, and work through whatever issues that brings up. If you can't work through that with them, god help you on the more troubling aspects of teenage/parent relations.
The system is a good idea overall, and I think every school should be moving this way.
Now on the other hand, there's the issue of their completely lax security. 6/7 social digits plus 5 digits of last name is just too easy. Anyone can get that. This is a serious privacy concern. You have to fix it without making the system cumbersome for the parents though. Probably the only really reliable way would be to have the parents come up to the school and register for the site physically and get a real username/pass - that way the person setting them up can actually verify who they are. I don't think it's too mcuh to ask the parents to care enough to show up at school once in their lifetime to establish a password for something like this. There's probably more creative schemes involving snail-mailing randomly-generated security numbers to parents' mailing addresses to authorize them for their kids and stuff, but the simple walk-in is probably easier to digest for an average school district.
For a development shop, I should think that all you really need is to make sure you've got secure, recent, usable backups of your source code and important licensing/contract data.
Unless you live in an area prone to a certain type of natural disaster, the types of things that cause real contigency plans to go into effect have a statistically small chance of ever happening to you. It's just not worth the money and effort to go to great lengths to make sure the company is running full speed the next day rather than two to three weeks down the road. As long as your data is safe, you should be ok. Just take good backups in duplicate - put one set in a fire safe onsite and ship one to a secure offsite location, perhaps using a service provider like Iron Mountain (although I'd encrypt that tape before I gave it to some random Iron Mountain driver if I were you).
Some businesses have to worry about 24/7 production operations that can't be allowed to stop. Typical examples of extreme uptime environments are stock exchanges, utility/telco companies, various emergency services, etc. In a lot of these sorts of cases, it's actually justifuable to double or even quadruple the cost of your implementations and the ongoing maintenance and salary costs just to make sure than when a 1:1,000,000 chance event occurs, you experience a 10 second performance hiccup rather than a serious outage. In some cases a one hour outage simply cannot be tolerated at any cost. These are the environments that really have a hard time pushing the bleeding edge of engineering geographically redundant "systems", where systems includes the machines, the networks, and the people using them. A development house, in contrast, is a pretty easy problem.
The fact that it contains more transistors is a matter of scale, not complexity. In a similar sense, the individual problems of a decade or two ago are now occuring on multiple levels, which increases the "depth" of the problem and the problem solving. However, in a meta-sense, the problems have not changed. It's not a truly more complex problem. We haven't moved from Algebra 1 to Differential Calculus, we've just moved from one-liner algebra problems to multi-page-long algebra problems.
Well, I suppose things could be different at the MIT AI Labs or something - but my experiences at a state college, and others' at "normal" colleges I have heard, are exactly what I described. Professors who couldn't do jack if presented with a real problem in the business world today, teaching courses in obsolete languages. You would still gain some theory, but you can gain that from a few good books and practical experience.
Motivated geeks do their work away from the pointy haired boss environment by getting hired somewhere that the bosses aren't so pointy haired and/or doing what they love on their own time, at home.
Now of course, there are some wonderful geeks out there with degrees, and there are some universities with great programs - but overall, in a statistical sense, I've observed that degreed CS people don't often know what they're doing and don't "get it".
And no, the job wasn't shelf stacking, it was software research and development at a major telecom company.
Yeah, listen up. Computers haven't gotten any more complex, you've just gotten dumber. Computer's don't develop neurosis, but it might make a cool catchphrase to sell a book, especially to someone who's incapable of diagnosing the real problems. Those real problems haven't changed in many years. Sure, there's a few more layers now, but they're pretty easy to peel away in your head.
It has been my experience for the past 9 years out here in the unixy sysadmin/developer world, that having a degree is a fairly accurate predictor that the person won't "get it". At my last job where I actually did some hiring and interviewing, I specifically avoided resumes with degrees. There's not much you can learn from a course in Pascal programming taught by someone who's only ever written dorky recipe-reminder programs on their own PC, that you can't pick up on your own if you're a motivated geek who gets it.
In another study I conducted recently, I noticed that states which have the largest ratio of non-mustached to mustached males have the highest average salaries. Therefore if you are male and have a mustache, you should shave your mustache to get richer.
Actually I wasn't all here mentally when I posted that comment, so I apologize if I offended anyone. However, please take a look again at the article, and think from the point of view of someone who couldn't give a rat's ass about anime. It just sounds really silly. Here's a different translation that's not as offensive: "Great, a cartoon is coming, and let me expound upon my knowledge of some even more obscure related cartoons so that I sound cool to other people into this fad". It's not really news for nerds, it's news for some nerds who like anime, with some personal ego-push attached to the end.
Ditto.
At one point I was a staunch supporter of tcsh as a login shell. I had read about and experienced the ugliness of *csh for scripting, but I still preferred tcsh's immensely good interactive interface.
But every now and then, I want to do a quick loop or some other simple scripting construct right there on the commandline, and I would actually run some bourne derivatite from my tcsh commandline just to do it and then drop back. Eventually I got more and more annoyed with that, and along the way Bash picked up a lot of the really good features (like advanced context-sensitive command completion) that tcsh had, so it only made sense to give up and go bash.
Well yes that's true in general, but it doesn't work out well in the programmer field. I consider myself fairly talented. I know a few other people in my area that are also on the "pretty damn talented list", and all of us have had serious job/money troubles in the past couple years at one time or another due to the job market. I gaurantee we're in whatever top X percent constitutes being good enough that you shouldn't have to worry, but we're still getting hit.
Part of this can be explained away with the notion that a few good people will always be lost in such a major wash, and that they'll recover hopefully (and I did recover, so have most of the others). But another part of it, I think, is in the nature of good programmers... A large number of the good programmers out there are the geeky-introvert type, and a large amount of the mediocre to crappy programmers out there are regular extravert joes with social skills. So when the job market squeezes, guess who makes all the good connections with the suits, and guess who's sitting on their ass at home with their 1 friend, a bottle of mountain dew, and their dwindling bank account as comfort? In a highly competitive scare-job time, the lower end programmers have superior job-seeking and people-networking skills to leverage over our heads.
Using water to boost engine power has been a well-known trick of racers for a long, long time. It is no secret that very small amounts of water vaporized into the air/fuel mixture will increase horsepower. I have heard anecdoctal tales dating back to the 60's and earlier of home-brew systems for drag race cars, very similar to some current strap-on NO2 injection systems, which allowed the driver to apply short controlled bursts of water mist into the intake manifold.
The primary benefits are in lowering intake mixture temperature, increasing the thermal conductivity of the pre-burn intake mixture and the post-burn exhaust mix, and and most important, increasing the effective compression ratio due to the fact that water is uncompressable. Any drop of water inserted into the cylinder before firing will not compress, and essentially has an effect similar to shaving the heads down to remove the same volume from the cylinder.
Of course, this is a very dangerous practice. A little too much water will cause all sorts of general failure, up to and including rods and even larger parts to come flying out of your engine block. There's probably also some extra maintenance steps neccesary that get taken care of during normal racing engine maintenance/rebuild to keep an engine subjected to this running safely. In other words, please don't go do this to your Civic because you saw my post here.
Considering this is a response to mutual trust between employee, employer, and client being a central idea in the backdoors discussion, a relation of how a seemingly trustworthy corporate situation is anything but irrelevant, but thanks for playing the mod game.
I did some research on this a while back, with the intent to purchase or build some LED lighting systems. As it turns out, for practical, normal household use, LEDs aren't as efficient as some would have you think. You're better off with some form of flourescent lighting. Where LEDs shine is in spot-lighting situations - such as desk lamps, or small spotlights that go under the bottoms of cabinets to light up counters, and that sort of thing.
They provide more light per watt of energy consumed to a small focused area than other technologies, which spread their light in all directions and are masked/reflected to give light to only one direction. But for a main light source illuminating a room in all directions, they're somewhere in the same neighboorhood as incandescents in efficiency, and soundly beaten by flourescents.
His situation mirrors one I was in a few years back with Worldcom. In my case, I was in a "long term" permanent position, with stock options being given to me every year, which each matured (became available to exercise) in 3 years and were valid for another 7 years. Given that stocks hsitory at the time, and the likelyhood that I would still be there after 10 years, it seemed like a really good deal.
Right about when I reach the 3 year mark and my first set of options became available was right about when the stock peaked for good, though I didn't know it at the time. By the 4 year mark, the stock was pretty obviously on a downward trend, but the management line was "you guys are valuable coders, you're here for the long term, the options will recover before their 10 years are up".
Sure enoughm, at around 4.5 years into the job, the options had reached zero value, and our whole building, irrespective of job function or worth to the company, was summarily laid off.
Thanks, Corporate America, I owe you one.
Yeah outbound traffic is easy, it's the inbound he's having a problem with I'm sure. The problem with two sets of addresses and DNS switching is the caching. Even if you set your records to expire in 30 seconds or something crazy like that, at various levels the records *will* get cached much longer than that, and it will "problematic" at best.
This question is truly worthy of Ask Slashdot, which is a first in a long time. I have yet to see a good answer for someone who wanst truly redundant internet connectivity and has too small an address space to really do BGP peering.
I thought of one solution at the ISP end of things, which would require partnerships between ISPs. Two distinct competing ISPs could grab a decent-sized netblock and share it. They sell these IPs to customers wanting dual-homed access from both ISPs, and split the money. In this type of scenario the customer can BGP to both ISPs, who in turn BGP with each other and the real backbone, and you can get all the redundancy you need in case of ISP or wan-link failure.
I agree. I still think books like this one are interesting to read, as they help you think about the problem, but essentially the Software Development problem comes down to these simple points, IMHO:
1) Talent - Get talented guys. Programming talent almost really can't be taught, find the "naturals". If you can't find talented programmers, and you're left with the random industry jerkoffs, then resign yourself to a slow process with buggy software.
2) Make them happy - Programmers who are asked to work 80 hour weeks for 40 hour salaries while expecting a layoff at any time between tommorow and 6 months out don't do good work. Increase their quality of life, and they do better.
Other than that, you can spout all the techno-babble you want about software development and it doesn't change a damn thing.
IMHO, SMB2 was a big letdown. SMB3 was superior to SMB2, but it was a bit too complex for being the best side-scroller. They were almost leaning in towards the rpg side of the side-scroller world with the complexity. I still think the original Super Mario Brothers was the best side-scroller ever. Simple, and done just right.