Yep. My father worked on every Saturn (guidance and control, especially the LVDC on the IU) except SA-1 (and then Shuttle, X-33, and now Ares). He retired from civil service a few years ago and now works part-time for a contractor, but if Congress/Obama can't get a budget passed and Dad goes home for a while due to a shutdown, he might not go back. There aren't many others left around from that era.
Even if you had the knowledge and the people, you wouldn't build another Saturn V anyway. You couldn't rebuild the same computers, so you'd update the computers and programs, at which point you might as well upgrade the engines, which leads to changes in the structure (since you have to build new dies and jigs anyway), etc. The test a few weeks ago at Marshall showed that the consensus for structural strength (that even SpaceX and such have used) was off by about a factor of 2 (the rocket structure was about twice as strong, and thus as heavy, as it needed to be).
Even the second run of Saturn V vehicles (if they had been built) would have been different, with upgraded engines (the J-2X was developed during the Apollo program, and then pulled out for Ares I), similar to the changes the Space Shuttle underwent during its 30 year run.
All those other vehicles have crew/cargo on top of the vehicle, not down beside the stages. When the crew/cargo area is beside the stages, a failure in the stages is almost certainly to be fatal or destroy the cargo. If the crew/cargo area is on top, you have an escape rocket and can recover the crew or cargo safely.
There wouldn't have been an explosion in a stacked system. The explosion was a direct result of the first stage booster being attached to the second (or 1.5) stage tank. The booster did not explode; the burn-through eventually destroyed the bottom strut between the booster and the tank. The booster pivoted and the nose punctured the tank, at which point the tank lost structural integrity and the fuel and oxidizer mixed and exploded. The orbiter was not "blown up" (nothing inside it exploded), it was torn apart by aerodynamic forces.
If this had been a stacked system (think something like the Ares I design), the burn-through would have eventually caused enough of a off-axis thrust that the guidance system wouldn't have been able to compensate, and you'd fire the escape tower and separate the capsule. Even if somehow the burn-though managed to burn all the way around (unlikely), you wouldn't have an explosion; you might could have a segment of the booster separate, but that would only increase the solid fuel surface area a little. You'd lose control, but again, separate the capsule and the crew should survive.
The current vehicles are already essentially a Mark II (or III or IV...). There is actually not much more than the airframe/skin left from the originals. They've upgraded the engines, replaced the computers and flight instruments, etc. Each vehicle underwent an extended downtime in Palmdale to be refurbished/rebuilt.
Also, the problems that lead to loss of life are inherent in the design, so the only way to "fix" them is to build something else. In retrospect, a staged vehicle with stages and tanks side-by-side is a bad idea. Both Challenger (first stage SRB punctured the tank) and Columbia (tank debris damaged the vehicle) would not have happened in a stacked setup (like basically every other orbital launch system has used). Obviously, there were a number of contributing factors, both in design and management, but the basic fact is that a stacked vehicle (with the crew at the top) would not have had these failures. Columbia wouldn't have happened at all, and Challenger at worst would have been a survivable event.
The problem is that flying the shuttles costs a lot of money, and developing a replacement costs a lot of money. NASA is never going to get enough budget to keep flying and developing a replacement at the same time. The only real option is to stop flying so NASA can concentrate on development.
The only "downstream" of RHEL that is significantly affected is Oracle, a company that rebuilds RHEL, sells it as their own "Unbreakable Linux", and then tells database customers that they really shouldn't run RHEL, they should run Unbreakable instead. A bunch of those customers run Oracle DB on RHEL from when Oracle was a Red Hat partner (before they started trying to poach the big DB customers). Oracle does much less for Linux (and Open Source in general) than Red Hat. Oracle throws a little bit of code over the wall when they have to, while Red Hat has bought other companies closed-source software and Open Sourced it.
I haven't looked yet (because I rarely need to see individual patches; I mostly just care about the end result), but Red Hat has said that customers will have access to the patch information, so cutting Red Hat out because they restrict that would be dumb (since as a customer you'd get it anyway). A lot of work in making the Linux kernel "enterprise-ready" has been (and continues to be) done by Red Hat.
Basically, Red Hat forks the kernel for each major RHEL release and then maintains it on their own. They backport patches from upstream as well as develop patches for their kernel (which they submit upstream). Do you think LibreOffice should be required to distribute every individual patch they've made to OpenOffice, or X.org vs. XFree86?
The CPU overhead of SSL is largely moot at this point; except for servers handling millions of requests per hour, any server from the last 5 years or so is powerful enough that SSL overhead is lost in the noise. I manage a server that gets over two million requests per day (mostly during business hours), all of them SSL (but almost all for static content), and the server is 97% idle during the busiest periods. There are two major reasons people don't use SSL.
First, SSL requires each site to have a unique IP address; shared hosting with multiple sites per IP doesn't work. There is an extension in TLS (version 1.2 IIRC) that allows for multiple sites per IP, but browser support is spotty. IPv6 will fix this (since it'll be just as easy to put sites on different addresses and the same), but not for many years (after IPv6 surpasses IPv4 in market penetration).
Second, SSL requires more maintenance and costs more. The site (or server) admin has to manage the SSL certificate and get it signed periodically (every year or two in most cases) by a recognized certifying authority (CA). Somebody has to remember to do it (or users get warnings) and it costs money (the cheapest widely-recognized CA I'm aware of is $50/year).
People here like to rail against the CA "cartel", but SSL without CAs is mostly pointless. If non-SSL is like a postcard, SSL without CAs is like putting your username/password in an envelope and then flagging down the first person you see and asking them to deliver it for you. Without CAs, you don't know who is on the other end of the encryption path; you could be the subject of a man-in-the-middle attack, a spoofed domain, etc. Some of this can be mitigated by just accepting a cert the first time you visit a site (and verifying it is the same on future visits), but that doesn't protect you against MitM on the first visit or when the cert expires and is replaced.
People keep saying this like it is a practical alternative. Everybody just waves a magic wand and <poof> our energy use drops. Basically, that's an idea that is already OBE and isn't going to happen on any large scale in the next few decades. For example, Atlanta is a big example of urban sprawl, with close to six million people in the metro area. How many trillions of dollars would have to be spent to somehow redesign/rebuild/relocate the city and its populace?
I guess I can agree to disagree, but I wanted to respond to one point:
there are only two moving parts in a hard drive: the platter and the heads, and over the years those movements and the related stresses have gone down considerably over their ancient siblings
I don't think that is really true. Years ago, a high-end SCSI drive ran at 7200 RPM, while now enterprise drives usually are 15K RPM. Also, the bits have gotten much smaller, which requires a much higher degree of precision. The access times are much lower (my first hard drive was "fast" as 28ms average access time, while now consumer drives have seek times less than a third of that). While the heads have less distance to travel, they also move (and stop) faster, which adds stress to the mechanism. 10-15 years ago, moving a drive at all while it was spinning was almost certain death, while now people carry around notebooks while they're running all the time.
Anyway, maybe I'm lucky, or maybe because I pay attention to cooling more than most, but I haven't had a personal hard drive fail in many many years. I've had a few drives fail at work (out of hundreds), but not any in recent years (I can't remember any of our SAS/SATA drives failing, just old SCSI and IDE), and I run servers until they just can't be used anymore due to performance (I have one server from 1999 that is being turned off tomorrow).
Just about every major drive vendor has had a similar problem at one point or another. Western Digital's original 3 platter 1.6G drives failed in droves, eventually leading them to replace all of them with a 2 platter version for free. More recently, Seagate had a bad problem with their Barracuda 7200.11 model line; are you also going to avoid Seagate?
It happens to almost everybody at some point. Do you not buy Intel products because of the Pentium FDIV or F00F bugs? DeWalt power tools used to be great, then for a while they were basically rebadges of the cheap Black and Decker stuff, and then they got better. Lots of companies seem to build a name-brand reputation, get complacent and drag their own name through the mud. The good ones pull themselves out of it and rebuild the name; it is largely about how they respond to a major screw-up than the screw-up itself.
Hey, calculating X modelines by hand was fun! I managed to get an EGA/VGA monitor that was rated for a max of 800x560 to run 1024x768 within the frequency specs. It was a horribly low interlaced frame rate (couldn't have any light in the room or it gave you an instant headache) and the bandwidth was too low (so all the pixels were fuzzy), but it worked!
Yeah, I remember hearing about linuxconf, looking at it, and running away screaming. What a pile of crap (the source of mangled sendmail configs that got Linux a bad name in any sendmail newsgroup or mailing list).
My first Linux boot was when H.J. Lu managed to fit a kernel and the root filesystem on a single 1.44 MB floppy for the first time. I remember TAMU, installing SLS (yeah, not so "soft" of a landing!), and then when Slackware was just a rip-off of SLS.
Yeah, but if you accept the Axiom of Choice, you can decompose the hot girl and recompose the non-discrete pieces into two hot girls, each equal to the original!
Your ISP can't interfere with SSL connections without causing browser errors (because the cert won't match). They might have been able to back in the days when many users used a CD from their ISP to set up their computer; the ISP could slip an extra CA cert into the browser config. A government may be able to strong-arm a recognized certificate authority to sign a fake cert, which would allow them to pretend to be www.facebook.com (and they could distribute that cert to participating ISPs).
I needed to switch to USB keyboards, and I didn't want to deal with USB-to-PS/2 adapters (I've had trouble with adapters and KVM), so I got a couple of Unicomp Customizer 104 buckling-spring USB keyboards. Except for the color, USB, and the added Windows keys, they look and feel just like my old IBM model M keyboards. I don't understand the "hate" for the Windows keys; I map them under Linux to useful things: Windows to Meta (for an extra modifier for keyboard shortcuts) and Menu to Compose (so I can type things like ü and , at least when I can remember the compose sequences).
Without Ring TFA (in the finest/. tradition), if it is susceptible to a replay attack, an idiot designed it. With proper public-key encryption, you do a challenge-response handshake with a timestamp and a random number; voila, no replay attacks. Associating a key fob with a car means learning each other's public key, and you're done.
If you have the money (or want the debt), go to a "name" school for the highest degree you plan to pursue. If you set out to get a Masters degree, then you can get your Bachelors at a less recognized school (such as a decent quality state school). You just don't want to get the lower degree(s) from a low-quality school (e.g. no accreditation, bad reputation, degree mill, etc.), because that could impact your ability to get into the higher-level program. For the most part, once you have the higher-level degree, nobody cares where you started, so don't waste money and effort (e.g. busting your ass for good grades at a high-difficulty school, when an easier program somewhere else would get you to the next level) at the beginning.
If you aren't sure about the higher-level degree, or you don't always have good follow-through, go ahead and go to a bigger "name" school to start with.
The computers that flew were digital, but the computers that tested them were analog. My father worked on the Saturn V guidance system, and they built one of the earliest "hardware in the loop" simulation setups to test the software and flight-certify the computers that flew. Digital computers of the day were not fast enough to simulate the inputs and monitor the outputs in real time, so the simulation was built with analog computers.
I map the Windows logo key to Meta, and the other Windows key (context menu?) to Compose. I get an extra modifier for keyboard shortcuts, and I can easily type those funny characters like and ü.
We buy links from different upstream providers. Multiple links to the same provider only provides redundancy against link failure, not provider network problems, peering spats, etc. Also, buying two links from point A to point B from the same provider probably means they are muxed together, which means you don't have much redundancy at all. We use different local and long-haul carriers where possible, but that pushes up costs some more (you can't just find the cheapest provider and use them).
Slashdot Mirror
Yep. My father worked on every Saturn (guidance and control, especially the LVDC on the IU) except SA-1 (and then Shuttle, X-33, and now Ares). He retired from civil service a few years ago and now works part-time for a contractor, but if Congress/Obama can't get a budget passed and Dad goes home for a while due to a shutdown, he might not go back. There aren't many others left around from that era.
Even if you had the knowledge and the people, you wouldn't build another Saturn V anyway. You couldn't rebuild the same computers, so you'd update the computers and programs, at which point you might as well upgrade the engines, which leads to changes in the structure (since you have to build new dies and jigs anyway), etc. The test a few weeks ago at Marshall showed that the consensus for structural strength (that even SpaceX and such have used) was off by about a factor of 2 (the rocket structure was about twice as strong, and thus as heavy, as it needed to be).
Even the second run of Saturn V vehicles (if they had been built) would have been different, with upgraded engines (the J-2X was developed during the Apollo program, and then pulled out for Ares I), similar to the changes the Space Shuttle underwent during its 30 year run.
All those other vehicles have crew/cargo on top of the vehicle, not down beside the stages. When the crew/cargo area is beside the stages, a failure in the stages is almost certainly to be fatal or destroy the cargo. If the crew/cargo area is on top, you have an escape rocket and can recover the crew or cargo safely.
There wouldn't have been an explosion in a stacked system. The explosion was a direct result of the first stage booster being attached to the second (or 1.5) stage tank. The booster did not explode; the burn-through eventually destroyed the bottom strut between the booster and the tank. The booster pivoted and the nose punctured the tank, at which point the tank lost structural integrity and the fuel and oxidizer mixed and exploded. The orbiter was not "blown up" (nothing inside it exploded), it was torn apart by aerodynamic forces.
If this had been a stacked system (think something like the Ares I design), the burn-through would have eventually caused enough of a off-axis thrust that the guidance system wouldn't have been able to compensate, and you'd fire the escape tower and separate the capsule. Even if somehow the burn-though managed to burn all the way around (unlikely), you wouldn't have an explosion; you might could have a segment of the booster separate, but that would only increase the solid fuel surface area a little. You'd lose control, but again, separate the capsule and the crew should survive.
The current vehicles are already essentially a Mark II (or III or IV ...). There is actually not much more than the airframe/skin left from the originals. They've upgraded the engines, replaced the computers and flight instruments, etc. Each vehicle underwent an extended downtime in Palmdale to be refurbished/rebuilt.
Also, the problems that lead to loss of life are inherent in the design, so the only way to "fix" them is to build something else. In retrospect, a staged vehicle with stages and tanks side-by-side is a bad idea. Both Challenger (first stage SRB punctured the tank) and Columbia (tank debris damaged the vehicle) would not have happened in a stacked setup (like basically every other orbital launch system has used). Obviously, there were a number of contributing factors, both in design and management, but the basic fact is that a stacked vehicle (with the crew at the top) would not have had these failures. Columbia wouldn't have happened at all, and Challenger at worst would have been a survivable event.
The problem is that flying the shuttles costs a lot of money, and developing a replacement costs a lot of money. NASA is never going to get enough budget to keep flying and developing a replacement at the same time. The only real option is to stop flying so NASA can concentrate on development.
The only "downstream" of RHEL that is significantly affected is Oracle, a company that rebuilds RHEL, sells it as their own "Unbreakable Linux", and then tells database customers that they really shouldn't run RHEL, they should run Unbreakable instead. A bunch of those customers run Oracle DB on RHEL from when Oracle was a Red Hat partner (before they started trying to poach the big DB customers). Oracle does much less for Linux (and Open Source in general) than Red Hat. Oracle throws a little bit of code over the wall when they have to, while Red Hat has bought other companies closed-source software and Open Sourced it.
I haven't looked yet (because I rarely need to see individual patches; I mostly just care about the end result), but Red Hat has said that customers will have access to the patch information, so cutting Red Hat out because they restrict that would be dumb (since as a customer you'd get it anyway). A lot of work in making the Linux kernel "enterprise-ready" has been (and continues to be) done by Red Hat.
Basically, Red Hat forks the kernel for each major RHEL release and then maintains it on their own. They backport patches from upstream as well as develop patches for their kernel (which they submit upstream). Do you think LibreOffice should be required to distribute every individual patch they've made to OpenOffice, or X.org vs. XFree86?
The CPU overhead of SSL is largely moot at this point; except for servers handling millions of requests per hour, any server from the last 5 years or so is powerful enough that SSL overhead is lost in the noise. I manage a server that gets over two million requests per day (mostly during business hours), all of them SSL (but almost all for static content), and the server is 97% idle during the busiest periods. There are two major reasons people don't use SSL.
First, SSL requires each site to have a unique IP address; shared hosting with multiple sites per IP doesn't work. There is an extension in TLS (version 1.2 IIRC) that allows for multiple sites per IP, but browser support is spotty. IPv6 will fix this (since it'll be just as easy to put sites on different addresses and the same), but not for many years (after IPv6 surpasses IPv4 in market penetration).
Second, SSL requires more maintenance and costs more. The site (or server) admin has to manage the SSL certificate and get it signed periodically (every year or two in most cases) by a recognized certifying authority (CA). Somebody has to remember to do it (or users get warnings) and it costs money (the cheapest widely-recognized CA I'm aware of is $50/year).
People here like to rail against the CA "cartel", but SSL without CAs is mostly pointless. If non-SSL is like a postcard, SSL without CAs is like putting your username/password in an envelope and then flagging down the first person you see and asking them to deliver it for you. Without CAs, you don't know who is on the other end of the encryption path; you could be the subject of a man-in-the-middle attack, a spoofed domain, etc. Some of this can be mitigated by just accepting a cert the first time you visit a site (and verifying it is the same on future visits), but that doesn't protect you against MitM on the first visit or when the cert expires and is replaced.
Like live next to work, use bicycles, etc.
People keep saying this like it is a practical alternative. Everybody just waves a magic wand and <poof> our energy use drops. Basically, that's an idea that is already OBE and isn't going to happen on any large scale in the next few decades. For example, Atlanta is a big example of urban sprawl, with close to six million people in the metro area. How many trillions of dollars would have to be spent to somehow redesign/rebuild/relocate the city and its populace?
I guess I can agree to disagree, but I wanted to respond to one point:
there are only two moving parts in a hard drive: the platter and the heads, and over the years those movements and the related stresses have gone down considerably over their ancient siblings
I don't think that is really true. Years ago, a high-end SCSI drive ran at 7200 RPM, while now enterprise drives usually are 15K RPM. Also, the bits have gotten much smaller, which requires a much higher degree of precision. The access times are much lower (my first hard drive was "fast" as 28ms average access time, while now consumer drives have seek times less than a third of that). While the heads have less distance to travel, they also move (and stop) faster, which adds stress to the mechanism. 10-15 years ago, moving a drive at all while it was spinning was almost certain death, while now people carry around notebooks while they're running all the time.
Anyway, maybe I'm lucky, or maybe because I pay attention to cooling more than most, but I haven't had a personal hard drive fail in many many years. I've had a few drives fail at work (out of hundreds), but not any in recent years (I can't remember any of our SAS/SATA drives failing, just old SCSI and IDE), and I run servers until they just can't be used anymore due to performance (I have one server from 1999 that is being turned off tomorrow).
Just about every major drive vendor has had a similar problem at one point or another. Western Digital's original 3 platter 1.6G drives failed in droves, eventually leading them to replace all of them with a 2 platter version for free. More recently, Seagate had a bad problem with their Barracuda 7200.11 model line; are you also going to avoid Seagate?
It happens to almost everybody at some point. Do you not buy Intel products because of the Pentium FDIV or F00F bugs? DeWalt power tools used to be great, then for a while they were basically rebadges of the cheap Black and Decker stuff, and then they got better. Lots of companies seem to build a name-brand reputation, get complacent and drag their own name through the mud. The good ones pull themselves out of it and rebuild the name; it is largely about how they respond to a major screw-up than the screw-up itself.
Hey, calculating X modelines by hand was fun! I managed to get an EGA/VGA monitor that was rated for a max of 800x560 to run 1024x768 within the frequency specs. It was a horribly low interlaced frame rate (couldn't have any light in the room or it gave you an instant headache) and the bandwidth was too low (so all the pixels were fuzzy), but it worked!
Yeah, I remember hearing about linuxconf, looking at it, and running away screaming. What a pile of crap (the source of mangled sendmail configs that got Linux a bad name in any sendmail newsgroup or mailing list).
My first Linux boot was when H.J. Lu managed to fit a kernel and the root filesystem on a single 1.44 MB floppy for the first time. I remember TAMU, installing SLS (yeah, not so "soft" of a landing!), and then when Slackware was just a rip-off of SLS.
Yeah, but if you accept the Axiom of Choice, you can decompose the hot girl and recompose the non-discrete pieces into two hot girls, each equal to the original!
But will that make all the vocals sound like Gilbert Gottfried?
Right after the first hot-foot on the bus.
You are free to quit your job for any reason (or for no reason), so why shouldn't the company have an equal right to terminate your employment?
Thanks. I tried to come up with an imaginary response, but I found that too complex.
Its worse than that! There are an uncountably infinite number of values between 0 and 1!
Only if you are irrational.
Your ISP can't interfere with SSL connections without causing browser errors (because the cert won't match). They might have been able to back in the days when many users used a CD from their ISP to set up their computer; the ISP could slip an extra CA cert into the browser config. A government may be able to strong-arm a recognized certificate authority to sign a fake cert, which would allow them to pretend to be www.facebook.com (and they could distribute that cert to participating ISPs).
I needed to switch to USB keyboards, and I didn't want to deal with USB-to-PS/2 adapters (I've had trouble with adapters and KVM), so I got a couple of Unicomp Customizer 104 buckling-spring USB keyboards. Except for the color, USB, and the added Windows keys, they look and feel just like my old IBM model M keyboards. I don't understand the "hate" for the Windows keys; I map them under Linux to useful things: Windows to Meta (for an extra modifier for keyboard shortcuts) and Menu to Compose (so I can type things like ü and , at least when I can remember the compose sequences).
Without Ring TFA (in the finest /. tradition), if it is susceptible to a replay attack, an idiot designed it. With proper public-key encryption, you do a challenge-response handshake with a timestamp and a random number; voila, no replay attacks. Associating a key fob with a car means learning each other's public key, and you're done.
If you have the money (or want the debt), go to a "name" school for the highest degree you plan to pursue. If you set out to get a Masters degree, then you can get your Bachelors at a less recognized school (such as a decent quality state school). You just don't want to get the lower degree(s) from a low-quality school (e.g. no accreditation, bad reputation, degree mill, etc.), because that could impact your ability to get into the higher-level program. For the most part, once you have the higher-level degree, nobody cares where you started, so don't waste money and effort (e.g. busting your ass for good grades at a high-difficulty school, when an easier program somewhere else would get you to the next level) at the beginning.
If you aren't sure about the higher-level degree, or you don't always have good follow-through, go ahead and go to a bigger "name" school to start with.
The computers that flew were digital, but the computers that tested them were analog. My father worked on the Saturn V guidance system, and they built one of the earliest "hardware in the loop" simulation setups to test the software and flight-certify the computers that flew. Digital computers of the day were not fast enough to simulate the inputs and monitor the outputs in real time, so the simulation was built with analog computers.
I map the Windows logo key to Meta, and the other Windows key (context menu?) to Compose. I get an extra modifier for keyboard shortcuts, and I can easily type those funny characters like and ü.
We buy links from different upstream providers. Multiple links to the same provider only provides redundancy against link failure, not provider network problems, peering spats, etc. Also, buying two links from point A to point B from the same provider probably means they are muxed together, which means you don't have much redundancy at all. We use different local and long-haul carriers where possible, but that pushes up costs some more (you can't just find the cheapest provider and use them).