I'm not sure what an RJ-45 SOL is. (RJ-45 serial consoles?)
Anyway, I had a cage next door to them for a while, and checked out their hardware a little. This was a few years ago, but at that time, it didn't look like they had any kind of consoles. There certainly wasn't any VGA, and they were using desktop motherboards, so no serial consoles.
For their application, why bother with a console at all? Image a bunch of machines, throw them in the rack, and never think about them again.
Please reread the first sentence of my post. I'm not saying this suit is legitimate.
Your argument is invalid because even if the people filing this suit improved their lives - a worthwhile goal - it still doesn't fix their complaint, that the cars are less fuel efficient than they should be. (Again, I'm not saying that the lawsuit is valid, just that your calling them hypocrites doesn't follow.)
Even if we restructure California cities so that we're not hopelessly dependant on cars, making the cars more fuel efficient is still a worthwhile goal. It's not an either-or situation.
Regardless of what you think of this suit, your argument is invalid. Hypothetically, these people might well *want* to buy a lower gas mileage car, but can't because the car companies are preventing such a thing from coming to market.
It's my opinion that the way to get people to behave responsibly is to trust them MORE.
This article is calling out how terrible it is because of a couple problems with trusting poeple. But sociology's a complicated thing. If these are really the biggest problems that Digg is having due to their trust model, I'd say they're doing pretty good. It certainly pales in comparison to the problems you get with people who are trying by social or technical means to break out of the little prison you put them in.
I disagree. I think a good bit of Google's success is based on not being evil. In some markets, evil works, but it's not the only way to succeed big most places.
I understand the need for shockpoofing the packaging, but Dell's seems WILDLY overpackaged. We could fit 5 HP laptop boxes or 10 Apple laptop boxes into one Dell laptop box. And the HPs and Apples all survived shipping just fine in their smaller boxes. So either Dell thinks their laptops are fragile (We've found them to be comparable to HP's and Apple's), or they're overpackaging them.
Reading a few of these, they can be excused away at least somewhat: They're for one-off items, that perhaps the company just put into one of the boxes they had on hand.
The ones that bug the hell out of me are the big companies that ship stuff completely overpackaged *routinely* for completely standard items.
Example 1: Dell Latitude notebooks. They come in a 2'x2'x2' box. Inside this are a few smaller boxes, suspended in the middle with some foam standoffs. Open those up, and there's more foam surrounding the notebook. Open another one, bigger than the entire notebook, with cardboard standoffs holding the battery. Open another one that has documentation and CDs, each wrapped in plastic. I'd estimate that 80% of the packaging is air space. Of the 20% non-air, 50% is foam. By comparison, Macbooks come very nicely packed. We can fit 10 macbooks in their packaging inside one Dell notebook box, with plenty of rattling around room to spare. This is particularly annoying, because it takes up HUGE amounts of storage space for us. We have to at least shed the outer box to compress things down before they go in the store room.
Example 2: Ordering keyboards from HP. Just a keyboard. Basic model. They take the keyboard and put it in plastic. Then they put that into a box (#1).
If you order a keyboard a la carte, they have another box, #2, custom made just the right size to fit Box #1, so they can ship it to you. This seems to be done for the purpose of having a different ordering number for the unit. IE, the part code for a PC means you get a box with a PC, a manual, and a Box #1. The part code for a keyboard means a box with a Box #1.
If you order 10 keyboards, they put 10 Box #2s into an aggregator box, Box #3.
Then they put Box #3 into a shipping box, Box #4, which gets the shipping label.
Thus, boxes:
#1: Protect the keyboard #2: Add a part code #3: Bundle 10 keyboards together #4: Place to put the shipping label
It's almost like the joke recursive gift box I saw a friend get for their birthday one year.
What do you mean by "Server"? What's it serving? The web site that you use to make money? Your personal mail server? The thing that streams mp3s to the rest of the house? You mention DNS. Does that mean internal DNS for your house, or external DNS for your domain?
What do you mean by "Reliable"? Laptops almost certainly don't have the reliability you want for any of the above purposes (Heat build up, unreliable fans), but it's still a relative term.
What's the purpose of keeping a server running if your network goes down?
A suggestion: Several companies makes 12v power supplies for Mini-itx motherboards. These systems can be built to draw very little power in the first place, and eliminating two conversion cycles (The UPS and the AC power supply) gives you a big efficiency gain. Add a float charger big enough to keep up with the small power supply, and a couple deep cycle batteries, and you have a great DIY long-runtime UPS. I've not tried this, though it should be easy (getting a suitable charger is the only hard part). The mini-itx system gives you the low power draw of a laptop, but lets you design proper cooling into the case.
If you're not the DIY type, just get one of those low power mini-itx systems, and use an off the shelf UPS. Even a large UPS will cost you less than replacing laptop parts that will likely fail in 100% duty cycle use.
If this is for internet-facing services: These days, I'd suggest not trying to serve out of your house. Rent a VPS. They're dirt cheap, and even mediocre data centers have better connectivity, power, and hardware reliability than you're going to get out of a laptop at home.
Deadlines for releases are different from deadlines for features.
You *have* to set a release deadline, or you'll be stuck in continuous development. That's not a bad thing unless they're trying to push half-baked features to meet the deadline. For Firefox, they're just choosing the bits that will be ready in time, and delaying the features that aren't.
So I think they're holding to both of those statements, if you look at it in terms of "deadlines for features".
They basically made a FPGA (field programmable gate array) that can plug directly into HyperTransport (the Opteron CPU bus). FPGAs let you efficiently solve many problems that a general purpose processor can't. This has been done with PCI cards before, but the PCI is too slow for many uses. Giving it direct access to HT solves that problem.
We're talking about the 60th percentile and below, not people living in poverty. The 50th percentile - median income - was $42k in 2001. That's enough to pay a mortgage on a nice house, own a car and DVD player, etc, and if you're responsible with your money, pay a little extra principal on your note each month, and pay off your credit cards. Instead, people at this level tend to carry tens of thousands in consumer debt (ie, other than their mortgage).
At the 20th percentile - $18k - you won't have a mortgage, but you should be able to live decently with a little savings, NOT a mountain of credit card debt.
So yeah, the kind of "poor people" we're talking about tend to have DVD players and health insurance.
I mean 1 in 10,000 dying from cancer or other reasons caused by higher radiation levels, in addition to other causes. In other words, a slight, but measurable, increase in health problems.
This changes when you have multiple LDAs and MUAs sharing an NFS store. Locking matters a lot. On mbox, if you have a user that has a 500MB mailbox, and they delete the first message, the whole file has to be rewritten. While that's happening, all your SMTP servers have to queue mail for that user, because the mbox is locked. When you have a user sitting there incrementally deleting messages one by one off the top of their mail, at the same time as spammers are delivering mail to the end of the file, that can make stuff backlog pretty bad.
Issue #2: some mail clients create multiple concurrent connections to the server when you're reading mail. With mbox, this hurts.:)
Aside from the locking issue, this creates a ton of IO on your NFS server, due to constant mbox rewrites, as well as simply having to read the whole file every time a user connects. The sheer volume of IO for mbox is really the bigger problem.
It's a lot easier to write a good POP client than a good SMTP server, so many customer service apps are written this way. It ends up in the same DB either way, so they write it with the protocol least likely to break things.
...don't touch mbox format. Whatever software you choose, make sure it uses Maildir.
You shouldn't state this as an absolute, because it's not. You also need to give reasons WHY to use maildir.
An example exception case: We had an application where thousands of very small emails needed to be delivered to a single mailbox every minute. They all get picked up every minute by POP, and all messages are deleted every cycle. mbox is *vastly* better in this scenario, because you don't have to create all the files, move them around a few times, stat large dirs every time POP runs, etc. With mbox, all the delivery threads become sequential, so you cut down seek overhead, and the POP read becomes a single large file read, which is far faster. You also cut way down on metadata updates, and caching works better.
mbox shines in this scenario, and it's not that uncommon. Many customer service apps work like this.
In the situation of handling many users's email in a scalable system Maildir is usually better (NFS-safe, concurrent delivery, efficient individual message deletion, etc), but you've not even considered the other range of things available. MH and database backends come to mind. Each has their good and bad points.
It's been a while since I built a mid-size email system, but the last time I did it I used:
Data stores were maildirs on NetApps SMTP servers running Postfix IMAP servers running Courier IMAP Logins via NIS IMAP and SMTP failover by means of load balancers
The SMTP and IMAP servers get NIS-distributed automounter tables, so everyone's homedir is available everywhere. The load balancers distribute the load out to the SMTP and IMAP servers, and work around any that fail. Mail comes into the SMTP servers, and Postfix delivers to maildirs in the users' homedirs. Any SMTP server can deliver to any user. Users log in with IMAP on the Courier IMAP servers. Again, all homedirs are everywhere, so it doesn't matter which server they hit.
Adding capacity at any point is easy - you just add more servers of the appropriate type when you need more. IMAP and SMTP are fully redundant. Load balancers usually only operate in failover pairs, but you can add more A records in DNS for more LB pairs if you need it.
The one sticky point is the data stores on the NFS servers. Adding capacity is easy (just add more servers). but there's no easy way to make this fully redundant. See notes for more.
So there you have it. That'll scale to a pretty large system, and it's simple to implement. It's not THE MOST scalable system, but if you have to ask, this is probably sufficient for your needs.
Notes:
You must use maildirs, not mbox. Maildirs perform very well even on NFS, because there can be multiple simultaneous readers and writers. mbox requires locking.
With NetApp, or Red Hat Cluster Server, or any other cluster NFS server, you can make the head end redundant, so your disk shelf becomes the last single point of failure. If you run RAID 1+0, you can have all the disks mirrored across two shelves, so at least the hardware is completely redundant. However, there are still rare, but possible failure modes. STONITH is, ultimately, a problem that has no perfect solution. (Look it up if you're not familiar with STONITH.)
NetApp makes very reliable NFS servers. Even in single head configurations my uptime experience has been incredibly good. Dual head is even better. But they're god awful expensive. There are other ones you can buy at all different price points. Clustered file systems like Coda sound really sexy, but they're still half baked. Lustre http://www.lustre.org/ might work well, but it wasn't available when I last did this, so I can't say. Choose what's appropriate to your needs and budget.
I used NIS. These days LDAP is more fashionable. Make your LDAP server redundant of course.
You need redundant networks. In the simplest case, put half of each type of servers (IMAP, SMTP, LB, NFS) on two different switches.
I never bothered with POP, but you can get POP servers for maildirs, too.
Configure your load balancers to balance per session - IE, if a user creates multiple IMAP connections, they all go to the same server. This helps keep down the number of NFS mounts, LDAP requests, etc.
Software opinions: I like Postfix and Courier. They're simple, robust, flexible enough for most situations, and perform very well. Cyrus also has a good following in the large-scale arena, but does things different. Qmail's non-OSS license prevents people from releasing versions that strip out djb's quirky way of doing things, which is why I left it for Postfix (and never looked back). Sendmail doesn't suck as much as it used to, but I haven't really seen why I SHOULD use it these days either. Any of these can be made to work, though, so use whatever you're comfortable with.
Tip for any email system: outright reject (IE, don't accept at all, don't send to someone's spam folder) as much spam as you can. If 90% of your mail is spam, and you reject the 90% most-likely-spam (delivering the other 10% more questionable stuff to a spam folder), you've just increased your mail performance and disk space by > 5x.
Slashdot Mirror
I'm not sure what an RJ-45 SOL is. (RJ-45 serial consoles?)
Anyway, I had a cage next door to them for a while, and checked out their hardware a little. This was a few years ago, but at that time, it didn't look like they had any kind of consoles. There certainly wasn't any VGA, and they were using desktop motherboards, so no serial consoles.
For their application, why bother with a console at all? Image a bunch of machines, throw them in the rack, and never think about them again.
Please reread the first sentence of my post. I'm not saying this suit is legitimate.
Your argument is invalid because even if the people filing this suit improved their lives - a worthwhile goal - it still doesn't fix their complaint, that the cars are less fuel efficient than they should be. (Again, I'm not saying that the lawsuit is valid, just that your calling them hypocrites doesn't follow.)
Even if we restructure California cities so that we're not hopelessly dependant on cars, making the cars more fuel efficient is still a worthwhile goal. It's not an either-or situation.
Regardless of what you think of this suit, your argument is invalid. Hypothetically, these people might well *want* to buy a lower gas mileage car, but can't because the car companies are preventing such a thing from coming to market.
You're making the measurement more complicated than it has to be. Light bulbs and ovens list how much power they use.
That's why we have the Watts Up Pro: http://www.thinkgeek.com/gadgets/electronic/7acf/ . It even has an RS232 interface. But it's relatively expensive.
I have a Kill-A-Watt, and it has all the problems you mentioned, but it also does everything it promised to do, for cheap. I'm quite happy with it.
It's my opinion that the way to get people to behave responsibly is to trust them MORE.
This article is calling out how terrible it is because of a couple problems with trusting poeple. But sociology's a complicated thing. If these are really the biggest problems that Digg is having due to their trust model, I'd say they're doing pretty good. It certainly pales in comparison to the problems you get with people who are trying by social or technical means to break out of the little prison you put them in.
No. Marijuana is the Alcohol Prohibition of the 21st century.
I disagree. I think a good bit of Google's success is based on not being evil. In some markets, evil works, but it's not the only way to succeed big most places.
I understand the need for shockpoofing the packaging, but Dell's seems WILDLY overpackaged. We could fit 5 HP laptop boxes or 10 Apple laptop boxes into one Dell laptop box. And the HPs and Apples all survived shipping just fine in their smaller boxes. So either Dell thinks their laptops are fragile (We've found them to be comparable to HP's and Apple's), or they're overpackaging them.
Reading a few of these, they can be excused away at least somewhat: They're for one-off items, that perhaps the company just put into one of the boxes they had on hand.
The ones that bug the hell out of me are the big companies that ship stuff completely overpackaged *routinely* for completely standard items.
Example 1: Dell Latitude notebooks. They come in a 2'x2'x2' box. Inside this are a few smaller boxes, suspended in the middle with some foam standoffs. Open those up, and there's more foam surrounding the notebook. Open another one, bigger than the entire notebook, with cardboard standoffs holding the battery. Open another one that has documentation and CDs, each wrapped in plastic. I'd estimate that 80% of the packaging is air space. Of the 20% non-air, 50% is foam. By comparison, Macbooks come very nicely packed. We can fit 10 macbooks in their packaging inside one Dell notebook box, with plenty of rattling around room to spare. This is particularly annoying, because it takes up HUGE amounts of storage space for us. We have to at least shed the outer box to compress things down before they go in the store room.
Example 2: Ordering keyboards from HP. Just a keyboard. Basic model. They take the keyboard and put it in plastic. Then they put that into a box (#1).
If you order a keyboard a la carte, they have another box, #2, custom made just the right size to fit Box #1, so they can ship it to you. This seems to be done for the purpose of having a different ordering number for the unit. IE, the part code for a PC means you get a box with a PC, a manual, and a Box #1. The part code for a keyboard means a box with a Box #1.
If you order 10 keyboards, they put 10 Box #2s into an aggregator box, Box #3.
Then they put Box #3 into a shipping box, Box #4, which gets the shipping label.
Thus, boxes:
#1: Protect the keyboard
#2: Add a part code
#3: Bundle 10 keyboards together
#4: Place to put the shipping label
It's almost like the joke recursive gift box I saw a friend get for their birthday one year.
The computer override for the landing gear created a NEW failure mode, but did that cause more crashes than it prevented?
If not, why not keep the computer safety?
What do you mean by "Server"? What's it serving? The web site that you use to make money? Your personal mail server? The thing that streams mp3s to the rest of the house? You mention DNS. Does that mean internal DNS for your house, or external DNS for your domain?
What do you mean by "Reliable"? Laptops almost certainly don't have the reliability you want for any of the above purposes (Heat build up, unreliable fans), but it's still a relative term.
What's the purpose of keeping a server running if your network goes down?
A suggestion: Several companies makes 12v power supplies for Mini-itx motherboards. These systems can be built to draw very little power in the first place, and eliminating two conversion cycles (The UPS and the AC power supply) gives you a big efficiency gain. Add a float charger big enough to keep up with the small power supply, and a couple deep cycle batteries, and you have a great DIY long-runtime UPS. I've not tried this, though it should be easy (getting a suitable charger is the only hard part). The mini-itx system gives you the low power draw of a laptop, but lets you design proper cooling into the case.
If you're not the DIY type, just get one of those low power mini-itx systems, and use an off the shelf UPS. Even a large UPS will cost you less than replacing laptop parts that will likely fail in 100% duty cycle use.
If this is for internet-facing services: These days, I'd suggest not trying to serve out of your house. Rent a VPS. They're dirt cheap, and even mediocre data centers have better connectivity, power, and hardware reliability than you're going to get out of a laptop at home.
Somehow, I suspect you use a Mac. :)
Deadlines for releases are different from deadlines for features.
You *have* to set a release deadline, or you'll be stuck in continuous development. That's not a bad thing unless they're trying to push half-baked features to meet the deadline. For Firefox, they're just choosing the bits that will be ready in time, and delaying the features that aren't.
So I think they're holding to both of those statements, if you look at it in terms of "deadlines for features".
They basically made a FPGA (field programmable gate array) that can plug directly into HyperTransport (the Opteron CPU bus). FPGAs let you efficiently solve many problems that a general purpose processor can't. This has been done with PCI cards before, but the PCI is too slow for many uses. Giving it direct access to HT solves that problem.
That's a pretty cool niche.
We're talking about the 60th percentile and below, not people living in poverty. The 50th percentile - median income - was $42k in 2001. That's enough to pay a mortgage on a nice house, own a car and DVD player, etc, and if you're responsible with your money, pay a little extra principal on your note each month, and pay off your credit cards. Instead, people at this level tend to carry tens of thousands in consumer debt (ie, other than their mortgage).
At the 20th percentile - $18k - you won't have a mortgage, but you should be able to live decently with a little savings, NOT a mountain of credit card debt.
So yeah, the kind of "poor people" we're talking about tend to have DVD players and health insurance.
Sure, but rational comparisons go out the window when you're talking about nuclear power. :)
I mean 1 in 10,000 dying from cancer or other reasons caused by higher radiation levels, in addition to other causes. In other words, a slight, but measurable, increase in health problems.
You're missing my point. I pulled the 10,000 number out of my... um, hat.
My point is that humans are pickier than animals. Humans will consider something completely uninhabitable LONG before it's biologically unsurvivable.
This changes when you have multiple LDAs and MUAs sharing an NFS store. Locking matters a lot. On mbox, if you have a user that has a 500MB mailbox, and they delete the first message, the whole file has to be rewritten. While that's happening, all your SMTP servers have to queue mail for that user, because the mbox is locked. When you have a user sitting there incrementally deleting messages one by one off the top of their mail, at the same time as spammers are delivering mail to the end of the file, that can make stuff backlog pretty bad.
:)
Issue #2: some mail clients create multiple concurrent connections to the server when you're reading mail. With mbox, this hurts.
Aside from the locking issue, this creates a ton of IO on your NFS server, due to constant mbox rewrites, as well as simply having to read the whole file every time a user connects. The sheer volume of IO for mbox is really the bigger problem.
I was just illustrating that it's a more complicated thing than "use maildirs", and that's an example I'm familiar with.
It's a lot easier to write a good POP client than a good SMTP server, so many customer service apps are written this way. It ends up in the same DB either way, so they write it with the protocol least likely to break things.
You shouldn't state this as an absolute, because it's not. You also need to give reasons WHY to use maildir.
An example exception case: We had an application where thousands of very small emails needed to be delivered to a single mailbox every minute. They all get picked up every minute by POP, and all messages are deleted every cycle. mbox is *vastly* better in this scenario, because you don't have to create all the files, move them around a few times, stat large dirs every time POP runs, etc. With mbox, all the delivery threads become sequential, so you cut down seek overhead, and the POP read becomes a single large file read, which is far faster. You also cut way down on metadata updates, and caching works better.
mbox shines in this scenario, and it's not that uncommon. Many customer service apps work like this.
In the situation of handling many users's email in a scalable system Maildir is usually better (NFS-safe, concurrent delivery, efficient individual message deletion, etc), but you've not even considered the other range of things available. MH and database backends come to mind. Each has their good and bad points.
So why are we surprised that any of this is happening?
It's been a while since I built a mid-size email system, but the last time I did it I used:
Data stores were maildirs on NetApps
SMTP servers running Postfix
IMAP servers running Courier IMAP
Logins via NIS
IMAP and SMTP failover by means of load balancers
The SMTP and IMAP servers get NIS-distributed automounter tables, so everyone's homedir is available everywhere. The load balancers distribute the load out to the SMTP and IMAP servers, and work around any that fail. Mail comes into the SMTP servers, and Postfix delivers to maildirs in the users' homedirs. Any SMTP server can deliver to any user. Users log in with IMAP on the Courier IMAP servers. Again, all homedirs are everywhere, so it doesn't matter which server they hit.
Adding capacity at any point is easy - you just add more servers of the appropriate type when you need more. IMAP and SMTP are fully redundant. Load balancers usually only operate in failover pairs, but you can add more A records in DNS for more LB pairs if you need it.
The one sticky point is the data stores on the NFS servers. Adding capacity is easy (just add more servers). but there's no easy way to make this fully redundant. See notes for more.
So there you have it. That'll scale to a pretty large system, and it's simple to implement. It's not THE MOST scalable system, but if you have to ask, this is probably sufficient for your needs.
Notes:
You must use maildirs, not mbox. Maildirs perform very well even on NFS, because there can be multiple simultaneous readers and writers. mbox requires locking.
With NetApp, or Red Hat Cluster Server, or any other cluster NFS server, you can make the head end redundant, so your disk shelf becomes the last single point of failure. If you run RAID 1+0, you can have all the disks mirrored across two shelves, so at least the hardware is completely redundant. However, there are still rare, but possible failure modes. STONITH is, ultimately, a problem that has no perfect solution. (Look it up if you're not familiar with STONITH.)
NetApp makes very reliable NFS servers. Even in single head configurations my uptime experience has been incredibly good. Dual head is even better. But they're god awful expensive. There are other ones you can buy at all different price points. Clustered file systems like Coda sound really sexy, but they're still half baked. Lustre http://www.lustre.org/ might work well, but it wasn't available when I last did this, so I can't say. Choose what's appropriate to your needs and budget.
I used NIS. These days LDAP is more fashionable. Make your LDAP server redundant of course.
You need redundant networks. In the simplest case, put half of each type of servers (IMAP, SMTP, LB, NFS) on two different switches.
I never bothered with POP, but you can get POP servers for maildirs, too.
Configure your load balancers to balance per session - IE, if a user creates multiple IMAP connections, they all go to the same server. This helps keep down the number of NFS mounts, LDAP requests, etc.
Software opinions: I like Postfix and Courier. They're simple, robust, flexible enough for most situations, and perform very well. Cyrus also has a good following in the large-scale arena, but does things different. Qmail's non-OSS license prevents people from releasing versions that strip out djb's quirky way of doing things, which is why I left it for Postfix (and never looked back). Sendmail doesn't suck as much as it used to, but I haven't really seen why I SHOULD use it these days either. Any of these can be made to work, though, so use whatever you're comfortable with.
Tip for any email system: outright reject (IE, don't accept at all, don't send to someone's spam folder) as much spam as you can. If 90% of your mail is spam, and you reject the 90% most-likely-spam (delivering the other 10% more questionable stuff to a spam folder), you've just increased your mail performance and disk space by > 5x.
Good luck!