Follow Slashdot stories on Twitter


Forgot your password?

Comment Re: probably, detects superheterodyne stage (Score 2) 42

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.

Comment Can they fix it? (Score 1) 222

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.

Comment Just how it is (Score 1) 445

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?

Comment Re:The lack of concern about systemd is concerning (Score 1) 246

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.

Comment Test code (Score 1) 285

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.

Comment Re:I hope he wins in court (Score 1) 1197

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.
