Working CW stations at the end of the year

I've set up an amateur radio station again this week, and worked some stations, including some friends. The transmission feeder is a temporary one, so I will disassemble and reassemble the system soon, after the new year vacation time is over.

Amateur radio for me since 2002 is mostly CW (Morse Code). CW is the most primitive but still practical digital communication form. The bit rate is about 10 to 25 bps (no kilo, mega, or giga) (that is 12 to 30WPM) and it's very slow indeed. You still can send something meaningful over CW, and it has been used for more than 100 years. See how people are using Twitter these days.

CW has already been phased out from the mainstream of professional communication systems, but it's still a viable backup, and ham radio operators still use it over shortwaves to exploit the maximum possibility of communication, to overcome the difficulties of natural and artificial noises, and significant path loss. On the other hand, the latency is minimal; only the path distance between the peers determines the delay time. It's the oldest chat system in the world.

The hardest part of CW is that you need to learn and have a lot of practice to listen to it. It's like learning another foreign language. Some eccentric people including me, however, choose this road less traveled, for many reasons.

Many old operators may find out their younger days of enthusiasm towards radio itself. And many hardware hackers will use CW for realizing the simplest but useful radio system with a pair of home-made transmitter and receiver. Whatever the reason it might be, still quite a lot of people devote themselves to CW. And I am one of them.

Working on CW is simply a good time for me. Learning for a faster CW listening stimulates my mind a lot. And CW reminds me of the very basic issues of digital communication; reliability, bandwidth, stability, latency, and practicality. The procedure of sending and receiving letters by yourself gives you more time to think.

I'm a computer engineer and scientist, and technologically CW is an archaic thing. The principle embedded, however, is still effective to be a fundamental motivation of pursuing engineering and scientific skills; to explore the road less traveled and discover the new world.

The following article of Jeff, KE9V may help you to understand why some old amateur radio operators are still enthusiastic to operate on CW: The Road Less Traveled

73 and have a happy new year 2009.

Kenji Rikitake, JJ1BDX(/3), JO3FUO, N6BDX and JQ2KST

My Influences

My influences on programming, Internet, and computer skills:

1. Tsuneji Rikitake, my father: who taught me basic math, FORTRAN, and financed my startup (of my professional career, indeed)
2. Paul Vixie and DEC NSL people: for the primary idea of firewalls and Internet systems administration, and the proper engineering attitudes toward problem solving
   
3. Daniel J. Bernstein: on re-thinking Internet protocols from the very beginning, especially on DNS
4. Bruce Schneier: for the basic philosophy and principles of security, not only for computer systems
5. UNIX gurus on Bell Labs and BSD communities: for the programming suite and styles, including C, awk, and Bourne shell
   
6. Joe Armstrong and the Erlang programming communities: for letting me know a practical message-passing-based concurrency
   

I know there are many other people I should put on the list, but I will just keep this list small.

My salutation to Chad Fowler and Kevin Smith for reminding me of this topic.

A quiet life without a TV tuner

I've been spending time without TV at home since this (2008) September. And I recommend you to do so too for living a quiet life.

I decided to stop watching TV regularly; no airwave, no satellite, no cable channel at all. Actually the condo building I live is cable-TV ready. But I decided to quit. I gave our LCD TV to my wife's Mom. We instead listen to the radio when we're at home and having a dinner or lunch and we want some news. Most of airwave TV programs are junk. And most of non-airwave (that is, paid) TV programs are also junk. And we know most of airwave radio programs are junk. But some of them, including news and classic music programs of our national broadcaster (in Japan), are fortunately not. I carry around a pocket radio when I travel in Japan to listen to the same night program called Radio Shin-ya-bin, a rather-quiet-and-calm program without ads.

We still want to see the DVD contents. We have a DVD player. So I decide to newly buy and install a new PC display instead. It accepts DVI, VGA, component and NTSC video, and even HDMI. It has 1920x1200 pixel resolution; an excessive spec for DVD or an old PC. It doesn't have a TV tuner, however. It doesn't have speakers either, but that is OK, because I installed a pair of speakers and an amplifier with AM/FM radio tuner installed. So no problem for enjoying audio.

The good thing about not watching TV while on a family meal is that we rather talk and make a lot of conversations. And we started to read a lot of books and talk about them. It's like living in the world of 1950s or 1960s, though we still use PCs.

We have also quit subscribing newspapers since this April. I decided so because even Nikkei Shimbun, let alone other papers, were carrying junk articles these days. The New York Times and The Economist have already allowed people to read their articles online freely, as other media companies follow. So I told my wife we didn't need a newspaper subscription at home anyway. She first complained, but eventually she also learned to enjoy reading something instead, or to spend the time for being exposed to mass media to something else.

We don't have any game machines such as Sony's PlayStation or Microsoft's Xbox. Our eyes can no longer follow or respond to artificial graphic pictures.

