Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Comment Re:bad idea (Score 1) 57

Well... if you don't have much to talk about I guess you can't complain about not having many folks to talk to.

But seriously, I find it nice to talk on simplex on the way to and from work. It's a good time for a conversation that is confined to a fixed length of time. With the family, my son and I have Baofeng UV-5rs that are very fun.

Comment Re:bad idea (Score 1) 57

Not sure where you live, but here in LA there is a fair amount of activity on 146.52, and plenty of activity on the local repeaters. Same goes for the 440 repeaters, there's always someone talking it up.

I would say if you find the amount of traffic disappointing, get up the nerve to call CQ, and make a point out of doing every time you are in the car at least a few times. Stir up the traffic! Tune in to your local repeaters and just ask if anyone is monitoring. There should at least be a control op on each one.

And if you want to see bands packed full of people, get a 20 meter SSB transceiver and a monoband antenna and you will work world-wide DX from your car pretty much whenever you like.

Comment Re:bad idea (Score 5, Interesting) 57

Why does emergency communication need to be encrypted? If you place yourself in a situation where ham radio would really save the day, the last thing you would want is *less* compatibility with other stations and agencies.

All this will do is allow commercial users to encroach onto the ham bands unnoticed because illegal encrypted traffic is indistinguishable from legal encrypted traffic.

I think it's already questionable why local police departments would use encrypted P25. If the last few months of newsworthy police activity are any hint, we need more opportunities to observe law enforcement, not fewer.

Why the heck does an ambulance need to use ham radio frequencies? Why would they need it encrypted? This argument is simply nonsense. If its an emergency, sorry, loose some privacy in place of saving your life. Hams have enough trouble setting up a PL on a radio, can you imagine them trying to coordinate encryption over the air? In emergency situations, communications networks like ham radio work because they are SIMPLE. They can spring up spontaneously out of nowhere and don't require anything more than a radio, antenna, and battery. This is why ham radio has been helpful in times of emergencies when complex cellular and digital trunking systems fail. There is an elegance to the simplicity of analog.

And if the DOD needs to transmit encrypted information using a ham radio, then can't they just do it anyway?

Furthermore, digital communication does not "need" to be encrypted as some posters here have stated. The protocol needs to be documented and standardized. Encryption doesn't help. Error correction does though, and these are totally different things. WiFi, for example, does not *need* to be encrypted.

Comment Re:What a wonderful article (Score 1) 296

You made some good points, but I think the unix compatibility fueled a lot of developer interest in the early days. Developing on OS X was a joy compared with windows. You have tons of useful built-in tools, plus the ability to port over tools common to the GNU Linux/FreeBSD environment.

If an OS is easy to develop on, it can't hurt.

I agree though, most end users do not care and never would know the difference.

Comment Re:Who cares about performance? (Score 1) 108

I was wondering the same thing too.

I have a decent 8-core xeon at work as my workstation. When I have intense computations to run, I do it on one of our clusters. The idea that someone would do intense calculations on a phone is pretty ridiculous. You've outlined a few good examples, but like you said, most of that is done with dedicated hardware, and seemingly instantly.

The only app that needs to be fast, and I mean really fast, is the app switcher and the Phone app. And they are pretty light on the computation anyway.

Comment The gradual middle road (Score 1) 522

I don't see why nobody is taking the middle road here.

Why not strip out all the non-init.d stuff from systemd for now (I understand there's a light fork that does this already), add plaintext logging (easy), and see how things go (testing).

This is linux, and debian at that. We shouldn't have to deal with extremely beta ideas that change so many paradigms all at once. If they can do what I've outlined here, then we should give it a shot (not on production servers yet of course). If it catches on, then over the years we can debate how much to delegate to systemd and how much to do another way.

For one, I can see no disadvantage in keeping a plaintext log around. Sure, takes a little more space, but most systems are not that space-limited these days. Seems like it would be handy...

Slashdot Top Deals

The answer to the question of Life, the Universe, and Everything is... Four day work week, Two ply toilet paper!

Working...