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


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.

No comments:

Post a Comment

Courtesy is courteous.