That's why Vista doesn't "shutdown"; it "hibernates". There are extra steps to make it actually shut the f*** down. But doing so means a lot longer "boot" time due to all the top-secret crap it does on startup.
PS: A former employer learned the very expensive lesson of what happens when you tell everyone to turn off your monitor before leaving each day so they can "save money on AC". Within 3 weeks they had replaced 90% of the monitors in the building because they wouldn't power back on. It would have been even worse if they said turn your computer off... dead hard drives everywhere!
energy saving policy that requires us to shut down the computer every night
Pretty much every computer made in the last decade supports low power "sleep" modes and completely powered off "hibernation". Returning from sleep to running usually takes seconds. Hibernation resumes in less than 5 minutes. (usually about 1.) This, of course, ignores the need to perform all those "idle background" tasks that cannot be done with the machine off -- virus updates, windows updates, etc., etc.
(As I have to explain weekly to sales people... your virus definitions never update because your computer is off or disconnected at 10pm when the server pushes the updates. And since your laptop is usually disconnected from any network when it is reactivated in the morning, it won't be able to check in for a random period of time. And if you are connected at 10pm, your laptop will appear to "go insane" when the update(s) are pushed out because it does a quick scan and/or restarts the software. Windows Update is even worse since it has a nasty habit of eating 100% of the cpu for long periods.)
Sadly, most of today's "pager companies" are just piggybacked on cellular networks which makes the coverage about the same as a cell phone -- it's a cheap service so it's pretty easy to partner with almost everybody. The days of the 150-ish MHz pagers is long past.
Just because no (active) kernel developer has the hardware does not mean there are no users with that hardware. I've seen drivers removed from the kernel for lack of a maintainer while they were still fully functional -- "ugly code" doesn't matter if it works and people depend on it. Every time a driver is removed, there are end users who complain about it.
Drivers do not get maintained for ever. I've been around long enough to see several drivers unmaintained and eventually dropped. And saying there's a new driver that supports the newer X and is supposed to be backwards compat with the older X, is all too often not entirely true -- sure, there's the qla driver from Qlogic, and it's supposed to support 2100's, but every 2100 I've ever tried (and that's dozens) has locked up using qla2100 while the old -- dropped several years ago -- qlogicfc driver works perfectly. (and based on conversations with qlogic engineers looking into the issue... they haven't had any 2100's for years.)
Actually, I tried making a 42 drive RAID5, but Linux wouldn't have it -- the limit was 26 (md). Dmraid will do it, but keeping parity limited to one shelf is a lot faster.
I have a $200 LTO2 drive (HH, external, with SCSI card) from eBay. Unless things have changed a lot in the last year, you just aren't looking in the right places often enough.
Actually, most of NASA's issues were not the tapes themselves, but finding hardware capabale of reading them. A properly cared for tape will last decades (manufacturers quote 30yrs MINIMUM) -- even a moderately cared for tape will last multiple decades (the ~20yr old tape that's been sitting in my kitchen for the past 11 years was perfectly readable last year when I found a compat drive.)
However, they do have a finite lifetime. The plastic ribbon that is the backbone of the tape will eventually degrade, crack, and fall apart. Seeing how the tape has to be under tention to be read, it will become unusable long before the magnetic information is lost. Yet, the most common "failure" is having tapes without a functional drive to read them.
And I have commercially manufactured DVDs less than 2 years old that are no longer playable -- the layers have fused. (one of them is my DVD of Army of Darkness!)
I submit you just don't know where to shop. eBay may get bad looks, but when you don't have the budget for new gear from CDW, it's a great source of stuff. I don't recommend buying used tapes (or hard drives in general) for important backups, but a used tape drive or library still has a great deal of life left in it. You don't need top of the line LTO16 technology to backup TB's of data -- and a TB or storage doesn't mean a TB of data to backup. I do it every week with SDLT320 (160GB) (onsite) and LTO2 (200G) (offsite) tapes. I used to do it with AIT-2 (50G) tapes. And IMO, the key factor in backups is speed, not size of each volume; backups need to complete within 4-6 hours. When it take 8-10 hrs or more, you need to start thinking about more drives and/or faster technology.
You see 70G and 140G drives because they are very, very, very fast and very, very reliable. While rebuild times are important, performance is often far more important, and that means more spindles. For example, my 42 drive (6 shelves * 7 drives * 18G) FC array can continuously flood a dual attached 4G FC controller. (using linux software raid... each shelf is a raid5 volume striped into a 6 volume raid0. And those are 11 year old, fully functional, FC-1 drives.)
Like it doesn't freak the hell out on the first error? Put down the crack pipe and step away from the server room. Linux is just as bad, if not worse, than hardware systems in the face of errors.
Linux software raid is easier to deal with, but that's simply because you're on the inside. It's pretty easy to make it shutup and reassemble the array anyway. You can do the same on a number of hardware systems, but it's always an undocumented "internal" process that has to be entered via morse code with a paper clip -- login to a serial port you didn't know it had with a password you don't have to run commands even the source code doesn't document.
SS7 can be spoofed, too. It's just a lot more work and needs access very few people have. No telco I've ever worked at, with, or ever walked through would even know someone had set something like this up. (they don't expect it, nor look for it.)
PRI's use DNIS and ANI. They are not caller-id. Most phone companies ignore the information sent to them from a customer's PRI; the switch fills the origin of the call based on the origin of the call. Caller-id spoofing is rather easy as it's just a short burst of ancient modem tones (1200 baud) between rings. The real problem is dumb callerid hardware that will listen to any broadcast and not the one between first and second ring (the one sent by the telco equipment.)
I saw an Exide Powerware (100kva?) system do that. One of it's many batteries exploded. *boom* exploded. Datacenter went dark. It was the only time I've ever seen a populated datacenter silenced. (I've seen plenty of *empty* silent datacenters.) Exide was there within the hour to fix it. (i.e. inspect and replace every battery.) I've seen many smaller (rack mount) UPSen melt/boil their batteries. I've seen a transfer switch convert itself into a pool of metal and chared plastic -- that was a Good Day(tm). (and many more...)
As a wild generalization, I would agree. However, experience has shown that such a generalization is merely that. It's not hard or expensive to setup a mail server that works perfectly with virtually zero downtime without needing a team of engineers constantly maintaining it. The linux (sendmail/cyrus) mail server I built 5+ years ago is still running perfectly fine with no non-power related disruptions, ever. And nobody has touched it in over a year. The other Communigate mail servers I've built over the years are the same way. As long as the hardware doesn't break, they just keep on going.
Btw, the very reason that mail server was built was because of horrible experiences with outsourcing email. If you run it, performance and reliability are in your hands. Outsourcing puts you at the mercy of your provider -- who can provide shitty service, collect your money, and close up shop.
I have to agree here. I've worked for several ISPs, telcos, and software companies over the years, and I've never left anything this critical (effecting so many people) down for so long. No mail server I have ever managed as been down for more than a few hours -- and only then because there was no power in the building. The system mastering server at my current employer is the longest I've left anything down, but it wasn't stopping anyone else from getting work done. (raid and mirrors won't help when a bug in the filesystem screws things up and an oversight in the backup software (default) configuration meant it ignored a fair amount of Very Important Files (directories named core.) It needed rebuilding before it failed anyway. Dead servers are good budget approval makers. *grin*)
Right. And the logic process of car vs. plane comes down to how long it takes to drive vs. fly. How much it costs to drive vs. fly. And the hastle of flying vs. driving. While distance is the bottom line factor, time is what people consider.
yes, applications/protocols that make bad assumptions about network setup have issues. (i.e. those things that think they are smarter than the network stack to know what their external address is. Those protocols had issues before NAT was ever thought of. If you bind INADDR_ANY, you don't know what your address is. No protocol designed in the last decade should ever make any assumption about what addresses the other end sees. yes, I'm bashing SIP.)
FTP in passive mode works perfectly without a protocol helper. The original standard for FTP (port mode) was written about 30 years. The internet is very different today. You cannot trust the client to tell you were to connect; it's too easily abused, and in the era of NAT the address of the socket you've setup for the connection isn't necessarily what the far end sees.
And in todays networks with firewalls (which everyone should be using), you need specific protocol handlers anyway so secondary communications channels we be allowed through.
People have been preaching IPv6 (IPng) for over a decade. Just like they've been screaming the sky is falling w.r.t. IPv4 address exhaustion pretty much since the first/8 was assigned.
You are underestimating the amount of work necessary as well as the amount of "legacy" equipment still in use today. Just look around your home/office and count up the number of devices for which the manufacturer has gone out of business (bought out, etc.) or has been declared "end-of-life" and is no longer supported. All of those devices are obviously working and providing some utility or they wouldn't be there.
Bottom line: it's going to cost people/companies a lot of money and time to replace equipment and software, and reconfigure systems in order to support IPv6. Right now, no one is willing to spend that much money for something that Is Not Necessary.
Actually, it is far more complicated than current generation IPv4 NAT/PAT. IPv4/IPv6 requires a protocol bridge. I guess you are too young (and I'm really not that old) to remember when IPv4 ("IP") was new. Everybody had networks built with Appletalk, IPX, etc. A company that wanted to "get on the internet" either had to replace equipment and completely restructure their network into a "dual stack" rig -- while you could install a TCP/IP package in windows and Mac System 6, none of the services commonly in use (i.e. the reason for the network in the first place) would use IP. It took many more years for IP to finally become the backbone. For example, a decade (+) ago game makers were still using IPX for network play. And even as recent as 2003, the telco I was working for still had, and used, a large IPX network. (luckily, they had fazed out all the token ring hardware in the mid/late '90s.)
It's not as simple as rewriting the source or destination in a packet. Both have to be changed and the entire packet rebuilt. Plus, there has to be logic to dynamically turn the IPv6 world into an IPv4 world -- because a legacy device has zero understanding of v6, it cannot understand a v6 address at all.
Heh, thanks troll. You're as bad as the lame tv spots making people think they have to buy a new TV before then or their TV will explode -- "stop working" as in "no longer power on".
ATSC recorders are not thousands of dollars. They are a few hundred at most. And the converter boxes are almost universally $49-59 -- go get your $40 FCC rebate cards.
The plain truth... On Feb. 18, 2009, all terrestrial NTSC broadcasts will cease. If that's all you watch, then you'll no longer have any stations to watch without the purchase of a converter box (or new TV -- all TVs on the market today are required by law to have an ATSC tuner in them even if they do not display in HD.) This does not effect pay TV services AT ALL.
Slashdot Mirror
That's why Vista doesn't "shutdown"; it "hibernates". There are extra steps to make it actually shut the f*** down. But doing so means a lot longer "boot" time due to all the top-secret crap it does on startup.
PS: A former employer learned the very expensive lesson of what happens when you tell everyone to turn off your monitor before leaving each day so they can "save money on AC". Within 3 weeks they had replaced 90% of the monitors in the building because they wouldn't power back on. It would have been even worse if they said turn your computer off... dead hard drives everywhere!
Pretty much every computer made in the last decade supports low power "sleep" modes and completely powered off "hibernation". Returning from sleep to running usually takes seconds. Hibernation resumes in less than 5 minutes. (usually about 1.) This, of course, ignores the need to perform all those "idle background" tasks that cannot be done with the machine off -- virus updates, windows updates, etc., etc.
(As I have to explain weekly to sales people... your virus definitions never update because your computer is off or disconnected at 10pm when the server pushes the updates. And since your laptop is usually disconnected from any network when it is reactivated in the morning, it won't be able to check in for a random period of time. And if you are connected at 10pm, your laptop will appear to "go insane" when the update(s) are pushed out because it does a quick scan and/or restarts the software. Windows Update is even worse since it has a nasty habit of eating 100% of the cpu for long periods.)
Sadly, most of today's "pager companies" are just piggybacked on cellular networks which makes the coverage about the same as a cell phone -- it's a cheap service so it's pretty easy to partner with almost everybody. The days of the 150-ish MHz pagers is long past.
Just because no (active) kernel developer has the hardware does not mean there are no users with that hardware. I've seen drivers removed from the kernel for lack of a maintainer while they were still fully functional -- "ugly code" doesn't matter if it works and people depend on it. Every time a driver is removed, there are end users who complain about it.
Drivers do not get maintained for ever. I've been around long enough to see several drivers unmaintained and eventually dropped. And saying there's a new driver that supports the newer X and is supposed to be backwards compat with the older X, is all too often not entirely true -- sure, there's the qla driver from Qlogic, and it's supposed to support 2100's, but every 2100 I've ever tried (and that's dozens) has locked up using qla2100 while the old -- dropped several years ago -- qlogicfc driver works perfectly. (and based on conversations with qlogic engineers looking into the issue... they haven't had any 2100's for years.)
So do I, boxes of them actually. But it was part of the collection, so one more in the box.
Actually, I tried making a 42 drive RAID5, but Linux wouldn't have it -- the limit was 26 (md). Dmraid will do it, but keeping parity limited to one shelf is a lot faster.
I have a $200 LTO2 drive (HH, external, with SCSI card) from eBay. Unless things have changed a lot in the last year, you just aren't looking in the right places often enough.
Actually, most of NASA's issues were not the tapes themselves, but finding hardware capabale of reading them. A properly cared for tape will last decades (manufacturers quote 30yrs MINIMUM) -- even a moderately cared for tape will last multiple decades (the ~20yr old tape that's been sitting in my kitchen for the past 11 years was perfectly readable last year when I found a compat drive.)
However, they do have a finite lifetime. The plastic ribbon that is the backbone of the tape will eventually degrade, crack, and fall apart. Seeing how the tape has to be under tention to be read, it will become unusable long before the magnetic information is lost. Yet, the most common "failure" is having tapes without a functional drive to read them.
And I have commercially manufactured DVDs less than 2 years old that are no longer playable -- the layers have fused. (one of them is my DVD of Army of Darkness!)
I submit you just don't know where to shop. eBay may get bad looks, but when you don't have the budget for new gear from CDW, it's a great source of stuff. I don't recommend buying used tapes (or hard drives in general) for important backups, but a used tape drive or library still has a great deal of life left in it. You don't need top of the line LTO16 technology to backup TB's of data -- and a TB or storage doesn't mean a TB of data to backup. I do it every week with SDLT320 (160GB) (onsite) and LTO2 (200G) (offsite) tapes. I used to do it with AIT-2 (50G) tapes. And IMO, the key factor in backups is speed, not size of each volume; backups need to complete within 4-6 hours. When it take 8-10 hrs or more, you need to start thinking about more drives and/or faster technology.
You see 70G and 140G drives because they are very, very, very fast and very, very reliable. While rebuild times are important, performance is often far more important, and that means more spindles. For example, my 42 drive (6 shelves * 7 drives * 18G) FC array can continuously flood a dual attached 4G FC controller. (using linux software raid... each shelf is a raid5 volume striped into a 6 volume raid0. And those are 11 year old, fully functional, FC-1 drives.)
Like it doesn't freak the hell out on the first error? Put down the crack pipe and step away from the server room. Linux is just as bad, if not worse, than hardware systems in the face of errors.
Linux software raid is easier to deal with, but that's simply because you're on the inside. It's pretty easy to make it shutup and reassemble the array anyway. You can do the same on a number of hardware systems, but it's always an undocumented "internal" process that has to be entered via morse code with a paper clip -- login to a serial port you didn't know it had with a password you don't have to run commands even the source code doesn't document.
SS7 can be spoofed, too. It's just a lot more work and needs access very few people have. No telco I've ever worked at, with, or ever walked through would even know someone had set something like this up. (they don't expect it, nor look for it.)
PRI's use DNIS and ANI. They are not caller-id. Most phone companies ignore the information sent to them from a customer's PRI; the switch fills the origin of the call based on the origin of the call. Caller-id spoofing is rather easy as it's just a short burst of ancient modem tones (1200 baud) between rings. The real problem is dumb callerid hardware that will listen to any broadcast and not the one between first and second ring (the one sent by the telco equipment.)
Indeed it would. It's not so much the fault of the UPS as the battery itself. A lot of people are more interested in cheap than good.
I saw an Exide Powerware (100kva?) system do that. One of it's many batteries exploded. *boom* exploded. Datacenter went dark. It was the only time I've ever seen a populated datacenter silenced. (I've seen plenty of *empty* silent datacenters.) Exide was there within the hour to fix it. (i.e. inspect and replace every battery.) I've seen many smaller (rack mount) UPSen melt/boil their batteries. I've seen a transfer switch convert itself into a pool of metal and chared plastic -- that was a Good Day(tm). (and many more...)
I didn't. The linux kernel tree does. And I said it was a bad idea at the time :-)
As a wild generalization, I would agree. However, experience has shown that such a generalization is merely that. It's not hard or expensive to setup a mail server that works perfectly with virtually zero downtime without needing a team of engineers constantly maintaining it. The linux (sendmail/cyrus) mail server I built 5+ years ago is still running perfectly fine with no non-power related disruptions, ever. And nobody has touched it in over a year. The other Communigate mail servers I've built over the years are the same way. As long as the hardware doesn't break, they just keep on going.
Btw, the very reason that mail server was built was because of horrible experiences with outsourcing email. If you run it, performance and reliability are in your hands. Outsourcing puts you at the mercy of your provider -- who can provide shitty service, collect your money, and close up shop.
I have to agree here. I've worked for several ISPs, telcos, and software companies over the years, and I've never left anything this critical (effecting so many people) down for so long. No mail server I have ever managed as been down for more than a few hours -- and only then because there was no power in the building. The system mastering server at my current employer is the longest I've left anything down, but it wasn't stopping anyone else from getting work done. (raid and mirrors won't help when a bug in the filesystem screws things up and an oversight in the backup software (default) configuration meant it ignored a fair amount of Very Important Files (directories named core.) It needed rebuilding before it failed anyway. Dead servers are good budget approval makers. *grin*)
Right. And the logic process of car vs. plane comes down to how long it takes to drive vs. fly. How much it costs to drive vs. fly. And the hastle of flying vs. driving. While distance is the bottom line factor, time is what people consider.
yes, applications/protocols that make bad assumptions about network setup have issues. (i.e. those things that think they are smarter than the network stack to know what their external address is. Those protocols had issues before NAT was ever thought of. If you bind INADDR_ANY, you don't know what your address is. No protocol designed in the last decade should ever make any assumption about what addresses the other end sees. yes, I'm bashing SIP.)
FTP in passive mode works perfectly without a protocol helper. The original standard for FTP (port mode) was written about 30 years. The internet is very different today. You cannot trust the client to tell you were to connect; it's too easily abused, and in the era of NAT the address of the socket you've setup for the connection isn't necessarily what the far end sees.
And in todays networks with firewalls (which everyone should be using), you need specific protocol handlers anyway so secondary communications channels we be allowed through.
People have been preaching IPv6 (IPng) for over a decade. Just like they've been screaming the sky is falling w.r.t. IPv4 address exhaustion pretty much since the first /8 was assigned.
You are underestimating the amount of work necessary as well as the amount of "legacy" equipment still in use today. Just look around your home/office and count up the number of devices for which the manufacturer has gone out of business (bought out, etc.) or has been declared "end-of-life" and is no longer supported. All of those devices are obviously working and providing some utility or they wouldn't be there.
Bottom line: it's going to cost people/companies a lot of money and time to replace equipment and software, and reconfigure systems in order to support IPv6. Right now, no one is willing to spend that much money for something that Is Not Necessary.
Actually, it is far more complicated than current generation IPv4 NAT/PAT. IPv4/IPv6 requires a protocol bridge. I guess you are too young (and I'm really not that old) to remember when IPv4 ("IP") was new. Everybody had networks built with Appletalk, IPX, etc. A company that wanted to "get on the internet" either had to replace equipment and completely restructure their network into a "dual stack" rig -- while you could install a TCP/IP package in windows and Mac System 6, none of the services commonly in use (i.e. the reason for the network in the first place) would use IP. It took many more years for IP to finally become the backbone. For example, a decade (+) ago game makers were still using IPX for network play. And even as recent as 2003, the telco I was working for still had, and used, a large IPX network. (luckily, they had fazed out all the token ring hardware in the mid/late '90s.)
It's not as simple as rewriting the source or destination in a packet. Both have to be changed and the entire packet rebuilt. Plus, there has to be logic to dynamically turn the IPv6 world into an IPv4 world -- because a legacy device has zero understanding of v6, it cannot understand a v6 address at all.
Heh, thanks troll. You're as bad as the lame tv spots making people think they have to buy a new TV before then or their TV will explode -- "stop working" as in "no longer power on".
ATSC recorders are not thousands of dollars. They are a few hundred at most. And the converter boxes are almost universally $49-59 -- go get your $40 FCC rebate cards.
The plain truth... On Feb. 18, 2009, all terrestrial NTSC broadcasts will cease. If that's all you watch, then you'll no longer have any stations to watch without the purchase of a converter box (or new TV -- all TVs on the market today are required by law to have an ATSC tuner in them even if they do not display in HD.) This does not effect pay TV services AT ALL.