I think the intent is that this equipment would be brought into an area by a telco and be used with some sort of connectivity (whatever is available) to link back to the rest of the world.
stocking up for an unknown period of time in the future can cause problems. Ten years is about the limit of recommended time I could find.
Not true at all. I routinely use comblock and US surplus ammo from as far back as the 50s. When properly stored, it's good for a whole lot more than 10 years.
The reactor is housed inside of a containment vessel, which means that the melted material should be contained.
Ahem. TFA:
"Now the company is worried that the molten pool of radioactive fuel may have burned a hole through the bottom of the containment vessel, causing water to leak."
"Tepco has not clarified what other barriers there are to stop radioactive fuel leaking if the steel containment vessel has been breached. "
Corium is a bitch. It's gonna burn down as far as it damn well pleases.
it's going to be for such a small group of people (compared to the total set of computer users) that defining something backwards compatible with 100Mb/s Ethernet may not be worthwhile.
I'm not sure what you think I was responding to or talking about. You're bringing up a point that I completely agree with, but also one that I wasn't discussing in my post.
At least until it becomes very much cheaper, anything faster than gigabit is mostly about reducing the cable mess in high density situations.
For instance, if you are doing server virtualization, cheap multicore CPUs and cheap RAM means that it isn't at all implausible or uncommon to have numerous VMs all living in a single 2U, with the bandwidth demands of whatever it is that they are doing, plus the bandwidth demands brought about by the fact that there isn't any room for disks in there, so all their storage I/O is happening over iSCSI. You end up with every expansion slot filled with 4 port gigE cards and a real rat's nest.
Try an ESXi cluster of a blade chassis of 16 servers, each running 10 or more VMs. The switch cross connects back to the core start to become a problem even at 10 GbE.
On the other hand, I've only found 100Mb/s too slow on a few occasions - maybe once per year. I've used GigE, but I've never come close to saturating it.
This isn't about or for home users, or even small office users. It's about network operators.
In my small operation (under 100 servers, 3 1 gb internet connections) I have several places where I completely saturate 1 GB and have, for cost reasons, trunked it (10 GbE is very expensive still when you look at having to replace/upgrade core switching to support it). Switch cross connects and SANs are the biggest offenders. Trunking sucks (anything that requires more complexity and configuration is always worse than the simpler solution in my opinion), and getting higher speed ethernet connections into the top of the market will reduce the cost of 10 GbE as well as giving us (datacenter guys) somewhere else to scale when we need it.
I got you. I know it can happen. I just don't see it being something that is likely in a properly managed network.
I mean....come on....if you're in a position where you can swap out infrastructure equipment - even if your lab setup is moronic and shares VTP info - you ought to be (at a bare minimum) blowing away the config (which includes vlan.dat) and either copy-pasting from your config repository or creating a new one.
My point is that this is very, very basic procedure. If you are tasked with touching infrastructure equipment, you ought to know these things.
Also, if this happens it is a very quick restore if you have proper config backups and proper out of band access. Again, I guess I'm assuming a competency level that others aren't accustomed to. This stuff isn't hard.
Just so you know, even a VTP *client* with a higher revision number and a different table used to be able to / can wipe out a VTP domain by being introduced. Being a VTP server just allows you to add and remove VLANs from the database. VTPv3 is supposed to fix these kinds of things though. The last time this happened to me, thankfully, I still had the output from a "show vlan" in my scroll back buffer.
See my previous post about "crusty old IOS/CatOS".
Also, who the hell runs the same VTP name and auth key in production and the lab? That is BEGGING for problems.
Maybe I've just been doing this the right way for too long. I find it difficult te believe that there are networks of any scale that have any duration of uptime that aren't following very, very simple procedures to ensure uptime and/or are operating with such a complete lack of knowledge of the basic plumbing that makes them work. Also, who doesn't have automated config backups of infrastructure equipment?
I guess this boils down to the fact that I'm not an armchair network admin. I've been doing this a long time, and I know how it works. Someone doing something this stupid would be like watching someone put a car in gear and then crawl under it to me. It's not something you should have to TELL someone not to do. It's something that SHOULD'T HAPPEN when one or more well agreed upon basic procedures are being followed. If the person you are asking to do that kind of work needs to be told these things, you have failed as a manager, and likely as an organization. If your network(s) set the stage for this type of thing to be a possibility (sharing vtp info bewteen production and lab, hoping someone won't ever accidentally bridge the two) you again have failed as a manager or organization. The most basic of widely accepted best practices would put multiple barriers between this type of thing happening, requiring a cascading series of procedural failures to actually happen.
In summary.....Nope, still not buying this as a reasonable explanation.
Plenty of people run their VTP domains as all servers...since they are too lazy to remember which is the server:)
And to my point, that's amateur hour stuff. Not what one would expect in a professional data center.
Also, that would not cause this proposed issue, as if they were all servers, none of them would take data as ca VTP client. It would be like not running VTP at all.
So....what I said. Except you have it in your lab environment. And you don't relize its your VTP master. And you don't bother to put your production config on your replacement box before putting it in production.......
Yeah. Not buying it as a likely scenario. This required multiple steps, and a fundamental lack of understanding of key functions of networking equipment in a datacenter setting (namely not knowing what your VTP master is) and a lack of any sort of sane procedures (putting a piece of equipment into production without so much as verifying a config). It's a plausible, but unlikely series of events that would require the input of someone who was not capable of building or maintaing the network in the first place.
More likely some idiot introduced a cisco switch into their VTP domain and it had a higher revision number queued up and it overwrote their entire LAN environment.
How does that even happen in a properly managed environment? In fact, even in an improperly managed one? I'd have to try hard to make that happen......I mean...really. Bring up an identically configured VTP master, change it enough times to get a higher rev number, put it on the same LAN and......without external inputs (dropping links to the real VTP master) pretty much nothing ought to happen (other than syslog screaming) unless you're using some really crusty old IOS/CatOS.
Long hours of menial tasks (how many times is it possible to jam the same printer anyway?), angry users (not my fault you didn't backup), and heavy work loads.
That's not a career in IT. You described a job at a help desk.
What are we supposed to do with our old Alphas? Just set them on fire? Not that I have one any more.
I think that's the point. As much as I like diving into old hardware, at some point I started getting rid of it because of space limitations and the simple fact that it's not feasible, even with new distro support, to do anything of consequence on it that can't be done cheaper (read: electric power) and faster on even the wimpiest of several year old cast off (free or nearly) servers and/or laptops.
I get your point, but you need to re-think that example. I have propane. It gets trucked in about 3 times a year. I have enough storage on site to last over a year without deliveries for a typical winter.
Not sure where you live for that to be your experience, but I'm 35 miles from Philadelphia, 35 miles from Princeton, and 75 miles from New York City. I'm not near any major city, not even any large towns. AT&T is 3G just about everywhere around here.
You are also assuming that all datacenters have and need UPSes. This is simply not the case.
More and more facilities are going to flywheel generators as maintaining batteries for transfer time between mains and generator power is insanely expensive in floor space, labor, and replacement costs.
Nothing in any of the linked content says what kind of generators they have, or anything about a UPS. Based on the simple fact that Google can afford and makes it a priority to hire too notch talent and build things the right way, are you really telling me that you believe you and ElectricTurtle are smarter than the combined brainpower set loose by Google for building and maintaining this facility?
encourage meetings (especially internal ones) to be done using instant messaging/IRC?
This increases productivity since employees can be in more than one meeting at the same time, and they can still do other stuff. They could even go to the toilet or answer phones without interrupting the meeting
Do you _REALLY_ think that allowing, if not outright encouraging, people to be distracted will make for a productive exchange of ideas?
The real problem is not that meetings take too long and take you away from other work. It's that there are too many meetings that are inconsequential and never really needed to be had in the first place. When you have a valid topic for a meeting and only the appropriate participants who actually respect each others time (not showing up late) things work just fine. The concept of a meeting is not broken or inefficient; the application of meetings to problems/people that aren't best solved by a meeting is.
Nothing is more frustrating than trying to deal with someone who you KNOW is distracted. It's rude, and its inefficient. "Multi tasking" your way through a virtual meeting is a recipe for this. If your participation at meetings is that inconsequential, the real problem is that you were required to attend in the first place.
Slashdot Mirror
how about removing the "Administrator" account and change the RDP port?
Who leaves services like this exposed to the Internet in the first place? Do you people not have VPNs?
I think the intent is that this equipment would be brought into an area by a telco and be used with some sort of connectivity (whatever is available) to link back to the rest of the world.
There is no need for this to perform that function. Carriers have enough money to own COWs. http://en.wikipedia.org/wiki/Cell_on_wheels
stocking up for an unknown period of time in the future can cause problems. Ten years is about the limit of recommended time I could find.
Not true at all. I routinely use comblock and US surplus ammo from as far back as the 50s. When properly stored, it's good for a whole lot more than 10 years.
The reactor is housed inside of a containment vessel, which means that the melted material should be contained.
Ahem. TFA:
"Now the company is worried that the molten pool of radioactive fuel may have burned a hole through the bottom of the containment vessel, causing water to leak."
"Tepco has not clarified what other barriers there are to stop radioactive fuel leaking if the steel containment vessel has been breached. "
Corium is a bitch. It's gonna burn down as far as it damn well pleases.
So you really can't get by with just the IR-based detectors, unfortunately.
Quick! Somebody tell the International Code Council and the 95% of business and home owners that have had smokes installed in the last 10 years!
Where are you getting this idea from? The standard coverage accepted smoke is a photoelectric and has been for quite some time.
Why, yes, I am a part time code enforcement official who's jurisdiction just happens to be fire.
ATM crowd, please step to the stage for due credit... ...crickets...
Oh right, everyone went for the technology they understood instead of the better one. Par for the course.
There is no possible rebuttal to this.
it's going to be for such a small group of people (compared to the total set of computer users) that defining something backwards compatible with 100Mb/s Ethernet may not be worthwhile.
I'm not sure what you think I was responding to or talking about. You're bringing up a point that I completely agree with, but also one that I wasn't discussing in my post.
At least until it becomes very much cheaper, anything faster than gigabit is mostly about reducing the cable mess in high density situations. For instance, if you are doing server virtualization, cheap multicore CPUs and cheap RAM means that it isn't at all implausible or uncommon to have numerous VMs all living in a single 2U, with the bandwidth demands of whatever it is that they are doing, plus the bandwidth demands brought about by the fact that there isn't any room for disks in there, so all their storage I/O is happening over iSCSI. You end up with every expansion slot filled with 4 port gigE cards and a real rat's nest.
Try an ESXi cluster of a blade chassis of 16 servers, each running 10 or more VMs. The switch cross connects back to the core start to become a problem even at 10 GbE.
On the other hand, I've only found 100Mb/s too slow on a few occasions - maybe once per year. I've used GigE, but I've never come close to saturating it.
This isn't about or for home users, or even small office users. It's about network operators.
In my small operation (under 100 servers, 3 1 gb internet connections) I have several places where I completely saturate 1 GB and have, for cost reasons, trunked it (10 GbE is very expensive still when you look at having to replace/upgrade core switching to support it). Switch cross connects and SANs are the biggest offenders. Trunking sucks (anything that requires more complexity and configuration is always worse than the simpler solution in my opinion), and getting higher speed ethernet connections into the top of the market will reduce the cost of 10 GbE as well as giving us (datacenter guys) somewhere else to scale when we need it.
I got you. I know it can happen. I just don't see it being something that is likely in a properly managed network. I mean....come on....if you're in a position where you can swap out infrastructure equipment - even if your lab setup is moronic and shares VTP info - you ought to be (at a bare minimum) blowing away the config (which includes vlan.dat) and either copy-pasting from your config repository or creating a new one. My point is that this is very, very basic procedure. If you are tasked with touching infrastructure equipment, you ought to know these things. Also, if this happens it is a very quick restore if you have proper config backups and proper out of band access. Again, I guess I'm assuming a competency level that others aren't accustomed to. This stuff isn't hard.
Just so you know, even a VTP *client* with a higher revision number and a different table used to be able to / can wipe out a VTP domain by being introduced. Being a VTP server just allows you to add and remove VLANs from the database. VTPv3 is supposed to fix these kinds of things though. The last time this happened to me, thankfully, I still had the output from a "show vlan" in my scroll back buffer.
See my previous post about "crusty old IOS/CatOS".
Also, who the hell runs the same VTP name and auth key in production and the lab? That is BEGGING for problems.
Maybe I've just been doing this the right way for too long. I find it difficult te believe that there are networks of any scale that have any duration of uptime that aren't following very, very simple procedures to ensure uptime and/or are operating with such a complete lack of knowledge of the basic plumbing that makes them work. Also, who doesn't have automated config backups of infrastructure equipment?
I guess this boils down to the fact that I'm not an armchair network admin. I've been doing this a long time, and I know how it works. Someone doing something this stupid would be like watching someone put a car in gear and then crawl under it to me. It's not something you should have to TELL someone not to do. It's something that SHOULD'T HAPPEN when one or more well agreed upon basic procedures are being followed. If the person you are asking to do that kind of work needs to be told these things, you have failed as a manager, and likely as an organization. If your network(s) set the stage for this type of thing to be a possibility (sharing vtp info bewteen production and lab, hoping someone won't ever accidentally bridge the two) you again have failed as a manager or organization. The most basic of widely accepted best practices would put multiple barriers between this type of thing happening, requiring a cascading series of procedural failures to actually happen.
In summary.....Nope, still not buying this as a reasonable explanation.
Plenty of people run their VTP domains as all servers...since they are too lazy to remember which is the server :)
And to my point, that's amateur hour stuff. Not what one would expect in a professional data center.
Also, that would not cause this proposed issue, as if they were all servers, none of them would take data as ca VTP client. It would be like not running VTP at all.
So....what I said. Except you have it in your lab environment. And you don't relize its your VTP master. And you don't bother to put your production config on your replacement box before putting it in production....... Yeah. Not buying it as a likely scenario. This required multiple steps, and a fundamental lack of understanding of key functions of networking equipment in a datacenter setting (namely not knowing what your VTP master is) and a lack of any sort of sane procedures (putting a piece of equipment into production without so much as verifying a config). It's a plausible, but unlikely series of events that would require the input of someone who was not capable of building or maintaing the network in the first place.
More likely some idiot introduced a cisco switch into their VTP domain and it had a higher revision number queued up and it overwrote their entire LAN environment.
How does that even happen in a properly managed environment? In fact, even in an improperly managed one? I'd have to try hard to make that happen......I mean...really. Bring up an identically configured VTP master, change it enough times to get a higher rev number, put it on the same LAN and......without external inputs (dropping links to the real VTP master) pretty much nothing ought to happen (other than syslog screaming) unless you're using some really crusty old IOS/CatOS.
Long hours of menial tasks (how many times is it possible to jam the same printer anyway?), angry users (not my fault you didn't backup), and heavy work loads.
That's not a career in IT. You described a job at a help desk.
What are we supposed to do with our old Alphas? Just set them on fire? Not that I have one any more.
I think that's the point. As much as I like diving into old hardware, at some point I started getting rid of it because of space limitations and the simple fact that it's not feasible, even with new distro support, to do anything of consequence on it that can't be done cheaper (read: electric power) and faster on even the wimpiest of several year old cast off (free or nearly) servers and/or laptops.
(or gas)
I get your point, but you need to re-think that example. I have propane. It gets trucked in about 3 times a year. I have enough storage on site to last over a year without deliveries for a typical winter.
Not sure where you live for that to be your experience, but I'm 35 miles from Philadelphia, 35 miles from Princeton, and 75 miles from New York City. I'm not near any major city, not even any large towns. AT&T is 3G just about everywhere around here.
That's a nice try at another troll.
You demonstrated that you don't know enough about modern data center design based on your 4 word comment. No further information was necessary.
Plenty of people who have worked in data centers wouldn't know this, so the fact that you may have worked in one is a moot point.
See the reply to the guy who also doesn't know this stuff that was trying to stick up for you. http://slashdot.org/comments.pl?sid=1575066&cid=31403320
You are also assuming that all datacenters have and need UPSes. This is simply not the case. More and more facilities are going to flywheel generators as maintaining batteries for transfer time between mains and generator power is insanely expensive in floor space, labor, and replacement costs. Nothing in any of the linked content says what kind of generators they have, or anything about a UPS. Based on the simple fact that Google can afford and makes it a priority to hire too notch talent and build things the right way, are you really telling me that you believe you and ElectricTurtle are smarter than the combined brainpower set loose by Google for building and maintaining this facility?
lol you = don't know how datacenters work
encourage meetings (especially internal ones) to be done using instant messaging/IRC? This increases productivity since employees can be in more than one meeting at the same time, and they can still do other stuff. They could even go to the toilet or answer phones without interrupting the meeting
Do you _REALLY_ think that allowing, if not outright encouraging, people to be distracted will make for a productive exchange of ideas?
The real problem is not that meetings take too long and take you away from other work. It's that there are too many meetings that are inconsequential and never really needed to be had in the first place. When you have a valid topic for a meeting and only the appropriate participants who actually respect each others time (not showing up late) things work just fine. The concept of a meeting is not broken or inefficient; the application of meetings to problems/people that aren't best solved by a meeting is.
Nothing is more frustrating than trying to deal with someone who you KNOW is distracted. It's rude, and its inefficient. "Multi tasking" your way through a virtual meeting is a recipe for this. If your participation at meetings is that inconsequential, the real problem is that you were required to attend in the first place.
In the context of a user name of Apple Acolyte, I'm not thinking the reference is to consoles.
I'm pretty knowledgeable when it comes to new Internet tech
[...]
PowerPC zealot
Does not parse.
too socially inept or immature for College? Let them enter the workforce
Re-read that, and then tell me what you think about your suggestion.