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, February 26, 2015

Skating Mashup on White Rock

Chasing around in memories of progressive rock.

Looked up Rick Wakeman's White Rock and found this mashup of The Shoot and Olympic performances by Tessa Virtue and Scott Moir on youtube.

And I'm distracted by the confllicts between law, courtesy, and art. I'm sure Rick Wakeman wouldn't mind, and I imagine Tessa Virtue and Scott Moir might be pleased. Maybe.

It's the Olympics committees I'm worried about.

Courtesy is owed, but it should not be forced.

Art is art.

Tuesday, February 3, 2015

To the Girl on the Train

(One of those had-a-bad-day riffs, still not sure whether I should post it.)

You got legs.
Pretty legs.
And a skirt to show them off.

Well I can see you got legs.
It's not my business, how beautiful they are,
It's not something I wanted to know.

I got eyes.
Bad eyes.
They only see what's in front of them,
And that, none too well.

If I see your legs in that skirt you're wearing,
Is it my fault or yours?

I don't know.

Fashion, what you wreak in men!
What you wreak in women!

I was already distracted,
My thoughts gone far afield
To arcane mathematical hobbies,
And now I see your legs.

You got needs.
I can see your needs in the fashion you wear.

But I'm not one to see your legs
And I'm not one to know your needs.
Will you pardon me
If I turn my eyes away?

