My Best Teaching Is One-on-One

一対一が僕のベスト

Of course, I team teach and do special lessons, etc.

当然、先生方と共同レッスンも、特別レッスンの指導もします。

But my best work in the classroom is after the lesson is over --
going one-on-one,
helping individual students with their assignments.

しかし、僕の一番意味あると思っている仕事は、講義が終わってから、
一対一と
個人的にその課題の勉強を応援することです。

It's kind of like with computer programs, walking the client through hands-on.
The job isn't really done until the customer is using the program.

まあ、コンピュータプログラムにすると、得意先の方に出来上がった製品を体験させるようなことと思います。
役に立たない製品はまだ製品になっていないと同様です。

Thursday, April 9, 2009

daydreams

Okay, so I'm having trouble getting out of the daydream mode. I have to go back to work tomorrow, and I have accomplished none of the projects I had lined up for myself over the break -- drupal, finishing my shiftJIS ctype project, getting my BIF dialect of figFORTH moved to C so I can port it to whatever I use, fixing RanBunHyou and extending it for scrambles, etc.

I did almost get Drupal up on my portable. And I sort of got a start on rebooting the shiftJIS ctype project.

Too many things I want to do.

So, I'm going to list the things I daydream about here and see if that helps me get a better grip on my prioities.

So --

First big dream. Buy Apple. (Where do I come up with a cool 60 billion or so?)
  1. Bring back PowerPC Macs, starting with a dual-G4 Mac Mini. (Let's see just how much "better" Intel's core really is.)
  2. Start a line of ARM Macs, not just iPhone and iPods, but netbooks and ARM Minis.
  3. Add one more ethernet port to all Mac Minis.
  4. Start a line of Macs for tinkerers, cheap, slots for additional ports, breadboard cards.
  5. Start a line of Mac Word Processors, essentially netbooks with built-in thermal or light-weight ink-jet printers.
  6. Etc.
Second big dream. Take over Microsfot. Microsoft, I mean.
  1. Freeze all current products, except for security and other serious bug fixes.
  2. Split it down the product lines. (Some guy who calls himself joudanzuki blogged about this.) Make the APIs all open and free.
  3. Fund the Wine project and a couple of others, and add paid engineers.
  4. Start a new OS product, MSWindows Mars, based on BSD code and Wine, under whatever license Wine is under for the MSWindows interface layers, and keeping the BSD license(s) for the BSD infrastructure. But ACLs (Access Control Lists) will be an add-on. The security model will be based on the Unix model.
  5. Make a real mail system somewhat compatible with Outspook, I mean, Outlook, but designing out the intentional holes. Put the thing under a true open source license, preferably GPL, but at least as open/free as Apple's APL v. 2.
  6. Etc.
Third big dream. (My real dream.)

Start an open source computer company to compete with Apple and Microsoft.
  1. Build and sell systems with free/open hardware design, with drivers licensed under a two-clause BSD-class license so they can be used in either Linux or BSD OSses. Netbooks, home and small office NAS/routers/servers using low power processors (most likely not Intel).
Once that company is up and running, start a new OS project that would borrow significantly from Unix.

  1. The run time would explicitly separate the program flow stack from the parameter stack, and explicitly provide a hierarchical local address space access mechanism (with the means to close it off).
  2. Users in said OS would be effectively virtual systems of their own, running their web, mail, and other external resource browsers as separate (sub-)users not privileged enough to access the primary user's data space or even other browser's data space.
  3. As a benefit of the user model, secure special-purpose browsers would be implemented to access banks and share credit information with stores, etc.
  4. Said OS would need a CPU that would cache the stacks efficiently and efficiently implement the address space separation in hardware, so I'd need to design a family of processors optimized to that kind of run-time.
  5. I'd need to build a language back-end that would take advantage of the OS, run-time, and CPU.
  6. And then build various front-end languages, post-fix, in-fix, and pre-fix. (Yeah, I like FORTH and C.)
  7. Etc.
