You're absolutely right. He should have returned the game and then sued them for false advertising and violation of the implied warranty of merchantability instead of downloading it. That way, not only would they have lost the sale, but they would have lost at a minimum a few thousand dollars in legal fees in the process, pretty much regardless of how the case turns out.
Good lord man, you don't dump it all into one company! This is basic economics, you do what they've been doing with COTS, you pick a few companies that look like they know what the hell they're doing, and you start giving them extra funding based on defined technical and fundraising targets. Your goal is to lower the barrier to entry for promising companies in a previously uncompetitive field that's almost impossible to get enough startup funds for solely through private investment.
This isn't about engineering. Have you read the investigation reports from Challenger? If not, I suggest you do so. NASA management was absolutely and unequivocally incompetent.
Then go read the reports from Columbia. They haven't gotten any better. NASA shouldn't be allowed to launch a bottle rocket.
As for "waiting 20 years", you're completely missing the point. It wouldn't have _taken_ 20 years if the money had been spent on worthwhile work instead of a vehicle that should have been retired the minute Challenger disintegrated.
I can't find the precise weight of the Mercury capsule, but the spacecraft's "landing weight" is listed as 1,098kg. A more modern capsule, the current Soyuz Reentry Module (the part humans actually ride in for the trip to orbit and landing), is about 3000kg.
If you're going for bare-bones and starting over with modern knowledge and materials, you could probably rip out enough to bring a one-man module under 670kg while still keeping the occupant alive. You couldn't really carry anything but the one human, though; no real cargo or experiments.
You are in no way _wrong_, but I carefully chose to focus on incremental launch costs in order to be conservative and avoid an exceedingly nuanced discussion about development costs. One can reasonably argue that some substantive portion of the R&D put into the Shuttle program (both at startup and since) benefits SpaceX and other commercial companies, as well, since most of the information is publicly available. A lot of knowledge was gained just by having a functioning reusable launch vehicle.
Comparing just the incremental launch costs of the Shuttle since 1986 against SpaceX's total costs since 2002 provides a clear, easy-to-understand picture that no one can reasonably argue is unfair to NASA.
Try again. Wikipedia (optimistically) puts the current incremental cost of a Shuttle launch at about $60 million. There have been over 100 launches since Challenger. In other words, we have spent at least $6,000,000,000 -- six billion dollars -- on shuttle flights since NASA's incompetence was put on display for the world.
In the last eight years with just a few hundred million in funding, SpaceX has developed vehicles now capable of launching payloads to LEO at roughly 2x the price of the Shuttle, and cost to a Geosynchronous Transfer Orbit is actually the same or _LOWER_ for the Falcon 9.
Can you possibly imagine how cheap spaceflight would be if that six BILLION dollars had been poured into something other than NASA's horrifically broken bureaucracy for the last 24 years?
At that point you're already a man in the middle and can send whatever you want to the browser, why on earth would you need to exploit XSS vulnerabilities?
rtorrent and m0n0wall need to get their act together, but the thing is that NFS and MySQL are amongst the services with the least-pressing need to incorporate IPv6, as they're almost never publicly-accessible services (IPv4 is going to live on in internal networks long after it's dead on the wider 'net; remember IPX?).
MythTV may be an issue, but I'm assuming most of its communication with the outside world happens over HTTP, probably with curllib or similar libraries, so "IPv6 support" should just mean compiling against a reasonably modern version of the library supporting IPv6, and possibly UI tweaks. On the server side, all the major HTTP implementations already support IPv6.
No, most programmers in the US work for companies who CLAIM they are classified as "exempt". There are specific legal requirements for such classification, and the truth is that the vast majority of programmers _do not_ meet them.
Read up on real employment law, don't just go off common knowledge -- it's almost always wrong.
You cannot skirt the law just by saying you're not doing anything illegal. What insane legal system are you living under?
If you have evidence the real reason you were fired was because you wouldn't work overtime without legally-mandated compensation, you have several agencies and then the courts to appeal to.
I encourage you to explain to people serving large quantities of content that in order to be in compliance with your personal view of network correctness, their routers must now perform NAT on all of their traffic.
I assure you, you will not get the hoped-for response from people saturating 10gbps uplinks.
If it's implemented right, you shouldn't take much of a performance hit, but the FPU would be more complex, with a _lot_ more transistors.
The only real speed hit should be transferring the larger values to/from RAM, but if we're talking about e.g. x86-64 growing 754r support, then QPI and HyperTransport are so bloody fast I doubt you'd notice much for most applications using floating point.
Well, naïvely, a dome supported by air pressure as is proposed here might be hard to keep inflated with several feet of snow on it, but a careful design will help get the snow off even without significant melting from heat exchange.
There's a reason roofs are steep in northern latitudes. If the dome's surface is sufficiently smooth and steep, the snow will fall or be easily pushed to the sides (and if they're smart, the bottom edge will be somewhat reinforced), where it can be safely plowed away, or collected for use as water in the dome.
Seek help. Many cities have free mental health clinics. Failing that, simply proceed to the nearest emergency room and inform them you have been transported into a bad Hollywood movie. They'll know what to do.
...before some vocal peanut-gallery subset of Debian developers decide this is a horrible, undemocratic idea and must be put to a vote of everyone who has ever contributed a toenail to the distribution?
Comcast's IPv6 strategy has absolutely nothing to do with NAT. A simple google search would reveal the mass ignorance being displayed in this thread.
Their initial deployment is for device management. Every device (set-top box, cable modem, etc.) on a DOCSIS network needs an IP address (most actually need two or more). Switching them to IPv6 has become an immediate necessity, as there simply are not enough IPv4 addresses left to deal with it.
Once the switch happens, they'll have freed up several million IPv4 addresses for use on end-user PCs, which will make the need for IPv6 on customer PCs less of a crisis for Comcast, but it's not going to put it off forever.
The reality is that most of Comcast's network is already capable of deploying IPv6 to everything, including end-user internet connections (and the parts that aren't are being actively upgraded). They've been preparing for this for years. Turning it on for end-user connections is primarily a business and customer service problem, not a technical one.
Hardware fails, and commodity hardware fails more. Using it on a large scale for systems with a high-availability requirement needs engineering/operations skills and resources that many companies simply do not have, and even at the companies that theoretically have the resources, they often fail.
Designing and building applications to withstand server failures can be extremely difficult, especially if you have to scale, and properly testing them can border on the impossible. Sometimes you're better off just getting hardware with a sufficiently low failure rate and dealing with the rare outages as they come up.
Compiling languages to other languages is nothing new. In fact, it's quite fundamental to computer science as we know it.
At the lowest level, assembly is "assembled" into the native language of the target machine, though modern assemblers handle enough syntactic sugar you could reasonably call them simplistic compilers. In either case, one language is effectively converted to another.
Further, it's quite typical for medium- and high-level languages, such as C, to be compiled down to some form of assembly. Sometimes, as in the case of GCC, they even hop through another, compiler-specific intermediate language on the way.
Know how most C++ compilers have worked? They reduce it to C, and then compile *that*.
Indeed, many language implementations have used C as an intermediary. It works pretty well for this purpose, being intended as a standardized, multi-platform assembly, and you immediately gain the invaluable ability to trivially interface with any library that has C bindings.
And that Ruby interpreter you love? The Ruby gets converted to the bytecode of whatever VM it's running on, which was most likely written in C, which was then converted to some intermediate language before going to assembly and machine code.
Ultimately, your logic only holds if you believe everyone should be working directly in machine code.
Slashdot Mirror
Any page that doesn't have complete idiots implementing it works quite well at 480x320. Sadly, most major companies hire nothing but complete idiots.
You're a bit confused. HTML 5 is a markup language, not a codec. YouTube's HTML 5 site is still in H.264, it's just not using Flash to play it.
You're absolutely right. He should have returned the game and then sued them for false advertising and violation of the implied warranty of merchantability instead of downloading it. That way, not only would they have lost the sale, but they would have lost at a minimum a few thousand dollars in legal fees in the process, pretty much regardless of how the case turns out.
Good lord man, you don't dump it all into one company! This is basic economics, you do what they've been doing with COTS, you pick a few companies that look like they know what the hell they're doing, and you start giving them extra funding based on defined technical and fundraising targets. Your goal is to lower the barrier to entry for promising companies in a previously uncompetitive field that's almost impossible to get enough startup funds for solely through private investment.
This isn't about engineering. Have you read the investigation reports from Challenger? If not, I suggest you do so. NASA management was absolutely and unequivocally incompetent.
Then go read the reports from Columbia. They haven't gotten any better. NASA shouldn't be allowed to launch a bottle rocket.
As for "waiting 20 years", you're completely missing the point. It wouldn't have _taken_ 20 years if the money had been spent on worthwhile work instead of a vehicle that should have been retired the minute Challenger disintegrated.
I can't find the precise weight of the Mercury capsule, but the spacecraft's "landing weight" is listed as 1,098kg. A more modern capsule, the current Soyuz Reentry Module (the part humans actually ride in for the trip to orbit and landing), is about 3000kg.
If you're going for bare-bones and starting over with modern knowledge and materials, you could probably rip out enough to bring a one-man module under 670kg while still keeping the occupant alive. You couldn't really carry anything but the one human, though; no real cargo or experiments.
You are in no way _wrong_, but I carefully chose to focus on incremental launch costs in order to be conservative and avoid an exceedingly nuanced discussion about development costs. One can reasonably argue that some substantive portion of the R&D put into the Shuttle program (both at startup and since) benefits SpaceX and other commercial companies, as well, since most of the information is publicly available. A lot of knowledge was gained just by having a functioning reusable launch vehicle.
Comparing just the incremental launch costs of the Shuttle since 1986 against SpaceX's total costs since 2002 provides a clear, easy-to-understand picture that no one can reasonably argue is unfair to NASA.
Try again. Wikipedia (optimistically) puts the current incremental cost of a Shuttle launch at about $60 million. There have been over 100 launches since Challenger. In other words, we have spent at least $6,000,000,000 -- six billion dollars -- on shuttle flights since NASA's incompetence was put on display for the world.
In the last eight years with just a few hundred million in funding, SpaceX has developed vehicles now capable of launching payloads to LEO at roughly 2x the price of the Shuttle, and cost to a Geosynchronous Transfer Orbit is actually the same or _LOWER_ for the Falcon 9.
Can you possibly imagine how cheap spaceflight would be if that six BILLION dollars had been poured into something other than NASA's horrifically broken bureaucracy for the last 24 years?
At that point you're already a man in the middle and can send whatever you want to the browser, why on earth would you need to exploit XSS vulnerabilities?
rtorrent and m0n0wall need to get their act together, but the thing is that NFS and MySQL are amongst the services with the least-pressing need to incorporate IPv6, as they're almost never publicly-accessible services (IPv4 is going to live on in internal networks long after it's dead on the wider 'net; remember IPX?).
MythTV may be an issue, but I'm assuming most of its communication with the outside world happens over HTTP, probably with curllib or similar libraries, so "IPv6 support" should just mean compiling against a reasonably modern version of the library supporting IPv6, and possibly UI tweaks. On the server side, all the major HTTP implementations already support IPv6.
No, most programmers in the US work for companies who CLAIM they are classified as "exempt". There are specific legal requirements for such classification, and the truth is that the vast majority of programmers _do not_ meet them.
Read up on real employment law, don't just go off common knowledge -- it's almost always wrong.
You cannot skirt the law just by saying you're not doing anything illegal. What insane legal system are you living under?
If you have evidence the real reason you were fired was because you wouldn't work overtime without legally-mandated compensation, you have several agencies and then the courts to appeal to.
Firing someone for exercising their workplace rights -- safety, overtime pay, etc. -- _IS_ explicitly illegal.
I encourage you to explain to people serving large quantities of content that in order to be in compliance with your personal view of network correctness, their routers must now perform NAT on all of their traffic.
I assure you, you will not get the hoped-for response from people saturating 10gbps uplinks.
If it's implemented right, you shouldn't take much of a performance hit, but the FPU would be more complex, with a _lot_ more transistors.
The only real speed hit should be transferring the larger values to/from RAM, but if we're talking about e.g. x86-64 growing 754r support, then QPI and HyperTransport are so bloody fast I doubt you'd notice much for most applications using floating point.
Well, naïvely, a dome supported by air pressure as is proposed here might be hard to keep inflated with several feet of snow on it, but a careful design will help get the snow off even without significant melting from heat exchange.
There's a reason roofs are steep in northern latitudes. If the dome's surface is sufficiently smooth and steep, the snow will fall or be easily pushed to the sides (and if they're smart, the bottom edge will be somewhat reinforced), where it can be safely plowed away, or collected for use as water in the dome.
Seek help. Many cities have free mental health clinics. Failing that, simply proceed to the nearest emergency room and inform them you have been transported into a bad Hollywood movie. They'll know what to do.
No, it's exactly what the whackjob is asking for. If Google doesn't index his sites, there won't be any links to them from Google. Period.
Again, how is it abusive to comply with his wishes? He wants them to stop "stealing" his content. If they comply, they're evil?
...before some vocal peanut-gallery subset of Debian developers decide this is a horrible, undemocratic idea and must be put to a vote of everyone who has ever contributed a toenail to the distribution?
Comcast's IPv6 strategy has absolutely nothing to do with NAT. A simple google search would reveal the mass ignorance being displayed in this thread.
Their initial deployment is for device management. Every device (set-top box, cable modem, etc.) on a DOCSIS network needs an IP address (most actually need two or more). Switching them to IPv6 has become an immediate necessity, as there simply are not enough IPv4 addresses left to deal with it.
Once the switch happens, they'll have freed up several million IPv4 addresses for use on end-user PCs, which will make the need for IPv6 on customer PCs less of a crisis for Comcast, but it's not going to put it off forever.
The reality is that most of Comcast's network is already capable of deploying IPv6 to everything, including end-user internet connections (and the parts that aren't are being actively upgraded). They've been preparing for this for years. Turning it on for end-user connections is primarily a business and customer service problem, not a technical one.
"Carrier-grade NAT" is not a solution, it's an oxymoron, and one that has already been rejected by the real world.
I'm sure Comcast will find it very interesting to know that their impending deployment of IPv6 to millions of devices will have all been a bad dream.
If you don't know what's actually going on behind the scenes with IPv6, I suggest you stop talking. You just make yourself look silly.
Hardware fails, and commodity hardware fails more. Using it on a large scale for systems with a high-availability requirement needs engineering/operations skills and resources that many companies simply do not have, and even at the companies that theoretically have the resources, they often fail.
Designing and building applications to withstand server failures can be extremely difficult, especially if you have to scale, and properly testing them can border on the impossible. Sometimes you're better off just getting hardware with a sufficiently low failure rate and dealing with the rare outages as they come up.
Compiling languages to other languages is nothing new. In fact, it's quite fundamental to computer science as we know it.
At the lowest level, assembly is "assembled" into the native language of the target machine, though modern assemblers handle enough syntactic sugar you could reasonably call them simplistic compilers. In either case, one language is effectively converted to another.
Further, it's quite typical for medium- and high-level languages, such as C, to be compiled down to some form of assembly. Sometimes, as in the case of GCC, they even hop through another, compiler-specific intermediate language on the way.
Know how most C++ compilers have worked? They reduce it to C, and then compile *that*.
Indeed, many language implementations have used C as an intermediary. It works pretty well for this purpose, being intended as a standardized, multi-platform assembly, and you immediately gain the invaluable ability to trivially interface with any library that has C bindings.
And that Ruby interpreter you love? The Ruby gets converted to the bytecode of whatever VM it's running on, which was most likely written in C, which was then converted to some intermediate language before going to assembly and machine code.
Ultimately, your logic only holds if you believe everyone should be working directly in machine code.