Linux Journal Insider January 2010

This is the maiden voyage of the Linux Journal Insider podcast, and we start the new year of Linux Journal off with a bang. Or more precisely with a HAM. HAM radio that is. If you're not a subscriber to the magazine, pick up this latest issue on newsstands mid-December, or buy a single copy in our on-line store. Both digital and print copies are available.

Linux Journal Insider is your monthly peek at what to expect from the new issue of Linux Journal, before it even hits the newsstands. Shawn Powers and Kyle Rankin give you the inside scoop on topics, articles, and geekery in general. Feel free to listen right here in your browser with the fancy embedded audio player, or subscribe to the FEED with your favorite podcast software. Either way, we hope you enjoy it!

This edition of Linux Journal Insider is brought to you by Microway. Go to www.microway.com/clusters to learn about their cluster offerings and request a quote based on your specifications.

A special thanks goes out to Jeff Robbins over at Lullabot for making that awesome intro music!

Comments

Linux based HAM radio - when?

Ham Man's picture

I'd love to see a switch to Linux based radios. Any thoughts? Sure there's third party software to 'manage' your ham contacts and such, but lets get down and dirty - when is ICOM/Kenwood/Yaesu/TenTec/etc going to put out hardware that can run Linux in a native mode - not an interface to manage the radio?

Once there - then we're getting back to the origins of HAM radio (build your own), but in the 21st century!

What say you?

Multiboot

Anonymous's picture

I actually have several computers. One is my dedicated Linux system. I use it for 99% of what I do. I have 2 other systems that multiboot. All my systems can boot into Linux so I can have them help out on big source code builds. It gets the job done faster.
Perhaps this is something you hadn't thought of. You definitely don't want a Virtual machine doing distributed makes.

Where's the OGG feed

Freemor's picture

O.k. I know you have to be comptaible with peoples pmp's so I expected that there would be an MP2/3 Stream but being from "Linux Journal". I thought that there'd be a OGG stream.. You know, support open source and open standards.. etc.

Maybe for episode 2 and beyond? (My PMP supports OGG :) )

Oggcasting!

Epicanis's picture

I'm not sure whether to be annoyed that I didn't get "first post" on the topic of wanting a legally-free Ogg file, or to be happy that I'm obviously far from the only person that agrees on this...

I second that. Let's keep it

metalx2000's picture

I second that.
Let's keep it Open where every possible.
Go OGG!

http://filmsbykris.com/
Everything you ever need to know about Open-Source Software.

Podcast feed

KamSalisbury's picture

Great job! Now a dedicated podcast feed would be even greater!

Bandwidth for Amateur Radio

David Lane's picture

Good job guys. Currently, in the 1.2 GHz band, we can push data up to about 128 kb/s, and while that is still slow when compared to what we are getting with 802.11 a/b/g/n gear, it is more than acceptable when you consider the range of the signal is measured in miles, rather than feet and inches and you cam push low-level web and email traffic over it.

Yes, encryption is not permitted by the FCC UNLESS you receive the data that way. So while I could not encrypt the message going from Shawn to Kyle, if Shawn hands me an encrypted message, I could pass it to Kyle via packet.

You can learn more in the Linux Journal Ham Shack.

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

Third Party Traffic?

Jonathan Guthrie - KA8KPN's picture

Well, okay. The guy at KARS last month said essentially the same thing about using PSK31 to transmit encrypted spreadsheets as part of a disaster relief effort. The problem is, it doesn't look to me like it's true. FCC Rule 97.113(a)(4) says that "No amateur station shall transmit...messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein."

"Otherwise provided herein" would be the exceptions granted in 97.211(b) to those stations acting as satellite ground stations, 97.215(b) for "telecommand of model craft", and 97.309(b) which says that you can send messages in any digital alphabet you want as long as you keep a copy of that alphabet.

See, for example,
The actual rules at the FCC

None of those say that you can pass encrypted third-party traffic around because it doesn't place any limits on who is obscuring the meaning. The rule prohibits any message whose meaning has been obscured through encoding.

There are also significant limitations on any transmissions made on behalf of any third parties. For example, it would appear to me that rule 97.113(e) bans any packets of any sort that were ever transferred using "any type of radio station" say, for example, that Part-15 WLAP that many people have in their houses.

