Podcast RSS Feeds

LHS Voice Line

+1-909-LHS-SHOW
Call us and leave a message with your questions, thoughts or suggestions and we'll put you on the air!

Join the Mailing List

Stay up to date with important information about the show, contests, live events and more. CLICK HERE to subscribe.

Become a Member

Membership has its rewards. Sign up for less than $2.00 per month and receive members-only content, free swag and more. CLICK HERE for details.
Namecheap.com - Cheap domain name registration, renewal and transfers - Free SSL Certificates - Web Hosting

LHS Episode #046: The TuxTel Conglomerate

Episode #044 of Linux in the Ham Shack makes its debut, and even on time. We’re still trying to catch up on a little bit of a backlog so this episode is mostly feedback from listeners. We touch on a variety of topics including packet radio, the AX.25 kernel driver for TNCs, the importance of Linux and Open Source, Android and emerging Linux markets, and much, much more.

Thanks for taking the time to download us and being an ever-faithful listener. We would be nothing without you and we want to let you know that we appreciate each and every pair of ears that hears us every fortnight. Don’t forget to send us your feedback, whether it be as a comment on the Web site, a voice mail submitted via our toll-free hot-line or an e-mail to one or both of us. Also, please don’t forget about making donations or buying some of our LHS merchandise if you have the wherewithal to do so. Enjoy our current offering and we’ll be back live in a week for more rowdy fun.

73 de The LHS Guys

2 comments to LHS Episode #046: The TuxTel Conglomerate

  • Randall KC4WZE wrote in about running an app on a cellphone and computer. This actually used to be almost possible. Check out Opie and GPE. They were environments for Linux PDAs back before the PDA market was absorbed into smartphones. Anyway, Opie used Qt which made it relatively easy to port KDE apps and GPE used GTK plus a cut down version of X-Windows. It would be pretty easy to compile the same program and make it run on GPE or on a Linux desktop. Opie was nice but Qt could be installed on GPE and then just about any Linux desktop app was easy to recompile for the device. You could find Opie and Gpe on the Sharp Zaurus PDAs and sometimes people ported them onto HP Journadas. Unfortunately that’s all pretty obsolete now.

    I don’t think you would want one executable which runs in both places because it would be pretty much double the size. Mobile devices usually use Arm processors which are not compatible with x86 desktops because they use less electricity. Then there is the obvious stuff like screen size, keyboard/mouse, etc…

    Had GPE caught on though a programmer could have easily written apps where the work is done by the same code. It would just be user interface stuff that gets swapped out and it would have to be compiled separately for the phone vs desktop.

    That’s sounds like something that is only of interest to the programmer but it brings us close to what you described. If cellphones where using straight Linux with X-windows and common desktop libraries like GTK and Qt we would see more applications which are written for both the desktop and cellphones. The guts of the apps would be shared between both places so they would work the same and it would be more natural for the user interfaces to come out similar. Desktop programmers would only require a little more work to get their app running on devices and vice versa.

    Unfortunately we are mostly at the mercy of cellphone makers and they haven’t chosen to go with that kind of environment. Instead we have Android which is a Linux kernel but the apps are built to run in a custom environment which has nothing to do with Linux and makes it pretty much impossible to share code between a desktop and a cellphone. In fact, the Android environment could probably be ported to Windows CE or any other OS kernel and the apps and their users would never notice the difference. I’m not sure about Palm Pre but I’m thinking they are similarly removed from Desktop Linux.

    If you really do want to play with sharing apps between the desktop and cellphone there is a way to sort of ‘hack’ Android to run Debian in a chroot environment. I’m not sure what kind of access this Debian environment gets to the cellphone hardware though. I’d like to get fldigi and soundmodem going that way. I haven’t gotten this to work yet though.

    You can also run Android on your desktop but then every app will always be designed for a tiny touchscreen rather than your full size monitor/keyboard/mouse.

    Last but not least…. check out opencellphone.org. These guys build their own cellphones using various modules which are available for hobbyists. With one of those you could run GPE. It’d be great to see people do this and pick back up on GPE development. I’d like to do this myself some day but really don’t have the time right now.

  • This sort of thought, well, is sort of bothersome to me. Think back to a more innocent time in your life when you could look at the sum of the components of a radio and say “wooooow”. Your computer is no different. It’s just a bunch of electronic components, the difference being is that with software, it’s an infinitely malleable medium. Whether something runs on X or Y doesn’t really matter to someone that is really a Ham, it’s all about experimenting with it, seeing what it can do, and molding it to the form limited only by your imagination.

    One can make the statement of interoperability being a problem, but the real crux of the issue is when you’re given that mound of transistors to do what you will with… can you? With Windows? The answer is a resounding no!

    One can make all the statements one wishes to about the state of applications and how Linux fits in. The basic answer to the questions posed is “java classes”. You really can’t expect something to run well that’s designed for a touch screen to operate similarly on something with no screen at all, but you can expect the same gearing underneath to pass similar results. Most development environments support cross-platform builds, QT, GTK, etc… platform is irrelavent in the discussion here.

    No, the problem isn’t interoperability, it’s that you need to think of your Ham shack computer as something that will let you pound out the bits and bytes to follow the bidding of your imagination. If you want a music play that works here and there, you’re talking about the commoditization of software, not about the values that a Ham needs to hold closely.

    While one may find that a Windows box or application environment of their choosing does their basic tasks better than the Linux environment, that sort of take on operation has nothing to do with the average tasks of a Ham. We’re people that open boxes up just to see how they work, and when the box doesn’t open, it defeats the values we have. Windows may have its place in many people’s lives, but it has no place in a Ham shack.

    By all means, keep your Windows box for whatever reason you use it for, but it’s the D-STAR of operating systems. They’ll let you go so far before you hit a roadblock where you’re just not invited to the party. This isn’t about Windows vs. Linux, it’s about someone telling you you’re not allowed to share an antenna design because there’s a weld that’s secret.

    In fact, I may be pretty bold here, but one might also argue that while the closed nature of Windows is bad for ham radio, the all or nothing approach of the GPL is bad as well. Is forced freedom of the GPL really freedom at all? I really can’t answer that without some intense debate.

    However, I think I can summarize that your Ham platform has nothing to do with your computer platform. Choose something for your every day tasks (for me, it’s Fedora), choose something for Ham radio (for me it’s Fedora). If they meet? Great! But the EULA is decidedly the opposite of what Hams should have to work with.

Leave a Reply

  

  

  


three × = 3

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>