We mostly use PC to read letters and design presentations; we don't make active 3D graphics and we will not unless we need to visualize something for our works. And of course we see visual presentations on YouTube and elsewhere. The good news is, however, they are on-demand only. Unless you explicitly tell PCs to show them, you don't have to watch at those on-demand videos.

Why choosing Erlang for concurrent processing

A few weeks ago I was reading a blog article called Erlang, the next Java. While I agreed with the author's views, I felt something was bugging me in the article, which eventually lead me to write this blog article.

I didn't choose Erlang just because it's a functional language. I have chosen Erlang to learn because Erlang programming requires and has to enforce the programmers to write the concurrent code. Concurrent programing should minimize the number and size of critical regions and bottlenecks. And I think writing such programs is very difficult without the assistance of the programming language.

Many programming languages claim or plan to be capable of running a part of code based on concurrent processing. For example, Ruby will incorporate distributed storage mechanism called Roma and the task administration subsystem called Fairy. Another good example is Haskell concurrency: it is implemented as a language feature called Parallel Haskell.

I think, however, introducing concurrency while allowing programmers to write code to use shared memory will cause a lot of problems. Joe Armstrong has already described his concern on shared memory in his blog. I support his arguments; those arguments an important part of the reason why I decided to learn Erlang.

I should add another problem programmers will face when dealing with code allowing shared memory; rewriting the code for removing shared access to run it efficiently on concurrent environment will be an incredibly difficult task.

Unfortunately, most existing languages have already had a lot of code written assuming shared memory areas. For example, C code with extern variables implicitly assume those are shared between the functions in all source code files linked together. I assume I can hardly find any set of C code without using an extern declaration. I have learned that even Common Lisp has special declaration for the variables, which allows multiple functions share the same object, out of lexical scopes.

Another example of shared-memory concurrency is the operating system (OS) threads. C/C++/Java threads inherently share the parent OS process address space and environment in common. Python has the Thread Objects. While OS threads often ease implementation of concurrent servers by reducing the task switching time, the semantics is implicit and error-prone.

I understand and agree that sharing objects itself cannot be completely eliminated under the read-world constraints of processing and communication timings between programming language functions. I think, however, that programming languages should help the programmers to minimize writing code including shared memory areas, which will turn themselves into critical regions.

Erlang imposes necessary restriction on avoiding implicit data sharing between functions by:

• prohibiting multiple variable assignments in a function;


• enforcing and helping the programmers to conduct message-passing programming between functions, by not providing any implicit data-sharing facility between the functions;


• providing fast task-switching capabilities, by giving the definition that functions are the minimum concurrent execution units; and


• restricting the usage of data-sharing facilities between functions to the minimum, such as process dictionaries, ETS, DETS, Mnesia, and the global naming service shared between connected Erlang nodes, by requring explicitly writing so in the code.
  

In short, I think adding concurrent features is not enough for concurrent programming; prohibiting non-concurrent habits and enforcing writing concurrent programs are necessary as part of the programming language specifications. I believe concurrent programming under coming multi-processor environment is only possible under such a hard-liner attitude to the programmers. I feel programmers including myself are very conservative and rigid to change their sequential-programming habits.

And actually, I was one of those programmers who did not recognize the urgency of learning concurrent programming in 2007.

Programming language design and security

I suspect quite a few programming language designers just don't care about the security of the languages and the systems built by them. Maybe I'm too pessimistic, but a recent experience brought me the idea.