And while I was balancing those two projects, current information encoding schemes are really messy. That's okay, but the URIs and other stuff that computers process need an encoding that is less ambiguous. So,
  1. Design a new standard for information encoding that would have an international encoding and international display/parsing context for use in things like URIs, and include most of the current encodings shifted, so that you could work with just about any language in its own context and not fight the production rules of all the other languages.
  2. It would also include a binary encoding, so that burying binary data would be less of a problem.
  3. And it would include separate tag characters so that parsing tags would not be such a headache.
  4. Extensible IP type addresses would also be defined in the encoding, although I suppose it's too late to replace IPv4 and IPv6 with extensible IP addressing. High-bit extension could be used, although it would require re-possessing most of the current IP addresses. Another possibility might be to start appending the internal, NATted addresses to the router address to get longer addresses, although that would require some standards beyond NAT to allow nested addresses to be physically independent of the router.
  5. Something like ASN.1 would be built into the encoding, as well.
And while that's eating my lunch and taking more time than a guy my age can manage out of every day, I'd set up a personal data service that would provide e-mail and web sites with a few more guardrails than we presently have. Specifically,
  1. Customers would have their own domains, and the personal data server would provide dynamic DNS mapping, so that the customers could even run their own domains on their own servers if they chose to do so.
  2. Customers would by default be routed IPv6, although I would prefer to use an extensible system, now that the processing resources are available to support an extensible numeric (index) addressing scheme.
  3. A mail system that would take advantage of the customers' private domains, to allow them to define their own mail addresses as they choose. This would help with spam problems, because the customer could even make up new addresses on the spot for new contacts, then go home and register filters for those addresses, and know who is trying to do what with his or her personal information.
  4. An on-server mail viewing system that assumes that the user wants to sort most of the mail before looking at it, and lets the user sort based on header and envelope contents, setting up persistent sorting rules that would, for instance, send all posts with variants of "viagra" and the like in the subject or sender headers to a folder labeled "fraudulent medical ads", and so forth: select the text, right-click for a list of context elements to trigger on, left click to commit the rule, and the sorting rule remains in effect until the user edits it. And the destination folders have rules like, hold one week and then dump, or dump oldest first when the folder hits a limit on size or number of messages. (Google mail does get close to this kind of thing, but, yet, not so close after all.)
  5. Web sites are where I get lost, but the point here is to refrain from restricting the knowledgeable customer, but not expose the less knowledgeable customer to the dangers of letting machines be their proxies. Domain management for customers hosting their own, web hosting for customers who want that, and bulletin boards and blogs for customers who want that. Google already does this one, pretty well, given the technology that's available to them.
Looking back on that, Apple and Microsoft are responsible for their own problems. So I really don't benefit from daydreaming about fixing their problems.

The web services companies, if the technology were available, Google, Yahoo, etc. would be able to do the things I'd like to do. The only issue is whether we can get the ISPs to quit trying to hold domain names and IP addresses for ransom, but I think competition would eventually take care of that.

The biggest problems are
  1. that the underlying information encoding is too cluttered by kludges to efficiently process in the way we need to get this kind of stuff to work,
  2. that the run-times of the various OSses are too cluttered by kludges and cruft from technologies that lead in other directions,
  3. that the programming languages we have are at once too inflexible in expression and too loose in semantics to support the kind of systems I'm trying to describe here.
  4. I'm not sure whether the current crop of CPUs can efficiently run this kind of system. I'm pretty sure the Intel CPUs have too much cruft, and not enough memory support for efficiently managing memory. Most of the other CPUs are oriented towards the limited execution model that the 8086 supported too efficiently, too, as a result of having to compete in a market where the 8086 was seen as the leader.
Hmm. Do I see anything in the above that would help me weed out daydreams I can't or shouldn't reach for, but leave me something to work on?

Can't say that I do.

value vs. price

The news on the radio this morning seems to be about a big data spill from Mitsubishi-UFJ or whatever's investment. (I'm thinking, I'm glad we don't bank there, then I remember, ...)

I was reading a lot yesterday, cleaning up old stuff, scanning some newspaper articles for possible use in classes, and I notice a theme -- the war on drugs, the war on terror, it's all driven by a disparity in price and value.

Most private data is of perceived value precisely because people protect it. The rest is only of value to the people who protect it. Well, if I take you down that path, you'll scream "Transcendental!" and run away.

Hmm.

Let's see. Sure, spam is a problem in your mailbox. It clogs the internet and wastes a lot of energy and a lot of user and administration time. It draws people into wasting their money and, in many cases, putting themselves at risk.

It took several years to train myself to recognize and delete the bad-ads, and I don't want to claim that I don't regret the time I wasted on that. But the primary problem was/is that I, like most people, am still a little susceptible to the lure of the quick fix.

