Hm. I have not been to the campus but Google seems to be doing "okay" (barely!) with that strategy so far. Why do you think there should be more stick and less carrot?
Every employer wants as much of your life as he can get - for as cheap as possible. My personal willingness to obey that wish relates proportionally to the perception of my compensation. I don't know about you but my perception is indeed influenced not only by my salary but also by the number of pool tables, arcade games, swimming pools and sexy female co-workers in the office. Furthermore I don't mind taking on responsible tasks like doing a massage interview every now and then, or so...
Also consider that pretty much all employers try to make you work long hours. Just normally instead of pool tables they use rigged "bonus programs", 360 peer reviews and other intimidation tactics. Maybe google has those, too? I don't know. But I guess having a pool table in the office (and being allowed to use it!) makes everything more bearable...
Hmm you're probably right. History repeating I guess, Gigabytes are the new Megabytes. I remember when 8 or 16M ram were highend. Soon it will be 8 or 16G.
Well, the SIP protocol is used more, yes. And it's gaining ground as more and more ISPs (at least here in europe) are offering VoIP along with internet access instead of landline + internet access.
In this case I was referring to the skype standard use-case, though. That is: end-users making calls with a softclient. AFAIK Skype is still the 900# gorilla in this segment, simply because everybody knows "Skype for calls" (akin to "Google for search") and hardly anyone bothers to look beyond.
VoIP/SIP is open. You only need a client and an account with any of the free SIP providers. Or you setup asterisk (or another free PBX software) and become your own provider.
The problem with SIP is that few people actually use it whereas skype is everywhere.
Well, okay, I give in.;-) You're right, hollywood will certainly rather buy "certified enterprise turnkey" instead of rolling their own. You're also correct that I still was too optimistic in my estimate, I was especially missing out on the switches/controllers. They'd probably go straight for 10Gbit/s or whatever the ceiling today is, that alone blows my little calc to pieces.
I guess my mind was a bit caught up in our own developments here as my company is in the process of moving away from StorageTek/NetApp towards a homegrown solution (3rd storage rack here). Our finding so far is that the savings are mindblowing when you start looking at the "discounters" like Overland and SuperMicro. Ofcourse we miss out on the tight SLAs and "4h on-site support" this time but in exchange we have gotten literally twice the capacity and 1,5 the IOPS for our money - with better redundancy, too.
Anyways, obviously that's not the way to go when you need high-end as I mistakenly implied in my earlier post...
I think there's a zero missing here. $200k wouldn't buy you a rack full of SATA disk from, say, IBM, let alone the fast stuff (or the controllers to sit in front of it).
Well, the 300G velociraptors go for around $300. Let's say we fit 16 per 2U, that's 336 drives per rack or roughly $100k USD (not even factoring in the discounts that you get at those volumes). The remaining $100k would break down to only ~$5k per shelf, which admittedly is a bit low for beefy FC fabric. Still I wouldn't say I was off by a zero. Nodge the estimate up to $250k per shelf and we're good to go.:-)
100T isn't much by storage standards. It translates to roughly 2 racks of hardware for high-speed/low-latency serving plus roughly half a rack for archival. I'd say $150-$200k ballpark which is a drop in the bucket for hollywood. So, serving the stuff at 4 Gbit/s ain't so hard, *processing* it at that rate is a different story.
It's not "unusual", it's simply nonsense. If your business process requires non-techie users to edit and share 32M-sized textfiles regularly then your business process is broken. The whole approach is broken beyond repair, the obvious solution would be to build some kind of frontend for the users.
Probably not for many database servers because bypassing the write-cache is *the* surefire way to kill performance. It's usually much cheaper to rely on UPS, battery backed controllers and a good backup strategy than to run twice as many servers in write-through mode. Furthermore you need the (offsite) backup-strategy anyways for the usual "nuke over datacenter" scenarios...
Hmm, that's funny. So you bought a midrange UPS (which must've been quite expensive in 1997) to protect your equipment and then that very UPS goes nuts and destroys your equipment? And then the vendor has the balls to refuse RMA, much less to cover the destroyed hardware?! Which UPS-vendor was that again?
I really wonder if you're incapable or just unwilling to understand. You have lost this argument long ago because you're not making a point!
Well, but if you so want I will iterate again:
There is no "frequent mishandling" in the "non-root management of daemons" in either daemontools or djbdns. Please quote your "significant security issues" with that because to my knowledge there have been no security issues with djbdns ever. Also please define your term "mishandling"?
Remember, one of the design goals for djbdns was to provide a more secure alternative to the horror that is BIND. According to its security track record it succeeded so far.
Furthermore djbdns is considered by many to be *much* more managable and configurable than BIND. Just compare the configuration mess in BIND (especially the awkward zones format) to the data-format in tinydns that I quoted in my earlier mail. Ultimately this boils down to taste and preference but in no case is it a point to be made against djbdns - much rather one to be made against BIND. Just ask some people who have used both (I have).
So what remains of your argument? The packaging. We can agree on that but that has nothing to do with security and is probably not the driving factor when choosing an DNS impl.
PS: Work on your reading comprehension. The post you replied to was not mine and the statement "better than bind" that you pulled out of context clearly compared the two on the basis of security problems and bugs, in the same friggin' sentence! That seems like a reasonable assertion to make when comparing djbdns (zero bugs, zero security issues) to BIND (an emberassing number of bugs and security issues), don't you think?
Ehm, I see you have an axe to grind with djb or how come you spill this unrelated rant, completely ignoring my question? None of your points are security related. In fact, some of them (malloc, "odd layout") are due to him striving for better security. Oh, and lack of documentation... Have you even looked at http://cr.yp.to/ - ever?
Anyways, I'm writing you off as a troll now. Maybe you think it's some kind of geek-chique to rant against djb these days but please, at least get a basic understanding first.
Your point is just as invalid when applied to daemontools. Djb is well-known for being very anal about security and seperation of concerns on all fronts, which is part of the reason why parts of his software feel quierky to many. Thus your blanket statement "is often done extremely badly and with convenience over security considered paramount" simply makes no sense in the context of djbware. Where did he do any of that "badly" or prioritize convinience over security?
Sorry, but you sound like you have no idea what you're talking about. Read the qmail security guarantee (bullet 4 under "Why is qmail secure?") to get back on topic.
I'm not a djb fanboy but I have to counter one of your points:
the 'daemontools' package he uses to run his software is extremely dangerous in most environments because it hands off control of daemons to non-root users
How is handing off control of daemons to non-root users dangerous? Djb goes a long way in terms of separation of concerns here, qmail for example runs with no less than seven different userids. Attacking Dan's software for a lack of security is a bit like preaching to the pope. Have you looked at his security track record recently?
I do agree with your other points, though, especially with the awkward packaging and the (past) licensing problems. I have recently converted from qmail to postfix because I got tired of the patching and so far I'm not missing anything.
It's a different story with dnscache/tinydns, though. I have still not found a viable replacement for these. It's not just the immunity to this recent exploit here, it's the whole design. Yes, dealing with daemontools is annoying at best. But dealing with the bind zones-format would be so much worse! The tinydns data format is a strike of genius. Until someone comes up with something comparable or just clones the format you'll have to pry djbdns from my cold, dead fingers...
Slashdot Mirror
I frequently wonder why people still bother with inkjets despite Laser printers are cheap nowadays and so much less painful to operate.
Just for reference, and here's the creative brain behind most of Microsoft's success products.
HP is also quite popular for their laptops.
Hm. I have not been to the campus but Google seems to be doing "okay" (barely!) with that strategy so far. Why do you think there should be more stick and less carrot?
Every employer wants as much of your life as he can get - for as cheap as possible. My personal willingness to obey that wish relates proportionally to the perception of my compensation. I don't know about you but my perception is indeed influenced not only by my salary but also by the number of pool tables, arcade games, swimming pools and sexy female co-workers in the office. Furthermore I don't mind taking on responsible tasks like doing a massage interview every now and then, or so...
Also consider that pretty much all employers try to make you work long hours. Just normally instead of pool tables they use rigged "bonus programs", 360 peer reviews and other intimidation tactics. Maybe google has those, too? I don't know. But I guess having a pool table in the office (and being allowed to use it!) makes everything more bearable...
16k? Hmm. Which one would that be?
Amen!
They may even expirience a small sales boost when all the linux enthusiasts and integrators can finally build their HTPCs around VIA-boards.
Hmm you're probably right. History repeating I guess, Gigabytes are the new Megabytes.
I remember when 8 or 16M ram were highend. Soon it will be 8 or 16G.
Core Duo 1.8 GHZ, 2G Ram ... Something makes me think that this is still beefier than what most Joe SixPacks are running at home.
Well, the SIP protocol is used more, yes. And it's gaining ground as more and more ISPs (at least here in europe) are offering VoIP along with internet access instead of landline + internet access.
In this case I was referring to the skype standard use-case, though. That is: end-users making calls with a softclient. AFAIK Skype is still the 900# gorilla in this segment, simply because everybody knows "Skype for calls" (akin to "Google for search") and hardly anyone bothers to look beyond.
VoIP/SIP is open.
You only need a client and an account with any of the free SIP providers. Or you setup asterisk (or another free PBX software) and become your own provider.
The problem with SIP is that few people actually use it whereas skype is everywhere.
Well, okay, I give in. ;-)
You're right, hollywood will certainly rather buy "certified enterprise turnkey" instead of rolling their own. You're also correct that I still was too optimistic in my estimate, I was especially missing out on the switches/controllers. They'd probably go straight for 10Gbit/s or whatever the ceiling today is, that alone blows my little calc to pieces.
I guess my mind was a bit caught up in our own developments here as my company is in the process of moving away from StorageTek/NetApp towards a homegrown solution (3rd storage rack here). Our finding so far is that the savings are mindblowing when you start looking at the "discounters" like Overland and SuperMicro. Ofcourse we miss out on the tight SLAs and "4h on-site support" this time but in exchange we have gotten literally twice the capacity and 1,5 the IOPS for our money - with better redundancy, too.
Anyways, obviously that's not the way to go when you need high-end as I mistakenly implied in my earlier post...
ofcourse in the last sentence meant to say: Nodge the estimate up to $250k per rack ...
Well, the 300G velociraptors go for around $300. Let's say we fit 16 per 2U, that's 336 drives per rack or roughly $100k USD (not even factoring in the discounts that you get at those volumes). The remaining $100k would break down to only ~$5k per shelf, which admittedly is a bit low for beefy FC fabric. Still I wouldn't say I was off by a zero. Nodge the estimate up to $250k per shelf and we're good to go. :-)
100T isn't much by storage standards. It translates to roughly 2 racks of hardware for high-speed/low-latency serving plus roughly half a rack for archival. I'd say $150-$200k ballpark which is a drop in the bucket for hollywood. So, serving the stuff at 4 Gbit/s ain't so hard, *processing* it at that rate is a different story.
It's not "unusual", it's simply nonsense.
If your business process requires non-techie users to edit and share 32M-sized textfiles regularly then your business process is broken. The whole approach is broken beyond repair, the obvious solution would be to build some kind of frontend for the users.
You mean ZoneAlarm must be broken when, for the first time, it makes a reasonable assessment?
Probably not for many database servers because bypassing the write-cache is *the* surefire way to kill performance. It's usually much cheaper to rely on UPS, battery backed controllers and a good backup strategy than to run twice as many servers in write-through mode. Furthermore you need the (offsite) backup-strategy anyways for the usual "nuke over datacenter" scenarios...
Hmm, that's funny. So you bought a midrange UPS (which must've been quite expensive in 1997) to protect your equipment and then that very UPS goes nuts and destroys your equipment? And then the vendor has the balls to refuse RMA, much less to cover the destroyed hardware?! Which UPS-vendor was that again?
Python.
I really wonder if you're incapable or just unwilling to understand. You have lost this argument long ago because you're not making a point!
Well, but if you so want I will iterate again:
There is no "frequent mishandling" in the "non-root management of daemons" in either daemontools or djbdns. Please quote your "significant security issues" with that because to my knowledge there have been no security issues with djbdns ever. Also please define your term "mishandling"?
Remember, one of the design goals for djbdns was to provide a more secure alternative to the horror that is BIND. According to its security track record it succeeded so far.
Furthermore djbdns is considered by many to be *much* more managable and configurable than BIND. Just compare the configuration mess in BIND (especially the awkward zones format) to the data-format in tinydns that I quoted in my earlier mail. Ultimately this boils down to taste and preference but in no case is it a point to be made against djbdns - much rather one to be made against BIND. Just ask some people who have used both (I have).
Documentation? Again?
Djbdns comes with an exhaustive manual and a truckload of community documentation.
So what remains of your argument? The packaging. We can agree on that but that has nothing to do with security and is probably not the driving factor when choosing an DNS impl.
PS: Work on your reading comprehension. The post you replied to was not mine and the statement "better than bind" that you pulled out of context clearly compared the two on the basis of security problems and bugs, in the same friggin' sentence! That seems like a reasonable assertion to make when comparing djbdns (zero bugs, zero security issues) to BIND (an emberassing number of bugs and security issues), don't you think?
Ehm, I see you have an axe to grind with djb or how come you spill this unrelated rant, completely ignoring my question? None of your points are security related. In fact, some of them (malloc, "odd layout") are due to him striving for better security. Oh, and lack of documentation... Have you even looked at http://cr.yp.to/ - ever?
Anyways, I'm writing you off as a troll now. Maybe you think it's some kind of geek-chique to rant against djb these days but please, at least get a basic understanding first.
Your point is just as invalid when applied to daemontools.
Djb is well-known for being very anal about security and seperation of concerns on all fronts, which is part of the reason why parts of his software feel quierky to many. Thus your blanket statement "is often done extremely badly and with convenience over security considered paramount" simply makes no sense in the context of djbware. Where did he do any of that "badly" or prioritize convinience over security?
Sorry, but you sound like you have no idea what you're talking about.
Read the qmail security guarantee (bullet 4 under "Why is qmail secure?") to get back on topic.
I'm not a djb fanboy but I have to counter one of your points:
How is handing off control of daemons to non-root users dangerous?
Djb goes a long way in terms of separation of concerns here, qmail for example runs with no less than seven different userids. Attacking Dan's software for a lack of security is a bit like preaching to the pope. Have you looked at his security track record recently?
I do agree with your other points, though, especially with the awkward packaging and the (past) licensing problems. I have recently converted from qmail to postfix because I got tired of the patching and so far I'm not missing anything.
It's a different story with dnscache/tinydns, though. I have still not found a viable replacement for these. It's not just the immunity to this recent exploit here, it's the whole design. Yes, dealing with daemontools is annoying at best. But dealing with the bind zones-format would be so much worse! The tinydns data format is a strike of genius. Until someone comes up with something comparable or just clones the format you'll have to pry djbdns from my cold, dead fingers...