Did anyone really think CDs were good for more than 5-10 years?
Gotta love how CNN assumes that everyone is as dumb as their editors. Somehow I doubt anyone in the slashdot crowd hasn't known about the longevity problems in CDs for at least 5 years now. And yet this is suddenly "news"?
I don't understand why the company isn't touting reliability.
Probably because they are? Their specs say 99.999% uptime all over them.
Too bad the storage is so teeny. Only 8-64 gig? What are we going to fit on that? Oh well, I guess it has applications for databases. But certainly nothing where you could survive waiting for your raid array to fetch the data.
this sounds like the best idea, at least the best idea i've read so
far.
Thanks... it took me about 20 minutes to come up with the idea, after
having a nightmare about being on death row and not wanting to give up
the passwords until the moment of my execution (just in case I got a
last-minute pardon, I wouldn't want the passwords to be compromised...).
Yes, I really did have that dream.
however... do you use the same password for quite some time, or do
you change it? for those that change passwords often for security
purposes, it would be a pain to go down and update your will each
time.
The passwords are not part of the will -- they are just stored in the
same envelope. And I have easy access to the envelope. So I can update
passwords if needed without having to amend the will (which would
necessitate having a witness sign it with me again, etc).
I confronted this issue a while back, when I realized my servers were nearly impossible to get into without screwdrivers, reference manuals, and lots of time. Ended up writing down passwords along with my will, and storing them in a sealed envelope with my signature over the flap. Instructions on the envelope say it is only to be opened in the event of my death, and it's left in the care of a trusted third party.
Ideally, I'd like to have a method for cleaning up certain things. There are probably files I wouldn't want others to see, in addition to files I *do* want them to see, but only after my death. Might be interesting to write a script that they would be told to execute, that would clean stuff up and print out my will. Of course, I'd have to put in protections to keep it from being run before my death....
I did some work on this a while back, dealing with splitting up passwords among N people such that any M people could recover the password (MN, of course). That way they all have to agree I'm dead, which prevents cheating.
Sure, it can transfer at 1 megabit. But that means they need to be able to generate crytographically strong random numbers at the 2MHz level, while changing polarizations to match. It's not a trivial statement. So... this might not be quite as safe as they're claiming. But those are just details which everyone hopes can be trivially solved in the near future.
My servers are gradually migrating to RHEL, most desktops are going to FC1 (FC2 seems a little iffy at present, so I'm testing it on a single box).
Initially I'd hoped to take advantage of the Fedora Legacy project, but they just don't seem serious. For example, one of their primary modes of distribution is via yum. They released packages for 7.2 and 7.3, but never for 8.0. I opened this bugzilla report on it nearly two months ago. They're just ignoring it. Hardly the response you want to see from someone you're trusting for security patches.... Maybe someone will mod this up enough that they'll take note.
As a side note, I'm keeping White Box Linux in the back of my mind as an option if FC2 flops. The legal issues are still a little disturbing, though.
With people recommending 100 for servers, and 0 for desktops, it makes me wonder: what's the default value of this parameter? (I can't check myself because I don't have any 2.6 boxen yet.) Would a slight change help? I really don't get why everyone is taking the all-or-nothing approach.
Also, someone mentioned an autoswappiness patch. Does that "solve" the issue?
Re:The reasons gentoo will never go enterprise
on
Gentoo Linux Musings
·
· Score: 1
Ok, so the predictable thing happened. The/. mods weren't sure what to do with my post, since it made sense, but goes against the current fad. And there were several responses, all of which contradicted themselves in an attempt to refute my individual points, while still missing the Big Picture. So, let me dumb it down for ya:
The primary reaction is that I can choose not to compile my own binaries, which gives me an exact set of binaries that can be used enterprise-wide. Which is fine. That's what RedHat does for me now.
And using these binaries allows me to save on the compilation time! Great! I don't do that with RedHat either, though. And of course, that kills off any performance increase Gentoo might have provided....
I'm just somewhat amused by those who say that vendor support isn't important. Obviously you don't have software like Tivoli TSM (for backups) that requires a specific kernel from a specific vendor. Or specialized raid cards. Yes, some stuff can be worked around by extracting vendor files from a.rpm and forcing them into place on a non-rpm system. But not all. I have to agree with the chicken-and-egg comment about vendors switching. So fine. You be the egg and take the risk of going *splat*. I'm too chicken.;)
The reasons gentoo will never go enterprise
on
Gentoo Linux Musings
·
· Score: 0, Insightful
identical binaries: we want to be able to take binaries from one system and use them on another. If a binary crashes, we need to be able to reproduce the problem on another system. Having binaries compiled with different options everywhere makes tracking down stability issues and other bugs a nightmare.
patches: enterprise systems don't want to upgrade, they want the patches to be backported to their version. New version of foobar fixes a security hole? We don't want it! We want the old version, with a patch. Otherwise we might have to modify our config files.
vendor support: some products will only work on certain distributions. The reason is that the vendors don't have time to test their product on every distribution. If they have to pick only one or two, it will be RedHat Enterprise and SuSE Enterprise. Gentoo rules itself out by not having a canonical set of binaries.
CPU time is valuable: we spend lots of money on our servers, and expect to get performance out of them. We really don't want to waste CPU time on compiling. Yes, I'm aware that a faster machine can compile faster. So what? I'm not about to spec out faster machines just to keep up with the compilation requirements. We'd rather spend our money elsewhere.
<flame>Sometimes I wonder if there are any real sysadmins that support gentoo, or if it's just a distro for a bunch of kids to use at home. Which isn't to say that having kids at home beta-test all the latest stuff isn't useful. It's just annoying when they start telling the real admins how to run the shop. Ok,/. kiddies, mod me into oblivion.
Just a note for all the idiots responding to this post: yes, I did watch the next scene. I was giving this as an example of how physics actually played into a storyline, and how if the average grunt sitting around guarding a safe knew more physics, the movie would have ended in the first scene.
I will admit that when watching it I was indeed "fooled". While I didn't believe for an instant that a safe could realistically fall and not crash through a boat, I was honestly fooled into believing that the director didn't know basic physics.
In the opening scenes, they have a safe drop through several floors and land in a boat. Now, I have an interest in security, and I know that safes weigh a lot. Falling several stories down, even if slowed by an impact with each floor, would give that thing enough penetrating power to punch right through any boat. So when I saw the boat speeding off with the safe in the back, I started laughing and telling the person next to me how stupid that was.
Oh, and yes, IAAP (I Am A Physicist), so really obvious physics stupidities jump out at me. Like sound effects in space....
I prefer to give a good hard hit on the brake pedal to wake them up
I've actually come up with a plan for how to do it to maximize the likelihood of fatality to the SUV-driving tailgater behind me. Here's how it goes:
Hit your brake, while moving a little to the right. They'll instinctively brake and move to the left.
Now, brake a little harder, but cut back to the left. They'll either swerve off the road, or cut back to the right. If they go to the right, they'll be maximizing pressure on the front left wheel. That is the way SUVs are statistically most likely to roll.
Now, technically doing this is premeditated murder, but who's to say you didn't see an animal in the road, and were avoiding it?
Disclaimer: make sure they're paying attention if you do this... otherwise they might just hit you without braking at all.
The 4TB arrays are units we're evaluating (one from Excel, the other from RaidKing). They're just rack-mountable boxes that have a scsi uplink. So, as far as the computer is concerned, you just have one massive scsi drive. (There's a catch, which is that these units can't seem to have more than 2TB per "device", so you really get two scsi devices presented to the computer.)
Life is made a litte annoying by the 2TB limit in the 2.4 kernel. But we're willing to live with that, for now. I'm told there are patches to fix this, but I prefer stability over features for this box.
As for 3ware, I've got a box with an Escalade 7500-4LP running RedHat 9. It works by default (can boot off the raid, etc). 3ware has extra drivers, but I don't use them. It's a messy situation, since you have to simultaneously upgrade firmware, driver, and utility programs. I've been less-than-impressed with their support. When I reported that the md5sum on their website didn't match the file, they said "We know.... don't worry about it... it doesn't matter." Umm, yeah. Right.
As I said, it's 16 SATA drives in hardware raid5 that presents itself to the server as a single scsi device.
Yes, they have a lower MTBF, but it's in a raid array, so who cares? It'll automagically rebuild on our hot spare, and when we wake up to the email, we just go in and replace the downed drive with another.
And yes, they have slightly lower performance. But the real performance reason for using SCSI instead of IDE is that it offloads the work to the SCSI controller/disk instead of wasting CPU time. If the entire raid array is presented to the system as a scsi device, then there's really no performance loss.
It's certainly cheaper, performs about as well, and we have backups anyway (gotta have those to protect against lightning strikes and wily h4x0rs).
I think 1000 of those were related to a little accident we had. Having an intelligent MUA that can select/delete by subject line is a wonderful thing. Especially when you get 1000 identical emails in about 5 minutes.
First off, you're looking at the wrong "uptime" number. Don't look at how many days since your last reboot. Look at how many hours/year you are offline. If you're not doing raid, a failed disk means restoring from backups. That's a time-consuming, and therefore costly, process. If your controller fails, just pop in your spare controller. You do have a spare in-house, don't you?
I'll agree that setting it up is a nightmare. I'm currently helping test two 4TB arrays for use on a Linux box (16 SATA drives presented as a single SCSI device). Benchmarks under linux are slower than under windows. It's a mess figuring out why. Meanwhile, vendors (who I will not name ship crappy software, and take months to act on bug reports.
As for transitioning servers, I've been there too. And yes, copying a terabyte of disk in single is a very long process. It'd have taken several days, which is of course unacceptable. This is where the magic of rsync comes in handy. Copy the data over several days in advance, sync it just before the scheduled downtime, and you'll have a fairly short downtime.
The explanation is that you're imagining things. That's what happens when you start sniffing chemicals on the first floor.;)
I just got curious, so I combined a little grep, wc, and gnuplot to produce this plot showing my email history over the past few months. No significant change in the past week.
This is for a production server, so we'd prefer to avoid 2.6.x if possible (it doesn't seem to have stabilized quite yet).
We're using a hardware raid (16 SATA drives that present themselves to the host as a single SCSI drive), which I think rules out the DMA/32 issue (that's IDE-only, right?). In any case, we're getting twice the read performance under Windows 2003 Server without hardware changes.
The network is definitely at 1000Mb mode. I can even get it to benchmark at 940Mb using iperf (both TCP and UDP). Obviously I should expect some slowdowns due to application overhead, but a slowdown by nearly a factor of 10 seems excessive. As a side note (in the off-chance it's relevant), our server has two gigE cards, channel-bonded. (I know the switch has limitations, but we still like the second for the redundancy it provides.)
Any advice you can provide for either issue would be greatly appreciated. (We've been beating our heads against this issue for a long time, and are open to try anything. That 2.6 kernel is even looking good at this point.)
How about hints for improving disk performance? I've got a raid array that does 100M/s reads, 80M/s writes under Win2k3 Server, but only 40M/s reads, 80M/s writes under RHEL 3.0. Obviously something is screwy with the linux read speeds, but we can't figure out why.
I won't even start on our network performance problems, which are around 15M/s transfers (our network is capable of 100M/s).
Is turning on your regular headlights during the day also illegal there?
Yes, I believe it is.
Where she lives, they have some rather unusual rules. Like right of way is determined by who flashes their lights first (roads aren't always wide enough for two vehicles to pass). If you have DRLs, that makes right-of-way a bit harder to determine, doesn't it?
Just an example... my sister bought a car that came with daytime running lights (DRL). Well, she moved to a location where they are illegal. Too bad the mechanics can't figure out how to disable them....
Slashdot Mirror
Gotta love how CNN assumes that everyone is as dumb as their editors. Somehow I doubt anyone in the slashdot crowd hasn't known about the longevity problems in CDs for at least 5 years now. And yet this is suddenly "news"?
Probably because they are? Their specs say 99.999% uptime all over them.
Too bad the storage is so teeny. Only 8-64 gig? What are we going to fit on that? Oh well, I guess it has applications for databases. But certainly nothing where you could survive waiting for your raid array to fetch the data.
Thanks... it took me about 20 minutes to come up with the idea, after having a nightmare about being on death row and not wanting to give up the passwords until the moment of my execution (just in case I got a last-minute pardon, I wouldn't want the passwords to be compromised...). Yes, I really did have that dream.
however... do you use the same password for quite some time, or do you change it? for those that change passwords often for security purposes, it would be a pain to go down and update your will each time.
The passwords are not part of the will -- they are just stored in the same envelope. And I have easy access to the envelope. So I can update passwords if needed without having to amend the will (which would necessitate having a witness sign it with me again, etc).
Ideally, I'd like to have a method for cleaning up certain things. There are probably files I wouldn't want others to see, in addition to files I *do* want them to see, but only after my death. Might be interesting to write a script that they would be told to execute, that would clean stuff up and print out my will. Of course, I'd have to put in protections to keep it from being run before my death....
I did some work on this a while back, dealing with splitting up passwords among N people such that any M people could recover the password (MN, of course). That way they all have to agree I'm dead, which prevents cheating.
Sure, it can transfer at 1 megabit. But that means they need to be able to generate crytographically strong random numbers at the 2MHz level, while changing polarizations to match. It's not a trivial statement. So... this might not be quite as safe as they're claiming. But those are just details which everyone hopes can be trivially solved in the near future.
Initially I'd hoped to take advantage of the Fedora Legacy project, but they just don't seem serious. For example, one of their primary modes of distribution is via yum. They released packages for 7.2 and 7.3, but never for 8.0. I opened this bugzilla report on it nearly two months ago. They're just ignoring it. Hardly the response you want to see from someone you're trusting for security patches.... Maybe someone will mod this up enough that they'll take note.
As a side note, I'm keeping White Box Linux in the back of my mind as an option if FC2 flops. The legal issues are still a little disturbing, though.
Also, someone mentioned an autoswappiness patch. Does that "solve" the issue?
The primary reaction is that I can choose not to compile my own binaries, which gives me an exact set of binaries that can be used enterprise-wide. Which is fine. That's what RedHat does for me now.
And using these binaries allows me to save on the compilation time! Great! I don't do that with RedHat either, though. And of course, that kills off any performance increase Gentoo might have provided....
I'm just somewhat amused by those who say that vendor support isn't important. Obviously you don't have software like Tivoli TSM (for backups) that requires a specific kernel from a specific vendor. Or specialized raid cards. Yes, some stuff can be worked around by extracting vendor files from a .rpm and forcing them into place on a non-rpm system. But not all. I have to agree with the chicken-and-egg comment about vendors switching. So fine. You be the egg and take the risk of going *splat*. I'm too chicken. ;)
<flame>Sometimes I wonder if there are any real sysadmins that support gentoo, or if it's just a distro for a bunch of kids to use at home. Which isn't to say that having kids at home beta-test all the latest stuff isn't useful. It's just annoying when they start telling the real admins how to run the shop. Ok, /. kiddies, mod me into oblivion.
I will admit that when watching it I was indeed "fooled". While I didn't believe for an instant that a safe could realistically fall and not crash through a boat, I was honestly fooled into believing that the director didn't know basic physics.
Oh, and yes, IAAP (I Am A Physicist), so really obvious physics stupidities jump out at me. Like sound effects in space....
Ok, so everyone's caught on to the fact that it prevents fast motions, and allows slow ones. So, can you run? How fast is too fast?
-1, Troll -- Gratuitous sendmail bashing.
I've actually come up with a plan for how to do it to maximize the likelihood of fatality to the SUV-driving tailgater behind me. Here's how it goes:
- Hit your brake, while moving a little to the right. They'll instinctively brake and move to the left.
- Now, brake a little harder, but cut back to the left. They'll either swerve off the road, or cut back to the right. If they go to the right, they'll be maximizing pressure on the front left wheel. That is the way SUVs are statistically most likely to roll.
Now, technically doing this is premeditated murder, but who's to say you didn't see an animal in the road, and were avoiding it?Disclaimer: make sure they're paying attention if you do this... otherwise they might just hit you without braking at all.
Oh, and yes, I'm a professional bastard. >:-]
Life is made a litte annoying by the 2TB limit in the 2.4 kernel. But we're willing to live with that, for now. I'm told there are patches to fix this, but I prefer stability over features for this box.
As for 3ware, I've got a box with an Escalade 7500-4LP running RedHat 9. It works by default (can boot off the raid, etc). 3ware has extra drivers, but I don't use them. It's a messy situation, since you have to simultaneously upgrade firmware, driver, and utility programs. I've been less-than-impressed with their support. When I reported that the md5sum on their website didn't match the file, they said "We know.... don't worry about it... it doesn't matter." Umm, yeah. Right.
Yes, they have a lower MTBF, but it's in a raid array, so who cares? It'll automagically rebuild on our hot spare, and when we wake up to the email, we just go in and replace the downed drive with another.
And yes, they have slightly lower performance. But the real performance reason for using SCSI instead of IDE is that it offloads the work to the SCSI controller/disk instead of wasting CPU time. If the entire raid array is presented to the system as a scsi device, then there's really no performance loss.
It's certainly cheaper, performs about as well, and we have backups anyway (gotta have those to protect against lightning strikes and wily h4x0rs).
I think 1000 of those were related to a little accident we had. Having an intelligent MUA that can select/delete by subject line is a wonderful thing. Especially when you get 1000 identical emails in about 5 minutes.
I'll agree that setting it up is a nightmare. I'm currently helping test two 4TB arrays for use on a Linux box (16 SATA drives presented as a single SCSI device). Benchmarks under linux are slower than under windows. It's a mess figuring out why. Meanwhile, vendors (who I will not name ship crappy software, and take months to act on bug reports.
As for transitioning servers, I've been there too. And yes, copying a terabyte of disk in single is a very long process. It'd have taken several days, which is of course unacceptable. This is where the magic of rsync comes in handy. Copy the data over several days in advance, sync it just before the scheduled downtime, and you'll have a fairly short downtime.
I just got curious, so I combined a little grep, wc, and gnuplot to produce this plot showing my email history over the past few months. No significant change in the past week.
We're using a hardware raid (16 SATA drives that present themselves to the host as a single SCSI drive), which I think rules out the DMA/32 issue (that's IDE-only, right?). In any case, we're getting twice the read performance under Windows 2003 Server without hardware changes.
The network is definitely at 1000Mb mode. I can even get it to benchmark at 940Mb using iperf (both TCP and UDP). Obviously I should expect some slowdowns due to application overhead, but a slowdown by nearly a factor of 10 seems excessive. As a side note (in the off-chance it's relevant), our server has two gigE cards, channel-bonded. (I know the switch has limitations, but we still like the second for the redundancy it provides.)
Any advice you can provide for either issue would be greatly appreciated. (We've been beating our heads against this issue for a long time, and are open to try anything. That 2.6 kernel is even looking good at this point.)
No. Does such an island exist?
By MiB/s I mean mebibytes per second.
By mebibyte I mean 2^20 bytes.
By byte I mean 8 bits.
I hope that clears things up.
(Our network is gigE, before someone tries explaining that 100Mb/s fast ethernet can't do 100M/s transfers.)
I won't even start on our network performance problems, which are around 15M/s transfers (our network is capable of 100M/s).
Yes, I believe it is.
Where she lives, they have some rather unusual rules. Like right of way is determined by who flashes their lights first (roads aren't always wide enough for two vehicles to pass). If you have DRLs, that makes right-of-way a bit harder to determine, doesn't it?
Just an example... my sister bought a car that came with daytime running lights (DRL). Well, she moved to a location where they are illegal. Too bad the mechanics can't figure out how to disable them....