Yeah, it's easy to get lost in a daydream about what I'd do if I won the lottery. But I'm getting pretty good at reminding myself that I just don't play the lottery, and you don't win if you don't play. Then I can ask myself what I really want to do, what is it that is distracting me from whatever job is in front of me?

After a little bit of thinking, I remember that the primary things I want to do, I have the means.

I don't need to win a lottery and start a company that sells just machines pre-loaded with a Linux or BSD class OS, even though it would be nice to have more such companies in the world. It would be fun, but it isn't the project I need to be working on.

Yeah, I'd like to have an ARM Kurobako to load openBSD on and run as my home server, and free up the Mac Mini for my kids to play with. But, again, my kids don't need to think they are free to load any web page that looks interesting, and I have another project or three that need my attention first. When/if I really need to get Drupal running on my home server (and therefore need to separate it from the family Mac), the Lord will help me get an appropriate server.

It's basically the same with drugs, pornography, private data, etc. Sure, I'm not invincible, but if I get uptight and do unreasonable things to prevent others from doing whatever they are doing, that raises the perceived value of whatever it is they are doing in their minds.

Like the kid in class who insists on disrupting. The more you try to prevent him from doing so, the more attention you're giving him, and the more he thinks that, even though your words say it's wrong, what he is doing is in some hidden sense "right".

What is the reason for the door lock on your car. Is it to prevent theft?

No.

It is to declare that the car is not public property.

If the society in which you and your car exist do not recognize private property (think, slums), the lock does no good. Period.

The real thing that protects your car is that its perceived value is lower than the hot car down the street. Well, the perceived value, less the trouble the potential thief has to go to.

So-called "speed bumps" really are useful, when used correctly.

So, what does this have to do with private data?

Maybe it has a bit to do with one reason why I wouldn't really want to win the lottery, even if I did play it.

The real key to security is to refrain from having things worth the trouble of taking.

Drive used cars, carry a used notebook PC.

Sure, use a password to keep the speed bump up, but don't put important information on the PC you carry around. (Leave it in the office, where it belongs, really.)

Don't use the internet for financial transactions, unless you have an account you can afford to lose money from every now and then.

(Yeah, one of the projects I have on a back burner somewhere is a dedicated internet terminal that could be safely used for on-line transactions, if the stores and banks would cooperate, but even that is relative. It would be more secure than what we currently have, but not unbreakable. You still would not want to regularly access your retirement fund with it.)

Tuesday, April 7, 2009

drupal on apple

I was going to install drupal and play with it, see whether it would save me time and otherwise help on my personal website.

