The way these things is by multiplying the incoming RF by a carrier of frequency very close to the radar frequency. The result is a lower-frequency product that can be sampled or simply compared in the analog domain to a reference. In this setup, the frequency we are multiplying by (the "LO" or "local oscillator") is what is detected remotely, because, as you point out, it has a very direct connection to the antenna.
Here's how you get around it:
Multiply by the expected radar frequency plus, say, 200 MHz. Before the multiplication, near the antenna jack, filter for radar frequency +/- 10 MHz (bandpass). Now the result of the multiplication will be very low-level signal except for a portion around f+/-10 MHz. You then sample this data. As you can see, the bandpass filter doesn't allow the LO to escape through the antenna connection.
Traditional receivers wouldn't do this because it wastes a lot of potentially useful bandwidth, but you can do this to avoid having the LO detected. Without much background on speed radar, I don't know how much variance there is in radar guns, but you would need to take this into account when designing the input filter and choosing the offset from expected frequency for the LO.
Not in textbooks, but definitely something that can be done.
So the question is, can they fix it? This is a relatively new car company, certainly the most successful of any new car company in the last decade. A problem with a door handle or a brake rotor is hardly unique in this industry.
To think this will cause permanent harm to all future Tesla owners is ridiculous. The car is pretty darn good for a new model. In a few years people will start to notice all the failed parts on their Fords and Toyotas and buy a Tesla next.
Maybe this is because the parents of minority race and the poor are, generally speaking, relatively uninformed about opportunities to enroll their children in "gifted" programs. Or perhaps they are aware of it but don't believe they would do well. You have to consider the background and culture.
It's one thing for some Ph.D to sit comfortably in his office running statistics on enrollment. It's entirely different if he were to go to the homes of the minority and poor students and ask them about their opinions of "gifted" programs.
Chances are he would chicken out at the doorstep. So how do you think those parents feel about special education offers?
I think I answered my own question, and the answer is obvious:
They distributed this malicious program as an SDK with source code inside the Xcode install. So it's not just a binary library that gets linked against, it's the code too. Is that correct?
Well I'll be darn, you've proven it. A bunch of folks at a conference were able to use systemd.
I have several systems running systemd. It's not impossible to use or install. But it is not as robust. It is different. And it did cause me a lot of pain on several production servers. For those of us who work in the field, we know a turd when we see one.
For those of us who depend on support contracts and certifications, such as yourself, I guess it's not as big a deal.
How is systemd "standard"? This is brand new. There is nothing standard about it either. It is completely different. People like myself are complaining because it is NOT standard.
And modern? I suppose that's open to interpretation. An apple watch is modern. So is Windows 10. As is OpenCL. What the heck are you trying to say? Because it's modern it is automatically simple to admin? WTF
It's not incompetence, I assure you. My inability to get systemd working at my level of standards speaks directly to the level of readiness of the systemd packages, distros, and maintainers.
I suppose every person complaining about systemd might be totally incompetent. Maybe it's only the new kids fresh off the ubuntu express that have issues with it. Perhaps most people that are really smart and analytical like systemd.
Or. maybe it really isn't ready. Maybe it is a big mess. Maybe it was pushed early in distros to sell more certifications and paid support contracts.
I mean, one guy (an AC) replying in this thread was using it without even noticing it. Do you think he really knows what's going on under the hood or is he just another ubuntu desktop user that thinks gnome is his operating system?
Despite your judgment of my non-expert status, I am an expert.
I have learned many new technologies within hours on linux. There is a sort of common "flow" between technologies on linux. Same can be said for FreeBSD and other unix-like systems. I have admin'd basically every version of unix you have ever heard of. Everyting from irix to solaris to a/ux to aix. My first linux install was off floppy disks. I've worked on corporate, university, and government platforms. I've been everything from a kernel device driver developer (atheros wifi drivers) to large cluster admin to net booting macs off a FreeBSD NFS cluster. I'm not new to this at all. Not to say that you were in diapers while I was compiling linux from scratch, but I've been there.
That is why I feel such a distain towards systemd. Yes, I could have dropped everything, read all the documentation, checked out the source code, and probably figured it all out sooner or later. But what a PITA. What I had before worked, and it was easy to maintain. Sure, init scripts lack elegance. So ok, address that. But pushing systemd is not a solution. Systemd basically cost me a lot of productivity. There was no gain, no benefit to my installs. I have a few computers running it. I can't see any advantage other than that they are "up to date" with trendy linux packages. And they boot faster (when they boot fully, that is).
Here's what I worry about: If we design core linux technologies (i.e., the kernel, kernel modules, udev, init system, etc) such that they cater to companies making money off supporting linux (red hat), then we may also loose something else in the process. (We don't have to, the two aren't mutually exclusive.) It has nothing to do with the existence of closed-source linux software and commercial deployments. It has to do with the overall closure of linux. There are companies that would love to make linux something like MS or Cisco where individuals need a new certificate every year in order to work government software contracts and big corporate installs. Systemd does facilitate that. Besides from being far from ready for the real world, systemd is overly complex. Systemd is a big single point of failure. Systemd has binary logs. Systemd is vastly more difficult to troubleshoot than Sys-V init (and yeah, Sys-V was a convoluted string of shell scripts, but it was pretty easy to follow through and get working). I mean, you've read or experienced these things, this is not really anything earth shattering.
So what I feel, is that the move towards systemd is a move away from the roots of linux. It's away from the days where you could install linux and start an ISP in a garage. It's like the writing is on the wall.
Let me ask you this: If they decided to do away with every single file in/etc and replace it with a binary-format database, editable only with a special program for gnome-3, would you like that? It would be modern. It would be enormous. It might be faster than parsing text files in C. It would require everyone to learn something new. It would begin rather untested and probably be pushed out to every enterprise distro immediately. I mean, how far will can we go from the roots of our success before we are alienated and cause our own demise?
I'm all for a *better* init system. And there are parts of systemd that have some good merits. But it's way too untested, and beginning its linux life with far too many tentacles.
In a time where unix and linux are the dominant (or nearly dominant) operating systems (android, iOS, linux, Mac OS X, embedded products), we must be very careful of the ground we tread.
So that's why I would expect more from RMS. Not on the software architecture, or the quality of the code. But on the philosophy and ecosystem of linux.
But hey, the proof is in the pudding. I spent two days trying systemd. I could not get it working properly. (This was with Debian, my favorite linux distro of all time.) Machines that couldn't mount an NFS point just booted to the rescue prompt. Networking didn't work. Many other issues. The whole thing just made me look at systemd as something that really has not been tested enough to have been distributed like wildfire. We can debate about the merits of a large overlord init+kitchen_sink system (and I think you can guess how I feel about that), but regardless, it is not ready yet. init is so tested and well-understood that, when compared with something like systemd, administrators and developers (and normal joe users too!) have a very good reason to hesitate.
If systemd has the potential to further commercialize the linux world (certifications, certified distributions, enterprise support contracts, etc), at the expense of the rest of the linux world then I think it is something we could use an RMS comment about.
Write code to test your code. Hit every edge case hard, every boundary condition.
All too often we tend to test our code by just running the overall program, but this is not good enough. Running the overall program does not introduce a wide enough range of input parameters to every function.
Write test code. Write code to log your inputs and outputs to files early in the development cycle. Don't get swamped down in the land of trying to debug code that was never written to be debugged.
I had many many tough bugs back in the day before I learned this lesson. Once I got this behind me, it was a lot easier.
Hmm... let's re-word that a bit and see how you feel from the other side:
Flying a drone in a populated area is unsafe in nearly every circumstance. Just because there's no malfunction doesn't mean there couldn't be. If the done had suddenly dropped altitude, would the pilot have tracked it like a skilled operator to land it? Would that have brought the craft down to a point where the pilot could have endangered neighbors? What if the drone landed in the pool? Was the pilot certain that in all cases his flight-range was clear before flying? These are all things which a responsible drone owner thinks about.
I hope the pilot gets a big-ass fine (I'd hate to pay for his jail food out of taxes). I also hope the flier gets a fine for trespassing - or even just gets called into court and let of with a warning. The lawyers fees will probably be 10x what the drone cost to begin with.
Section 97.101(d) of the Commission's Rules prohibits amateur operators from willfully or maliciously interfering with or causing interference to any radio communication or signal. 47 C.F.R. 97.101(d).
Then there's the water absorption problem. 2.4 GHz is used in microwave ovens for a reason. At a few KW, you'd basically cook the drone in the sky. Hope you don't have any SWR, it will be a complete disaster on your feed.
Try this one out: remap the upper numeric keys from numbers to the symbols they have above the numbers. When you need a number, hit shift to get the numbers or use the numeric keypad.
I find it very annoying to hold down shift so often while coding. I almost never use the upper-row numbers as numbers, but I hit a lot of symbols coding in C and C++. I definitely use the symbols more, why do I have to hit shift to get to them?
Just look at a hunk of your favorite OSS project's code. Are there more numbers or symbols?
Granted, any facebook/gmail computer user wouldn't get this at all...
Come to think of it though, if you are working in uint space (that is, unsigned ints), than you *can't* have approached from below zero.
And if you were for some reason working with unsigned ints that were always multiplied by -1 than I think you'd still be ok with -1 * inf as your result.
Just so we're clear: this is stupidity -- the algorithm is not returning useful data and it will only mess up everything down the line. Sanitize before you divide, handle divide by zero as an error or a special case.
If x1 == x2, you probably don't actually *need* a slope. You can mark those shapes or lines as perfectly vertical. Any algorithms that process based on slope would just skip those lines. A simple bool array that accepted pixel or shape (not really sure of the application) coordinates could return several useful parameters that would keep other algorithms from tripping up.
You might think this is a lot of overhead, but passing uint(-1) to an algorithm needlessly, or rotating your entire scene to avoid this is also a lot of overhead. If you just make a single pass over the scene and store the parameters (remember, memory is plentiful these days compared with CPU), then you can do very simple logic on the processing side, re-using the stored results.
You can fix the math by fixing the algorithm, no need to return results when the results are not only undefined but also not useful.
I have been suffering browsing the web with only one audio channel per ear for literally decades.
What to them so long, this is embarrassing. When I go to the movies I get to smell expensive popcorn and experience 6 to 16 channels of high-def audio. Why not on my windows smart phone and my tablet?
PowerPoint is not the crutch. The crutch is pointless meetings and the desire for "material" when what you really need is a discussion with the right key people in the room.
Might as well ban PDFs while we're at it, I've seen lots of pointless PDF files too.
You might be right that this is a loaded Trojan horse.
However, I have no problem with what is on the surface. These are good ideas -- the internet is very much deserving "public utility" status. I'm not worried about fast lanes, I'm worried about intentionally making competition-owned services slower. The internet is a freaking power outlet, it should not matter what brand of hair dryer I plug in. If I need more power, I buy more power (bandwidth). But it doesn't matter what I am using it for.
The thing is we're worried about what comcast "might" do. And you're worried about what the NSA/government "might" do. Well maybe we're both right, did that ever occur to you? Maybe the government wants to overreach, to spy on your ebay shopping and snoop on your email. Maybe private industry wants insert extra ads while I web surf, or slow down Skype so that I am more likely to use iMessage, or make Amazon faster than Netflix in return for a little cash on the side. or whatever. Lots of maybe here.
We have to attack on both fronts. Neither party is trustworthy here.
Slashdot Mirror
Actually it can be done with a little RF theory.
The way these things is by multiplying the incoming RF by a carrier of frequency very close to the radar frequency. The result is a lower-frequency product that can be sampled or simply compared in the analog domain to a reference. In this setup, the frequency we are multiplying by (the "LO" or "local oscillator") is what is detected remotely, because, as you point out, it has a very direct connection to the antenna.
Here's how you get around it:
Multiply by the expected radar frequency plus, say, 200 MHz. Before the multiplication, near the antenna jack, filter for radar frequency +/- 10 MHz (bandpass). Now the result of the multiplication will be very low-level signal except for a portion around f+/-10 MHz. You then sample this data. As you can see, the bandpass filter doesn't allow the LO to escape through the antenna connection.
Traditional receivers wouldn't do this because it wastes a lot of potentially useful bandwidth, but you can do this to avoid having the LO detected. Without much background on speed radar, I don't know how much variance there is in radar guns, but you would need to take this into account when designing the input filter and choosing the offset from expected frequency for the LO.
Not in textbooks, but definitely something that can be done.
So the question is, can they fix it? This is a relatively new car company, certainly the most successful of any new car company in the last decade. A problem with a door handle or a brake rotor is hardly unique in this industry.
To think this will cause permanent harm to all future Tesla owners is ridiculous. The car is pretty darn good for a new model. In a few years people will start to notice all the failed parts on their Fords and Toyotas and buy a Tesla next.
Maybe this is because the parents of minority race and the poor are, generally speaking, relatively uninformed about opportunities to enroll their children in "gifted" programs. Or perhaps they are aware of it but don't believe they would do well. You have to consider the background and culture.
It's one thing for some Ph.D to sit comfortably in his office running statistics on enrollment. It's entirely different if he were to go to the homes of the minority and poor students and ask them about their opinions of "gifted" programs.
Chances are he would chicken out at the doorstep. So how do you think those parents feel about special education offers?
sorry, not reading the article. But doesn't an iPhone automatically fallback to cellular data when out of wifi range? I'm pretty sure mine does.
What's new here? Is it faster? More fault-tollerant?
I think I answered my own question, and the answer is obvious:
They distributed this malicious program as an SDK with source code inside the Xcode install. So it's not just a binary library that gets linked against, it's the code too. Is that correct?
Ok, I read the article you linked to. Very interesting.
What I do not understand is how the source code was "found". I understand how to use a disassembler, but that would not yield such readable code.
Can you comment on this?
Thanks for linking to the article.
Well I'll be darn, you've proven it. A bunch of folks at a conference were able to use systemd.
I have several systems running systemd. It's not impossible to use or install. But it is not as robust. It is different. And it did cause me a lot of pain on several production servers. For those of us who work in the field, we know a turd when we see one.
For those of us who depend on support contracts and certifications, such as yourself, I guess it's not as big a deal.
And one more thing:
What the heck is "standard modern software"?
How is systemd "standard"? This is brand new. There is nothing standard about it either. It is completely different. People like myself are complaining because it is NOT standard.
And modern? I suppose that's open to interpretation. An apple watch is modern. So is Windows 10. As is OpenCL. What the heck are you trying to say? Because it's modern it is automatically simple to admin? WTF
And who is this "We" you speak of?
Not eating the cake.
It's not incompetence, I assure you. My inability to get systemd working at my level of standards speaks directly to the level of readiness of the systemd packages, distros, and maintainers.
I suppose every person complaining about systemd might be totally incompetent. Maybe it's only the new kids fresh off the ubuntu express that have issues with it. Perhaps most people that are really smart and analytical like systemd.
Or. maybe it really isn't ready. Maybe it is a big mess. Maybe it was pushed early in distros to sell more certifications and paid support contracts.
I mean, one guy (an AC) replying in this thread was using it without even noticing it. Do you think he really knows what's going on under the hood or is he just another ubuntu desktop user that thinks gnome is his operating system?
Despite your judgment of my non-expert status, I am an expert.
I have learned many new technologies within hours on linux. There is a sort of common "flow" between technologies on linux. Same can be said for FreeBSD and other unix-like systems. I have admin'd basically every version of unix you have ever heard of. Everyting from irix to solaris to a/ux to aix. My first linux install was off floppy disks. I've worked on corporate, university, and government platforms. I've been everything from a kernel device driver developer (atheros wifi drivers) to large cluster admin to net booting macs off a FreeBSD NFS cluster. I'm not new to this at all. Not to say that you were in diapers while I was compiling linux from scratch, but I've been there.
That is why I feel such a distain towards systemd. Yes, I could have dropped everything, read all the documentation, checked out the source code, and probably figured it all out sooner or later. But what a PITA. What I had before worked, and it was easy to maintain. Sure, init scripts lack elegance. So ok, address that. But pushing systemd is not a solution. Systemd basically cost me a lot of productivity. There was no gain, no benefit to my installs. I have a few computers running it. I can't see any advantage other than that they are "up to date" with trendy linux packages. And they boot faster (when they boot fully, that is).
First off, thank you for your well-written reply.
Here's what I worry about: If we design core linux technologies (i.e., the kernel, kernel modules, udev, init system, etc) such that they cater to companies making money off supporting linux (red hat), then we may also loose something else in the process. (We don't have to, the two aren't mutually exclusive.) It has nothing to do with the existence of closed-source linux software and commercial deployments. It has to do with the overall closure of linux. There are companies that would love to make linux something like MS or Cisco where individuals need a new certificate every year in order to work government software contracts and big corporate installs. Systemd does facilitate that. Besides from being far from ready for the real world, systemd is overly complex. Systemd is a big single point of failure. Systemd has binary logs. Systemd is vastly more difficult to troubleshoot than Sys-V init (and yeah, Sys-V was a convoluted string of shell scripts, but it was pretty easy to follow through and get working). I mean, you've read or experienced these things, this is not really anything earth shattering.
So what I feel, is that the move towards systemd is a move away from the roots of linux. It's away from the days where you could install linux and start an ISP in a garage. It's like the writing is on the wall.
Let me ask you this: If they decided to do away with every single file in /etc and replace it with a binary-format database, editable only with a special program for gnome-3, would you like that? It would be modern. It would be enormous. It might be faster than parsing text files in C. It would require everyone to learn something new. It would begin rather untested and probably be pushed out to every enterprise distro immediately. I mean, how far will can we go from the roots of our success before we are alienated and cause our own demise?
I'm all for a *better* init system. And there are parts of systemd that have some good merits. But it's way too untested, and beginning its linux life with far too many tentacles.
In a time where unix and linux are the dominant (or nearly dominant) operating systems (android, iOS, linux, Mac OS X, embedded products), we must be very careful of the ground we tread.
So that's why I would expect more from RMS. Not on the software architecture, or the quality of the code. But on the philosophy and ecosystem of linux.
I was around for those changes and many others.
Systemd is far more fundamental than those.
But hey, the proof is in the pudding. I spent two days trying systemd. I could not get it working properly. (This was with Debian, my favorite linux distro of all time.) Machines that couldn't mount an NFS point just booted to the rescue prompt. Networking didn't work. Many other issues. The whole thing just made me look at systemd as something that really has not been tested enough to have been distributed like wildfire. We can debate about the merits of a large overlord init+kitchen_sink system (and I think you can guess how I feel about that), but regardless, it is not ready yet. init is so tested and well-understood that, when compared with something like systemd, administrators and developers (and normal joe users too!) have a very good reason to hesitate.
If systemd has the potential to further commercialize the linux world (certifications, certified distributions, enterprise support contracts, etc), at the expense of the rest of the linux world then I think it is something we could use an RMS comment about.
They paid to get screwed.
Seems they are getting their money's worth.
Write code to test your code. Hit every edge case hard, every boundary condition.
All too often we tend to test our code by just running the overall program, but this is not good enough. Running the overall program does not introduce a wide enough range of input parameters to every function.
Write test code. Write code to log your inputs and outputs to files early in the development cycle. Don't get swamped down in the land of trying to debug code that was never written to be debugged.
I had many many tough bugs back in the day before I learned this lesson. Once I got this behind me, it was a lot easier.
Hmm... let's re-word that a bit and see how you feel from the other side:
Flying a drone in a populated area is unsafe in nearly every circumstance. Just because there's no malfunction doesn't mean there couldn't be. If the done had suddenly dropped altitude, would the pilot have tracked it like a skilled operator to land it? Would that have brought the craft down to a point where the pilot could have endangered neighbors? What if the drone landed in the pool? Was the pilot certain that in all cases his flight-range was clear before flying? These are all things which a responsible drone owner thinks about.
I hope the pilot gets a big-ass fine (I'd hate to pay for his jail food out of taxes). I also hope the flier gets a fine for trespassing - or even just gets called into court and let of with a warning. The lawyers fees will probably be 10x what the drone cost to begin with.
Also, that would be willful interference.
Section 97.101(d) of the Commission's Rules prohibits amateur operators from willfully or maliciously interfering with or causing interference to any radio communication or signal. 47 C.F.R. 97.101(d).
https://www.fcc.gov/guides/ama...
But hey, I think you can argue the situation calls for it anyway!
Then there's the water absorption problem. 2.4 GHz is used in microwave ovens for a reason. At a few KW, you'd basically cook the drone in the sky. Hope you don't have any SWR, it will be a complete disaster on your feed.
73.
Try this one out: remap the upper numeric keys from numbers to the symbols they have above the numbers. When you need a number, hit shift to get the numbers or use the numeric keypad.
I find it very annoying to hold down shift so often while coding. I almost never use the upper-row numbers as numbers, but I hit a lot of symbols coding in C and C++. I definitely use the symbols more, why do I have to hit shift to get to them?
Just look at a hunk of your favorite OSS project's code. Are there more numbers or symbols?
Granted, any facebook/gmail computer user wouldn't get this at all...
Come to think of it though, if you are working in uint space (that is, unsigned ints), than you *can't* have approached from below zero.
And if you were for some reason working with unsigned ints that were always multiplied by -1 than I think you'd still be ok with -1 * inf as your result.
Just so we're clear: this is stupidity -- the algorithm is not returning useful data and it will only mess up everything down the line. Sanitize before you divide, handle divide by zero as an error or a special case.
Just take the mean: ...which is zero. Oh wait hmm...
mean(-inf, +inf)
(yes I realize the multiple fallacies here, this is intended as a joke)
if(x1!=x2)
{
slope = (y2-y1) / (x2-x1);
}
If x1 == x2, you probably don't actually *need* a slope. You can mark those shapes or lines as perfectly vertical. Any algorithms that process based on slope would just skip those lines. A simple bool array that accepted pixel or shape (not really sure of the application) coordinates could return several useful parameters that would keep other algorithms from tripping up.
You might think this is a lot of overhead, but passing uint(-1) to an algorithm needlessly, or rotating your entire scene to avoid this is also a lot of overhead. If you just make a single pass over the scene and store the parameters (remember, memory is plentiful these days compared with CPU), then you can do very simple logic on the processing side, re-using the stored results.
You can fix the math by fixing the algorithm, no need to return results when the results are not only undefined but also not useful.
I have been suffering browsing the web with only one audio channel per ear for literally decades.
What to them so long, this is embarrassing. When I go to the movies I get to smell expensive popcorn and experience 6 to 16 channels of high-def audio. Why not on my windows smart phone and my tablet?
PowerPoint is not the crutch. The crutch is pointless meetings and the desire for "material" when what you really need is a discussion with the right key people in the room.
Might as well ban PDFs while we're at it, I've seen lots of pointless PDF files too.
I would say that linux would be a superior choice to windows for a car. Less re-starting.
You might be right that this is a loaded Trojan horse.
However, I have no problem with what is on the surface. These are good ideas -- the internet is very much deserving "public utility" status. I'm not worried about fast lanes, I'm worried about intentionally making competition-owned services slower. The internet is a freaking power outlet, it should not matter what brand of hair dryer I plug in. If I need more power, I buy more power (bandwidth). But it doesn't matter what I am using it for.
The thing is we're worried about what comcast "might" do. And you're worried about what the NSA/government "might" do. Well maybe we're both right, did that ever occur to you? Maybe the government wants to overreach, to spy on your ebay shopping and snoop on your email. Maybe private industry wants insert extra ads while I web surf, or slow down Skype so that I am more likely to use iMessage, or make Amazon faster than Netflix in return for a little cash on the side. or whatever. Lots of maybe here.
We have to attack on both fronts. Neither party is trustworthy here.