[Really hadn't wanted to channel ZZ Top today.]

Monday, January 5, 2015

What WordPerfect Corp Should Have Done in the 1980s (or, the Reasons They Did Not Hire Me)

A question about running Unix WP 5 on a modern Debian system brought back some ancient memories.

I was at BYU in the mid-'80s, when WordPerfect was becoming the standard word processor. I knew the guy who managed the Macintosh version development for the first several years. Took classes from one of the founders of the company. Etc.

Tried to get a job there. I was headed in a different direction than they were, so they turned me down.

One of Satellite Software International's products was a FORTH language system which I used (not very effectively) as an intern at IBM when I was recovering from a broken engagement in 1986 or so.

(Heh. As I write this, the English wikipedia page on WordPerfect has it as Satellite Systems International, which is a completely different company. The Japanese page has it correct. There's one kind of bit rot.)

My memory is that Dr. Ashton once said, in class or lab, something about early versions of WordPerfect being implemented in FORTH, and that the C code base had a lot of FORTH-isms for quite a while. (This would not be surprising. FORTH, like LISP, is structured well for text stream processing, which is a lot of what made WordPerfect such a successful product.)

If I could have gotten Dr. Ashton's ear --

Never saw Bruce Bastion on campus that I remember, but I did have some opportunities to talk with Dr. Ashton, since I took a class from him. I tried to talk FORTH and the 6809 up to him. Didn't find out about their FORTH language system product until some time after that class. This was just another example of the social, political, market, non-technical stuff going on at the time, and my studied cluelessness.

I daydreamed while doing my homework, about getting into that company and building a "WordPerfect PC" using the 6809 or the 68000. About re-writing, as I assumed, the code in FORTH, and thus making it possible for the customers to add custom modules.

About using WordPerfect and a canonical WordPerfect Personal Computer as a wedge to push a new cross-platform freedom-enabling OS based on constructing a Unix-like system on the foundations of FORTH as a run-time and library model.

I was enamored with FORTH. They were moving the code base for WordPerfect along on standard C.

-- Don't get me wrong. I like C, to play with. It's lacking in certain features to support large projects, and C++ and Java only manage to point their fingers sort of in the right directions.

-- And not that FORTH did/does not need extending to handle some of the things that C handles well. But FORTH has the extensibility that C still lacks. (And I know that extensibility is a two-edged sword, the tendencies of source code to slip away from standards. And I now have an idea how most FORTH enthusiasts have cut themselves carelessly wielding that sword)

I was interested in the cooperative and open models of software development. They were interested in capitalizing their intellectual property.

I was anxious to set up viable opposition to the Microsoft Way. They were interested in a cozy third-party relationship with Microsoft.

I do not understand why anyone would want to voluntarily enter into a relationship with either Microsoft or Intel. It was obvious to me back then, that both companies were hell-bent on pushing their (quite patently false) claims of being the standard, pushing until they had a de-facto monopoly. And anyone who knows history knows the tyranny of monopolies.

Bell Telephone was the only counter-example of a non-evil monopoly, and the only reason they kept their nose (mostly) clean was that the government was breathing down their back.

There seem to be sirens lounging and singing on the rocks of technology --

Technology can be built into systems. (Computers are the archetype of this.)

Systems are great tools for tying customer relationships.

If you can discover it first, keep it secret, get a patent, you can tie your customers to your technology and then you have a guaranteed revenue stream.

It's a siren song.

These kinds of royal grants have been the tools of tyrants in practically every age, and the wedge they form in the social structures of tyranny has proven to be the most effective and destructive tool in undoing the same tyranny.

Unfortunately, innocent bystanders usually get hurt in the wars that result, by the thousands and millions.

That's the reason the US Constitution said "limited time". Temporary stewardship over part of the intellectual and creative commons, derived from the facts of individually-implemented ambition. None of this nonsense about making property out of the social artifacts of the intellectual domain.

No one was supposed to be able to keep control of their inventions and writings their whole lives.

Otherwise tyranny results.

Well, I was disappointed that people who should have been steeped in the traditions of freedom at BYU should be taking their company right into the heart of tyrannical traditions.

And they weren't interested in an idealistic, naive fourth-year sophomore like me.

Now, who's naive?

I guess we all are.

You know, here's the whole reason idolatry is so strictly discouraged in the Bible:
Systems.

The tyrannical pseudo-religious systems that idols represent.

Until we, as a race, become mature enough to quit worshipping systems, I think God will never let us build a proper computer operating system.

Thursday, December 11, 2014

Typing in Japanese in OpenBSD

Finally got my shiny, new openbsd boxes to let me type in Japanese. It was not hard, after all.

First, I got that tablet that I have complained so much about pointed to the packages directory in a local mirror (This was so I didn't have to log in as an admin user while I browsed the web, really. Didn't have non-admin users for surfing set up yet.):
  • Choose a nearby mirror (In my case, jaist, in Japan).
  • Select a release (5.5 or 5.6 right now).
  • Select the packages directory (folder).
  • Select your architecture (in my current examply, i386, but maybe AMD64 for more modern 64 bit machines).
  • Wait several minutes for that page to load. It's a really long list.
  • Scroll down to the ja-*** stuff and read the package names.
  • Now, in a virtual console (ctrl-alt-F1 through -F4) where you have logged in as a wheel group (administrator) user, type: 
    • sudo pkg_add ja-fonts-gnu
    • sudo pkg_add ja-sazanami-ttf
    • sudo pkg_add ja-mplus-ttf
    • sudo pkg_add ibus-anthy
    as you read the package names out of that list. You'll need to type your administrator user password once or more times in the process.
And that should do the job.

[Really late update (2015.01.05):

Learn more about packages form this page:
http://www.openbsd.org/faq/faq15.html
You'll need to add an application that is capable of taking input through input methods, of course.

gedit and firefox are among the applications in the repository that will accept Japanese now.
]

(There's supposed to be a dictionary access tool, too, but I don't see it yet.)

If you want information on any of those packages before you add them, you can use the pkg_info command:
pkg_info ja-vim
Ignore the advice to mess with your font paths unless you have trouble displaying Japanese fonts when you connect to, say, NHK.

Now, you can start it by opening up your IBus Preferences in your Settings menu in, say, XFCE4. But that doesn't stick when you log out.

I'll update this post when I figure it out or get an answer on the mailing list. (I've seen some conflicting information around the internet, and haven't found something that works, yet.)

[Late update (2014.12.31):

As noted in this post to the openbsd list, getting XFCE4 to run the input method on startup was a lot "easier" than I expected. I found a post in the ubuntu forums which mentioned a Startup Items setting (in Gnome, maybe?). I looked around in the XCFE4 Settings menu and found the "Session and Startup" item.

Go to the "Application Autostart" tab in the Session and Startup dialog. Look for ibus and you won't find it. Click the add button. Add the following command:
/usr/local/bin/ibus-daemon -d
with appropriate name and comments. ("Start input method" and "So you can type in other languages", maybe?)

The "-d" argument appears to be the daemonize directive, in other words, it makes ibus a proper service, so to speak.

Adding these to .xinitrc does not seem to make any real difference for xfce4:
export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus
but they are recommended.

One more thing before you can type in Japanese, if you haven't done it yet: Log out and then back in. Notice the ibus icon now in your task bar or whatever you want to call it. It looks like a small keyboard with an even smaller globe of the world. In fact, right-click it. Select "Preferences" in the pop-up menu.

In the Preferences dialog, go to the "Input Method" tab. Select an input method (Japanese-Anthy in this case) from the "Input Method" pop-up menu, and click "Add". You have to click the Add button or it won't add the method. (I added "Japanese-Japanese", too, for some reason.)

When you close the dialog, the ibus icon changes to show a Latin "A" and a Kana "chi", which is supposed to indicate that Japanese is switched in.

In brief, for XFCE4:
  • Applications Menu=>
  • Session and Startup=>
  • Application Autostart=>
  • add command "/usr/local/bin/ibus-daemon -d"
and
  • Task Bar=>
  • Ibus Icon=>
  • Preferences=>
  • Input Method=>
  • Japanese-Anthy=>
  • Add
What that does for you in XFCE can be found with a few commands at the terminal:
  • ps wwaux | anthy # to show that the key is ibus
  • grep -R ibus  .
  • vi ".config/autostart/I bus daemon.desktop"
which reveals
[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=I bus daemon
Comment=Start ibus when xfce starts
Exec=/usr/local/bin/ibus-daemon -d
OnlyShowIn=XFCE;
StartupNotify=false
Terminal=false
Hidden=false
Playing with that should prove interesting and enlightening.

Gnome and other bloated desktop environments should be similar.

I'll try to add instructions for more minimal stand-alone window managers at some point in the future, but the key should be adding the environment settings and command to start the ibus daemon in the appropriate X11 startup script, such as .xinitrc, etc. If I can spring the time, I'll try to look at other input methods, as well. No promises, however. See what you can do with the information above.

end update]




Wednesday, November 19, 2014

Everybody Wants to Rule the World

A couple of days back, the shiri-tori request on the radio was Tears for Fears' "(Everybody Wants to) Rule the World".

I looked it up on youtube and watched the video again, trying to remember what it once meant.

There was a comment in there, somewhere, something about "those wonderful '80s, when videos didn't have to have anything to do with the lyrics."

No way!

The video was very definitely the lyrics.

"Rule the world." was a meme. But it wasn't about trying to control what other people do.

It was about doing what you wanted, even if you really didn't know exactly what it was you wanted.

Looking cool while you were at it was just extra points.

The last decade or so, we've seen a lot of "[X] Rules". This is the exact opposite.

Controlling others, making everybody else join your project, actually being king of the hill, all of that was minus points.

Ruling the world was about ruling yourself.

Saturday, October 25, 2014

The root problem with systemd (according to me, anyway).

I'm wasting too much time posting on this stuff, but I'm going to try to lay out my complaints against systemd and the way it has been induced into the Linux community.

This comes from an exchange on the debian lists, where a member of the community is asking people to help debug systemd in jessie before the release.

If I could afford the hardware to replace my netbook that is no longer portable, or even if my tablet were not locked down and legally driver-hidden, I would be dual booting and probing for bugs in my spare time between classes and while I'm on the train.
 

Not that I really have any spare time.
 

Someone asked me off-list if I were seeking absolution. I assume the question was relative to my claiming that I don't have the resources to help test.

And that seems to me to be an odd question. Why should I feel anything even approaching guilt or remorse for not wanting to jump onto this train?

But, really, why should I even want to test systemd?
That question still has not been sufficiently answered to justify Red Hat in their completely arbitrary decision to push their community (Fedora) onto this train.

I know that the fact that they did so puts the rest of the larger Linux community in an awkward position. That the debian developer community wouldn't try to find their way around pushing the entire debian community onto the same train is still a significant concern to me.

systemd is not just an init, and, as an init, it takes an architectural approach that is rather disruptive.

Disrupting the fluff end of a market is one thing, but this is not a superficial change like the ipod was in the consumer market. This goes deep to the core of the community of Linux users.

Arguments about whether the architectural changes will turn out to be justified in the end aside, the correct thing for any distribution with a broad user base should have been to make an internal fork, similar to the fork that is kfreebsd in the debian community.

Just dumping it into testing to be processed into the mainline was irresponsible behavior on the part of Red Hat management.

I know that in Fedora they have a policy of not doing forks like kfreebsd, but this was (and will continue to be) disruptive. So disruptive that, if they weren't willing to change policy and set up the separate test community infrastructure, they should have simply refused. They could have told Poettering and his friends, "No. We are not going to sponsor your shiny new vision of an OS, nor your plan to push a shim on top of Linux so you can slide Linux out and slip your re-implementation of VMS or Multics underneath."

You know, that's really not a bad idea, developing a way to get other OSses from a bit outside the Unix traditions underneath the userland applications that have sprung up around Linux. But proper engineering methods should be used in the process.

I personally think the burden should have been on the shoulders of the freedesktop.org group to set up their own distribution. And they should have accepted that burden and not been so anxious to obtain involuntary testers. And they should have been willing to listen to constructive criticism about the design of their software, even if it hurt a bit.

That was the sane way, and the friendly way. Lots of people have set up their own private spins of Linux. It's not that hard, just takes a weekend or two. There's even the Linux-from-Scratch group that will walk beginners through the steps, although we should assume Lennart Poettering, Kay Sievers, and their friends (Did they really call themselves a cabal or were they just being sarcastic?) would not need to be walked through it.

And this is really the core of the argument:

If Red Hat had been willing to do this up-front and set up a parallel distribution (maybe call it Fedora-d) where the engineering questions could be worked out and the shim they are calling an init could have been re-factored more freely when the inevitable design errors were discovered, there would have been grumbling and even a few flame wars. But there would have been nothing like the push-back we have now.

And debian would have been more at liberty to set up a debian-d similar to the way kfreebsd is set up.

And the engineering problems could have been solved with engineering solutions, not with politics.

So, why should I even want to test systemd, even though someone is attempting to push me onto that train?

If I just boot Debian Jessie, I would be testing systemd. Sure.

But I don't really know if I can boot it.

Available hardware? I have one notebook that I'm using for experimenting, an old thinkpad, 256MB total RAM, 32 bit processor, 20GB HD. It runs openbsd (XFCE) okay, although I'm still working out how to get one of the available IMEs to work. A five-year-old vine linux install was a little heavy, but it did work. It is is sitting on the borderline of the level recommended for Debian's current stable OS, Wheezy.

Is it going to be worth wasting the time to see if Jessie runs at all on that? Maybe, but I really don't want to wipe openbsd off of it to do so. I've got things I need to do with that.

Well, sure, it would be pushing systemd beyond certain limits, into functional regions where some of the bugs I expect will definitely show up, but would my bug reports get anything more than a "fix by upgrading hardware" response? Not from what I've seen so far.

One other option, I could load a stripped-down jessie on a 4G SD card and see how it runs on the old netbook with the broken screen, an almost reasonable processor, and 1G of RAM. But, again, wouldn't bug reports tend to get a "fix hardware" response?

It has been asserted time, and time again, on the debian list, that, if I am not finding bugs and reporting them, I'm at fault for the bugs that don't get fixed before the release.


If I add up the time it has taken for me to try to "comment" intelligently, and the time it will most likely continue to take, it would in fact be easier and take less time to just borrow the money to get a new netbook and start digging out the more serious flaws in systemd in my spare time, reporting them to the systemd community, and posting them elsewhere where they will be seen when the systemd community is too arrogant to deal with them (as they have been known to be in the past, see the systemd mailing list).

But
why, exactly, is it supposed to be my responsibility to contribute, when I fundamentally disagree with the direction being taken?

There are some who say that, if systemd is as bad as I and others are guessing, the defects will be made obvious through testing in as many configurations as possible. And if the design itself is fatally flawed, fixing the bugs that are found should not be trivial.

(Many of the bugs so far have not been trivial. No surprise there.)

But, remember, that's what many of us said or thought about MS-DOS, and then about MS-Windows. That is precisely the attitude that allowed Microsoft to get its de-facto monopoly.

I am not saying testing is unnecessary to prove that systemd is fatally flawed, what I'm saying is, if you are not willing to look at and deal with the flaws, testing will not help.

Okay, for those who think you are not technically inclined, who have gotten to this point anyway, how do you learn how to find the flaws?

Learn how to program. 

Don't learn from Microsoft. They'll just teach you how to line up orders that you give to machines and people, as if giving orders and getting your way were all there is to programming.

(One of these days I'll get my Programming Is Fun sites up -- at present, on sourceforge.jp, and blogspot -- but right now there isn't much there.)

One of the primary things anyone should try to understand before trying to become involved with programming on a professional basis is that there are classes of problems for which programmed solutions are not appropriate, for both technical and ethical reasons, if not for reasons involving how we define ourselves as humans.

Monday, October 13, 2014

Thinking about an Ideal Operating System Init System

Just daydreaming, here. The systemd brouhaha is not dying down, of course. But proponents keep saying, "If you don't like it, fork it."

I don't particularly want to fork systemd. The so-called sysv-init was good enough until Red Hat decided that Linux had to be "management friendly" or some such really strange goal. And decided to abandon proper engineering practices to achieve their goals.

Proper engineering goals for bringing a change as drastic as systemd into an OS is to split development. (In the open source world, that's called a "fork".) Develop the stable, existing OS and the new one in parallel, let users experiment with the new one and use the stable, existing one for real work.

And keeping the stable one means you have something reasonable to compare the new one against when looking for the root causes of difficult bugs in the new system.

No, Red Hat Enterprise is not "good enough" as a stable OS. That's their product. They needed a stable Fedora and a systemd Fedora, separate from their product. Product should not participate at that level of development. (And Red Hat really hasn't used it as such.)

But that's not what this rant is about. systemd is a bad design for any and all the functions it does. One of the biggest problems is that it tries to do way too much at process id 1.

What does systemd do? It is not just a replacement for the venerable sysv-init. In addition, it tries to enforce all the things that are "supposed to be happening" in a Linux OS. What the kernel does is apparently not enough. What the various processes in a traditional Linux OS do is apparently not enough.

Well, okay, management does not want to be entirely at the mercy of their IT department, and that's a reasonable desire.

If they were willing to learn enough information science to do their job of managing people correctly, they'd know enough to not be at the mercy of their IT departments, too. But in the real world, too many managers are scared of actually knowing what's happening. So they need bells and whistles on their computers so they can think they know what's happening.

There is a right way to do this, even though it's not the best goal. And it fits within the traditional way of doing things in Linux or Unix.

The right way to do it is to develop machine functions to support the desired management and reporting functions. In the *nix world, these support functions are called daemons.

Not demons, daemons.

Daemons in mythology are unseen servants, doing small tasks behind the scenes to keep the world running. (Okay, that's an oversimplification, but it's the meaning that was intended when early computer scientists decided to use the word.)

In computers, we could have called them "angels", I suppose, but the word "angel" focuses on the role of messenger more than general laborer. The word "service" is also not quite right because what the daemons do is the work to make it possible to provide the service. And the word "servant" would also cause false expectations, I think. Servants are human, and too functional.

In engineering, there is a principle of simplicity. Make your machines as simple as possible. Complexities invite error and malfunction. Too much complexity and your machine will fail, usually at very inopportune moments.

Computers are often seen as a magic way to overcome this requirement of simplicity, but the way they work is to manage the complexity in small, simple, chunks. Inside a well-designed operating system, complex tasks are handled by dividing them into small pieces and using simple programs to deal with the pieces, and simple programs to manage the processes. This is the reason computer scientists wanted to use a word that could, in English, by used to evoke simple processes.

This is the right way to do things in computer operating systems. Break the problem into simple pieces, use simple programs to work on the simple pieces, and use simple programs to manage the processes.

One place where the advantage of this divide-and-solve approach is in the traditional Unix and Linux "init" process. This process starts other processes and then basically does little other than to make sure the other processes are kept running until their jobs are done.

So, when we think we are solving hard and complicated problems with computers, we should understand that the computer, when programmed correctly, is usually seeing those problems as a simple, organized set of simple problems and using simple techniques to solve them one at a time, very quickly.

(There are some exceptions to this rule, problems that programmers have not figured out how to divide up into simpler problems, but when we fail to use the divide-and-solve approach in our programs, our programs tend to fail, and fail at very inopportune moments.)

Now, if I were designing an ideal process structure for an operating system, here's what I would do:

Process id 1, the parent to the whole think outside the kernel, would

  • Call the watchdog process startup routine.
  • Call the interrupt manager process startup routine.
  • Call the process resource recycling process startup routine.
  • Call the general process manager process startup routine.
  • Enter a loop in which it 
    • monitors these four processes and keeps them running (Who watches the watchdog? -- Uses status and maintenance routines for each.);
    • collects orphaned processes and passes their process records to the resource recycler process;
    • and checks whether the system is being taken down, exiting the loop if it is.
  • Call the general process manager process shutdown routine.
  • Call the process resource recycling process shutdown routine.
  • Call the interrupt manager process shutdown routine.
  • Call the watchdog process shutdown routine.
All other processes, including daemons, would be managed by the process manager process.

systemd and traditional init systems manage ordinary processes directly. I'm pretty sure it's more robust to have them managed separately from pid 1. Thus the separate process manager process.

There are a few more possible candidates for being managed directly by pid 1, but you really don't want anything managed directly by pid 1 that doesn't absolutely have to be. Possible candidates, that I need to look at more closely:
  • A process/daemon I call the rollcall daemon, that tracks daemon states and dependencies at runtime. 
  • A process/daemon to manage signals, semaphors, and counting monitors. But non-scalar interprocess communication managers definitely should not be handled by pid 1. 
  • A special support process for certain kinds of device managers that have to work closely with hardware.
  • A special support process for maintaining system resource checksums.
Processes I consider ordinary processes to be managed by the general process manager, instead of pid 1, are basically everything else, including
  • Socket, pipe, and other non-scalar interprocess communication managers,
  • Error Logging system managers,
  • Authentication and login managers,
  • Most device manager processes (including the worker processes supported by the special support process I might have the pid 1 process manage),
  • Processes checking and maintaining system resource checksums,
  • Etc.
Definitely, code to deal with SELinux, Access Control Lists, cgroups, and that kind of fluff, should be managed by ordinary processes managed by the general process manager.

Well, this is daydreaming. I am not in a position where I have the time or resources to code it up.

So, to you who tell me to shut up about systemd and make my own Linux distribution, I'd love to. You wanna pay my wages and buy me the hardware so I can?