Yes...but..

David Lane's picture

This has been debated back and forth...the official word from Riley Hollingsworth and John Johnston who covered it earlier this century (and if I can find the citation I will stick it up here) is it falls under the third party traffic rules in that if you are handed traffic, encrypted or otherwise, you have to pass it as written, so it falls outside the encryption rules because as the amateur we are not encrypting it. Of course, the third party country rules also fall into play too. If you really want to get technical, there was some discussion about 7-bit encoding and whether or not that was considered encryption under the rules (it was ruled no) even though it is clearly obfuscation of data under the rules.

Generally, this would only come into play in extreme cases where PII or HIPAA data was involved and there clearly was no other way to pass it.

However, there are situations where encryption is something we need to address in a rule change as more and more information in a disaster is more sensitive than we should realistically be handling in the clear.

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

hidden assumptions?

David T Stark - NF2G's picture

There appear to be two assumptions at work in this thread.

1) That third-party traffic received by a ham operator MUST be passed on. This is not true. The station operator is responsible for rules compliance, and that gives him/her the ultimate authority to refuse transmission. With respect to encrypted traffic, my take is that it should never be relayed, regardless of source or other factors. The station operator cannot discharge their statutory obligations if they are unaware of the content of any message they transmit. Ham radio is not a common carrier. Individual operators are liable for violations.

2) That encryption and access control are the same thing. Using WEP to protect one's station from unauthorized access is not only lawful but probably a good idea. The control operator is liable for whatever happens with the equipment, so ensuring that said operator is known and authorized (and qualified) to utilize the station is a requirement of the FCC Rules.

As someone who passes along

Jonathan Guthrie - KA8KPN's picture

As someone who passes along a message on behalf of a third party, you are required to ensure that the third party traffic complies with all of the rules, including (I would expect) the messages not being encrypted to obscure the meaning. Actually, there are more rules for third party traffic than there are for direct ham contact.

By all means please pass along that link, if you can find it. The only link I could find about encrypting packet radio was to a TAPR paper about HSMM that said that using WEP was apparently okay as long as you weren't using WEP to obscure your meaning, which (while true) I find a little hard to use as a justification because one usually seeks privacy in order to obscure something.

Oh, speaking of HSMM, did you (meaning, actually, Shawn et al) know that the part-15 802.11 access points share frequencies with those allocated to hams? You can configure access points to use only ham frequencies and operate them as part-97 devices, which means (among other things) that your data rates would be the same as WiFi, because it is Wifi, but you also get privileges such as less congested frequencies and higher power limits and the ability to make or modify your own equipment. There's some folks up in Austin who are apparently using the WRT54GL access points in that fashion.

Lastly, because it's just about time for me to drive home to Katy, I finally figured out what APRS is for. Don't think position reporting (although it is used for that) think text messaging. You use APRS for the sorts of messages that you use the cellphone networks text message system for.

802.11

David Lane's picture

I suspect Shawn and Kyle do not know that because the 802.11 devices share our allocation, or that we have the ability to bring our additional privileges to bear on them. They did the cast without any input from me. The biggest problem with most of the off-the-shelf gear is the power restrictions on the radios in them, making it harder to boost them in the box, but being able to frequency shift them off the crowded channels is certainly an advantage, but not one I have seen a lot of folks take advantage of. The best example I am aware of is a new APRS digi in my corner of the world running on a Linksys set up.

We use the text function of APRS quite a bit during exercises, especially if there is one or more hospitals involved. We also have chat capability wired in to our D-Star set ups for the Marine Corps Marathon to facilitate communications without chewing up valuable phone space.

I have to spelunk my NAS drive for the encryption stuff. I want to say it was in an issue of Auto Call.

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

Great Job!

waparmley's picture

Interesting and informative. Very good, accurate discussion of Amateur Radio. Shawn and Kyle clearly took the time to get an in depth understanding of the subject.

A bit of trouble with Kyle's audio, by the way.

As they say on BOL, "Love the show!"

73 (I'm sure you know what that means now),

KR8L

VM

waparmley's picture

Well, I posted that comment before the end of the podcast, thus interrupting the stream (duh!).

Just wanted to add that having tried both dual boot and virtualization, I actually prefer dual booting, and I can't really explain why.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState