Even if you're aware of employee morale, maintaining it is hard. I burn *myself* out sometimes. I'll do the occasional marathon programming effort, thinking that it will be a one-day thing, it ends up being a week and then I discover that I can't think clearly for a day or two. A "thinking hangover". As a result, the last thing I want to do is go into work, and I resent being there. But, shit, I did it to myself. I could have simply given people more reasonable deadlines.
Anyway, I see that trait in my staff, because we hire people who like to hack, like me. When people tell me to ease up a bit, do I listen? Not usually. Same deal with them. They have immense personal pride in getting the job done, even if it burns them out. I make an effort to convince them that pacing themselves is good for both themselves and the company, but, shit, geeks are stubborn people.
Well, I suspect that allowing your evil program to swap out would make implementing an evil hypervisor very difficult, so that's one rootkit tactic that you can largely eliminate with this technique. I'm not entirely convinced that this method is practical, though, but it's an interesting idea.
I'm not worried about that. We should be concerned for our children's children, when a gigantic sea monster calling itself A'e comes up from the deep, wanting to "join with its creator".
I think your comment is spot-on, and I think the reason is this: programmers hate network programming. They hate concurrency. CODER WANT SIMPLE.
When you look at much of the development of platforms, a great deal of effort has been expended to make sure that the programming model is simple. E.g., from the perspective of a typical process running in a typical modern OS, the world still looks like a simple OS: your own flat address space and simple system calls to use to write to disk, etc. Generally, you don't have to deal with interrupts, shared memory, etc. But networking is where all of this breaks down. The location of your storage is important, because while hard disks are slow, network storage is really slow. Some parts of your application run here, and some run there, and here and there may even be wildly different platforms (e.g., 'there' could be a functional language running on a cluster, while 'here' could be a mobile web browser on a cellphone), so race conditions and slow network links and processors are a real problem.
This constant shifting around is an attempt to find the right complexity balance. I don't know if there is a 'right' balance for all scenarios, but it doesn't look like that's going to stop people from trying to find it. Just look at all the iterations of RPC out there. They all suck, too (you just can't pretend the network doesn't exist!), but that does not stop them from being useful. Just look at NFS.
It depends on what you mean by 'do'. There may be more people 'doing HTTP' on the net, i.e., more people actively involved in that application than any other, but at least half of all traffic on the net is currently BitTorrent, so by that measure, you could say that "BitTorrent is the net". I think that kind of thinking is wrong, though, no matter the dominant application. It's abundantly clear that the net is not one application, but many, many applications, and that a real strength of the current Internet is precisely that this diversity is allowed.
(Whether we need so many application protocols for all these applications is a different conversation entirely, though)
Why, they should end their sentences with lowercase lols, like you?
My wife thought for the longest time that "LOL" meant "lots of love". I asked her one day why she signed an email "LOL, your wife". I mean, I know I'm lame but "LOL, your wife"?!!!
One can be a libertarian and love the free market, but still not want to do business with companies that screw over your friends and neighbors.
And, I think, this is the essence of a free market. Free Marketeers don't (er, shouldn't) stipulate why people can choose not to purchase a product or service, just that they can. If a number of people decide, collectively, to boycott IBM, that's about as "Free Market" as it gets.
I'm no legal expert, but I was under the impression that drug laws prohibit possession and distribution, not ingestion. So perhaps in practice that's a bit of a fine point, but laws do not actually regulate your blood stream, at least, not directly.
Rent, though. I recently moved out of the Fenway neighborhood in Boston. It was uncomfortably expensive, and I make a very nice salary. Not six figures, mind you, but not bad either. Now that I've moved a couple miles out of the city, I have enough money where I can considering actually doing those discretionary things. One of my favorite Boston activities was going to the BSO, but with the cost of living in the city, I could never afford to go, even though I walked past it every day on the way to work. In many ways, that's more of a bummer than having to make a special trip into the city to actually do something fun.
If I had to guess, NYC rents are probably comparable... if not more expensive. I own a car, but like you, it was far too expensive to operate in the city. It sat in my parents' driveway 50 miles to the north. Now I actually get to use it!
I think, as you get older, the diminishing flow of music is primarily the result of one thing: your time becomes more valuable. When I was younger, I listened to lots of music. Lots of it was shit, but I sifted through it and found many gems. In college, I worked at the local radio station, and I had access to, really, insane amounts of music. I also had the habit of just up and going to shows I knew nothing about. This yielded possibly the coolest show I had ever been to, Low at the Middle East Upstairs in Cambridge, MA. Everyone just sat around the band on the floor, chilling out. Wow.
Now... I'm a bit more conservative, and as a result, I come across a lot fewer good bands. I don't want to spend the money, and heck, I don't really have the time anymore. Amazon's recommendation system sucks in this respect (it's recommending stuff that other people like you have bought... which you probably have already bought, too), but most artists have some kind of blog or Twitter thingy now, and you can find a lot of leads there, too. For instance, I just discovered The Tower of Dudes from Mike Doughty's Twitter feed. Yeah, Czech accordion-banjo punk!
I hear this a lot, but in a modern OS (e.g., one with a good scheduler) and with modern applications (ones that use either threading or cooperating processes), you can easily use a handful of processors, and yes, with normal desktop apps. Google Chrome, for instance, uses the cooperating process model, and for security reasons, I think you're going to start seeing [good] programmers divvy up their applications this way. Not only does it make application security a bit easier (separate address space for each code module), but you get real CPU-level parallelism for free. FreeBSD's new scheduler can even put threads running in the same process on different cores in some cases.
My concern isn't being able to use all those cores-- it's being able to throttle or shut them off when I'm not.
Am I the only one here who understands that client-side Javascript has absolutely nothing to do with how many cores your server has?
Web 1.0 can use plenty of cores, too, but generally your Web x.x requirements and your required server core count are orthogonal. Bandwidth and latency requirements for Web 2.0 are a different story, though. Those things tend to scale depending on how shitty your programmers are.
I think the debate is much simpler than many people make it out to be. The simple fact is that both sides (pro- and anti-abortion) play the rhetoric card to their advantage, but in neither case does it actually help to deal with the real moral and policy choices that people have to make.
Abortion is the killing of a pre-birth human. Whether we call this "murder" is a moral and legal question. For instance, war is also killing, but when it is "just" (i.e., "justified"), it is not legally considered "murder", and in many cases it is not morally considered to be "murder", either. Almost no one thinks that killing an attacker in self-defense is "murder".
So it's clear that we make this distinction between simple killing and murder, where murder is killing that should be prohibited. Morally, it is easier to make generalizations about killing than legally, where there are important public policy implications to consider. Let's take vaccination, for example. Some people consider vaccination to be "murder" because it kills people, and indeed it does-- no one disputes this. However, vaccination often saves many more people; this was especially true for smallpox. So now, we're in the uncomfortable position of having to decide whether the lives of one larger group of people is more important than the lives of another, smaller group of people. No amount of speechifying can get around this uncomfortable state, but these are the kinds of decisions that modern humans have to make.
There is good evidence that the legalization of abortion in the United States is in part responsible for the drop in crime in the 1990's. These findings are discussed in the book Freakonomics. Abortion probably also has a large economic impact on the social mobility of the affected women. So if these things are indeed the case, how do we decide what to do about abortion? It is the killing of a human, however it is also true that this human is barely what we would consider human: as far as we know, it is hardly differentiated, and as far as we know, it is not "aware" in any sense. Do the pros ouweigh the cons? What do we consider to be unacceptable? This is another difficult position to be in, but it's part of being a modern human.
Given the proportion of software-caused car accidents to human-caused accidents, I think we can more reasonably state that humans have no business being in control of braking and acceleration.
Now, are you talking about FC vs. SAS on the interface level, or are you talking about FC vs. SAS disks? Those are very expensive, but that's a non-issue for us, because we use SAS disks in our FC arrays. The cost of those FC-interface arrays is marginally more expensive than a pure SAS array, but there are things you cannot do with SAS interconnects that you can do with FC, namely switched topologies. It seems that most shops that have that requirement use NFS to emulate it. Fine, but in order to get the same kind of performance as an FC fabric, you're going to have to buy a good 10GbE switch and a number of 10GbE cards, all of which more than make up for whatever gap you originally had paying for that FC switch.
So I'm still not convinced that SAS is cheaper. Maybe for an entry-level system. Sadly, we have many more requirements than can be met by entry-level gear. I recently spent 2 months pricing this stuff out, and in the end, FC won again, despite the fact that we were willing to make a clean break from our existing SAN tech.
It should also be added that, on Slashdot at least, you can "buy" page views. I realized at some point last year that I had been reading the site for nearly ten years, and over that time I have learned a lot and made friends through this website. In fact, I just met another longtime Slashdotter yesterday, and-- he's a professor now! Time to pony up.
I still block ads for Slashdot, because I'm never going to click on one, and they are always distracting, by definition. But, as with NPR, I owe something for what I take, so I pay up. If you enjoy reading this site, you should too, especially if you ad-block.
Why distributed FS and not something like live mirroring/shadow copy? I wonder also... what do you consider an "expensive disk system"?
We played around with DIY JBOD a bit (i.e., moving the complexity up into software) because it seemed a lot cheaper, but we have yet to get the thing to operate as reliably and simply as our fibre channel RAID units. The main problem we're running into is that for SATA to be practical, you need to multiplex several SATA disks onto single SATA ports, but that software support for doing this (at least in Linux and Solaris) is terrible. SAS interconnects are obviously better in this regard, but the hardware doesn't end up being any cheaper than standard fibre channel RAID, so you end up spending the same amount of money but doing more work because the spanning/striping/whatever is not managed for you. Also, under Linux, we've been somewhat dissatisfied with mdadm compared with something like OpenBSD's bioctl (which is easy to use and AWESOME). Sadly, OpenBSD is severely limited in some other areas that make it inappropriate to manage large disks (very large filesystems are not possible... fsck is prohibitively expensive with large volumes... etc...).
The other thing I've been wondering, and it is unclear to me whether distributed filesystems solve this is: it seems like they're designed to spread data around on many nodes. Are they also good for allowing access FROM many hosts? E.g., our StorNext system allows us to plug any client into a fibre channel switch and simply use the disk without really having to think through what that means. But StorNext limits us because we can't plug, say, an OpenBSD machine into it (proprietary drivers, no client software) and that licensing can get expensive fast. StorNext's documentation also leaves something to be desired, and their salespeople do not inspire confidence (none of them could tell us how to actually install a license on a machine... I had to figure it out myself).
Slashdot Mirror
Oh, but Sony's been doing it for years!
Even if you're aware of employee morale, maintaining it is hard. I burn *myself* out sometimes. I'll do the occasional marathon programming effort, thinking that it will be a one-day thing, it ends up being a week and then I discover that I can't think clearly for a day or two. A "thinking hangover". As a result, the last thing I want to do is go into work, and I resent being there. But, shit, I did it to myself. I could have simply given people more reasonable deadlines.
Anyway, I see that trait in my staff, because we hire people who like to hack, like me. When people tell me to ease up a bit, do I listen? Not usually. Same deal with them. They have immense personal pride in getting the job done, even if it burns them out. I make an effort to convince them that pacing themselves is good for both themselves and the company, but, shit, geeks are stubborn people.
Well, I suspect that allowing your evil program to swap out would make implementing an evil hypervisor very difficult, so that's one rootkit tactic that you can largely eliminate with this technique. I'm not entirely convinced that this method is practical, though, but it's an interesting idea.
OK, taking you seriously for a moment. Scroll down for the "where" and "impact" graphs.
Windows Server 2008
And, because Secunia categorizes each OpenBSD release separately...
OpenBSD 4.4
OpenBSD 4.3
OpenBSD 4.2
OpenBSD 4.1
OpenBSD 4.0
Obviously, the most important one in there is "system access", "from remote". Big difference, no?
I'm not worried about that. We should be concerned for our children's children, when a gigantic sea monster calling itself A'e comes up from the deep, wanting to "join with its creator".
I think your comment is spot-on, and I think the reason is this: programmers hate network programming. They hate concurrency. CODER WANT SIMPLE.
When you look at much of the development of platforms, a great deal of effort has been expended to make sure that the programming model is simple. E.g., from the perspective of a typical process running in a typical modern OS, the world still looks like a simple OS: your own flat address space and simple system calls to use to write to disk, etc. Generally, you don't have to deal with interrupts, shared memory, etc. But networking is where all of this breaks down. The location of your storage is important, because while hard disks are slow, network storage is really slow. Some parts of your application run here, and some run there, and here and there may even be wildly different platforms (e.g., 'there' could be a functional language running on a cluster, while 'here' could be a mobile web browser on a cellphone), so race conditions and slow network links and processors are a real problem.
This constant shifting around is an attempt to find the right complexity balance. I don't know if there is a 'right' balance for all scenarios, but it doesn't look like that's going to stop people from trying to find it. Just look at all the iterations of RPC out there. They all suck, too (you just can't pretend the network doesn't exist!), but that does not stop them from being useful. Just look at NFS.
It depends on what you mean by 'do'. There may be more people 'doing HTTP' on the net, i.e., more people actively involved in that application than any other, but at least half of all traffic on the net is currently BitTorrent, so by that measure, you could say that "BitTorrent is the net". I think that kind of thinking is wrong, though, no matter the dominant application. It's abundantly clear that the net is not one application, but many, many applications, and that a real strength of the current Internet is precisely that this diversity is allowed.
(Whether we need so many application protocols for all these applications is a different conversation entirely, though)
Awesome. Thanks for the link. She'll be very pleased to hear this!
Oh, I just thought that guy had chronic keyboard diarrhea. You mean it's more than one guy?!! It's contagious!
Why, they should end their sentences with lowercase lols, like you?
My wife thought for the longest time that "LOL" meant "lots of love". I asked her one day why she signed an email "LOL, your wife". I mean, I know I'm lame but "LOL, your wife"?!!!
One can be a libertarian and love the free market, but still not want to do business with companies that screw over your friends and neighbors.
And, I think, this is the essence of a free market. Free Marketeers don't (er, shouldn't) stipulate why people can choose not to purchase a product or service, just that they can. If a number of people decide, collectively, to boycott IBM, that's about as "Free Market" as it gets.
But... uid... ??? Does. Not. Compute.
I'm no legal expert, but I was under the impression that drug laws prohibit possession and distribution, not ingestion. So perhaps in practice that's a bit of a fine point, but laws do not actually regulate your blood stream, at least, not directly.
Rent, though. I recently moved out of the Fenway neighborhood in Boston. It was uncomfortably expensive, and I make a very nice salary. Not six figures, mind you, but not bad either. Now that I've moved a couple miles out of the city, I have enough money where I can considering actually doing those discretionary things. One of my favorite Boston activities was going to the BSO, but with the cost of living in the city, I could never afford to go, even though I walked past it every day on the way to work. In many ways, that's more of a bummer than having to make a special trip into the city to actually do something fun.
If I had to guess, NYC rents are probably comparable... if not more expensive. I own a car, but like you, it was far too expensive to operate in the city. It sat in my parents' driveway 50 miles to the north. Now I actually get to use it!
I think, as you get older, the diminishing flow of music is primarily the result of one thing: your time becomes more valuable. When I was younger, I listened to lots of music. Lots of it was shit, but I sifted through it and found many gems. In college, I worked at the local radio station, and I had access to, really, insane amounts of music. I also had the habit of just up and going to shows I knew nothing about. This yielded possibly the coolest show I had ever been to, Low at the Middle East Upstairs in Cambridge, MA. Everyone just sat around the band on the floor, chilling out. Wow.
Now... I'm a bit more conservative, and as a result, I come across a lot fewer good bands. I don't want to spend the money, and heck, I don't really have the time anymore. Amazon's recommendation system sucks in this respect (it's recommending stuff that other people like you have bought... which you probably have already bought, too), but most artists have some kind of blog or Twitter thingy now, and you can find a lot of leads there, too. For instance, I just discovered The Tower of Dudes from Mike Doughty's Twitter feed. Yeah, Czech accordion-banjo punk!
Computers are awesome.
http://slashdot.org/comments.pl?sid=1575426&cid=31405814
You are not going to put these in your gaming rig
I hear this a lot, but in a modern OS (e.g., one with a good scheduler) and with modern applications (ones that use either threading or cooperating processes), you can easily use a handful of processors, and yes, with normal desktop apps. Google Chrome, for instance, uses the cooperating process model, and for security reasons, I think you're going to start seeing [good] programmers divvy up their applications this way. Not only does it make application security a bit easier (separate address space for each code module), but you get real CPU-level parallelism for free. FreeBSD's new scheduler can even put threads running in the same process on different cores in some cases.
My concern isn't being able to use all those cores-- it's being able to throttle or shut them off when I'm not.
Am I the only one here who understands that client-side Javascript has absolutely nothing to do with how many cores your server has?
Web 1.0 can use plenty of cores, too, but generally your Web x.x requirements and your required server core count are orthogonal. Bandwidth and latency requirements for Web 2.0 are a different story, though. Those things tend to scale depending on how shitty your programmers are.
I think the debate is much simpler than many people make it out to be. The simple fact is that both sides (pro- and anti-abortion) play the rhetoric card to their advantage, but in neither case does it actually help to deal with the real moral and policy choices that people have to make.
Abortion is the killing of a pre-birth human. Whether we call this "murder" is a moral and legal question. For instance, war is also killing, but when it is "just" (i.e., "justified"), it is not legally considered "murder", and in many cases it is not morally considered to be "murder", either. Almost no one thinks that killing an attacker in self-defense is "murder".
So it's clear that we make this distinction between simple killing and murder, where murder is killing that should be prohibited. Morally, it is easier to make generalizations about killing than legally, where there are important public policy implications to consider. Let's take vaccination, for example. Some people consider vaccination to be "murder" because it kills people, and indeed it does-- no one disputes this. However, vaccination often saves many more people; this was especially true for smallpox. So now, we're in the uncomfortable position of having to decide whether the lives of one larger group of people is more important than the lives of another, smaller group of people. No amount of speechifying can get around this uncomfortable state, but these are the kinds of decisions that modern humans have to make.
There is good evidence that the legalization of abortion in the United States is in part responsible for the drop in crime in the 1990's. These findings are discussed in the book Freakonomics. Abortion probably also has a large economic impact on the social mobility of the affected women. So if these things are indeed the case, how do we decide what to do about abortion? It is the killing of a human, however it is also true that this human is barely what we would consider human: as far as we know, it is hardly differentiated, and as far as we know, it is not "aware" in any sense. Do the pros ouweigh the cons? What do we consider to be unacceptable? This is another difficult position to be in, but it's part of being a modern human.
Given the proportion of software-caused car accidents to human-caused accidents, I think we can more reasonably state that humans have no business being in control of braking and acceleration.
Now, are you talking about FC vs. SAS on the interface level, or are you talking about FC vs. SAS disks? Those are very expensive, but that's a non-issue for us, because we use SAS disks in our FC arrays. The cost of those FC-interface arrays is marginally more expensive than a pure SAS array, but there are things you cannot do with SAS interconnects that you can do with FC, namely switched topologies. It seems that most shops that have that requirement use NFS to emulate it. Fine, but in order to get the same kind of performance as an FC fabric, you're going to have to buy a good 10GbE switch and a number of 10GbE cards, all of which more than make up for whatever gap you originally had paying for that FC switch.
So I'm still not convinced that SAS is cheaper. Maybe for an entry-level system. Sadly, we have many more requirements than can be met by entry-level gear. I recently spent 2 months pricing this stuff out, and in the end, FC won again, despite the fact that we were willing to make a clean break from our existing SAN tech.
It should also be added that, on Slashdot at least, you can "buy" page views. I realized at some point last year that I had been reading the site for nearly ten years, and over that time I have learned a lot and made friends through this website. In fact, I just met another longtime Slashdotter yesterday, and-- he's a professor now! Time to pony up.
I still block ads for Slashdot, because I'm never going to click on one, and they are always distracting, by definition. But, as with NPR, I owe something for what I take, so I pay up. If you enjoy reading this site, you should too, especially if you ad-block.
Why distributed FS and not something like live mirroring/shadow copy? I wonder also... what do you consider an "expensive disk system"?
We played around with DIY JBOD a bit (i.e., moving the complexity up into software) because it seemed a lot cheaper, but we have yet to get the thing to operate as reliably and simply as our fibre channel RAID units. The main problem we're running into is that for SATA to be practical, you need to multiplex several SATA disks onto single SATA ports, but that software support for doing this (at least in Linux and Solaris) is terrible. SAS interconnects are obviously better in this regard, but the hardware doesn't end up being any cheaper than standard fibre channel RAID, so you end up spending the same amount of money but doing more work because the spanning/striping/whatever is not managed for you. Also, under Linux, we've been somewhat dissatisfied with mdadm compared with something like OpenBSD's bioctl (which is easy to use and AWESOME). Sadly, OpenBSD is severely limited in some other areas that make it inappropriate to manage large disks (very large filesystems are not possible... fsck is prohibitively expensive with large volumes... etc...).
The other thing I've been wondering, and it is unclear to me whether distributed filesystems solve this is: it seems like they're designed to spread data around on many nodes. Are they also good for allowing access FROM many hosts? E.g., our StorNext system allows us to plug any client into a fibre channel switch and simply use the disk without really having to think through what that means. But StorNext limits us because we can't plug, say, an OpenBSD machine into it (proprietary drivers, no client software) and that licensing can get expensive fast. StorNext's documentation also leaves something to be desired, and their salespeople do not inspire confidence (none of them could tell us how to actually install a license on a machine... I had to figure it out myself).
There's the problem, though. It didn't. That's why they called in the surgeons.