I was an audience at an event called Lightweight Language Future yesterday in Nakano, Tokyo, Japan. I only attended the first two sessions. The second session was a panel discussion about the programming language 100 years later. While the discussion was technically intriguing, I heard not a word about security at all during the panel. Two of the panelists (names withheld because I don't want this article to be a personal attack to them) were the principal designers of popular lightweight languages, so I asked them in the Q&A session about how they would deal with the security issues which would become more serious in the future. One of the answers surprised me; the person told me that VMware would do.

I understand virtualization in various operating system layers, including VMware and FreeBSD jail, is surely a good hack to control the damage area in the whole system to run a public access system. I think it's not sufficient at all, however, to prevent future security incidents; if a programming language is potentially vulnerable to attacks, the systems built by the language will be also equally vulnerable.

I think programming language designers are not exempted from the responsibility of (at least trying to) making computer systems secure. If I could hear more constructive ways of solving the security problems in the answer from one of the panelists, such as:

• protecting the language from the buffer-overflow bugs;
  
• preventing the garbage collector from crashing even in a hostile environment where the external attackers try to deliberately manipulate the pointers or variables to hack into the protected memory area;
  
• implementing a syntax or semantics validation system in the programming language so that the programmers can apply it to validate the external data, such as those from the network-connected users; or
  
• preventing the race condition, deadlocks, or any sort of resource starvation by the intentional or unintentional programming;
  

then I would have been much more convinced. But now I should suspect that quite a few programming language designers just don't care about the security consequences of the features they build into the language.

I don't have a definitive answer to solve the issues of unsecure systems built from unsecure programming languages. All I can write now is that a security-aware programming language will surely help making a secure system. Note that security is not just about privacy and secrecy; it's also about the reliability and fault-tolerance.

Note on 4-SEP-2008: one of my friends later reviewed the panel recording and told me that it was not VMware but VM layer that the panelist answered to me. I still think solely relying on the VM layer is insufficient for building a security structure in a programming language, though.

About myself: 1965-2000

This self introduction is a reprint of an article once posted to my own website http://www.k2r.org/kenji/ as a part of my self introduction.

---

I was born in 1965. I grew up in a Japanese urban community in Setagaya-ku, Tokyo. The whole things changed in 1974 when my father decided to go to Boulder, CO, USA for a visiting professor job at Cooperative Institute for Research in Environmental Sciences of University of Colorado at Boulder.

For the first 6 months of my American life, I didn't speak English at all. We lived there for 15 months, so I was a lousy kid speaking broken English just before when we returned to Japan. I still think the life in the USA was the best of my times. I've never lived abroad since then. I've been keeping up my English proficiency by listening to and watching English-speaking broadcasts, and reading English Web articles.

After coming back to Tokyo, I found out myself I was fatally incompatible with and just way too outspoken than other kids around.The totalitarian and socialist society and elementary schools of Japan did not and still do not accept me. They told and still tell me that I was and I am so-called contaminated with individualism and American way of thoughts. So I had to make a difference to survive.

I didn't have much advantage from the other kids, except for hacking around the radio and audio devices, writing some code on the papers (no desktop PC existed in 1975 in Japan), playing around with electronic circuits, and having no fear for speaking English. I was just a geek. My father Tsuneji bought me a FORTRAN book and a shortwave radio in 1973, the slide rules and electronic calculators in 1974, and a bunch of math books. I learned them mostly by myself.

I went to Musashi high school, a private school well-known for the liberalism. Soon I became a programmer of Apple II in 1979. My programming experience was mostly on 6502 assembly language, 6K Integer Basic, and the GAME programming language. ASCII Magazine bought my GAME-APPLE compiler in 1980 and I earned about JPY200,000 by the sales.During that time I met a lot of talented hackers. Many of them are active in the Japanese Internet R&D scene.

In 1982, my right eye was badly damaged with the retina detachment so I had to stay away from computers. I started to make techno music instead of computer programs, using later well-known techno gears such as TB-303 and TR-909, until 1986. I loved making music, but I didn't feel I belonged to the music industry. I think I made the right decision,after discovering the whole mess of the ripping-off business models.

I went to University of Tokyo in 1984 and there I experienced the harshest part of Japanese career competition. I managed to be accepted by the faculty of Engineering to learn instrumentation physics. I later studied information engineering for my Master's degree. Life in the university was no fun; hanging around with real hackers and real systems were much better.

In 1985 after NTT finally opened up the phone lines to public, I discovered international computer networks and online systems. I soon became an e-mail and BBS junkie. In 1987, I started working with Jeffrey Shapard, who was running an English-speaking system called TWICS, for the VAX/VMS system administration, until 1989. During the TWICS days I met Joichi "Joi" Ito, an English-speaking multi-talented Japanese activist.

Many hackers went for UNIX, BSD, VAX and Sun in 1980s. I was also one of the root-privileged users of a packet-radio UNIX systems, learning vi and hacking with the code. Having an account on an UNIX system was a cool thing. What made my difference was that I ported the UUPC/Extended software package for NEC's PC-9801 computers. It was a version of UUCP software,which performed automatic file exchange and email address relay between computers. And I was a licensed radio amateur (as JJ1BDX since 1976), so I made some gateway software packages linking ham radio TCP/IP mail/NetNews systems and the UUCP-based systems.

In 1990, I joined Digital Equipment Corporation (DEC) Japan, to write the core software of VAX/VMS. During that period, I had a chance to exchange messages to many Internet gurus, including Paul Vixie, a DNS guru and Internet leading technologist, who was working for DEC then. It was really nice to learn the philosophy and principles of Internet from those hard-core hackers.

During my 2 years of Digital career, I was struggling with the corporate bureaucrats, and too many overworking and commuting hours which were eventually killing me. I met Kyoko in 1991, and we decided to get together and married. She told me she had a new job in Osaka from April 1992, so I decided to move to Osaka too. I was looking for an Internet job there, and Kazuo Hirono hired me for one of his research team at TDI Co., Ltd., a Japanese software service firm. We started to build a research lab in Kyoto and the lab was operational from 1993 to 2000, also as a part of WIDE Project Kyoto NOC (POP). Hirono-san taught me a lot of things, and he was very tolerate on my rather individualistic and outspoken communication style. (Hirono-san passed away on June 2007. RIP.)

(Originally written in March 2008)

nsplit available as a Google Code project

My Erlang code nsplit is now available as a part of Google Code projects.

Link on this blog about the code is here.