The issue isn't the number of bytes per second, it's the number of distinct requests. The data is _way_ bigger than will fit in memory, and hard disks can only do 100-150 seeks per second so you need a lot of them to serve from disk. A naive implementation will go to disk many times for a single file, because filesystems aren't designed for this many small files. So this is really an issue of getting exactly the right stuff in memory so you can serve hot content from memory, and if you go to disk you seek exactly once instead of several times.
And what happens to the money that they withold from Peter Jackson? Does it go to feed the poor?
The people running the studio are even more obscenely rich than Peter Jackson. If they agreed to a contract they should honor it, and he's perfectly right to sue if they don't.
And more importantly, the studios are screwing a lot of other people who aren't already rich. If they lose this case they might be less likely to pull the same scam against someone who will really be hurt by it.
no library code should ever cause the whole application to abort, ever. There are few absolutes in software development, but this is one of them.
I think a more accurate way to state that would be: No library code should ever cause the whole application to abort when the application is being used by an end user.
Under development it's a completely different situation. The top goal isn't running cleanly at all cost; the top goal is finding anything that might be a bug.
That's the whole point of assert. It lets you know when something is wrong in debug mode, but in release mode it's #defined as a no-op. So it fills your criteria perfectly. It never does anything to a real user's application.
This isn't always a good thing of course. As you mentioned above, it your assert has side effects you could be in big trouble when you switch to release and they don't happen. Or if you use assert to catch legitimate runtime errors you end up #ifdefing away your error checking when it really matters. But used correctly, assert can be useful.
Re:Important points of a good manager
on
Geeks in Management?
·
· Score: 2, Informative
Great comment. I would add a couple more things:
- Don't let "giving your team input" turn into "decisions by commitee". Group decisions don't turn out well. The way to give your team input is to empower them to do particular tasks. For example: instead of sitting down with six people and trying to decide everything, split the project into six parts and give one person ablsolute control over each of them. This reduces conflict, makes people more productive, and makes people feel good about themselves. (of course you'd better do a good job of splitting up the task, which will require input from your team)
- Learn how to delegate tasks: When you ask someone to do something make it very clear what outcome you expect. The details of what they're going to do aren't important, just a clear understanding of the expected outcome. It sounds obvious, but it's very easy to forget.
I've been a manager for 2 years, and I completely disagree that it's where geeks go to die. There are two important things you get from it: more control over the work you're doing, and getting to deal with problems on a larger scope.
I don't get to spend as much time looking at compiler errors and log files, but I'm still very involved with technical work. There are some managers who just turn to politics and paperwork, but those aren't good managers. A good manager should understand what their people are doing, and do whatever it takes to make them successful at it. This means a lot of stuff that's still geeky, such as scheduling complicated projects with lots of dependencies, looking at tools, processes, and architecture, and looking out for long term dangers.
And most importantly, if you are a manager that's a geek, you are going to make decisions that are more likely to be correct technically, which will make things better for your company and your geek empoyees. The more geeks there are higher up the ranks of your company, the easier life will be for geeks.
If geeks always decline the management jobs, we'll always just be the slaves of the non-geeks.
One simple reason is that it's a hell of a lot harder to figure out what the code does, which means it's far more likely to ship with bugs, and those bugs could be security holes. A more specific security risk is that if you have other bugs that cause your program to produce garbage data, executing the garbage will probably be far more destructive than just outputting garbage.
Self generating code is playing with fire. It's of dubious value, and it has a non-trivial chance of going wrong spectacularly. Even if it works, the next person who looks at the code will be cursing your name because of the extra hours they had to spend unravelling it.
If the company wanted to pay for my cell phone service, THEN they could reach me after hours.
If they ask you to be on call after hours, it should cost them a hell of a lot more than a cell phone.
In general it should be very clear between you and your employer how much is expected of you after hours. If it is anything more than "nothing", it should be an official policy and they should be compensating you for it. How much depends on how reliable you promise to be, and how often they call.
If it's every few months in an emergency then fair compensation might be having a nice salaried job and a boss that trusts you. If it's every weekend, then you're really working two jobs, so they should pay you accordingly or hire a second person.
Either way, who bought the phone is not nearly as important as what work you're doing, and whether or not they're paying you for it.
The idea behind "exploration" is that you can see a lot of interesting things about how something works when you push it outside of its normal running conditions.
Given that Microsoft will write software that can be exploited, I'd much rather have it exploited by something that reboots my machine and some script kiddie gets a kick out of it, than have it exploited secretly and repeatedly by someone with worse motives. If we didn't have these occasional public displays of how insecure our software is, it would be far easier for other people to take advantage of it, people like the terrorists and governments. That would be a hell of a lot worse than having all your machines reboot, or even losing a hard drive here and there.
The real solution is quality software, and punishing virus writers won't get us any closer to that.
This argument is of course only valid as long as the viruses are relatively benign.
Additional code can obviously make things faster, but that wasn't the point of the original post.
The point was that if your code is simpler, it will be much easier to understand what the important algorithms and data structures are, and much more likely that you will be able to choose the correct ones.
If you obfuscate your code with a lot of pre-emptive attempts to fix perceived performance problems that might or might not actually matter, you're more likely to miss the important high level optimizations.
So in the end you might add code to make things run faster, but by keeping the code small to start with it's much more clear what code needs to be added.
My first reaction to this is that they test them all against the same deals, so there's not much luck, but on further reflection there is luck, it's just more subtle than the luck you deal with in the casino.
The luck in this game is whether or not the deals that everyone gets are the type of deals that your scripts handles well.
So based on this, I think the winning strategy is the following: Write a script that will do very well against a certain kinds of draws, and poorly against others. This would be a poor strategy if you were playing for money, and got to keep the net, but that isn't the game. The game here is that if you do the best (or one of the best) you win, and everything else loses. So losing badly isn't any worse than doing well but not the best. So take advantage of this by writing an aggresive strategy that will lose on most draws, but is sure to win on some. This is much better than writing a conservative script that will do well on any draw, but will always lose to whichever aggressive script happened to hit on the particular draw that was used.
When they run the contest, most of the entries will play a conservative strategy, and end up in a nice bell curve around a reasonable return. But the winner will be some off the wall script that does something crazy that happened to pay off against the draw they used.
How crazy it will take to win will of course depend on the number of entries.
You can be a sure winner if you get enough friends to enter with different aggresive strategies to cover all possible draws.
1) Programming is hard.
2) Programming shouldn't be hard.
3) A bunch of yammering that never even attempts to answer why 1) and 2) are true or what could be done about it.
4) Java is cool.
5) Assorted other buzzwords.
Don't bother reading it, unless you want to be impressed by how long someone can talk about absolutely nothing.
very true, those are big risks as well. But that doesn't change the fact that going after counterfeiters is a worthwhile thing for the government to do.
The point I wanted to make is that even though it might look on the surface like the usual government invading our personal business story, there really is a good reason for the government to be interested in this. There's enough other _really_ stupid stuff that the government does that its not worth getting all worked up about this one.
I agree that any increase in the government's power over our lives is ominous, but this is a pretty specific case where I think it is worthwhile.
Having a trustworthy currency is a cornerstone of our economy and our society. If our currency became less stable it would be very bad for all of us; that's why controlling the currency is something the US government has been doing right from the start.
There are a lot of other places where the government is erroding our freedom for no good reason at all, and I think we should focus on fighting those. Currency is one of the few things that I'm actually glad the government is looking after.
yeah, it is. I had some friends who did it, and the average career was a couple of weeks. The telemarketing company would put up signs that said "student work" but didn't say what it was. Every week they would hire a big group of new people, and then they would all quit. The job was basically being yelled at for 8 hours, all the while being monitored by a supervisor who's just the one asshole who didn't mind being yelled at all day.
Doesn't seem so bad to me. Sounds like any engineering project I've ever worked on:
Engineer says it will take X dollars and Y time to get it working if things go well, and not everything will go well so we add a little bit of padding.
The non-engineer who makes the decision doesn't really believe that things won't go well, and only hears the X and Y that he wants to hear.
Its too bad that the world works this way, but its not exactly the bombshell described in the article.
It's not the "time, effort, and sweat" that makes old mechanical products tougher, its that the designers didn't spend as much time making them just tough enough. Take VCRs for example. Many first generation VCRs are still running strong, while ones made a couple of years ago are already falling apart. The reason is that when they were designing the first VCRs they were just trying to make it work at all. So any piece that could be overengineered was. The design of a modern VCR, however, has the goal of making an already working technology cheaper. So all of the places where in the original design they just made something twice as big as it needed to be, just to be sure, they go back and spend the effort finding out _exactly_ how big it needs to be to meet their requirement for reliability. So then its just exactly meets the requirement for reliability, rather than overshooting by some large and indeterminate amount.
You can also get similar beds now at the camping section in walmart that are almost as good and a lot cheaper. The main difference is that they don't have the pump attached, and they take longer to infate, but it will only cost you about fifty or sixty bucks for the bed and the pump. Also, the ones on TV come with a mattress pad. This actually turns out to be important because the inflatable bed can get cold. So if you buy the cheap one, use a mattress pad, or even better some egg crate foam.
Do you mean MTBF for a single box, or the whole cluster? One of the big advantages of using a cluster is that you are robust to any particular node failing. So even if your commodity hardware is sketchy, you still have a reliable system on the whole.
Moving people in planes is not a good analogy because it is perfectly parallel. Each person getting to the destination is not in any way dependant on the other people's journey, so splitting up the work has no overhead.
The Cray design philosophy is for solving problems that can't be split up easily. If all of the parts of the problem depend heavily on one another, you pay a large price for communication when you split it up. That's the situation where the cluster doesn't do as well as the Cray. So each design has its strengths, and it really depends on the problem.
Slashdot Mirror
The issue isn't the number of bytes per second, it's the number of distinct requests. The data is _way_ bigger than will fit in memory, and hard disks can only do 100-150 seeks per second so you need a lot of them to serve from disk. A naive implementation will go to disk many times for a single file, because filesystems aren't designed for this many small files. So this is really an issue of getting exactly the right stuff in memory so you can serve hot content from memory, and if you go to disk you seek exactly once instead of several times.
And what happens to the money that they withold from Peter Jackson? Does it go to feed the poor?
The people running the studio are even more obscenely rich than Peter Jackson. If they agreed to a contract they should honor it, and he's perfectly right to sue if they don't.
And more importantly, the studios are screwing a lot of other people who aren't already rich. If they lose this case they might be less likely to pull the same scam against someone who will really be hurt by it.
no library code should ever cause the whole application to abort, ever. There are few absolutes in software development, but this is one of them.
I think a more accurate way to state that would be: No library code should ever cause the whole application to abort when the application is being used by an end user.
Under development it's a completely different situation. The top goal isn't running cleanly at all cost; the top goal is finding anything that might be a bug.
That's the whole point of assert. It lets you know when something is wrong in debug mode, but in release mode it's #defined as a no-op. So it fills your criteria perfectly. It never does anything to a real user's application.
This isn't always a good thing of course. As you mentioned above, it your assert has side effects you could be in big trouble when you switch to release and they don't happen. Or if you use assert to catch legitimate runtime errors you end up #ifdefing away your error checking when it really matters. But used correctly, assert can be useful.
Great comment. I would add a couple more things:
- Don't let "giving your team input" turn into "decisions by commitee". Group decisions don't turn out well. The way to give your team input is to empower them to do particular tasks. For example: instead of sitting down with six people and trying to decide everything, split the project into six parts and give one person ablsolute control over each of them. This reduces conflict, makes people more productive, and makes people feel good about themselves. (of course you'd better do a good job of splitting up the task, which will require input from your team)
- Learn how to delegate tasks: When you ask someone to do something make it very clear what outcome you expect. The details of what they're going to do aren't important, just a clear understanding of the expected outcome. It sounds obvious, but it's very easy to forget.
I've been a manager for 2 years, and I completely disagree that it's where geeks go to die. There are two important things you get from it: more control over the work you're doing, and getting to deal with problems on a larger scope.
I don't get to spend as much time looking at compiler errors and log files, but I'm still very involved with technical work. There are some managers who just turn to politics and paperwork, but those aren't good managers. A good manager should understand what their people are doing, and do whatever it takes to make them successful at it. This means a lot of stuff that's still geeky, such as scheduling complicated projects with lots of dependencies, looking at tools, processes, and architecture, and looking out for long term dangers.
And most importantly, if you are a manager that's a geek, you are going to make decisions that are more likely to be correct technically, which will make things better for your company and your geek empoyees. The more geeks there are higher up the ranks of your company, the easier life will be for geeks.
If geeks always decline the management jobs, we'll always just be the slaves of the non-geeks.
One simple reason is that it's a hell of a lot harder to figure out what the code does, which means it's far more likely to ship with bugs, and those bugs could be security holes. A more specific security risk is that if you have other bugs that cause your program to produce garbage data, executing the garbage will probably be far more destructive than just outputting garbage.
Self generating code is playing with fire. It's of dubious value, and it has a non-trivial chance of going wrong spectacularly. Even if it works, the next person who looks at the code will be cursing your name because of the extra hours they had to spend unravelling it.
If the company wanted to pay for my cell phone service, THEN they could reach me after hours.
If they ask you to be on call after hours, it should cost them a hell of a lot more than a cell phone.
In general it should be very clear between you and your employer how much is expected of you after hours. If it is anything more than "nothing", it should be an official policy and they should be compensating you for it. How much depends on how reliable you promise to be, and how often they call.
If it's every few months in an emergency then fair compensation might be having a nice salaried job and a boss that trusts you. If it's every weekend, then you're really working two jobs, so they should pay you accordingly or hire a second person.
Either way, who bought the phone is not nearly as important as what work you're doing, and whether or not they're paying you for it.
Asking hourly workers to work unpaid hours under threat of termination is seriously illegal. If you can prove it, sue them.
The idea behind "exploration" is that you can see a lot of interesting things about how something works when you push it outside of its normal running conditions.
That's right except you got it backwards. If you've seen more small cards, bet more. Aces and tens in the deck favor the player.
Given that Microsoft will write software that can be exploited, I'd much rather have it exploited by something that reboots my machine and some script kiddie gets a kick out of it, than have it exploited secretly and repeatedly by someone with worse motives. If we didn't have these occasional public displays of how insecure our software is, it would be far easier for other people to take advantage of it, people like the terrorists and governments. That would be a hell of a lot worse than having all your machines reboot, or even losing a hard drive here and there.
The real solution is quality software, and punishing virus writers won't get us any closer to that.
This argument is of course only valid as long as the viruses are relatively benign.
"Freedoms Revoked in Defense of Liberty"
Additional code can obviously make things faster, but that wasn't the point of the original post.
The point was that if your code is simpler, it will be much easier to understand what the important algorithms and data structures are, and much more likely that you will be able to choose the correct ones.
If you obfuscate your code with a lot of pre-emptive attempts to fix perceived performance problems that might or might not actually matter, you're more likely to miss the important high level optimizations.
So in the end you might add code to make things run faster, but by keeping the code small to start with it's much more clear what code needs to be added.
funbobby
Forgot to mention above, if you use my idea and win, let me know. I don't care about the prize, I'd just be happy to see it work.
My first reaction to this is that they test them all against the same deals, so there's not much luck, but on further reflection there is luck, it's just more subtle than the luck you deal with in the casino.
:(
The luck in this game is whether or not the deals that everyone gets are the type of deals that your scripts handles well.
So based on this, I think the winning strategy is the following:
Write a script that will do very well against a certain kinds of draws, and poorly against others. This would be a poor strategy if you were playing for money, and got to keep the net, but that isn't the game. The game here is that if you do the best (or one of the best) you win, and everything else loses. So losing badly isn't any worse than doing well but not the best. So take advantage of this by writing an aggresive strategy that will lose on most draws, but is sure to win on some. This is much better than writing a conservative script that will do well on any draw, but will always lose to whichever aggressive script happened to hit on the particular draw that was used.
When they run the contest, most of the entries will play a conservative strategy, and end up in a nice bell curve around a reasonable return. But the winner will be some off the wall script that does something crazy that happened to pay off against the draw they used.
How crazy it will take to win will of course depend on the number of entries.
You can be a sure winner if you get enough friends to enter with different aggresive strategies to cover all possible draws.
I wish I wasn't too busy to do it myself
- Funbobby
1) Programming is hard.
2) Programming shouldn't be hard.
3) A bunch of yammering that never even attempts to answer why 1) and 2) are true or what could be done about it.
4) Java is cool.
5) Assorted other buzzwords.
Don't bother reading it, unless you want to be impressed by how long someone can talk about absolutely nothing.
very true, those are big risks as well. But that doesn't change the fact that going after counterfeiters is a worthwhile thing for the government to do.
The point I wanted to make is that even though it might look on the surface like the usual government invading our personal business story, there really is a good reason for the government to be interested in this. There's enough other _really_ stupid stuff that the government does that its not worth getting all worked up about this one.
I agree that any increase in the government's power over our lives is ominous, but this is a pretty specific case where I think it is worthwhile.
Having a trustworthy currency is a cornerstone of our economy and our society. If our currency became less stable it would be very bad for all of us; that's why controlling the currency is something the US government has been doing right from the start.
There are a lot of other places where the government is erroding our freedom for no good reason at all, and I think we should focus on fighting those. Currency is one of the few things that I'm actually glad the government is looking after.
yeah, it is. I had some friends who did it, and the average career was a couple of weeks. The telemarketing company would put up signs that said "student work" but didn't say what it was. Every week they would hire a big group of new people, and then they would all quit. The job was basically being yelled at for 8 hours, all the while being monitored by a supervisor who's just the one asshole who didn't mind being yelled at all day.
If they have a lot of people in their district who work as telemarketers, they are representing them.
But if I lived in one of those districts, yeah, I would be pretty mad.
Doesn't seem so bad to me. Sounds like any engineering project I've ever worked on:
Engineer says it will take X dollars and Y time to get it working if things go well, and not everything will go well so we add a little bit of padding.
The non-engineer who makes the decision doesn't really believe that things won't go well, and only hears the X and Y that he wants to hear.
Its too bad that the world works this way, but its not exactly the bombshell described in the article.
It's not the "time, effort, and sweat" that makes old mechanical products tougher, its that the designers didn't spend as much time making them just tough enough. Take VCRs for example. Many first generation VCRs are still running strong, while ones made a couple of years ago are already falling apart. The reason is that when they were designing the first VCRs they were just trying to make it work at all. So any piece that could be overengineered was. The design of a modern VCR, however, has the goal of making an already working technology cheaper. So all of the places where in the original design they just made something twice as big as it needed to be, just to be sure, they go back and spend the effort finding out _exactly_ how big it needs to be to meet their requirement for reliability. So then its just exactly meets the requirement for reliability, rather than overshooting by some large and indeterminate amount.
You can also get similar beds now at the camping section in walmart that are almost as good and a lot cheaper. The main difference is that they don't have the pump attached, and they take longer to infate, but it will only cost you about fifty or sixty bucks for the bed and the pump. Also, the ones on TV come with a mattress pad. This actually turns out to be important because the inflatable bed can get cold. So if you buy the cheap one, use a mattress pad, or even better some egg crate foam.
Do you mean MTBF for a single box, or the whole cluster? One of the big advantages of using a cluster is that you are robust to any particular node failing. So even if your commodity hardware is sketchy, you still have a reliable system on the whole.
Moving people in planes is not a good analogy because it is perfectly parallel. Each person getting to the destination is not in any way dependant on the other people's journey, so splitting up the work has no overhead.
The Cray design philosophy is for solving problems that can't be split up easily. If all of the parts of the problem depend heavily on one another, you pay a large price for communication when you split it up. That's the situation where the cluster doesn't do as well as the Cray. So each design has its strengths, and it really depends on the problem.