ucAsterisk
ucAsterisk is a project to breach the last barriers that stand before transparent telephony designs. It will combine Asterisk, ucLinux, and Open Hardware.
Once ucAsterisks milestones have been met, it will effectively complete a transparent embedded telephony design, from the hardware designs through firmware, DSP code and applications - all freely available under the GPL.
David Rowe has made the port of Asterisk to ucLinux and is now working on the open telephony hardware. This shouldn't be surprising as David started the first company to build multi-port voice telephony cards with open source Linux drivers and he's contributed heavily to projects like Bayonne, Speex, Asterisk, and Ctserver.
One of the goals of the ucAsterisk project is to build a PBX running on the BlackFin 533 target platform. This is a small, inexpensive (5USD in quantity), low-power (sub-watt), 500MHz CPU with some DSP functionality. To buy a development board and tools for a few hundred bucks look here. The BlackFin PBX will be an important milestone.
<opinion>Transparency
ucAsterisk is a proof of principle and an omen. Telephony design is now open end-to-end.
ucLinux/OpenCores have finally brought together open hardware design and the dominant platform for open-source software design. For the next couple of years, this will be the most transparent platform for end-to-end open designs. Porting important applications to this platform is the best way to plant the seeds of completely open end-to-end computing systems (hardware and software) with practical, commercial applications.
Since Asterisk is the dominant Open-Source telephony application, it is now possible to build a dominant platform that is completely transparent, end-to-end. This is as near a foolproof recipie for creating an industry standard reference design as can be imagined.
This is another data point suggesting that there is nothing left to hide in this field, and no beneficial reason to do so (beneficial to consumers, that is). Another data point showing that the free exchange of ideas trumps any system of patents. Designs will move more quickly, they will be more secure and more innovative.
To me, it is just as important that this project feels right. It's a huge relief after being in this industry as long as I have to see proper reference designs developed in an open manner.
NOTE: If you haven't seen the OpenCores project you probably don't follow me. You should check it out.</opinion>
Sub 100USD Linux Boxen
This new tiny platform for Asterisk has me excited about toying with tiny platforms for Linux. So I'm taking another look at small, Linux-compatible boxen. Asterisk runs on all of the following, as they all run standard Linux.
Gumstix still looks like the most bang for the buck, although a little underpowered. 99 bucks gets you a very small, relatively slow little linux board with some super-cool features like bluetooth modules. Good deal.
If you want something turnkey and don't need lots of mips or a tiny package, get yourself a Linksys WRT54G series wireless router. OpenWRT has a lot of ported applications. At 80 bucks retail, including the wireless router, this little item is the low cost leader.
If you want something powerful and don't need it too small, used 500MHz laptops (or even 1GHz laptops with a broken screen) can be found on ebay for around 100USD.
Linux Devices has a small list of fairly turnkey stuff. Compulab has some sub-100USD boards that look good as well.
OpenCores.org
Let's face it though, the most attractive thing to you, geek, is the most Open system - the system you can actually engineer. To get there you need to geek out a little more, and, unfortunately, spend more money. The single most interesting hardware project out there today is probably OpenCores.org.
My goal is to find out how cheaply I can get FPGAs and the hardware to program FPGAs that will run ucLinux/Asterisk/Ethernet. There are OpenCores platforms that will run ucLinux and emulate risc, motorola, sparc, arm, etc.
I really haven't got a solid understanding as to which OpenCores modules will fit on which FPGAs. You have to really dig to get this kind of information from the opencores site (the forums are the most useful repository). A matrix of this type will have to wait for another article.
One problem that is recognized but unsolved by the OpenCores community is that the tools and components required to build an embedded system are not cheap. It looks like most people prove they have a design and then humbly request for help from commercial vendors.
AFAICT, the cheapest FPGA development kit that will definitely run ucLinux on opencores is the Cyclone II from Altera, which supposedly will be available for 270USD (according to the Altera website). I don't know enough yet to evaluate that, but here is one evaluation.
The best way to get started might be to order a prototype board kit from a designer.
Ah, well, that was fun. Back to work on Rails.
Tuesday, December 13, 2005
Monday, December 12, 2005
Saving the Remote Environment
Kaboom!
So I was at Superhappydevhouse when my thinkpad unexpectedly went into hibernation. It took me a little while to figure out that someone across the room inadvertantly flipped the switch that controlled the outlet I was plugged into, and my battery had died. The din in the room was loud enough that I could not hear it's last, plaintive beeps.
My battery was resurrected at the flip of a switch, but I lost some time setting up application sessions, so I asked around as to how people save session data in their application of choice.
While there is no way to restore the complete state of my Linux system upon a crash (a car battery to thinkpad power adapter is on my list of things to do), there are quite a few things I can do to make things less painful. Here are the best of state-saving helpers I looked at:
emacs
First, Emacs has the commands desktop-save and desktop-read.
This feature is directory dependent, that is, emacs will ask you what directory your desktop config file is in.
I have one emacs desktop file in each of my project directories now. The desktop feature doesn't re-tile your windows, but it at least brings up all the files you had open and, of course, emacs tells you which ones have auto-save data.
The single-desktop-per-directory limitation encourages subdirectories for different work modes.
screen
I don't run most programs in crappy emacs shells, I use real terminals. I need something to save the state of all my terminals. I have finally been getting to know GNU screen. Good tutorial here.
Using screens keybindings is painful. However, unlike gnome terminals bindings, they don't collide with the readline namespace. Alt-B really takes me back a word, instead of popping up some useless menu. (Update: I have since been enlightened by Eterm, and now run screen in an eterm window.)
Screen runs as a daemon and manages consoles - sort of like a text-only window manager. Obviously, it can't restore running applications after a crash. However, run over an ssh session, it will happily run whether you are attached or not, so it's a nice way to work remotely. Evidently, it can also be configured to tee I/O for multiple clients, aiding in collaborative development.
Screen encourages one to work remotely on a more reliable system; which effectively means it encourages one to have a non-production machine that is internet accessible.
firefox
Third, Firefox has SessionSaver.
http://kb.mozillazine.org/SessionSaver
Session saver is useful, but not exactly feature complete. A few things I noticed:
One, to overwrite a saved session, you have to open the session, configure as desired, right click on the saved session to delete it, and re-save the current browser state with the same name.
Two, SessionSaver actually uses a good bit of CPU.
Three, SessionSaver explicitly suggests that you save your data via WebDAV and has some utilities to make it easier to do.
More encouragement for remote work. I'm starting to get the message...
The overall hint is that I should give in and store everything on a remote server. I could use screen, emacs, and webdav/sessionsaver to store everything there.
WebDAV
I had been experimenting with WebDAV long ago, so I re-installed it on a server I have access to. My primary goal is to get this going with firefox sessionsaver. However, my secondary, more exciting goal is to get this working with the actively developed and nearly useable DavFS2 for the linux kernel. WebDav installation and usage is tangent to the omnibus remote-coding review of this article, but I *will* handle this in a subsequent article.
ssh-agent
As long as we're on a roll, lets slap on another convenience utility for setting up our sessions that I have ignored for a long time: ssh-agent. Ssh-agent helps you manage passwordless ssh logins - here is a good explanation. If you run linux, you should already have this tool, and every other tool I'm covering (with the exception of a quick SessionSaver download for firefox). This particular tool is something that is a better friend to system administrators than developers, but it *might* save me time in the long run.
am I really better off?
So now I can quickly login with ssh-agent, reconnect to my screen session, fire up desktops with emacs and sessions with firefox. If my laptop dies, very little time lost. (and thinkpads are cheap so I always have two of them running - very, very little time lost.) I figure in a week or so I'll actually be used to using them.
The answer is yes; I am better off. Philosophically, I have come to the same place I came to years ago when starting my last business. I recognized that I wanted every business application I touched on a daily basis to be a web-application. Personal mobility and data integrity are worth spending time and money on.
So what happens when my server dies?
Well, my server has RAID 1 and is probably in the most reliable colo my friends can afford. Unless it gets maliciously cracked, I think it's going to stay up and hold on to my data.
However, these tools have made me a little more dependent on one particular server and an internet connection. They have also made me a little more security conscious.
Hmmm...I guess I don't know if I'm better off after all. This clearly and definitively proves that you need to read very bad haiku to put your pain in perspective:
Switch to remote work
Trading worries for worries
Emotional wash
Deposit days now?
Why tilt at crazy windmills?
silent dividends...
Synchronize, Backup
Endless server maintenance
Gag me with - - - a spoon.
No! not the next blog!
I have a better idea?!?!?.;
It hurts, I know-Yiiiiiii!
(Update: I should mention Elinks somewhere, which is my ideal reader for primarily text-based web sites. You'll want to read it's FAQ. Try it with gmail vs. any other browser and I think you will agree. Blazing fast, and no advertisements. It supports JavaScript as well. Just the ticket for a text-based environment.)
So I was at Superhappydevhouse when my thinkpad unexpectedly went into hibernation. It took me a little while to figure out that someone across the room inadvertantly flipped the switch that controlled the outlet I was plugged into, and my battery had died. The din in the room was loud enough that I could not hear it's last, plaintive beeps.
My battery was resurrected at the flip of a switch, but I lost some time setting up application sessions, so I asked around as to how people save session data in their application of choice.
While there is no way to restore the complete state of my Linux system upon a crash (a car battery to thinkpad power adapter is on my list of things to do), there are quite a few things I can do to make things less painful. Here are the best of state-saving helpers I looked at:
emacs
First, Emacs has the commands desktop-save and desktop-read.
This feature is directory dependent, that is, emacs will ask you what directory your desktop config file is in.
I have one emacs desktop file in each of my project directories now. The desktop feature doesn't re-tile your windows, but it at least brings up all the files you had open and, of course, emacs tells you which ones have auto-save data.
The single-desktop-per-directory limitation encourages subdirectories for different work modes.
screen
I don't run most programs in crappy emacs shells, I use real terminals. I need something to save the state of all my terminals. I have finally been getting to know GNU screen. Good tutorial here.
Using screens keybindings is painful. However, unlike gnome terminals bindings, they don't collide with the readline namespace. Alt-B really takes me back a word, instead of popping up some useless menu. (Update: I have since been enlightened by Eterm, and now run screen in an eterm window.)
Screen runs as a daemon and manages consoles - sort of like a text-only window manager. Obviously, it can't restore running applications after a crash. However, run over an ssh session, it will happily run whether you are attached or not, so it's a nice way to work remotely. Evidently, it can also be configured to tee I/O for multiple clients, aiding in collaborative development.
Screen encourages one to work remotely on a more reliable system; which effectively means it encourages one to have a non-production machine that is internet accessible.
firefox
Third, Firefox has SessionSaver.
http://kb.mozillazine.org/SessionSaver
Session saver is useful, but not exactly feature complete. A few things I noticed:
One, to overwrite a saved session, you have to open the session, configure as desired, right click on the saved session to delete it, and re-save the current browser state with the same name.
Two, SessionSaver actually uses a good bit of CPU.
Three, SessionSaver explicitly suggests that you save your data via WebDAV and has some utilities to make it easier to do.
More encouragement for remote work. I'm starting to get the message...
The overall hint is that I should give in and store everything on a remote server. I could use screen, emacs, and webdav/sessionsaver to store everything there.
WebDAV
I had been experimenting with WebDAV long ago, so I re-installed it on a server I have access to. My primary goal is to get this going with firefox sessionsaver. However, my secondary, more exciting goal is to get this working with the actively developed and nearly useable DavFS2 for the linux kernel. WebDav installation and usage is tangent to the omnibus remote-coding review of this article, but I *will* handle this in a subsequent article.
ssh-agent
As long as we're on a roll, lets slap on another convenience utility for setting up our sessions that I have ignored for a long time: ssh-agent. Ssh-agent helps you manage passwordless ssh logins - here is a good explanation. If you run linux, you should already have this tool, and every other tool I'm covering (with the exception of a quick SessionSaver download for firefox). This particular tool is something that is a better friend to system administrators than developers, but it *might* save me time in the long run.
am I really better off?
So now I can quickly login with ssh-agent, reconnect to my screen session, fire up desktops with emacs and sessions with firefox. If my laptop dies, very little time lost. (and thinkpads are cheap so I always have two of them running - very, very little time lost.) I figure in a week or so I'll actually be used to using them.
The answer is yes; I am better off. Philosophically, I have come to the same place I came to years ago when starting my last business. I recognized that I wanted every business application I touched on a daily basis to be a web-application. Personal mobility and data integrity are worth spending time and money on.
So what happens when my server dies?
Well, my server has RAID 1 and is probably in the most reliable colo my friends can afford. Unless it gets maliciously cracked, I think it's going to stay up and hold on to my data.
However, these tools have made me a little more dependent on one particular server and an internet connection. They have also made me a little more security conscious.
Hmmm...I guess I don't know if I'm better off after all. This clearly and definitively proves that you need to read very bad haiku to put your pain in perspective:
Switch to remote work
Trading worries for worries
Emotional wash
Deposit days now?
Why tilt at crazy windmills?
silent dividends...
Synchronize, Backup
Endless server maintenance
Gag me with - - - a spoon.
No! not the next blog!
I have a better idea?!?!?.;
It hurts, I know-Yiiiiiii!
(Update: I should mention Elinks somewhere, which is my ideal reader for primarily text-based web sites. You'll want to read it's FAQ. Try it with gmail vs. any other browser and I think you will agree. Blazing fast, and no advertisements. It supports JavaScript as well. Just the ticket for a text-based environment.)
Subscribe to:
Posts (Atom)