Yeah, right. Maybe on a current system, 10.4 or 10.5. I have reasons for trying to install drupal on an iBook running Mac OS 10.3, but, right now, rather than explain to the world why, I want to record what I did and where I ran out of time. (This is from memory, I'm probably forgetting something.)

Drupal can theoretically run on the stock apache+php on 10.3. PostGreSQL seems to run fine, so I should be able to run basic drupal functions.

But there were some critical security issues with both php and apache between the latest updates available from Apple for 10.3 and the latest versions of both php and apache.

Well, the notebook is not a production server, and is generally behind a firewall not configured to show it to the web, so I really don't need to be that concerned about security. (Oh, yeah?) But, I'm installing stuff anyway, and I've become used to the idea in the open source world that there are often less bumps if you go ahead and use the latest versions applicable.

So, I tried installing apache 1.3.41 over the system version. I thought about parallel installs, the way I do with perl, but I looked at all the tweaks I'd have to do to php, and balked.

So, after backing up /usr/libexec, I downloaded apache 1.3.41 from apache.org, unpacked it in a local build directory, read the READMEs and the INSTALLs,

cd ${my local build directory}
gnutar czvf libexec_httpd_old.tgz /usr/libexec/httpd
cd apache_1.3.41
./configure [bunch of arcane parameters that weren't what I wanted]
make
sudo make install

and mod_rewrite bit me. Could not get a valid copy of the re-compiled mod_rewrite to install to /usr/libexec/httpd. More reading, and I discovered that, for some modules, the make file seems to want you to say,

--enable-module=mod_xyz.c --enable-shared=xyz

That effectively doubles what was already a lot of typing arcane parameters anyway.

Deep sigh.

Next place I got hung up was mod_hfs_apple. It is compiled outside the apache source tree, so I had to figure out how. Late last night, with my mind buzzed by lack of sleep, I tried the obvious thing. (Well it was obvious last night, after re-discovering where Apple puts the source for Darwin, not so obvious yesterday afternoon.)

I downloaded the apache_mod_hfs_apple-5 tarball from Apple's darwinsource for Mac OS 10.4.11 archives, unpacked it in the local build directory and, after reading more and just trying configures and makes in various places, I downloaded apache from Apple's archives, as well. They have apache 1.3.41 in the archive directory for Mac OS 10.4.11, as well as in the latest directory for 10.5, and it is buried in a directory containing some (but not all) of their customization work. For some reason, I got the one from 10.5.6. (Late at night, you see.) I'm not sure whether that caused me the problems that have me stumped right now.

cd ${my local build directory}
gnutar xzvf ${my downloads for 10.5}/apache1-697.tar.gz
cd apache1-697
ls

hmm. There is apache_1.3.41.tar.gz sitting there. Okay,

gnutar xzvf apache_1.3.41.tar.gz
cd apache_1.3.41

and I looked around for a few minutes.

./configure [tons of arcane parameters]
make
sudo make install

and, of course, it's not quite there.

cd ..
make
sudo make install

and now I see something that raises my eyebrows: apxs-1.3?

After nosing around the net, I decided to just go into /usr/sbin and

ln apxs apxs-1.3

No, this was not last night, it was this morning. My mind is not as clear. After more fussing around with make files and such,

cd ${my local build directory}/apache1-697/apache_1.3.41
./configure \
--with-perl=/usr/local/bin/perl \
--server-uid=70 --server-gid=70 --with-port=80
--disable-shared=vhost_alias --disable-shared=env \
--enable-module=log_config --enable-shared=log_config \
--enable-module=log_forensic --enable-shared=log_forensic \
--disable-shared=mime_magic \
--enable-module=mime --enable-shared=mime \
--enable-module=negotiation --enable-shared=negotiation \
--disable-shared=status --disable-shared=info \
--enable-module=include --enable-shared=include \
--enable-module=autoindex --enable-shared=autoindex \
--enable-module=dir --enable-shared=dir \
--enable-module=cgi --enable-shared=cgi \
--enable-module=asis --enable-shared=asis \
--enable-module=imap --enable-shared=imap \
--enable-module=actions --enable-shared=actions \
--disable-shared=speling \
--enable-module=userdir --enable-shared=userdir \
--enable-module=alias --enable-shared=alias \
--enable-module=rewrite --enable-shared=rewrite \
--enable-module=access --enable-shared=access \
--enable-module=auth --enable-shared=auth \
--disable-shared=auth_anon --disable-shared=auth_dbm \
--disable-shared=digest --disable-shared=proxy \
--disable-shared=cern_meta --disable-shared=expires \
--disable-shared=headers --disable-shared=usertrack \
--disable-shared=unique_id \
--enable-module=so \
--enable-shared=setenvif \
--add-module=/local/build/apache_mod_hfs_apple-5/mod_hfs_apple.c \
--enable-shared=hfs_apple
make
sudo make install
sudo /usr/sbin/apachectl start

And no go. Now it's hung up on mod_rendezvous_apple. So I go looking around for a more recent apache_mod_rendezous_apple on darwinsource. Nope. Download mod_bonjour_9 from the Mac OS 10.5 archives and try compiling. Lots and lots of errors.

Download apache_mod_rendezvous_apple-8 from the Mac OS 10.3 archives. Just a few link errors, and I might have a hope of actually finding a way to clear them. But I have other things I wanted to do today. I don't really need mod_rendezvous, I think. So I disable mod_rendezvous in httpd.conf and go back:

cd ${my local build directory}/apache1-697/apache_1.3.41
./configure [the list above]
make
sudo make install
sudo /usr/sbin/apachectl start

And apache tells me it started successfully. I suppose I could have used the apachectl test command. Anyway,

sudo /usr/sbin/apachectl stop
cd ..
make
sudo make install
sudo /usr/sbin/apachectl start
sudo /usr/sbin/apachectl stop

And that is how I got apache 1.3.41 on this iBook running Mac OS X 10.3.9. I think it will serve for my development work, but I'll tell you. This is one of the huge reasons I want to leave Mac OS behind and switch to Fedora full time.

The reasons I don't switch now?

I need some time to read up on loading the binary blob to the wireless card. --Bleaugh-- Stupid hardware companies that still believe in security through obscurity.

Trackpad. I need to figure out how to unset some "advanced" behavior for the trackpad and find all those notes that I can't find any more on setting up right-click emulation.

ClarisWorks/AppleWorks. I'm using draw documents with embedded spreadsheets (with randomized lists), and, last time I looked, iWork is not quite there yet.

MSOffice? Are you kidding? Microsoft has no idea how to do this stuff. They just don't know how to get out of the end-user's way any more.

One of these days, I hope to be able to figure out how to load java extensions to openoffice, and maybe then, but openoffice basically inherits the clumsy interface from MSOffice. (Quoth Bill Gates: "Let us help you do things the MS-OUR-WAY!")

I suppose, if teaching English paid enough to squeeze JPY 200,000 out of a year's wages, I'd go for a new Intel macbook and appropriate software, or even the macair or whatever that is. (A light-weight portable would ease some of the stress on my back quite a bit.) Maybe. I prefer AMD or other non-Intel on principle, if I have to put up with x86.

Or, I could spring $300 for a family pack of Mac OS X 10.4 original install CDs from some dubious internet company, and keep using AppleWorks. Or I could get new dictionary software and finish re-writing ranbunhyou to run on Mac OS X and get Mac OS X 10.5 on this iBook for a bit less. Or something.

I have something else in my queue now. Hopefully I'll get back to Drupal later.

Wednesday, April 1, 2009

A Parable of Drive-in Banks and Cars

Well, okay, this isn't really a parable. Parables come from the real world, and this analogy comes from an alternate universe.

In this world, there is one major automobile manufacturer. It sells more than 80% of all cars. It also sets a bunch of implicit standards relative to the way cars are built and used. For instance, all cars have a driver's-side window at a specific height, of a specific size and shape, to match drive-in service facilities, and all drive-in service facilities are built to match the standard driver's-side window.

Moreover, all drive-in service personnel are trained, and required by law, to only serve windows of the standard height.

The reasons for this standard are said to be safety and efficiency, but there is one other reason that over-rides the rest. The window also has a special encoded certificate in it that identifies the person who is authorized to drive the car. This certificate, of course, is hidden, so that the casual thief won't have an easy time of copying it.

The certificate was originally intended only for banks and other financial institutions, but they proved so convenient that even the fast-food industry has taken to using them. They weren't supposed to be trained to read them, but you know how it is with secrets.

Besides, it provides another revenue stream for the banks, to handle the money for other drive-in services automatically. It's considered a win-win situation.

This works for a little while, because the "bad guys" go along with it for the most part. They knew that they could get away with copying only a few certificates and using them only occasionally. The banks and other companies are insured, so the customers don't lose money, and if the bad guys don't steal too much, nobody gets overly concerned.

But, just like in this world, not all countries are created equal in our alternate universe. And there are some countries that, because of war, or graft, or by tradition, or other reasons, have a large number of people who have no prospects of finding work, and very little access to the charity hand-outs.

These people have grown up without the traditions that would help them plan ahead and not steal too much. So, now, suddenly, certificates are being copied all over the place, and the insurers are losing so much money that the economy is threatened.

Okay, it's not a really great analogy. Don't try to push it too far.

Sunday, February 15, 2009

undun

On the train to work the other day, I was reading the headlines about the economy and, for some reason, the song Undun was playing in my head.

It's too late. She's gone too far. She's lost herself.

She's come undone.

She found a mountain that was far too high.
And when she found out she couldn't fly.
Mama, it was too late.

It's too late. She's gone too far. She's lost the sun.

She's come undone.

And so forth.

Memory is not nearly as accurate as digital recordings, and there is that thing about "she's lost the sun," or "she's lost herself." Either way, the American Woman's come undone, and the reasons are listed in the song:

Looking for truth in lies.

Not knowing where she was heading.

Too many mountains, and not enough hills. 

Okay, stairs, the metaphor still works.

Too many churches ...

Okay? The Church of Microsoft, The Church of Wallstreet, The Church of Automobile Manufacturing, ...

Too many people around her unwilling to see that when she comes undone, the rest of us do, too.

Too many lives people want to lead, and too much getting toys that make it possible to pretend to have lived them, without the time to do it right.

I think it's that last one that is really killing us. We have to slow down.

(Speaking of toys, I used my iBook to record me doing the song unaccompanied. Hopefully I can get a chance to upload it to youtube, so you can torture your ears.)


Saturday, November 29, 2008

winning the war against the spammers

As I write this, the volume of spam in my e-mail accounts has dropped drastically. A couple of ISPs have cut certain of their customers' access to the 'net.

Colocation is supposed to be pretty neutral, but when your customers are sending commands to 'botnets from serveres you are colocating for them, you eventually know what's going on, and your contract does allow you to quit co-locating for them, and even turn their servers over to the police. And if you don't take action, that makes you an accessory to the crimes, so the ISPs that supply your connection are within their rights to cut you off.

So, two levels up, but the co-locators were cut off. Without the command centers, the 'bots don't know what to send to whom, and the volume of spam drops. Until the bad guys find another patsy to host their command centers. Only, this time, they'll find legitimate fronts, spread their command centers out, and so forth.

Junk e-mail is kind of like drugs. The only way we'll win the war against drugs is to quit buying them, quit using them. That means the war is won or lost, one person at a time.

The only way to win the war against junk e-mail is to refrain from doing business with them:

(1) Refrain from sending them e-mail (and thus confirmation that you are reading their illicit advertizing channel).

(2) Refrain from clicking the "Don't send me any more!" booby-trap buttons. (Yeah, right, we won't send you any more! hyuck, hyuck.)

(3) Refrain from clicking on the link to the "hot pictures". (Look at the url blank in your browser next time. See that code on the end? They look that code up in their database, and they know what address the mail was sent to. That's your address, you see?)

(4) Don't even look at the mail if the sender and the subject are obviously spam. (Forget sender notification. IFRAME leaks, anyone? Besides, if you don't look, you won't be tempted to buy, or even to look some more.)

(5) Oh. And never, never send them money or your credit card number or bank account information, etc. Don't send them anything. Not if they promise your next night of love-making will be more fulfilling. Not even if they promise that they have lots of money to give you for reason X, Y, or Z. This is organized crime you are dealing with.

You can win the war for yourself, and then you can encourage your friends to win the war for themselves.

I know that what I am proposing may be easier said than done. Maybe you aren't susceptible to letters that start out, "Dear sir or madaam. I am your long lost friend/relative/employer's ex-husband's cat's manicurist/prince-of-some-vaguely-familiar-sounding-country and I have lots of money from our mutual friend/relative/veterinarian/politician/whatever that is legitimately mine, but I can't get at it because of the weather/wars/economy/fleas on my dog and I need your help."

Maybe you are inoculated against that kind of scam. Maybe designer shoes or rip-offs at bargain prices do nothing for you. Maybe you have no fears about your love-life, or at least are well aware that a pill that may or may not make you sexually excited can't solve your social problems. How about expensive wrist-watches? Or the slightly odd, but maybe-not-so-really-terrible mail list that you suddenly found yourself signed up on?

In a sense, you have to get in touch with your conscience, have to develop a good sense of reality, have to get to know your God in order to tell which mail is legitimately worth looking at and which is not. Of course, now I'm making it sound really hard. So let's talk about it a different way.

What we are talking about is setting up filters in your mind:

(1) Check the sender. Do you recognize the sender? Family? Friend? Co-worker? Someone from Church?

On the other hand, do you recognize the sender as a source of stuff you didn't ask for? You know what to do with that.

(2) Don't recognize the sender, so check the subject.

v1A6or@ is not something you want a special price on, okay?

Free nude pictures of that famous hotty? If there are pictures at the site linked, you can be really sure that they've figured out a way to make you pay without you realizing it until you're out a bunch of money. Besides, she/he is not that hot, really. Not hot enough to expose yourself to even more spam.

And, no, you are not interested in letters that promise to tell you how totally awful the current president or president-elect or the last candidate of the opposition party really is.

Nor are you interested in good deals on designer this or that, credit cards or just credit or loans, or basically anything when you don't know the sender.

(3) Vaguely familiar name and a "Long time no see!" or something similar? That one may require looking at. There is a risk of IFRAMEs or similar ways to leak the information that you looked at it, but once you've seen the mail itself, well, a fuzzy GIF with stock prices or something is also not going to give you useful information. You do understand pump-and-dump, don't you? Nor is a cry of "I'm lonely!" from a girl or guy you don't know going to be legitimate, romantic movies notwithstanding. Most likely the picture is used without permission and the real sender is an ugly man or woman who wants, at minimum, to see if your e-mail address is valid. More likely, he or she wants your bank account information.

I should mention again, by the way, that giving money to criminals often makes you an accessory to their crimes. You do not want to do that.

(4) Sometimes, the sender name is one you really think you recognize. But if you look at the raw source code, you can usually see that the real sender is something else.

Now, if you can do that kind of filtering in your head, why can't we just set e-mail software up do that for us?

Well, we can, sort of. The problem is that the spammers know that, so they use little variations to get past the software filters. (Thus the v1A6or@, instead of viagra.) The automatic filters tend to catch more than you wanted them to. (This is what they mean by "false positives".) And then the automatic filters tend to dump all the probable spam in a single folder, so scanning through the positives for the rare false positive is only mitigated by the fact that you now know that almost all of it is stuff you don't want to see.

The automatic filters would be more effective if you could directly train them. For instance, if you could select a word, phrase or url in the sender, subject, or content fields, and click a "This is spam." button, the software could even make a folder for stuff that has that word, phrase, etc. in it. Scanning through a folder that contains mostly similar spam is going to be much more effective than scanning them all together. It also should reduce the false positives, because the guesses the software makes are more restricted in context.

There are other tricks, trap addresses, door-knocking mail addresses, and more. I wish I had time to program such a mail filter, but I don't seem to have that much time. And I have too many other interests, too.

Friday, August 8, 2008

Looking Back to Go FORTH

A long, long time ago, back when dinasour mainframes roamed the earth, I was fresh back from my mission to Japan, trying to figure out what all LDS young men just back from their missions are trying to figure out: What do I do now?

But this little rant is less about that and more about one of the things I did. My brother, out of the kindness of his heart, gave me a 6800 prototyping board, I think it was the micro-chroma 68. Basically, it was the Radio Shack Color Computer, but with a 6800 instead of a 6809, or even a 6801. Okay, it was a 6802, but that was just a 6800 with some built-in RAM and ROM.

It's about 4000 miles away, so I can't post a picture, but that's okay. This rant is not so much about that piece of kit, either.

My brother dug up a ROM BASIC somewhere, but I wanted a better language. One of the teachers at the community college suggested FORTH, so I wrote off for the fig-FORTH model implementation for the 6800. The printout did not contain the object dump, so I had to go through the entire assembly listing and add the op-codes that had been abbreviated in the listing. I really did not think much of hand-assembling code at the time, writing it down seemed like more work than looking up the op-codes.

[I once had the insane urge to actually transcribe the source for that 6800 fig-FORTH. For a while, it was linked at forth.org, but they seem to have removed the link now. You can find it in the appropriate sub-directory of my 6800 assembler. Joel -- 2015-03-28]

I was silly enough to not build a floppy disk controller, but I did build a fast cassette tape controller, which was a little bit more reliable than the built-in 300 baud cassete tape controller. So I had some place to store the results after I typed the the entire model in in hexadecimal code. How long did it take? Don't remember, but it did seem like a long time, when I had friends and teachers playing around with the original IBM PCs, Apple ][s, and the like. Not to mention the time I wasted at Radio Shack playing around with the Color Computer demo models.

I don't think I can explain why I didn't just save up the money and get one of those Color Computers, with disk drive, etc. It sure would have saved me some time.

I think.

I played around with the FORTH, worked out the examples in Brodie's Starting Forth, as far as I could without disk drives. The dRAM was actually 64K, and I used a bit on the parallel port to toggle between banks, but I didn't really have the experience to figure out how I could usefully emulate a (very small, very volatile) floppy disk with it. So I was a little stuck on the disk examples. Also, the model provided hooks for implementing multi-tasking, but no actual implementation, so I wasn't able to play with that.

But I did learn enough FORTH to make me very impatient with other languages.

Fast forward to to when I got my associates and transferred to BYU. Found myself at the end of the BS-CS coursework with three class left, the one where you write a simple compiler, the one where you write a simple OS, and an elective. I was still spoiled by FORTH. (Maybe I still am.) Could not resign myself to stupidly hashing through simple closed algebrae and playing stupid register allocation games when I "knew" there was a better way. Kept trying to synthesize something useful from the two diametrically opposed approaches to computer languages, without the experience to know where the boundaries of object orientation were, to see where the difference between closed mathematical objects and infinite tape were always depositing me during my design attempts at random places in my own undefined memory.

Hey, I'm stronger for it. Right?

Anyway, those were my first flunked classes. I had, actually, a low A average to that point. Fortunately, BYU allows you to repeat classes. I took on the OS class first. Finally got up the courage and the wisdom to invest enough money to buy a Color Computer on sale, with Radio Shack's recommended cassette deck. (Yeah, I know about store recommendations, but it was also on sale. I could have saved another five dollars, but I'd have wasted a day running around.) Wrote screen routines and keyboard routines and time routines, and whatever else I could to pass the class.

The elective I chose was software tools. I went ahead and bought a disk drive and Radio Shack's disk-based assembler package, and implemented FORTH on the Color computer's 6809.

Actually, I got OS-9/6809 before I got the more basic assembler, and tried to do the FORTH in the OS-9 assembler, but found myself fighting with trying to make a relocatable FORTH, without fully understanding that I was effectively trying to define an i-code without actually pinning the codes down to specific values.

No, actually, I really did figure that out fairly quickly, but I just couldn't reconcile myself to the solution, you know, the one that put a 64K code limit on classes in early versions of Java -- Make the i-codes an index into an array, put the actual pointers in that array. Cry when you run out of array. Or not, if you never compile that many words.

One other option might have been possible, using self-relative i-codes. Needless to say, Microware's assembler would not assemble such a beast. For some reason, I declined writing an assembler that would. OS-9/6809's pre-ANSI C compiler might have been one of those reasons, or maybe I was just too lazy.

You have a similar problem when you try to use raw C language function pointers as i-codes. Most modern OSses relocate by keeping a list of addresses that need to be fixed up when the code is loaded. You can't help filling borked when you have to implement your own fix-up on an OS designed not to be fixed-up, and the fix-up table is as big as your object.

So I dropped my attempts to do it in OS-9, and went out and got the more primitive assembler software and worked with that. That way, I didn't have to think about relocation issues.

Once I had a simple enough implementation environment, the port was fairly straightforward. Or it should have been. First, assign the virtual registers of the FORTH model to real 6809 registers:

The return stack pointer, RP, was the 6809's call stack pointer, S.

The parameter stack pointer, SP, was the 6809's user stack pointer, U.

The i-code instruction pointer, IP, was the 6809's Y index, but I would sometimes save it off temporarily when I needed two index registers.

I put W on the top of the return stack, if I remember right. A little weird, but it was out-of-the-way, and still accessible.

You might think I'd use DP for the user variable pointer. But that sure was an awkward idea, DP being only the top eight bits. I ended up putting most (all) of the headerless primitive words in the DP and using DP relative jumps to get there, which was not a good idea, either. Oh. I also put the user variable pointer in the DP, too.

I designed the symbol table structure as a nested binary tree instead of using the more typical hashing techniques. That facilitated a certain amount of information hiding, for modularity and other object-ish behaviors.

Then I wrote the primitives, the inner interpreter, the basic parser, the symbol table lookup, the basic math. At a certain point, I had enough primitives that I could have finished off by just typing in the rest of the fig-forth high level model's compiled form. But the teacher wanted to be sure I was not just copying, so I re-wrote some of the stuff where it looked like 6809 object would actually be smaller than the high-level object. Used a kind of stupid-code-trick approach to shifting between high-level object and 6809 object on the fly (mostly stupid because shifting gears is not really a good idea, other than showing the teacher that you understand what it's doing at some level.

Once I had the 6800 model converted to 6809, with my modifications, I copied the fig editor source into a screens disk and had a running system. Source code was about a hundred 60-line pages, the object a bit fatter than I had expected, just over 8K if I remember right.

Then the teacher asked me to document every word in the model, so I did that. By hand. On paper. Don't know why I did it by hand, on paper. I later typed it into a text file, and that is also a part of the download on my site, linked again here, in case you missed it above. (Just what you always wanted, wasn't it?) All of that took me about six months, working pretty much full-time on the project. (Thanks go to my parents for letting me live in their attic for a while.)

[My personal website is now off-line until such time as I can afford $20 a year or so to pay dyn.com or someone else to resolve the url for me on an on-going basis, I guess. See the bif-c link below, and look in the appropriate subdirectory for the source code. -- Joel 2015-03-28]

I ended up passing my compiler class with a compiler written on that FORTH. So my education was all FORTH colored. Maybe that's why I just gave up on the industry about two and a half years ago. Maybe I can do something about it [link added 2 May 2011] while I'm taking a break.