A colleague said to me once, "You're the only VP I've ever known who installs equipment." I'm always amazed at how out of touch "senior" people can get. And besides, when we get new toys I want to see them working NOW.
There's definitely truth to what he's saying but it cuts the other direction as well. Having your lead guru developer swapping disk drives on a machine isn't the best use of his time. However, I've also seen environments where the developers can't/won't/aren't allow to do the system admin tasks and wind up waiting around or being frustrated when their development systems have a problem. Likewise, with QA - I've seen developers that will just toss any old crap over the wall and expect QA to catch all of their bugs. And, developing tests is often software engineering, often complex software engineering that needs an experienced developer to establish at least the outline of how everything works.
Personally, I expect any developers I'm working with to have at least basic sys admin abilities and know how to setup/fix any other part of the stack they might touch. Those skills should be used when working with the dev systems and in establishing the base line for production. I would then expect that someone who is more specialized in those other roles to actually setup and run production and also be available when the developers get in over their heads on system admin, hardware troubleshooting, etc. In the same way I would expect a systems admin to at least be able to write a script to automate something and not go running to the developers for everything.
For test development, I always like to set groups against each other and develop the test suite for each other's code. Most people are a lot more comfortable and eager to break someone else's code than they are their own.
The article focused on how Amazon cuts hardware costs. The first step there is a big one - once you let go of buying name brand hardware, especially for storage, the price drop dramatically. So dramatically, in fact, that hosting (largely electricity, cooling and network connectivity) becomes the major cost in the equation. Amazon is pushing for extremely high density, however, that has a ripple effect throughout your whole datacenter design. If you're not in a high cost area, you might ask why focus on density because floor space is relatively cheap.
I haven't tried setting up a large PKI infrastructure so I'm curious if you know more. Technically it's possible but I could see why a CA wouldn't do it. The info for this GlobalSign "Trusted Root" seems to imply that you get to sign keys with your own existing root CA but that GlobalSign will sign it as well so you don't need to distribute your own root cert. Am I reading it wrong?
If you're a CA, then yes, the intermediate key would be used for automated signing. It STILL shouldn't be on hosts that are directly connected to the Internet.
If you're a company that is not a CA, then the intermediate key signed by the CA is pretty much your root key. It shouldn't be on your web servers, you should keep it offline if possible and you should be generating another layer of keys that are used to sign actual server certificates.
If your intermediate certificate's signing keys are on the internet facing web servers you're doing it wrong. That intermediate signing key should be treated with the same level of security you would treat a root key with.
Yah, like all that oh-so-secure code that used to float around back in the 70's and 80's? I remember when systems used to get hacked by dial-up modem on a regular basis. There were and have been security holes in things forever. It just used to be harder to exploit most of them remotely and there were fewer people trying to exploit them.
Actually, I don't see anything wrong with systemd using the same flag to turn on debugging. However, it shouldn't crash the system by outputting too much stuff in debug mode! That's unacceptable no matter what you call the debug flag.
That and the fact that each car model has a different type of battery pack with different geometry and capacity. Sounds like more trouble than it is worth.
You'll note that the reason they're losing money is not because the water is more expensive but because people's voluntary conservation efforts have reduced the amount of water being purchased.
Water bills typically don't go up a lot in droughts. That may change, but the way they've been managed in California in the past, they don't raise the rates because of a shortage.
Are you talking about California? Drought doesn't hit poor people any harder than rich in California. Other areas, especially where subsistence farming is practiced, yes.
First, people like to talk about "consuming" water. Water isn't consumed because it isn't turned into something else permanently, unlike say, oil or coal, which do not replenish in a reasonable amount of time. The only time the amount of water being used is actually relevant is when it's being pulled from a finite source for irrigation, like an underground aquifer or a river. A large portion of the planet gets sufficient rainfall to support all manner of agriculture. Raising alfalfa in California is dumb. Raising rice in Japan is not.
Feeding cattle on grassland that is not irrigated is not "consuming" water. As long as the land is not over-grazed it's not really an issue. In fact, the grass needs to be eaten and fertilized to thrive - it's co-evolved with large ruminants like cattle or horses.
So, these statistics are meaningless because it depends on where you're growing the crops as to whether or not you're consuming a finite resource. They're only useful in a local context. There are other side effects of raising cattle, such as deforestation, that are relevant.
Customer and Border Patrol should stick to enforcing customs laws AT THE BORDER. Once it's entered the country they should have no authority. We've also seen them trying to enforce copyright, as in the recent Google Glass case. They're already out of control at the borders with their warrantless searches, their authority should be rolled back, not expanded.
That would be kind of nice, but will it make "Linux" (i.e. Ubuntu, Fedora, etc.) into a major gaming platform? There are people who run Linux as their major desktop and keep a Windows partition around for gaming but is that a large market?
I think Steam OS has a decent shot at being successful, but is it fair to call a machine running Steam OS a Linux machine? I don't think so (unless you want to call Android a Linux machine as well) and if that's the case, then no, I don't think Linux will become the #2 gaming platform.
It's a variant of Linux but it's not for use with a general purpose computer. By that standard, BSD (iOS sorta kinda) and Linux (Android) are already major game platforms.
Well, to modulate an electric current you need an electric current (that's how a transistor works). Amplification isn't done by increasing the voltage/current of the reference signal. You use the reference signal to modulate a higher voltage/current. Once you have a transistor-equivalent we know how to use that to do all kinds of interesting things.
Their presentation makes analogies between "reactive programming" and spreadsheets and specifically references the power of "chaining" to have multiple functions firing as the result of changes.
There are a number of issues with this kind of event chaining that you run into as you get past the toy cases.
1) Fan-out. How many actions are being kicked off by a simple change? 2) Latency - this is a direct corollary to the fanout. Are all of the chained functions being run synchronously? If so, what happens when someone introduces a very slow function that gets run as the result of a user input. So the user changes the price of a part and every purchase order in the system is suddenly being updated? 3) Synchronicity - of course, as soon as you find out that your synchronously run chained functions slow things down you start running them in the background. Now, you have a problem where you don't know if something is up-to-date or not. And, in this model, it's not possible to find out if something is up-to-date.
The examples that they gave are very poor use cases for triggers even. Most general ledger systems I've looked at, running on top of a database, would just recalculate the balance on demand. If your database is large enough that the recalculation starts to take significant time, you cache the result and invalidate it using a trigger. Most GL systems typically make entries much more frequently than they need to calculate the balance for an account. If the recalculation of the balance takes significant time, you probably don't want to do it every time an entry is made anyhow.
Hey, at least you used numbers that had a basis in reality Though I think the no-nuke nuts must have decided they liked the "can't contain it" argument without understanding the context.
Slashdot Mirror
A colleague said to me once, "You're the only VP I've ever known who installs equipment." I'm always amazed at how out of touch "senior" people can get. And besides, when we get new toys I want to see them working NOW.
There's definitely truth to what he's saying but it cuts the other direction as well. Having your lead guru developer swapping disk drives on a machine isn't the best use of his time. However, I've also seen environments where the developers can't/won't/aren't allow to do the system admin tasks and wind up waiting around or being frustrated when their development systems have a problem. Likewise, with QA - I've seen developers that will just toss any old crap over the wall and expect QA to catch all of their bugs. And, developing tests is often software engineering, often complex software engineering that needs an experienced developer to establish at least the outline of how everything works.
Personally, I expect any developers I'm working with to have at least basic sys admin abilities and know how to setup/fix any other part of the stack they might touch. Those skills should be used when working with the dev systems and in establishing the base line for production. I would then expect that someone who is more specialized in those other roles to actually setup and run production and also be available when the developers get in over their heads on system admin, hardware troubleshooting, etc. In the same way I would expect a systems admin to at least be able to write a script to automate something and not go running to the developers for everything.
For test development, I always like to set groups against each other and develop the test suite for each other's code. Most people are a lot more comfortable and eager to break someone else's code than they are their own.
The article focused on how Amazon cuts hardware costs. The first step there is a big one - once you let go of buying name brand hardware, especially for storage, the price drop dramatically. So dramatically, in fact, that hosting (largely electricity, cooling and network connectivity) becomes the major cost in the equation. Amazon is pushing for extremely high density, however, that has a ripple effect throughout your whole datacenter design. If you're not in a high cost area, you might ask why focus on density because floor space is relatively cheap.
How about this https://www.globalsign.com/cer...?
I haven't tried setting up a large PKI infrastructure so I'm curious if you know more. Technically it's possible but I could see why a CA wouldn't do it. The info for this GlobalSign "Trusted Root" seems to imply that you get to sign keys with your own existing root CA but that GlobalSign will sign it as well so you don't need to distribute your own root cert. Am I reading it wrong?
It depends on where you are in the chain.
If you're a CA, then yes, the intermediate key would be used for automated signing. It STILL shouldn't be on hosts that are directly connected to the Internet.
If you're a company that is not a CA, then the intermediate key signed by the CA is pretty much your root key. It shouldn't be on your web servers, you should keep it offline if possible and you should be generating another layer of keys that are used to sign actual server certificates.
If your intermediate certificate's signing keys are on the internet facing web servers you're doing it wrong. That intermediate signing key should be treated with the same level of security you would treat a root key with.
Yah, like all that oh-so-secure code that used to float around back in the 70's and 80's? I remember when systems used to get hacked by dial-up modem on a regular basis. There were and have been security holes in things forever. It just used to be harder to exploit most of them remotely and there were fewer people trying to exploit them.
Actually, I don't see anything wrong with systemd using the same flag to turn on debugging. However, it shouldn't crash the system by outputting too much stuff in debug mode! That's unacceptable no matter what you call the debug flag.
That and the fact that each car model has a different type of battery pack with different geometry and capacity. Sounds like more trouble than it is worth.
You'll note that the reason they're losing money is not because the water is more expensive but because people's voluntary conservation efforts have reduced the amount of water being purchased.
Water bills typically don't go up a lot in droughts. That may change, but the way they've been managed in California in the past, they don't raise the rates because of a shortage.
You can also refer to the water table as being an "aquifer" and if you read my post you'll see that I explicitly called that out as finite.
Are you talking about California? Drought doesn't hit poor people any harder than rich in California. Other areas, especially where subsistence farming is practiced, yes.
First, people like to talk about "consuming" water. Water isn't consumed because it isn't turned into something else permanently, unlike say, oil or coal, which do not replenish in a reasonable amount of time. The only time the amount of water being used is actually relevant is when it's being pulled from a finite source for irrigation, like an underground aquifer or a river. A large portion of the planet gets sufficient rainfall to support all manner of agriculture. Raising alfalfa in California is dumb. Raising rice in Japan is not.
Feeding cattle on grassland that is not irrigated is not "consuming" water. As long as the land is not over-grazed it's not really an issue. In fact, the grass needs to be eaten and fertilized to thrive - it's co-evolved with large ruminants like cattle or horses.
So, these statistics are meaningless because it depends on where you're growing the crops as to whether or not you're consuming a finite resource. They're only useful in a local context. There are other side effects of raising cattle, such as deforestation, that are relevant.
Just because it's done doesn't make it a good idea.
But it's so much more fun to rewrite from scratch!
It's snowing in Tokyo right now so I'm curious if he's camped out. I'd like a picture of "sad iPhone in snow"
Kids these days.
Customer and Border Patrol should stick to enforcing customs laws AT THE BORDER. Once it's entered the country they should have no authority. We've also seen them trying to enforce copyright, as in the recent Google Glass case. They're already out of control at the borders with their warrantless searches, their authority should be rolled back, not expanded.
That would be kind of nice, but will it make "Linux" (i.e. Ubuntu, Fedora, etc.) into a major gaming platform? There are people who run Linux as their major desktop and keep a Windows partition around for gaming but is that a large market?
I think Steam OS has a decent shot at being successful, but is it fair to call a machine running Steam OS a Linux machine? I don't think so (unless you want to call Android a Linux machine as well) and if that's the case, then no, I don't think Linux will become the #2 gaming platform.
It's a variant of Linux but it's not for use with a general purpose computer. By that standard, BSD (iOS sorta kinda) and Linux (Android) are already major game platforms.
As far as functions, I'd say bcopy().
Well, to modulate an electric current you need an electric current (that's how a transistor works). Amplification isn't done by increasing the voltage/current of the reference signal. You use the reference signal to modulate a higher voltage/current. Once you have a transistor-equivalent we know how to use that to do all kinds of interesting things.
Their presentation makes analogies between "reactive programming" and spreadsheets and specifically references the power of "chaining" to have multiple functions firing as the result of changes.
There are a number of issues with this kind of event chaining that you run into as you get past the toy cases.
1) Fan-out. How many actions are being kicked off by a simple change?
2) Latency - this is a direct corollary to the fanout. Are all of the chained functions being run synchronously? If so, what happens when someone introduces a very slow function that gets run as the result of a user input. So the user changes the price of a part and every purchase order in the system is suddenly being updated?
3) Synchronicity - of course, as soon as you find out that your synchronously run chained functions slow things down you start running them in the background. Now, you have a problem where you don't know if something is up-to-date or not. And, in this model, it's not possible to find out if something is up-to-date.
The examples that they gave are very poor use cases for triggers even. Most general ledger systems I've looked at, running on top of a database, would just recalculate the balance on demand. If your database is large enough that the recalculation starts to take significant time, you cache the result and invalidate it using a trigger. Most GL systems typically make entries much more frequently than they need to calculate the balance for an account. If the recalculation of the balance takes significant time, you probably don't want to do it every time an entry is made anyhow.
Hey, at least you used numbers that had a basis in reality Though I think the no-nuke nuts must have decided they liked the "can't contain it" argument without understanding the context.