To most of the commenters: WTF? You have obviously never been involved in a DDOS attack. Here is why:
1) A typical DDOS attack in 2012 will send traffic measured in hundreds of MBPS/GBPS down your pipe. Not only is this a massive volume of traffic, but almost all of it is in the form of SYN/ACK packets (which are exponentially more difficult for your frontend servers to handle; especially when they are never followed by a FIN.) This is many orders of magnitude more difficult to deal with than what most sites are scoped for. You cannot just "handle it," we're talking about something that is often 7-8 standard deviations away from your "normal" peak traffic levels. In other words, your infrastructure cannot handle it. Because if you overbuilt your infrastructure to those levels, you are an idiot. DDoS protection services cost a fraction of what it would cost you to build a network that could handle that. 2) Your normal DDOS doesn't come from one "large user." (hence, the first D in DDoS.) It comes from thousands (or hundreds of thousands) of IP addresses, all at once. Botnets? Yeah, they are real things, and they can be really destructive. And bad people control them, and you may have fired their mother at one point. Who knows why they have it in for you, but they probably will at some point. 3) Even if your infrastructure could handle an amount of legitimate traffic equal to the volume the DDoS will produce over the span of 6-12 hours, you would then have to pay for it. I promise you, you don't want to be in that position. Most hosting providers probably won't make you pay for all of it, but they will become real interested in what you're hosting that would make someone want to DDoS you in the first place. And your boss will probably make you find a proxy solution to solve the problem; so why not be proactive about it so you can say "Yeah, those/b/tards decided to DDoS us, but I took care of it 3 months ago."
TL;DR: DDoS proxy services like CloudFlare exist for a reason: it's simply not economically feasible to overbuild your infrastructure to the point where you could survive such an attack. Pay the man, keep your site up, and ignore the punks smashing cars in the street because you have insurance, so fuck em.
Not when copper prices fall through the floor thanks to the implosion of the construction boom. If there's no demand for the stuff, the price goes way down.
The article specifically says that he is NOT entitled to a share of iPod sales; he was paid a one-time consultancy fee and was just happy to have his contribution to technology acknowledged.
You're looking at about $1500 to add a portable AC to a room. That's about right. I'm guessing if you need supplemental air conditioning, you have around $100,000 worth of gear sitting in said room. Do you really want to cheap out on this? If the cheaped-out AC (if you're not sacrificing amount of cooling, you're sacrificing reliability) fails and burns up your gear, was the savings really worth it?
If this seems high to you; you can often add a 1-ton HVAC for about $5000-$8000 providing you have space on the breaker panels. That's a much better permanent solution.
This is one of the (many) reasons that people often end up colocating mission-critical gear. It costs you more to build your own server room than host it in a tier 4 datacenter for 3 years.
Fortinet makes a pretty badass product in the Fortigate 50B. For $400 we're talking a full QoS/NAT box with 2 WAN ports, load balancing, HA failover and connection tracking.
And they're not even that difficult to set up if you know how to do QoS firewalling. If you pay the yearly maintenance fee you also get full IDS/AV/Spam/Content filtering (any of which can be turned on/off either on a schedule or at your pleasure.) If you're really paranoid you can buy 2 and set them into HA mode for failover.
Yeah, you can roll your own but it'll probably cost you at least $200 and many weeks of aggravation, and still probably not work as well.
It probably has more to do with the fact that they're officially no longer with their big record label. EMI recently released a "greatest hits" album; something Radiohead has also been vehemently against in the past. Something tells me EMI realized that the band has been too successful on their own to ever come back to a major label, so they might as well just make a buck without having to worry about pissing them off.
And really, Amnesiac and Kid A are albums greater than the sum of their parts. I'll admit they're not for everyone; but the albums stand better as albums than on the strength of the individual songs. You'd be disappointed buying individual tracks.
Technical reasons aside (there's technically no reason you can't do this,) the main reasons business/risk exposure reasons. If you make money off running reports for them, why the hell would you want to let them do it themselves?
Also, if you're not skilled enough with Oracle security to be able to do this; it's not going to happen overnight. Just say you don't have the proper security structures in place to allow for that kind of access.
Besides, do you want to be the one who has to explain to the rest of your customers that your database access got 0wned because "Special client A" had a vulnerable intranet web application they wrote to query the DB without your permission that allowed the hacker to query your database and run some form of Oracle privelege escalation to get access to 20 million credit card numbers? You can't trust your clients to be as careful with security as you are.
Since you can't control the security on their end, you can't trust them. Financial companies have external compliance audits to iron out this kind of thing; is that what you're going to do for this customer? Or is the prospect of a $250,000 security audit every 2 years enough to scare them off?
SELinux is great for hardening a box. Unfortunately most sysadmins don't take the time to learn how it works and turn it off because they can't get something to work. Yes; it is a pain in the ass to deal with most of the time, but it's saved me from some big mistakes before as well.
SELinux almost makes more sense in an appliance server; as the config is not likely to change much. Just assume the web interface is vulnerable (it probably is; if not through your code then some as-yet undiscovered vulnerability in the LAMP stack.) I'll admit, SELinux is a religion you've got to practice, but Unix filesystem permissions leave a lot to be desired (I don't like having to create a new group every time I want to set permissions on a subset of users, thanks.) There needs to be more in the 21st century, and while SELinux is not the best solution, it's a workable one.
The goal of SELinux IMO is the realization that you will never get rid of all vulnerable code on your box. What you can do is limit the damage they can do when they get past the application layer security. Who cares if they can hack your sendmail server when it doesn't have access to read/write anything outside its config and spool directories?
Be fair here; MkLinux was really an educational project for Apple's core developers to play around with Mach before starting the heavy lifting on OS X. Porting an existing OS lets you play with things and get them wrong in a sandbox so you can see why you might want to make certain design decisions when coding one from scratch.
I used MkLinux, and it was at the time the only way to run Linux on Mac hardware. It didn't stick around for long; once the Apple sponsored developers had played with it long enough, it was abandoned as they started moving over to OS X development.
Monolithic Linux had been around for a long time before MkLinux (which came out somewhere around Linux kernel 1.2.) It was far better supported on the PC side of things, so it was the only natural course to take to port a monolithic kernel to Mac hardware. The monolithic kernel was easier to use, and you could basically re-use HOWTOs and instructions from the x86 tree.
Just FYI, if you have the proper OEM license media for Office 2003, the OEM license keys for Office 2007 will work with 2003 (and even XP, if I remember correctly.)
There is lots of upside, especially for small businesses. At a company of 5-10 people you're not going to have an IT guy, or if you do, you're the IT guy. You don't want to spend your time being the IT guy for your own company, because it doesn't make you money. A full company wide suite of SaaS applications is almsot guaranteed to be less than the salary of a part-time IT guy (~$1,500 - 2,000 a month for a part timer buys a hell of a lot of SaaS apps.)
Biggest upside: Your data is accessible anywhere, without an IT department and independent of TimeWarner or whatever cheap internet access you use. You don't have to pay for a rack at a datacenter. Your application is upgraded without you having to do anything or pay extra. It's basically someone else's problem; and an SaaS vendor is going to be far more invested in a HA infrastructure than you can afford to be (economies of scale and all) and as such, will be down less often on average than if you did it yourself (anecdotal evidence need not apply, I'm sure a lot of people have servers that haven't been down in 2+ years.)
Another big upside: No big up-front capital costs in deploying programs. Chances are, unless you're an implementation vendor, you're going to pay someone else to implement large open source projects for you (Zimbra, SugarCRM, etc; this is the hidden cost of open source.) Even if you do it yourself, there's an opportunity cost because you could have been making money when you were mucking with setting this crap up, and there will inevitably be issues somewhere down the line.
SaaS is not right for every company, but it does make a lot of sense for small companies.
Developers need not worry about HA too much. Your IT department should be able to set this up for you rather seamlessly. With things like LVS/Keepalived you can easily implement load balancing and auto-failover for databases, web servers, etc (you don't even need to code in multiple DB servers; VRRP works wonders for this kind of thing.) As long as the application is designed sanely to begin with, HA as it is typically discussed comes down to minimizing the impact of hardware failure by buying two of everything and making failover happen automatically (human response time is anywhere from 5-15 minutes in a best-case scenario, where worst-case for auto failover is http://keepalived.org/) is an excellent solution for something your size. It's basically an LVS frontend with host checking and automatic failover capability (via VRRP,) custom host checks (i.e. run a typical SQL query every 3 seconds to check that everything is ok, if it's not, remove the DB from the pool, do some other stuff and rebalance the cluster. It can all run off one IP on the front end so the app won't notice what happened.)
This is important in the IT industry for reasons other than being a tree-hugging hippie (not that there's anything wrong with that.)
More efficient, lower power servers directly relate to a cash savings on your electric bill. One server operating at 10% greater efficiency may not be a big deal, but it starts to matter when multiplied over a room of servers. Servers that use less power (generally) put off less heat, so you also save electricity because you don't have to cool them as much, and you can cram more servers on a UPS without overloading it. In the end it's really about density.
It is marketing, but it's not coming out of left field. There are real business reasons to want servers that are cheaper to operate.
The idea itself is not innovative. The devil, as always, is in the details.
It actually does require innovation; old things have to be done in completely different ways.
What you're saying is that if someone created a space ship that could travel at light speed, that would not be innovative. We already have space ships that go slower than light speed, so it's trivial to scale it up. That's obviously not the case.
Ideas, by themselves, are worthless. The real innovation is how to actually do it. That, combined with the ability to do it, is what makes a technology company money. Nanoscale chip fabrication does in fact require real innovation. Materials at this scale have different properties than they do at a larger scale. If it didn't require innovation, we would have been making 5nm chips for years now.
SEO is a cat and mouse game and the professionals are very good at it. For a few grand a year a top-notch SEO company can get you on the first page of pretty much any competitive keyword you want in a few months. Google makes it hard enough that I wouldn't do it myself, but SEO is a very integral part of an online marketing campaign, and considering that, its dirt cheap.
And Google is constantly tweaking their algorithms. But so are the SEO guys.
It's all about population density. Japan and most Asian and European countries are very densly populated. The reasons for this are many; good urban planning, good public transportation, lack of space, or simply the fact that the cities themselves grew in poverty or before the invention of the automobile.
American cities are spread out. Most US cities didn't really start exploding in population until cars were ubiquitous. That meant that you could live 30 miles from your job and the commute wasn't prohibitive.
The way wireless coverage area works, you don't need just twice as many towers to serve the same amount of people living at half the density of Europe, you need about 4 times as many. Forget the rural areas, covering the cities and suburbs is hard enough.
Now factor in that even the densest of US cities, Los Angeles (90th most dense city in the world,) is only about 1/2 as dense as Tokyo, or a staggering 1/10 as dense as Seoul (source: http://www.citymayors.com/statistics/largest-citie s-density-125.html ). Most major Asian and European cities on the same scale. Because square area is an exponential function, you need 100 times as many towers to serve a population that is 1/10 as dense (you need less cells per tower, but it's still more physical locations to manage and upgrade.)
With these sorts of density figures, it definitely starts to screw with the numbers. You can't upgrade as often and still make a profit, and you have to treat your customers like crap because you can't afford to treat them well and still make money (and if they weren't making money, we wouldn't be getting cell service.)
You start looking at where you can make money, and it eventually leads to the fact that you have to make more off of every customer by nickel and diming them while you can't upgrade your network as quickly because it takes too long and is too expensive.
Or maybe because computers are faster, developers don't HAVE to optimize as much to get acceptable performance and can use slower, interpreted languages that are quick to write and debug. It also means the applications can be more capable and include more features. Some call this bloat, some call it progress. History has consistently shown it to be the latter. Development speed has increased as a result, meaning cool shit gets in our hands faster. How is that a bad thing?
This argument is basically the "my rock works fine, why do I need a hammer?" argument. Vista is a pig, but you know what? MS designed it to be capable for the next 10 years. Of course it's a pig now, but it won't seem too bad in 3 years when XP finally is phased out for real. XP was a pig because it used (oh my god!) 128 MB of RAM in 2002. In 2010 the fact that Vista uses ~800 MB at idle won't be a big deal because your average PC will have 4-8 gigs.
Console development is already much like what you suggest; developers use a specialized set of tools to write highly optimized code for a low-power platform. Embedded machines as well.
Where I see the multiple cores concept going is towards multiple virtual machines. Windows 7 is already headed in this direction (10 years after Apple did it with OS X and Classic? Sorry, had to add that.:) Wouldn't it be ironic if everyone started using their cheap low-power PC as a dumb terminal to connect to their multi-core monster server in the basement?
I find this attitude among interviewers very offputting. I can understand wanting to see how someone reacts to tough questions, but if you're a senior admin interviewing people for a position, you can't possibly expect them to know as much as you do. With so many technologies out there, nobody is going to have the exact same experience as your shop.
If they've used vxvm or set up a veritas environment at a small shop, they've had enough introduction to the tools that they can be trained quickly without too much hand-holding. I wouldn't consider myself a veritas expert, but I have built and configured 2 Veritas environments so I'm putting it on my resume. If nothing else, offer them $10k less the first year and spend that money sending them to a few specialized training classes.
If your job posting lists specific requirements (must have implemented X technology and they lied about it) then yeah, go ahead and grill them, but most job postings are far too general for applicants to actually realize the level of skills required. A lot of people put together shotgun resumes on job sites to get maximum coverage on resume searches. Ask them to see if they bullshit you about it, but if they fess up they're not exactly an expert in the subject, it shouldn't disqualify them for putting it on the resume.
Slashdot Mirror
To most of the commenters: WTF? You have obviously never been involved in a DDOS attack. Here is why:
1) A typical DDOS attack in 2012 will send traffic measured in hundreds of MBPS/GBPS down your pipe. Not only is this a massive volume of traffic, but almost all of it is in the form of SYN/ACK packets (which are exponentially more difficult for your frontend servers to handle; especially when they are never followed by a FIN.) This is many orders of magnitude more difficult to deal with than what most sites are scoped for. You cannot just "handle it," we're talking about something that is often 7-8 standard deviations away from your "normal" peak traffic levels. In other words, your infrastructure cannot handle it. Because if you overbuilt your infrastructure to those levels, you are an idiot. DDoS protection services cost a fraction of what it would cost you to build a network that could handle that. /b/tards decided to DDoS us, but I took care of it 3 months ago."
2) Your normal DDOS doesn't come from one "large user." (hence, the first D in DDoS.) It comes from thousands (or hundreds of thousands) of IP addresses, all at once. Botnets? Yeah, they are real things, and they can be really destructive. And bad people control them, and you may have fired their mother at one point. Who knows why they have it in for you, but they probably will at some point.
3) Even if your infrastructure could handle an amount of legitimate traffic equal to the volume the DDoS will produce over the span of 6-12 hours, you would then have to pay for it. I promise you, you don't want to be in that position. Most hosting providers probably won't make you pay for all of it, but they will become real interested in what you're hosting that would make someone want to DDoS you in the first place. And your boss will probably make you find a proxy solution to solve the problem; so why not be proactive about it so you can say "Yeah, those
TL;DR: DDoS proxy services like CloudFlare exist for a reason: it's simply not economically feasible to overbuild your infrastructure to the point where you could survive such an attack. Pay the man, keep your site up, and ignore the punks smashing cars in the street because you have insurance, so fuck em.
Mod parent up, OpenNMS rules.
Not when copper prices fall through the floor thanks to the implosion of the construction boom. If there's no demand for the stuff, the price goes way down.
The article specifically says that he is NOT entitled to a share of iPod sales; he was paid a one-time consultancy fee and was just happy to have his contribution to technology acknowledged.
You're looking at about $1500 to add a portable AC to a room. That's about right. I'm guessing if you need supplemental air conditioning, you have around $100,000 worth of gear sitting in said room. Do you really want to cheap out on this? If the cheaped-out AC (if you're not sacrificing amount of cooling, you're sacrificing reliability) fails and burns up your gear, was the savings really worth it?
If this seems high to you; you can often add a 1-ton HVAC for about $5000-$8000 providing you have space on the breaker panels. That's a much better permanent solution.
This is one of the (many) reasons that people often end up colocating mission-critical gear. It costs you more to build your own server room than host it in a tier 4 datacenter for 3 years.
Fortinet makes a pretty badass product in the Fortigate 50B. For $400 we're talking a full QoS/NAT box with 2 WAN ports, load balancing, HA failover and connection tracking.
And they're not even that difficult to set up if you know how to do QoS firewalling. If you pay the yearly maintenance fee you also get full IDS/AV/Spam/Content filtering (any of which can be turned on/off either on a schedule or at your pleasure.) If you're really paranoid you can buy 2 and set them into HA mode for failover.
Yeah, you can roll your own but it'll probably cost you at least $200 and many weeks of aggravation, and still probably not work as well.
It probably has more to do with the fact that they're officially no longer with their big record label. EMI recently released a "greatest hits" album; something Radiohead has also been vehemently against in the past. Something tells me EMI realized that the band has been too successful on their own to ever come back to a major label, so they might as well just make a buck without having to worry about pissing them off.
And really, Amnesiac and Kid A are albums greater than the sum of their parts. I'll admit they're not for everyone; but the albums stand better as albums than on the strength of the individual songs. You'd be disappointed buying individual tracks.
Technical reasons aside (there's technically no reason you can't do this,) the main reasons business/risk exposure reasons. If you make money off running reports for them, why the hell would you want to let them do it themselves?
Also, if you're not skilled enough with Oracle security to be able to do this; it's not going to happen overnight. Just say you don't have the proper security structures in place to allow for that kind of access.
Besides, do you want to be the one who has to explain to the rest of your customers that your database access got 0wned because "Special client A" had a vulnerable intranet web application they wrote to query the DB without your permission that allowed the hacker to query your database and run some form of Oracle privelege escalation to get access to 20 million credit card numbers? You can't trust your clients to be as careful with security as you are.
Since you can't control the security on their end, you can't trust them. Financial companies have external compliance audits to iron out this kind of thing; is that what you're going to do for this customer? Or is the prospect of a $250,000 security audit every 2 years enough to scare them off?
SELinux is great for hardening a box. Unfortunately most sysadmins don't take the time to learn how it works and turn it off because they can't get something to work. Yes; it is a pain in the ass to deal with most of the time, but it's saved me from some big mistakes before as well.
SELinux almost makes more sense in an appliance server; as the config is not likely to change much. Just assume the web interface is vulnerable (it probably is; if not through your code then some as-yet undiscovered vulnerability in the LAMP stack.) I'll admit, SELinux is a religion you've got to practice, but Unix filesystem permissions leave a lot to be desired (I don't like having to create a new group every time I want to set permissions on a subset of users, thanks.) There needs to be more in the 21st century, and while SELinux is not the best solution, it's a workable one.
The goal of SELinux IMO is the realization that you will never get rid of all vulnerable code on your box. What you can do is limit the damage they can do when they get past the application layer security. Who cares if they can hack your sendmail server when it doesn't have access to read/write anything outside its config and spool directories?
Be fair here; MkLinux was really an educational project for Apple's core developers to play around with Mach before starting the heavy lifting on OS X. Porting an existing OS lets you play with things and get them wrong in a sandbox so you can see why you might want to make certain design decisions when coding one from scratch.
I used MkLinux, and it was at the time the only way to run Linux on Mac hardware. It didn't stick around for long; once the Apple sponsored developers had played with it long enough, it was abandoned as they started moving over to OS X development.
Monolithic Linux had been around for a long time before MkLinux (which came out somewhere around Linux kernel 1.2.) It was far better supported on the PC side of things, so it was the only natural course to take to port a monolithic kernel to Mac hardware. The monolithic kernel was easier to use, and you could basically re-use HOWTOs and instructions from the x86 tree.
Slashdot trolls tried this YEARS ago with goatse.cx; can't you be a little bit more original?
What's next, is he going to call Rick Astley as a witness?
Just FYI, if you have the proper OEM license media for Office 2003, the OEM license keys for Office 2007 will work with 2003 (and even XP, if I remember correctly.)
Nope, BitTorrent. Then NBC gets nothing.
There is lots of upside, especially for small businesses. At a company of 5-10 people you're not going to have an IT guy, or if you do, you're the IT guy. You don't want to spend your time being the IT guy for your own company, because it doesn't make you money. A full company wide suite of SaaS applications is almsot guaranteed to be less than the salary of a part-time IT guy (~$1,500 - 2,000 a month for a part timer buys a hell of a lot of SaaS apps.)
Biggest upside: Your data is accessible anywhere, without an IT department and independent of TimeWarner or whatever cheap internet access you use. You don't have to pay for a rack at a datacenter. Your application is upgraded without you having to do anything or pay extra. It's basically someone else's problem; and an SaaS vendor is going to be far more invested in a HA infrastructure than you can afford to be (economies of scale and all) and as such, will be down less often on average than if you did it yourself (anecdotal evidence need not apply, I'm sure a lot of people have servers that haven't been down in 2+ years.)
Another big upside: No big up-front capital costs in deploying programs. Chances are, unless you're an implementation vendor, you're going to pay someone else to implement large open source projects for you (Zimbra, SugarCRM, etc; this is the hidden cost of open source.) Even if you do it yourself, there's an opportunity cost because you could have been making money when you were mucking with setting this crap up, and there will inevitably be issues somewhere down the line.
SaaS is not right for every company, but it does make a lot of sense for small companies.
That, and congress is full of ninjas. It's true.
Developers need not worry about HA too much. Your IT department should be able to set this up for you rather seamlessly. With things like LVS/Keepalived you can easily implement load balancing and auto-failover for databases, web servers, etc (you don't even need to code in multiple DB servers; VRRP works wonders for this kind of thing.) As long as the application is designed sanely to begin with, HA as it is typically discussed comes down to minimizing the impact of hardware failure by buying two of everything and making failover happen automatically (human response time is anywhere from 5-15 minutes in a best-case scenario, where worst-case for auto failover is http://keepalived.org/) is an excellent solution for something your size. It's basically an LVS frontend with host checking and automatic failover capability (via VRRP,) custom host checks (i.e. run a typical SQL query every 3 seconds to check that everything is ok, if it's not, remove the DB from the pool, do some other stuff and rebalance the cluster. It can all run off one IP on the front end so the app won't notice what happened.)
This is important in the IT industry for reasons other than being a tree-hugging hippie (not that there's anything wrong with that.)
More efficient, lower power servers directly relate to a cash savings on your electric bill. One server operating at 10% greater efficiency may not be a big deal, but it starts to matter when multiplied over a room of servers. Servers that use less power (generally) put off less heat, so you also save electricity because you don't have to cool them as much, and you can cram more servers on a UPS without overloading it. In the end it's really about density.
It is marketing, but it's not coming out of left field. There are real business reasons to want servers that are cheaper to operate.
The idea itself is not innovative. The devil, as always, is in the details.
It actually does require innovation; old things have to be done in completely different ways.
What you're saying is that if someone created a space ship that could travel at light speed, that would not be innovative. We already have space ships that go slower than light speed, so it's trivial to scale it up. That's obviously not the case.
Ideas, by themselves, are worthless. The real innovation is how to actually do it. That, combined with the ability to do it, is what makes a technology company money. Nanoscale chip fabrication does in fact require real innovation. Materials at this scale have different properties than they do at a larger scale. If it didn't require innovation, we would have been making 5nm chips for years now.
SEO is a cat and mouse game and the professionals are very good at it. For a few grand a year a top-notch SEO company can get you on the first page of pretty much any competitive keyword you want in a few months. Google makes it hard enough that I wouldn't do it myself, but SEO is a very integral part of an online marketing campaign, and considering that, its dirt cheap.
And Google is constantly tweaking their algorithms. But so are the SEO guys.
Then I'll just wait till they come out as budget titles. No big deal, I'm too old to have the time to play the latest and greatest anyway.
It's all about population density. Japan and most Asian and European countries are very densly populated. The reasons for this are many; good urban planning, good public transportation, lack of space, or simply the fact that the cities themselves grew in poverty or before the invention of the automobile.
e s-density-125.html ). Most major Asian and European cities on the same scale. Because square area is an exponential function, you need 100 times as many towers to serve a population that is 1/10 as dense (you need less cells per tower, but it's still more physical locations to manage and upgrade.)
American cities are spread out. Most US cities didn't really start exploding in population until cars were ubiquitous. That meant that you could live 30 miles from your job and the commute wasn't prohibitive.
The way wireless coverage area works, you don't need just twice as many towers to serve the same amount of people living at half the density of Europe, you need about 4 times as many. Forget the rural areas, covering the cities and suburbs is hard enough.
Now factor in that even the densest of US cities, Los Angeles (90th most dense city in the world,) is only about 1/2 as dense as Tokyo, or a staggering 1/10 as dense as Seoul (source: http://www.citymayors.com/statistics/largest-citi
With these sorts of density figures, it definitely starts to screw with the numbers. You can't upgrade as often and still make a profit, and you have to treat your customers like crap because you can't afford to treat them well and still make money (and if they weren't making money, we wouldn't be getting cell service.)
You start looking at where you can make money, and it eventually leads to the fact that you have to make more off of every customer by nickel and diming them while you can't upgrade your network as quickly because it takes too long and is too expensive.
Or maybe because computers are faster, developers don't HAVE to optimize as much to get acceptable performance and can use slower, interpreted languages that are quick to write and debug. It also means the applications can be more capable and include more features. Some call this bloat, some call it progress. History has consistently shown it to be the latter. Development speed has increased as a result, meaning cool shit gets in our hands faster. How is that a bad thing?
:) Wouldn't it be ironic if everyone started using their cheap low-power PC as a dumb terminal to connect to their multi-core monster server in the basement?
This argument is basically the "my rock works fine, why do I need a hammer?" argument. Vista is a pig, but you know what? MS designed it to be capable for the next 10 years. Of course it's a pig now, but it won't seem too bad in 3 years when XP finally is phased out for real. XP was a pig because it used (oh my god!) 128 MB of RAM in 2002. In 2010 the fact that Vista uses ~800 MB at idle won't be a big deal because your average PC will have 4-8 gigs.
Console development is already much like what you suggest; developers use a specialized set of tools to write highly optimized code for a low-power platform. Embedded machines as well.
Where I see the multiple cores concept going is towards multiple virtual machines. Windows 7 is already headed in this direction (10 years after Apple did it with OS X and Classic? Sorry, had to add that.
MMO Halo?
Don't think that MS probably isn't planning this...
I find this attitude among interviewers very offputting. I can understand wanting to see how someone reacts to tough questions, but if you're a senior admin interviewing people for a position, you can't possibly expect them to know as much as you do. With so many technologies out there, nobody is going to have the exact same experience as your shop.
If they've used vxvm or set up a veritas environment at a small shop, they've had enough introduction to the tools that they can be trained quickly without too much hand-holding. I wouldn't consider myself a veritas expert, but I have built and configured 2 Veritas environments so I'm putting it on my resume. If nothing else, offer them $10k less the first year and spend that money sending them to a few specialized training classes.
If your job posting lists specific requirements (must have implemented X technology and they lied about it) then yeah, go ahead and grill them, but most job postings are far too general for applicants to actually realize the level of skills required. A lot of people put together shotgun resumes on job sites to get maximum coverage on resume searches. Ask them to see if they bullshit you about it, but if they fess up they're not exactly an expert in the subject, it shouldn't disqualify them for putting it on the resume.