I think your math teacher never realized that there is structure to numbers, and most math problems in general. When solving a problem, it's silly to ignore all the knowledge you may have that lets you infer certain things without grudgingly following some procedure that's useful for a computer perhaps. If your, perhaps informal, knowledge of number theory and basic algebra, lets you select results without doing any computation -- fine. Computation is just a rather long proof of a theorem, so if you can prove that theorem quicker/simpler, more power to you. It's this lack of understanding that computation is, in fact, proving a theorem (about the answer), using a very limited set of rules (the "rote" way), or some more advanced ones (you're skipping steps, as a dumb teacher would say), is irrelevant. As long as your reasoning is correct, you're fine.
No, that's how you are supposed to do the math if you understand it. Teachers who demand rote following of the rules are idiots and I will say that without any reservations, to their face, and I will never ever apologize for there's no need to when stating facts. Feynman was completely right about that.
I would have worked the same way had there been various answers in the right ballpark. Since the only thing sensible was 141, the other answers were way too big, I clicked on 141 immediately after realizing it was 47*3. I guess as an engineer I try to size up orders of magnitude almost as a second nature, so the answers in the thousands were instinctively "off".
It's not a matter of feeling warm and fuzzy. It's a matter of working in the field.
The consumer is a human being. If it weren't for who sees the image, there wouldn't be a need for all this stuff. So, given limitations of the human consumer's visual system, you're basically striving for an equivalent of 24 bit audio for a phone conversation. On a cellphone. In a car with broken muffler. Sure, it's cool engineering, but given biological limitations -- entirely pointless.
Do note that I'm talking about (dissing) ONLY color matching for broadcast, and only absolute color matching (color profiles, etc). It's obvious that you have to do relative color matching in compositing and editing, otherwise things will look amateurish because composited/edited pieces won't match.
Printing is an entirely different thing, because the print output is badly nonlinear in a very visible way. In video -- it doesn't matter if the end-product green is quite green. In printing -- it does, because unless it's a saturated color it may well turn out like crap just because it wasn't quite green. If you want green on paper perhaps you want to use a process color and you don't really want a grid of any other color to overlay it, even if it's a minuscule bleed it looks awful. With video, the display/projection is way more linear and you don't have that problem at all. Nobody cringes because you meant pure blue, and the red and green elements are also ON at 1/256th. In printing if you mean C but there's a bit of M,Y,K dots, even tiny ones, it'd be bad, in video -- nope.
There is some difference between resolution and color matching. It's easy for most of us to notice compression artifacts and know that the source is SD. And of course upconverting DVD players can't fix what's missing in the data in the first place. So I agree there.
But when it comes to color -- the basic premise is broken. Our visual system has a built-in auto white balancer. Of course you can feel warm and fuzzy that the various light-emitting elements on the display panel are pushing out just the right ratios, but so what. There's professionalism, and then there's overdoing it. I hate bugs in software, but I'm pretty sure that the "white" on my display is not really white, and I honestly can't tell which way it's off. And without something to compare it with, no one else would be able to tell either. If I get a white piece of paper, I'll be comparing my display to whatever happens to be illuminating my desk at the moment... With broken software, everyone can tell it's broken. With color gamut mapped a bit off, no one can tell it's broken.
A fridge has remained almost unchanged for many decades. The basic system is exactly the same. The efficiency of the compressor has seen pretty much no improvement in the last 20 years or so, because it's a rather simple electromechanical part, and the efficiency is determined by the thermodynamic cycle itself. That's my experience at least. The only way to make a fridge less efficient is to put insufficient insulation on it. Any decent, high-end fridge has so much insulation that it makes no sense to put any more -- diminishing returns and all that.
What's the point of all that "broadcast quality proofing", if people view it on crappy displays anyway. No one cares about it, because there's no way of noticing unless you happen to have a color/luminance reference right next to your TV. I find color calibration for broadcast work to be an overkill.
European-style washers and dryers have not made huge advances in energy efficiency in the last decade. Heck, dryers probably didn't for at least two decades. My parents had a BOSCH condensing dryer for 20 years, and there's no way really to make it any more efficient. A decent washing machine (front-loader) from 10 years ago will use a motor with electronic commutation, and those are as good as it gets. Same goes for a toaster: the ones from today aren't any more efficient than ones from 30 years ago. Coffeemaker, too. I doubt an electric range these days is much better than one from 40 years ago. So, there's a whole class of appliances where there's no improvement to efficiency due to limits of the underlying technology. IT tech is in an entirely different class!
Well, since the IT folks must have extra capacity (in terms of storage, network, processing, etc) saved for times when there's server or disk downtime, it's fairly obvious that service must be cut/rationed until such extra capacity is restored. If the bigwigs will be getting their email delivered timely only 8 hours per day, the money will come. I think that the problem is that the IT does not apply a cut-off point. They stretch until stuff break. The correct way of doing it is: you don't stretch anything, you run your systems with extra capacity assigned to planned-for failure modes. An extra employee comes and his/her mailbox would go over your quota? You say you need a hard drive or two, etc. Yes, just for that one user. No, there's no resources left elsewhere.
Um, because the "internal directory" can't be implement using LDAP?! What's wrong with LDAP anyway? Even OpenLDAP seems to scale decently and I'd hardly consider it a "bother".
I've had this problem at a big ten school. They have a mailing list where the disclaimer at the bottom of every email is that if you unsubscribe (even though they won't let you anyway), you may miss some important stuff (I'm paraphrasing). I've archived all of those email from almost a decade, and one afternoon went through them all. All of six messages out of almost 3000 were relevant to me, and most of them would be irrelevant to 90%+ of students they were reaching. Yet there was no way of unsubscribing: I tried. They'd sternly rebuke my request, saying that "I might miss on critical messages". Fuck them, idiots, that's about all that I get to say.
You can't undo programming a bunch of bytes in an EEPROM? I doubt that the phones used OTP memory for that. It'd probably take a minute with download cable and factory service software to undo the anti-theft block...
It doesn't need to be a pointable dish in the physical sense. You can do a flat phased array. Heck, a competent RF engineer living in a U.S. suburb could probably assemble one if he/she pooled up the backyards with a couple of neighbors.
There's nothing to crack. An interplanetary mission is pretty much the ultimate in security through obscurity. You won't have a clue what to send until you get a backseat worth of documentation. That's all that's to it.
Whoever modded the parent flamebait is an idiot. Please post to undo the moderation. It's an insightful question that needs to be seriously considered.
I don't think there's any encryption involved. I presume that all of the telemetry and command uplink coding at several levels (modulation, error correction coding, data coding, framing/packetizing, etc) could be reverse engineered fairly quickly. But the problem is that what goes over the air is still useless until you have most of the details of the spacecraft itself. You need to know the computers that run on it, what programs are stored, how to interact with them, etc. You basically need a dozen feet worth of shelf space worth of documentation and months just to familiarize yourself with how to run the damn thing. Say, if China or Russia wanted to hijack a mission in a LEO parking orbit to take some images of their favorite landmark to show their imperial prowess in commanding the capitalist hardware:)
I imagine that the most one could pull off would be a denial-of-service attack: point a pretty damn large antenna at the craft and keep the receiver busy listening to junk. Even that would require some engineering and radio-related mission planning expertise.
To protect yourself from reprogramming the craft to carry out some substitute nefarious mission you literally just need to physically protect access to documentation and the software tools needed to prepare the data loads. It's security by obscurity that works very well here because the hardware is pretty much inaccessible for reverse engineering. It's not like the billions of PCs all running Windows full of security holes. There are two Voyagers out there, and without access to documentation and test hardware you cannot really do anything useful with it. Same goes for any other current mission: as long as you keep a bunch of physical artifacts secure from unauthorized access, there's nothing besides DoS that a 3rd party could pull off. I think that most space program contractors know how to provide physical security by now.
Those big dishes you need to send suffciently strong signal to the craft aren't exactly omnipresent, and I'd think it's fairly trivial not only to localize them, but to remotely figure out where they are pointed. If there was any sort of a nefarious DoS uplink present for the current Mars missions, I presume NASA, JPL and DOD working together could figure out in a couple of weeks tops exactly where the signal was coming from. Probably much quicker than that. Do note that the spacecraft itself, even when faced with junk coming in, still sends telemetry that will tell you that the receiver is getting junk. It's not a long shot to figure out that the receiver is receiving a DoS uplink, the folks who run those missions I'm sure can tell sun interference from something else.
But it can survive in all kinds of extreme temperatures, all kinds of G forces, and it works perfectly well in a vacuum. And it's so small to begin with, the extra hardware it needs to power it, recharge it, move it, etc, doesn't have to be that big to begin.
Sorry, that's engineering fantasy. No, a phone not designed for it will not survive "all kinds of extreme temperatures", "all kinds of G forces", etc. You'd have to test it -- you know, environmental chambers, shakers, etc. Without such tests any assumptions are pure fantasy. We don't know how it works in vacuum, because it hasn't really been in vacuum, only in atmosphere that's survivable to humans with supplemental oxygen. There's plenty of components that I'd expect will experience problems in vacuum simply because there's no reason at all to put ones rated for vacuum operation in a consumer device. Silly things such as plastic encapsulant outgassing can have dire consequences for quite short-term reliability (weeks). Thermal management becomes a big issue because you have to radiate all the heat out of the enclosure with no convection to help you.
I have once seen tests of a fairly unassuming low-key data acquisition device in vacuum at -100C to 100C temperature ranges, and there was a lot of redesign involved to get it to work acceptably with no air present around it. It still could be done by qualifying everyday COTS components that you can get from any distributor like DigiKey (no milspec stuff), but this requires quite good recordkeeping and procedures/software to make sure human mistakes don't slip through.
I disagree. I'm no lover of AT&T, I got screwed by them once on international calls and had to fight for a couple of months to get my money back. This was at a time when money was in really short supply, and the $500 or so that I had to get back would have made a big difference. If you actually read FCC's Analysis, and look at what AT&T disagrees with, you can't but agree with AT&T. Their rebuttal is backed by facts, and an hour of googling later you will see for yourself that they are certainly right in the issues they have enumerated. I would have personally really wanted AT&T's response to turn out to be made up shitty troll, but it turns out not to be so.
Sprint's "short and sweet" response turns out to be completely unfounded. It essentially translates to "yeah, yeah, we don't like AT&T either, kudos to FCC for sharing in our dislike". FCC did a pathetic job in their Analysis, that's all there's to it.
Calling AT&T's response "scathing" is uncalled for. We have a saying in Polish: the truth stings you in the eyes. As far as I'm concerned, the submitter takes "factual" for "scathing". It's silly. People often take a defensive stance when presented with facts that clearly contradict whatever they previously claimed, so I can at least understand the psychology in the mostly negative reaction to AT&T's rebuke to FCC. What I don't get is why people side with FCC without spending the time necessary to verify the sources. It only takes a couple of hours.
Multiplication is done largely the same on Z80 and 6502. You need additions and perhaps table lookups. The length of the product can be abstracted out in a loop if you want a generic multiprecision multiplication. If your multiplication is long enough, you will save cycles by using FFT that uses many shorter multiplies that take less time than a naive long one. The only major difference is that Z80 has 16 bit add/subtract. That's what you nebulously refer to by saying "Z80 could use 16 bit data words". Well, on a 6502, 16 bit addition is a whooping two instructions instead of one, so I don't see the problem, really.
Zilog's newer offerings are better here: eZ8 (an upgrade to Z8) offers 8x8->16 unsigned multiply, and ZNEO offers 32x32->64 multiply.
Slashdot Mirror
I think your math teacher never realized that there is structure to numbers, and most math problems in general. When solving a problem, it's silly to ignore all the knowledge you may have that lets you infer certain things without grudgingly following some procedure that's useful for a computer perhaps. If your, perhaps informal, knowledge of number theory and basic algebra, lets you select results without doing any computation -- fine. Computation is just a rather long proof of a theorem, so if you can prove that theorem quicker/simpler, more power to you. It's this lack of understanding that computation is, in fact, proving a theorem (about the answer), using a very limited set of rules (the "rote" way), or some more advanced ones (you're skipping steps, as a dumb teacher would say), is irrelevant. As long as your reasoning is correct, you're fine.
No, that's how you are supposed to do the math if you understand it. Teachers who demand rote following of the rules are idiots and I will say that without any reservations, to their face, and I will never ever apologize for there's no need to when stating facts. Feynman was completely right about that.
I would have worked the same way had there been various answers in the right ballpark. Since the only thing sensible was 141, the other answers were way too big, I clicked on 141 immediately after realizing it was 47*3. I guess as an engineer I try to size up orders of magnitude almost as a second nature, so the answers in the thousands were instinctively "off".
Mods fail at sarcasm. News at 11.
It's not a matter of feeling warm and fuzzy. It's a matter of working in the field.
The consumer is a human being. If it weren't for who sees the image, there wouldn't be a need for all this stuff. So, given limitations of the human consumer's visual system, you're basically striving for an equivalent of 24 bit audio for a phone conversation. On a cellphone. In a car with broken muffler. Sure, it's cool engineering, but given biological limitations -- entirely pointless.
Do note that I'm talking about (dissing) ONLY color matching for broadcast, and only absolute color matching (color profiles, etc). It's obvious that you have to do relative color matching in compositing and editing, otherwise things will look amateurish because composited/edited pieces won't match.
Printing is an entirely different thing, because the print output is badly nonlinear in a very visible way. In video -- it doesn't matter if the end-product green is quite green. In printing -- it does, because unless it's a saturated color it may well turn out like crap just because it wasn't quite green. If you want green on paper perhaps you want to use a process color and you don't really want a grid of any other color to overlay it, even if it's a minuscule bleed it looks awful. With video, the display/projection is way more linear and you don't have that problem at all. Nobody cringes because you meant pure blue, and the red and green elements are also ON at 1/256th. In printing if you mean C but there's a bit of M,Y,K dots, even tiny ones, it'd be bad, in video -- nope.
There is some difference between resolution and color matching. It's easy for most of us to notice compression artifacts and know that the source is SD. And of course upconverting DVD players can't fix what's missing in the data in the first place. So I agree there.
But when it comes to color -- the basic premise is broken. Our visual system has a built-in auto white balancer. Of course you can feel warm and fuzzy that the various light-emitting elements on the display panel are pushing out just the right ratios, but so what. There's professionalism, and then there's overdoing it. I hate bugs in software, but I'm pretty sure that the "white" on my display is not really white, and I honestly can't tell which way it's off. And without something to compare it with, no one else would be able to tell either. If I get a white piece of paper, I'll be comparing my display to whatever happens to be illuminating my desk at the moment... With broken software, everyone can tell it's broken. With color gamut mapped a bit off, no one can tell it's broken.
Mercedes had a long stretch in the 90s when their quality was crap.
A fridge has remained almost unchanged for many decades. The basic system is exactly the same. The efficiency of the compressor has seen pretty much no improvement in the last 20 years or so, because it's a rather simple electromechanical part, and the efficiency is determined by the thermodynamic cycle itself. That's my experience at least. The only way to make a fridge less efficient is to put insufficient insulation on it. Any decent, high-end fridge has so much insulation that it makes no sense to put any more -- diminishing returns and all that.
What's the point of all that "broadcast quality proofing", if people view it on crappy displays anyway. No one cares about it, because there's no way of noticing unless you happen to have a color/luminance reference right next to your TV. I find color calibration for broadcast work to be an overkill.
European-style washers and dryers have not made huge advances in energy efficiency in the last decade. Heck, dryers probably didn't for at least two decades. My parents had a BOSCH condensing dryer for 20 years, and there's no way really to make it any more efficient. A decent washing machine (front-loader) from 10 years ago will use a motor with electronic commutation, and those are as good as it gets. Same goes for a toaster: the ones from today aren't any more efficient than ones from 30 years ago. Coffeemaker, too. I doubt an electric range these days is much better than one from 40 years ago. So, there's a whole class of appliances where there's no improvement to efficiency due to limits of the underlying technology. IT tech is in an entirely different class!
It's a rational explanation allright, but still the status quo is idiotic :)
Well, since the IT folks must have extra capacity (in terms of storage, network, processing, etc) saved for times when there's server or disk downtime, it's fairly obvious that service must be cut/rationed until such extra capacity is restored. If the bigwigs will be getting their email delivered timely only 8 hours per day, the money will come. I think that the problem is that the IT does not apply a cut-off point. They stretch until stuff break. The correct way of doing it is: you don't stretch anything, you run your systems with extra capacity assigned to planned-for failure modes. An extra employee comes and his/her mailbox would go over your quota? You say you need a hard drive or two, etc. Yes, just for that one user. No, there's no resources left elsewhere.
Um, because the "internal directory" can't be implement using LDAP?! What's wrong with LDAP anyway? Even OpenLDAP seems to scale decently and I'd hardly consider it a "bother".
I've had this problem at a big ten school. They have a mailing list where the disclaimer at the bottom of every email is that if you unsubscribe (even though they won't let you anyway), you may miss some important stuff (I'm paraphrasing). I've archived all of those email from almost a decade, and one afternoon went through them all. All of six messages out of almost 3000 were relevant to me, and most of them would be irrelevant to 90%+ of students they were reaching. Yet there was no way of unsubscribing: I tried. They'd sternly rebuke my request, saying that "I might miss on critical messages". Fuck them, idiots, that's about all that I get to say.
You can't undo programming a bunch of bytes in an EEPROM? I doubt that the phones used OTP memory for that. It'd probably take a minute with download cable and factory service software to undo the anti-theft block...
+1 Insightful. I completely agree.
:)
It doesn't need to be a pointable dish in the physical sense. You can do a flat phased array. Heck, a competent RF engineer living in a U.S. suburb could probably assemble one if he/she pooled up the backyards with a couple of neighbors.
There's nothing to crack. An interplanetary mission is pretty much the ultimate in security through obscurity. You won't have a clue what to send until you get a backseat worth of documentation. That's all that's to it.
Whoever modded the parent flamebait is an idiot. Please post to undo the moderation. It's an insightful question that needs to be seriously considered.
I don't think there's any encryption involved. I presume that all of the telemetry and command uplink coding at several levels (modulation, error correction coding, data coding, framing/packetizing, etc) could be reverse engineered fairly quickly. But the problem is that what goes over the air is still useless until you have most of the details of the spacecraft itself. You need to know the computers that run on it, what programs are stored, how to interact with them, etc. You basically need a dozen feet worth of shelf space worth of documentation and months just to familiarize yourself with how to run the damn thing. Say, if China or Russia wanted to hijack a mission in a LEO parking orbit to take some images of their favorite landmark to show their imperial prowess in commanding the capitalist hardware :)
I imagine that the most one could pull off would be a denial-of-service attack: point a pretty damn large antenna at the craft and keep the receiver busy listening to junk. Even that would require some engineering and radio-related mission planning expertise.
To protect yourself from reprogramming the craft to carry out some substitute nefarious mission you literally just need to physically protect access to documentation and the software tools needed to prepare the data loads. It's security by obscurity that works very well here because the hardware is pretty much inaccessible for reverse engineering. It's not like the billions of PCs all running Windows full of security holes. There are two Voyagers out there, and without access to documentation and test hardware you cannot really do anything useful with it. Same goes for any other current mission: as long as you keep a bunch of physical artifacts secure from unauthorized access, there's nothing besides DoS that a 3rd party could pull off. I think that most space program contractors know how to provide physical security by now.
Those big dishes you need to send suffciently strong signal to the craft aren't exactly omnipresent, and I'd think it's fairly trivial not only to localize them, but to remotely figure out where they are pointed. If there was any sort of a nefarious DoS uplink present for the current Mars missions, I presume NASA, JPL and DOD working together could figure out in a couple of weeks tops exactly where the signal was coming from. Probably much quicker than that. Do note that the spacecraft itself, even when faced with junk coming in, still sends telemetry that will tell you that the receiver is getting junk. It's not a long shot to figure out that the receiver is receiving a DoS uplink, the folks who run those missions I'm sure can tell sun interference from something else.
But it can survive in all kinds of extreme temperatures, all kinds of G forces, and it works perfectly well in a vacuum. And it's so small to begin with, the extra hardware it needs to power it, recharge it, move it, etc, doesn't have to be that big to begin.
Sorry, that's engineering fantasy. No, a phone not designed for it will not survive "all kinds of extreme temperatures", "all kinds of G forces", etc. You'd have to test it -- you know, environmental chambers, shakers, etc. Without such tests any assumptions are pure fantasy. We don't know how it works in vacuum, because it hasn't really been in vacuum, only in atmosphere that's survivable to humans with supplemental oxygen. There's plenty of components that I'd expect will experience problems in vacuum simply because there's no reason at all to put ones rated for vacuum operation in a consumer device. Silly things such as plastic encapsulant outgassing can have dire consequences for quite short-term reliability (weeks). Thermal management becomes a big issue because you have to radiate all the heat out of the enclosure with no convection to help you.
I have once seen tests of a fairly unassuming low-key data acquisition device in vacuum at -100C to 100C temperature ranges, and there was a lot of redesign involved to get it to work acceptably with no air present around it. It still could be done by qualifying everyday COTS components that you can get from any distributor like DigiKey (no milspec stuff), but this requires quite good recordkeeping and procedures/software to make sure human mistakes don't slip through.
I disagree. I'm no lover of AT&T, I got screwed by them once on international calls and had to fight for a couple of months to get my money back. This was at a time when money was in really short supply, and the $500 or so that I had to get back would have made a big difference. If you actually read FCC's Analysis, and look at what AT&T disagrees with, you can't but agree with AT&T. Their rebuttal is backed by facts, and an hour of googling later you will see for yourself that they are certainly right in the issues they have enumerated. I would have personally really wanted AT&T's response to turn out to be made up shitty troll, but it turns out not to be so.
Sprint's "short and sweet" response turns out to be completely unfounded. It essentially translates to "yeah, yeah, we don't like AT&T either, kudos to FCC for sharing in our dislike". FCC did a pathetic job in their Analysis, that's all there's to it.
Calling AT&T's response "scathing" is uncalled for. We have a saying in Polish: the truth stings you in the eyes. As far as I'm concerned, the submitter takes "factual" for "scathing". It's silly. People often take a defensive stance when presented with facts that clearly contradict whatever they previously claimed, so I can at least understand the psychology in the mostly negative reaction to AT&T's rebuke to FCC. What I don't get is why people side with FCC without spending the time necessary to verify the sources. It only takes a couple of hours.
1. No way to compile your own software for those.
2. No way to download firmware updates IIRC without an active support contract with Cisco.
3. Fail.
If anything, HP gear seems to have firmware downloads available without having to jump through hoops. Cisco is their exact opposite.
Karma is a bitch ;) Alas, I think many of us can relate :)
Multiplication is done largely the same on Z80 and 6502. You need additions and perhaps table lookups. The length of the product can be abstracted out in a loop if you want a generic multiprecision multiplication. If your multiplication is long enough, you will save cycles by using FFT that uses many shorter multiplies that take less time than a naive long one. The only major difference is that Z80 has 16 bit add/subtract. That's what you nebulously refer to by saying "Z80 could use 16 bit data words". Well, on a 6502, 16 bit addition is a whooping two instructions instead of one, so I don't see the problem, really.
Zilog's newer offerings are better here: eZ8 (an upgrade to Z8) offers 8x8->16 unsigned multiply, and ZNEO offers 32x32->64 multiply.