1. Distinguish between serious -operational- issues and other issues. The sysadmin doesn't need to know that you had a pointer problem; there's nothing he can do about it. He does, however, want to know that a message was received and the appropriate action taken. Or that a connection was attempted but failed.
2. Be grep freindly. The first log entry related to a particular activity should have an ID of some sort in the log message which is then included in every additional log entry associated with that activity.
Any network engineer or system administrator who doesn't fall under the "administrative exemption" should be fired. Seriously. Doing the job competently requires the constant exercise of independent judgment and discretion. If you're not doing that then either your boss is an incompetent control freak (in which case you should quit and find a better boss) or you are lazy slug who lacks initiative (in which case you should be fired).
Help desk and in some cases field tech might not fall under this, but then they're not engineers or administrators: they're technicians.
I don't know, but my 1337 reading comprehension skills suggest that Oberg thinks it is. He seems to think that the ablation process as the satellite falls could have resulted in a chunk of still-cold hydrazine making it close enough to the ground to hurt people, or at least make a mess.
I think he's probably right. But then the best lies are always true.
We don't care if a couple cubic feet of hydrazine lands in the Sahara. IMO, the shoot down was an object lesson to China: This is how you do a missle test without drawing International condemnation [you inexperienced wannabe's].
Oberg goes on to quote 'There is a widespread notion that meteorites falling to Earth arrive red hot.' He is correct here. In fact, meteorites falling through the atmosphere typically explode, shattering into dozens or hundreds of pieces; something that occurs at the point when the dynamic pressure on the leading face exceeds the yield stress of the material. This occurs for meteoroids of all compositions, including nickle-iron meteorites that are far more robust than hydrazine tanks. If the atmospheric entry of meteorites is relevant, it hardly bolsters the case that a tank will enter intact (and if it's not relevent, why did Oberg bring it up?)
Perhaps he brings it up because that widespread notion is dead wrong. In fact, the parts of meteorites which make it all the way to the ground arrive quite cold, way below 'zero'. That's because of ablation. The outer part of the meteorite gets superheated by friction with the atmosphere, but before any significant portion of that heat can conduct to the inner part, the superheated part loses structural integrity and is torn away from the rest. However, the part torn away has, up until that moment, shielded the inner part from absorbing any direct friction heat.
Rinse and repeat. The end result is that whatever part does make it all the way to the ground is still at substantially the same temperature as it was when it entered the atmosphere.
Sure, because nobody is going to notice a gigabit of traffic pouring into their DNS server for 10 hours in order to get -just-one- cache poisoning.
Sorry, but this extension of the attack is simply unworthy of mention. What is worthy of mention is the danger posed by corporate NAT boxes that reorder the source ports sequentially, defeating randomization.
Lots of folks have ideas. Some are brilliant. Most are unworkable. It's awfully hard to be sure at the front end that yours won't be among the unworkable ones.
That's why VC's don't buy ideas. They buy teams instead: a group of apparently well qualified people who have subscribed to the consensus that a particular set of ideas is good and have already spent a considerable amount of effort building the idea to a point where they need capital to take it further.
You're the artist. When you, a composer, a developer and salesman (at least one of you with prior entrepreneurial experience) have each put 200 hours into the project, that's when the VC's will start to become interested in talking.
Until you can convince 3 other people with the right set of talents to jump on your bandwagon and put their time and reputation on the line, well, no offense but the VC's time is too valuable to waste on you.
Here's the problem with this gentleman's analysis:
1. Without a third-party signed certificate, you're vulnerable to a man-in-the-middle attack.
2. If you accept the connection without a warning (it's no worse than plain http, right?) the user won't notice when a normally signed site (like his bank) suddenly presents an unsigned certificate.
Then again, the user probably won't notice if a normally-encrypted site like his bank suddenly starts using plain http instead of https.
There is probably a middle ground, like creating another URL type (in addition to http and https) which encrypts but doesn't check certificates.
If you actually read the article, the problem wasn't that they wouldn't let him enter his last name. The problem was that they wouldn't let him include his last name in his -login- name because it contained a four-letter word as a substring.
Why would Verizon care what you put in your username? How about the fact that when you call support, the rep will have to say what you typed in multiple times. And then a troll is going to record it and upload it to Youtube. Why should their staff be subjected to that embarrassment?
Granted in this case the call should have been passed to an engineer with the ability to edit at a level past the word filter. But that's Verizon for you: compartmentalized to hell and back.
Our IT department has been tasked with creating a list of authorized software, and only allowing software to be added to such a list after it has been thoroughly tested
That is an incredibly bad idea which will make you the target of user hatred. Your staff is in business to do the business. This is like telling a carpenter that he has to get a new brand of hammer approved by the corporate tool testers instead of just going down the street and buying whatever hammer the hardware store has.
It's also a profoundly impossible task. You have no basis for validating all of the myriad shareware and freeware out there. For Windows software, you mostly don't even have source code you can inspect.
Your best bet is to simply forbid specific pieces of software that are known to be a problem (certain browser extensions) and specific categories of software of are usually a problem (peer to peer.) Then, add to the list as folks make poor choices.
The governments of Europe hassle companies (in general) more than the US does. This hassle has a cost. The cost is reflected in the price.
Let me put it another way: Adobe considers it worth their while to sell Dreamweaver at $400 in the US. After all the hassle, they consider it worth their while to sell Dreamweaver for $900 in Europe. At $400, would it be worth their while to sell Dreamweaver in the EU at all? Maybe not.
Let me put it a third way: go on eBay and you find that a lot of US sellers won't ship outside of the US and Canada. Why not? Because it isn't worth the hassle. Would it be worth the hassle if the seller could check a box which said, "double price outside North America?" Maybe so.
If I buy a copy of Batman, draw a mustache on all the faces and then upload it, that's not fair use. It's a derivative work.
We're not talking about a few screenshots and 10-second video clips; we're talking about folks who have recorded playing the entire game from start to finish, performing virtually the entire work. And then uploaded it. No court in the nation would agree that's fair use.
The hard drives and DMA controller however, will run a bit longer; so if data is being written to disk, the DMA controller will keep reading data from memory, but it has no idea that this data is corrupted.
Pretty sure that's wrong. It used to be (20 years ago) that hard drives losing power in this way had a chance of the heads crashing against the platters (the fabled "hard drive crash"). To solve this, modern drives are very sensitive to the power input. As soon as power fails the drives extract power from the spinning platters to move the heads over to the parked position. Regardless of what the DMA controller thinks it should be doing, the hard drive is busy parking the heads.
How did Neanderthals warn us about the dangers or buried Uranium?
Seriously, get a grip. While I suppose we could have done without the manufacture of radium-coated clock dials, our lack of forewarning about radiation wasn't especially deadly to our society.
openSUSE has warnings in those files NOT to use them and tell you which one you need to use.
True enough. Doesn't help when I want the application to do something it is capable of but which wasn't envisioned by the SuSE packagers. Like binding sendmail to a non-privileged port as a non-privileged user and then using iptables to redirect port 25 up to that port.
Debian won't automatically overwrite my modified init.d script during an upgrade. It'll ask permission with the default set to "no." SuSE and Red Hat will overwrite it.
Then there's my sendmail.cf that I've built up over the course of 15 years. I'm not about to replace it with a suse-originated sendmail.mc. With Debian, I can prevent the upgrade process from trying to regenerate the.cf files from the default.mc. Not so with SuSE or Red Hat.
I like also how you use 'almost never', 'tend to work' and 'often'.
Almost never: I had a Debian upgrade in 2002 that had a bug in it which removed one of the inetd.conf listeners because it started with the same string as another listener that it was supposed to remove and replace. With scores of servers over better than a decade, that's the only incremental upgrade I recall hosing me. Close enough to never for you?
Tend to work: I built one of my home servers on Debian in 1997. Since then I've upgraded it in place all the way to the current Debian stable version by sshing in and using the package management system. For hardware upgrades I use tar and grub-install, preserving the exact system image. Try that with SuSE. Oh, that's right, you can't. Despite how difficult it is to automate that sort of task, my most recent major version upgrade from sarge to etch required manual cleanup to only three packages afterwards.
I suppose I will have to finally rebuild that one Debian server now that the hardware is moving from 32-bit to 64-bit. But who knows -- the clever Debian maintainers may find a way around that too.
Red Hat makes this mistake a LOT. It makes the update process very unreliable. SuSE isn't as bad but they still have problems if you customize a piece of software's configuration in an unexpected way.
Debian is king here. The incremental patches almost never break a configuration and the major release upgrades tend to work; they often change package names if the new "version" has a major incompatible change in the configuration.
I don't know whether to laugh or cry. What kind of incompetence does it take on the part of the rest of the system administrators there to be unable to regain access to a system to which they have physical access?
You were modded down because just about everyone knows that it's unlawful to void warranties merely because service wasn't performed by an authorized vendor.
Generally, tie-in sales provisions are not allowed. Such a provision would require a purchaser of the warranted product to buy an item or service from a particular company to use with the warranted product in order to be eligible to receive a remedy under the warranty. The following are examples of prohibited tie-in sales provisions.
In order to keep your new Plenum Brand Vacuum Cleaner warranty in effect, you must use genuine Plenum Brand Filter Bags.
Failure to have scheduled maintenance performed, at your expense, by the Great American Maintenance Company, Inc., voids this warranty.
Anyone capable of implementing the man-in-the-middle attack that signed certificates protect you against is also capable of modifying you web pages in flight so that the checksum the user sees matches the certificate they created.
Signed certificates provide exactly one additional protection versus no certificate at all: sessions so protected are not vulnerable to a man in the middle attack. With a self-signed certificate, someone in the middle can create a new self-signed certificate, decrypt and log your communications and then re-encrypt them with the site's real certificate. As the user, you won't know because it all looks the same to you.
That having been said, SSL with a self-signed certificate is MUCH more secure than no encryption at all.
There is no chance that there will be cars powered by "under the hood" nuclear reactors in the near future.
Given cheap electricity, today's technology offers a very real possibility of replacing the commuting fleet with battery powered cars. Nuclear was cheap relative to oil even before the price of oil started going up.
Slashdot Mirror
Correct.
I would note, however, that most of the $600 1-ton units don't require drainage: they evaporate the condensate into the exhaust air instead.
1. Distinguish between serious -operational- issues and other issues. The sysadmin doesn't need to know that you had a pointer problem; there's nothing he can do about it. He does, however, want to know that a message was received and the appropriate action taken. Or that a connection was attempted but failed.
2. Be grep freindly. The first log entry related to a particular activity should have an ID of some sort in the log message which is then included in every additional log entry associated with that activity.
Any network engineer or system administrator who doesn't fall under the "administrative exemption" should be fired. Seriously. Doing the job competently requires the constant exercise of independent judgment and discretion. If you're not doing that then either your boss is an incompetent control freak (in which case you should quit and find a better boss) or you are lazy slug who lacks initiative (in which case you should be fired).
Help desk and in some cases field tech might not fall under this, but then they're not engineers or administrators: they're technicians.
Is it [relevant]?
I don't know, but my 1337 reading comprehension skills suggest that Oberg thinks it is. He seems to think that the ablation process as the satellite falls could have resulted in a chunk of still-cold hydrazine making it close enough to the ground to hurt people, or at least make a mess.
I think he's probably right. But then the best lies are always true.
We don't care if a couple cubic feet of hydrazine lands in the Sahara. IMO, the shoot down was an object lesson to China: This is how you do a missle test without drawing International condemnation [you inexperienced wannabe's].
Oberg goes on to quote 'There is a widespread notion that meteorites falling to Earth arrive red hot.' He is correct here. In fact, meteorites falling through the atmosphere typically explode, shattering into dozens or hundreds of pieces; something that occurs at the point when the dynamic pressure on the leading face exceeds the yield stress of the material. This occurs for meteoroids of all compositions, including nickle-iron meteorites that are far more robust than hydrazine tanks. If the atmospheric entry of meteorites is relevant, it hardly bolsters the case that a tank will enter intact (and if it's not relevent, why did Oberg bring it up?)
Perhaps he brings it up because that widespread notion is dead wrong. In fact, the parts of meteorites which make it all the way to the ground arrive quite cold, way below 'zero'. That's because of ablation. The outer part of the meteorite gets superheated by friction with the atmosphere, but before any significant portion of that heat can conduct to the inner part, the superheated part loses structural integrity and is torn away from the rest. However, the part torn away has, up until that moment, shielded the inner part from absorbing any direct friction heat.
Rinse and repeat. The end result is that whatever part does make it all the way to the ground is still at substantially the same temperature as it was when it entered the atmosphere.
Sure, because nobody is going to notice a gigabit of traffic pouring into their DNS server for 10 hours in order to get -just-one- cache poisoning.
Sorry, but this extension of the attack is simply unworthy of mention. What is worthy of mention is the danger posed by corporate NAT boxes that reorder the source ports sequentially, defeating randomization.
Lots of folks have ideas. Some are brilliant. Most are unworkable. It's awfully hard to be sure at the front end that yours won't be among the unworkable ones.
That's why VC's don't buy ideas. They buy teams instead: a group of apparently well qualified people who have subscribed to the consensus that a particular set of ideas is good and have already spent a considerable amount of effort building the idea to a point where they need capital to take it further.
You're the artist. When you, a composer, a developer and salesman (at least one of you with prior entrepreneurial experience) have each put 200 hours into the project, that's when the VC's will start to become interested in talking.
Until you can convince 3 other people with the right set of talents to jump on your bandwagon and put their time and reputation on the line, well, no offense but the VC's time is too valuable to waste on you.
Here's the problem with this gentleman's analysis:
1. Without a third-party signed certificate, you're vulnerable to a man-in-the-middle attack.
2. If you accept the connection without a warning (it's no worse than plain http, right?) the user won't notice when a normally signed site (like his bank) suddenly presents an unsigned certificate.
Then again, the user probably won't notice if a normally-encrypted site like his bank suddenly starts using plain http instead of https.
There is probably a middle ground, like creating another URL type (in addition to http and https) which encrypts but doesn't check certificates.
If you actually read the article, the problem wasn't that they wouldn't let him enter his last name. The problem was that they wouldn't let him include his last name in his -login- name because it contained a four-letter word as a substring.
Why would Verizon care what you put in your username? How about the fact that when you call support, the rep will have to say what you typed in multiple times. And then a troll is going to record it and upload it to Youtube. Why should their staff be subjected to that embarrassment?
Granted in this case the call should have been passed to an engineer with the ability to edit at a level past the word filter. But that's Verizon for you: compartmentalized to hell and back.
Our IT department has been tasked with creating a list of authorized software, and only allowing software to be added to such a list after it has been thoroughly tested
That is an incredibly bad idea which will make you the target of user hatred. Your staff is in business to do the business. This is like telling a carpenter that he has to get a new brand of hammer approved by the corporate tool testers instead of just going down the street and buying whatever hammer the hardware store has.
It's also a profoundly impossible task. You have no basis for validating all of the myriad shareware and freeware out there. For Windows software, you mostly don't even have source code you can inspect.
Your best bet is to simply forbid specific pieces of software that are known to be a problem (certain browser extensions) and specific categories of software of are usually a problem (peer to peer.) Then, add to the list as folks make poor choices.
Have fun!
The governments of Europe hassle companies (in general) more than the US does. This hassle has a cost. The cost is reflected in the price.
Let me put it another way: Adobe considers it worth their while to sell Dreamweaver at $400 in the US. After all the hassle, they consider it worth their while to sell Dreamweaver for $900 in Europe. At $400, would it be worth their while to sell Dreamweaver in the EU at all? Maybe not.
Let me put it a third way: go on eBay and you find that a lot of US sellers won't ship outside of the US and Canada. Why not? Because it isn't worth the hassle. Would it be worth the hassle if the seller could check a box which said, "double price outside North America?" Maybe so.
Fair use of one copy of the work. Just as recording a game session for your own later perusal would very likely be fair use of a derivative work.
The Betamax case never came close to saying that making copies of the taped shows and giving those copies to your 10,000 closest friends was fair use.
If I buy a copy of Batman, draw a mustache on all the faces and then upload it, that's not fair use. It's a derivative work.
We're not talking about a few screenshots and 10-second video clips; we're talking about folks who have recorded playing the entire game from start to finish, performing virtually the entire work. And then uploaded it. No court in the nation would agree that's fair use.
If they are creative expression then they're unlicensed derivative works. You lose either way.
The hard drives and DMA controller however, will run a bit longer; so if data is being written to disk, the DMA controller will keep reading data from memory, but it has no idea that this data is corrupted.
Pretty sure that's wrong. It used to be (20 years ago) that hard drives losing power in this way had a chance of the heads crashing against the platters (the fabled "hard drive crash"). To solve this, modern drives are very sensitive to the power input. As soon as power fails the drives extract power from the spinning platters to move the heads over to the parked position. Regardless of what the DMA controller thinks it should be doing, the hard drive is busy parking the heads.
01999 is a faulty number. Octal digits are only 0 to 7. :P
How did Neanderthals warn us about the dangers or buried Uranium?
Seriously, get a grip. While I suppose we could have done without the manufacture of radium-coated clock dials, our lack of forewarning about radiation wasn't especially deadly to our society.
openSUSE has warnings in those files NOT to use them and tell you which one you need to use.
True enough. Doesn't help when I want the application to do something it is capable of but which wasn't envisioned by the SuSE packagers. Like binding sendmail to a non-privileged port as a non-privileged user and then using iptables to redirect port 25 up to that port.
Debian won't automatically overwrite my modified init.d script during an upgrade. It'll ask permission with the default set to "no." SuSE and Red Hat will overwrite it.
Then there's my sendmail.cf that I've built up over the course of 15 years. I'm not about to replace it with a suse-originated sendmail.mc. With Debian, I can prevent the upgrade process from trying to regenerate the .cf files from the default .mc. Not so with SuSE or Red Hat.
I like also how you use 'almost never', 'tend to work' and 'often'.
Almost never: I had a Debian upgrade in 2002 that had a bug in it which removed one of the inetd.conf listeners because it started with the same string as another listener that it was supposed to remove and replace. With scores of servers over better than a decade, that's the only incremental upgrade I recall hosing me. Close enough to never for you?
Tend to work: I built one of my home servers on Debian in 1997. Since then I've upgraded it in place all the way to the current Debian stable version by sshing in and using the package management system. For hardware upgrades I use tar and grub-install, preserving the exact system image. Try that with SuSE. Oh, that's right, you can't. Despite how difficult it is to automate that sort of task, my most recent major version upgrade from sarge to etch required manual cleanup to only three packages afterwards.
I suppose I will have to finally rebuild that one Debian server now that the hardware is moving from 32-bit to 64-bit. But who knows -- the clever Debian maintainers may find a way around that too.
Red Hat makes this mistake a LOT. It makes the update process very unreliable. SuSE isn't as bad but they still have problems if you customize a piece of software's configuration in an unexpected way.
Debian is king here. The incremental patches almost never break a configuration and the major release upgrades tend to work; they often change package names if the new "version" has a major incompatible change in the configuration.
I don't know whether to laugh or cry. What kind of incompetence does it take on the part of the rest of the system administrators there to be unable to regain access to a system to which they have physical access?
I have been burnt by this in the past for ripping the 'factory seals' off to do upgrades so i am more cautious now..
Mind naming the guilty? Companies whose service is so bad it actually breaks the law strike me as good companies to avoid doing business with.
-1 wrong might be ok.. but troll?
Don't know; I didn't mod you. Look at the bright side: it could have been moderated "overrated."
You were modded down because just about everyone knows that it's unlawful to void warranties merely because service wasn't performed by an authorized vendor.
http://www.ftc.gov/bcp/conline/pubs/buspubs/warranty.shtm
"Tie-In Sales" Provisions
Generally, tie-in sales provisions are not allowed. Such a provision would require a purchaser of the warranted product to buy an item or service from a particular company to use with the warranted product in order to be eligible to receive a remedy under the warranty. The following are examples of prohibited tie-in sales provisions.
In order to keep your new Plenum Brand Vacuum Cleaner warranty in effect, you must use genuine Plenum Brand Filter Bags.
Failure to have scheduled maintenance performed, at your expense, by the Great American Maintenance Company, Inc., voids this warranty.
Anyone capable of implementing the man-in-the-middle attack that signed certificates protect you against is also capable of modifying you web pages in flight so that the checksum the user sees matches the certificate they created.
Signed certificates provide exactly one additional protection versus no certificate at all: sessions so protected are not vulnerable to a man in the middle attack. With a self-signed certificate, someone in the middle can create a new self-signed certificate, decrypt and log your communications and then re-encrypt them with the site's real certificate. As the user, you won't know because it all looks the same to you.
That having been said, SSL with a self-signed certificate is MUCH more secure than no encryption at all.
There is no chance that there will be cars powered by "under the hood" nuclear reactors in the near future.
Given cheap electricity, today's technology offers a very real possibility of replacing the commuting fleet with battery powered cars. Nuclear was cheap relative to oil even before the price of oil started going up.