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.

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

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?

Sunday, October 12, 2014

Two Posts on the /usr Merge Relative to systemd That Were Filtered on debian-user

The debian-user list is not moderated, but sometimes they shut down threads that get out of hand.

I responded to two posts on a thread on the topic of the /usr merge, but my posts never made it to the list. I'm feeling stubborn, so I'm posting my posts here. But I don't want to mess with copyright issues, so I'll paraphrase what Hans and Jonathan said instead of quoting them.

I include links to their posts in the archives so you can decide if my interpretation of their posts is accurate.

[Now that I have the thing posted here and look back over it, I don't think I've interpreted Jonathan's post correctly, and I think I've dragged my responses out waaaaaay too long. (Leaving this here in case my posts ever make it through whatever tarpit the debian list server sent them to.)

Short version: So what if the recent /usr merge being pushed by the guys who bring us systemd is just another in a long line of attempts at removing a poorly understood organizational division? So what if we have big hard drives? 

The solution is not to abandon efforts to organize things. Rather, we should take a clue from such projects as Gobolinux (They aren't the only ones.) and go in the other direction -- even more separation. 

You should only read the following if you have time to waste.]

================================


(1) systemd and initrd and /usr [Questions by Hans.]

--------------------------------
Warning -- I do not use systemd.

> [Asking how to mount /usr and /usr/local to initrd]

I'll leave that for someone else.

> [The problem involves a mapped, encrypted /usr partition. There is a question as to why systemd requires /usr and /usr/local to be the same directory, flying in the face of traditional unix practices of putting important directories in their own partitions, with the comment that the tradition is as old as SCSI disk drive technology. Concern that systemd is intended to sweep away the traditionalprinciple of partition separation.]

Partially [I mean, about changing the partitioning practices]. These might help:

https://news.ycombinator.com/item?id=3519952
http://wiki.gentoo.org/wiki//usr_move

You can find more by searching the web for things like "/bin /usr/bin merge" or "/usr merge".

(For me, it's a very depressing tale, the lame leading the blind, and all of us being dragged into the ditch, so to speak, but that's supposedly my personal opinion.)

> [And what about /var and /home ?]

They weren't stupid enough to require /home in the same partition.
/var, I'm not sure about. [After checking, yes, /var can also remain separate, with some caveats.] Some of what I read indicates that when they were slapped in the face with their idiocy by the problems of logging when /var couldn't be mounted, they chose to ignore reality. Which is just as well, since they now aren't trying too hard to force everyone into the world of one big partition.

> [Request for explanation of reasons and methods.]

I'll leave that to someone who agrees with new policy.

==========================


(2) systemd and initrd and /usr [Response by Jonathan.]

--------------------------------
My reply to Hans didn't make it to the list. Wonder why. Wonder if my comments on Jonathan's response will make it. [Neither have made it as I post this.]

>> [Question about /usr and /usr/local and primary directories being mounted  separately, see above.]

> [Assertion that something about the portrayal of separation as traditional was wrong.]

I'd say partially wrong. Or partially right concerning some, less right concerning others. At least, I think Hans is talking indirectly about the sizes of hard drives.

Anyway, there were many people involved and they were not all doing the same things at the same time.

> [Assertion that the /usr split was derived from diskspace limitations.]

Or something. People like to organize things for some reason, and sometimes they use incidental divisions as their organizational dividers.

Consider the tendency during the '80s to try to use the accidental segmentation of the 8086 to organize software in a sort of modularization. Of course, if you didn't happen to be in the management sessions where this was promoted as a "feature" of the 8086, and/or the later sessions where the use of long pointers had to be explained, and/or the debugging sessions where coders tried to explain to managers that you basically had to load both parts of the segmented pointer on every use to avoid obscure bugs, you may not be familiar with the intended example.

But I've sure seen it a lot. Come to think of it, when inheriting a desk, I often used to leave the dividers the previous user of the desk left as they were, thinking it might save me the time of setting up my own dividers.

> [Implied suggestion that we have been stuck with the split since then ...]

I wonder why it would seem to have stuck, considering that (as you point out) merges have been attempted so many times.

It hasn't really "stuck", of course, except as one of several default practices.

> [... implied assertion that the purpose of /usr was for holding login user account home directories that there would otherwise not be room enough for, pointing to the name as evidence ...]

Uh, no. There were many different people doing many different things, remember.

The history you are familiar with seems to be one thing some people were doing.

I'm familiar with a different history. Others are familiar with other histories.

However, the point you make further down that the current use is full of historical and functional inconsistencies is well made. That you seem to suggest that the merge is a good thing, is something I'll take exception to.

> [..., assertion that there is no more need ...]

I think the real reasons have not at all vanished, have only become more pronounced.

> [... because disks are big enough now, and login directories are now pretty much moved to /home or /user or /u , and the split occurred way before SASI/SCSI anyway.]

You've lost me a little on your time line. Mixing the time line and (probably unintentionally) cherry-picking examples may be what leads you to the conflation of /usr and /Users.

> [Lamenting that some people don't understand history.]

Sad? Maybe.

Little to no awareness? Sure. I don't know anyone who knows the whole history.

There was lots of history, lots of different shops doing lots of different things.

We didn't have the internet, or even its predecessor, connecting most of the people who were using unix like we did in the 1980s and later. People got their information from the vendor or support group, from conferences (once a year, maybe), from magazines, and from private discussions and correspondence.

> [A reference to Stephen Coffin, in UNIX System V Release 4: The Complete Reference (1987) observing that /bin has become a link to /usr/bin , and /lib a link to /usr/lib in Unix System 5 Release 4, and that the change was part of changing the file system structure in Release 4.]
 
Which was a bit of a controversial release, and the book was also a bit controversial. Not even everyone who used release 4 thought that book was worth the paper it was printed on. Others thought it was wonderful, IIRC.
But such is the substance of history books (as opposed to the substance of history, itself).

> [Lamenting that some people think the idea of merging is of recent invention.]
 
Sad? I don't know. Not unusual, sure. Not exactly optimal, under some definitions of optimal, yeah.

Avoidable confusion? No.

Preventable confusion? No.

Should we all learn more from history? Absolutely.

> [Discussion of history of merges, The 2010 merge in Solaris 11 being pointed to as precedent to the recent /usr merge in the Linux community, but Solaris 11 being preceded by at least 20 years.]

Evidence that people who don't learn from history tend to repeat it, I guess?

> [Assertion that the motivation for the merge is that /usr is no longer on a separate volume, ...]
 
You mean, because we no longer need to keep our volumes small, I think.

> [... or at least will be mounted early enough that programs, libraries, and other resources in /usr will be available in time for the boot process to use them, ...]

Which early mounting is, as we all know, difficult to achieve in practice, because of the differences in vendor/distribution (both hardware and software) implementations.

> [... and then pointing out that the boot process in the initramfs must indeed explicitly mount /usr if it is in a separate partition.]

Because mount order and timing is so hard to enforce across all hardware/software combinations.

> [Declining to further explain, deferring to other's explanations:
 * https://fedoraproject.org/wiki/Features/UsrMove 
 * http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
]

Which is an approach to the problem taken by people with a specific goal, and ignores a lot of issues they consider side-issues. (If they acknowledge the issues at all.)

But I think they (and you?) are focusing on the size limitation motivation for the separation and ignoring the need for structure and organization.

> [Pointing out that the opinion was expressed as early as the early 1980s, that dividing things between the root file system and the /usr file system was a mess resulting from the historical accident ...]

Would it be wrong to say, rather, "... some people were under the impresssion that /usr was a mess caused by historical accident."?

> [Reference to a 1986 Unix system administration book by David Fielder ...]

David Fiedler, for those who want to look him up. (My fingers get crossed when I'm typing fast, too. :-/)

> [... and Bruce Hunter, who gave up on trying to explain the division, calling it a "hodge-podge" "overflow" "grab-bag". Also invoking a computer historian, Rob Landley, recently agreeing with Fiedler and Hunter:
* http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
]
 
The nice thing about experts is you can usually find one to support the point of view you have. :-/

I look and find others that describe the organization as somewhat arbitrary, accidental, and so forth, but stay short of calling it miscellany.

> [Assertion that the /usr merge is not just Lennart Poettering's baby, neither merely a feature of systemd.]

You mean that it is not particularly original with the systemd project or with that project's founder, Lennart Poettering. And you're right about that. But it is one of the things that exists within the broader agenda of the loose group of projects that includes systemd.

> [Pointing out that people are on record as thinking it inconvenient and messy the year Poettering was born, and that failing to fix it is tantamount to failing to learn from history.]

Some people see a mess where others see incomplete structure. Or historical organization, as the case may be.

My timeline is a bit different from yours, by the way. From memory, and not properly consulting my records/sources:

** late 1960s ~ early 1970s:

In early unix systems, some integrators and end-users were separating binaries in /bin and /sbin by whether they were statically linked (and thus could be used early in the boot process) or not. /sbin was mounted earlier than /bin in many cases, but were on the same disk or partition in other cases. Also, if independent drives could be read concurrently, it was convenient to have executables and libraries spread across more than one drive.

It was said (by many) to be more convenient to always separate the binaries so you could mount them separately when you needed to, which, due to disk sizes those days, was not too rare.

[This is not a problem of size, but of organization, although the problem of organization can currently be ignored somewhat if the boot volume is large enough to contain both the root file system, with /bin and /lib , et. al., and /usr and all that is under that.]

(Note that dynamic linking was not available for the earliest unix systems. Also note that "vendor" in this context is most often a department within Bell, rather than Bell, itself.)

(Also note that many of the patterns and practices used in Unix were inherited from extant non-Unix OSses that we don't hear of much anymore, so what I'm describing here is naturally mixing part of unix history with the history of those other OSses.)

/usr was not present on all unix systems during much of this time.

Where it was present, it was, in fact, sometimes used as the home directory for user accounts, when the system integrator or whoever was setting it up wanted to collect all login directories under a single tree.

But it was more often intended as a place to localize all the customizations for a customer ("user", in the broader senses of end-user, most often a department within Bell). (If you're saying, "Wait! Wasn't that /opt or /usr/local?", slow down. You're jumping the gun. That was in a later iteration.)

(Sometimes, people who put login directories directly under /usr were chided for confusing "usr" for "user", in a possibly misguided effort to get them to understand the difference between "end-user" stuff and "user account" stuff.)

IIRC, there were floppy-only systems that had root, including /sbin, on one floppy, and /bin on another. And they might have /usr on a third.

** mid ~ late 1970s:

We actually had people talking about "mature unix systems" already. Heh.

Much of the root tree structure was becoming common, if not exactly standard -- /bin , /sbin , /lib , /include (!!), /etc , and so forth. Vendors had their own quirks, and directory names were not exactly reliable indications of what they contained.

But /usr , as a place for customization, was possibly closer to a standard practice than /sbin for your start-up binaries. Sometime during this time, /include tended to get moved to /usr/include, and parallels of /bin , /sbin and /lib under /usr , for less general, more end-user oriented stuff became fairly common.

Many hard disk manufacturers got their products stabilized, so systems running on floppy became somewhat rare. Disk size was becoming a non-issue, but the organizational structure was still useful.

/sbin , in particular, became viewed more as an "important system binaries" directory, rather than a "statically linked binaries" directory, but it was still common to arrange for /sbin to be on the first volume to be mounted, whether /bin was or not.

** late 1970s ~ mid 1980s:

This was where Shugart's SASI interface became something of a standard, and where IBM and others refined it to SCSI.

But we should note that neither of these interfaces were original in providing the ability to connect multiple drives. We should also note that the size of a system was increasing, so even with "huge" 20M hard drives, it was useful to physically split the file system and the file system, and the organizational divisions provided natural boundaries to split the volumes on. Thus, /usr as a place for integrators to use in customizing an installation became somewhat standard.

The content of /usr/bin , /usr/sbin , and /usr/lib became fairly standardized as well, partly because of the BSD work making once optional utility and application programs easier to get and install.

So now it became desirable to have another place to put the end-user customizations. /usr/local and /opt were among several directories that came to be commonly used for that purpose around this time. /home for the user account directories was not yet as common.

Remember that there were no hard-set rules about the structure of the file system tree. In particular, unix-like OSses (OS-9 is one example that comes quickly to mind) would tend to vary significantly from the mainstream practices. Also, many integrators and end-users would re-organize the tree as they saw fit, generally seeking more meaningful names.

Various efforts at merging the binary and library directories were tried, as well. Putting everything executable in /usr/bin and putting links in /bin and /sbin was just one of many attempts.

** mid 1980s ~ mid-first-decade of 21st century:

/bin , /sbin , /lib , and other parts directly under root (including some of /etc) have been the focus of unix industry standardization efforts, also in Linux.

Stuff under /usr has been the focus of distribution- or vendor-specific standardization, in both unix and Linux. And /home has become something close to a standard place for user-level login account home directories.

And various efforts to re-structure the tree continued to be tried, including merging.

Note that there is a natural organization seen here:

-- core stuff, things that all players in the industry want to rely on;

-- value-added stuff, things that individual vendors want to use to differentiate their offerings;

-- customization stuff, the applications that are the real reason for buying the computer.

Note also that Solaris, the captive OS of Sun and now Oracle does not need the first two levels. They are vendor and integrator. Apple's Mac OS and iOS, likewise. Google's Android, likewise.

** mid 1990s ~ present:

Linux-based systems generally started a step or so behind mainstream unix in standardization efforts and such, but ultimately took the lead in general-purpose systems [in many ways, not all]. The kernel developers borrowed lots of ideas from embedded systems and non-unix unix-like systems, including alternate file system structures.

The BSD derivatives have not [been] as popular as the Linux-based systems, but there is a lot of sharing, so there is a bit of convergence, a lot of similar experiments.

The three pseudo-layers of the file system tree that [I] specified above have continued to be convenient for the various distributions (as virtual vendors) to use, to show their stuff in. They have been traditionally reflected in the division of / , /usr , and /usr/local , or the several variations thereof.

Merging /bin with /usr/bin seems to me to be nothing less that pushing one set of integrations into the implied standard.

Unfortunately, in spite of the borrowings from embedded systems, one desktop-oriented file system layout now gets a lot of attention, and by the middle of the first [second, I meant] decade of the new century, has come to be seen as the one-and-only goal by a small, vocal, and inordinately influential group.

We missed the news. Linux on the desktop was Mac OS X. The fact that MkLinux was dropped for FreeBSD is only incidental. Linux and BSD are twins. We "won" the desktop. But there seem to be lots of engineers who wanted to be leading the charge, and they seem to want a re-match.

Okay, the last two paragraphs are somewhat speculative on my part.

The point I'm trying to make is that the /usr merge seems to me to be motivated by the assumption that the integrations thought to be appropriate for a certain desktop environment are necessarily appropriate and correct for all environments that use the Linux kernel. It's one of several such changes that are being pushed by a group of projects which includes systemd.

And, while I have seen noise about how the merge is more convenient to certain developers who take a certain class of approaches to desktop systems, for my purposes, I'd far rather see the approach taken by the GoboLinux project become the standard, if we have to have a single standard layout.

==========================

Not exactly a satisfactory exposition of the questions. It leaves the question dangling, of whether there is a better organization, and I think there is.

Gobolinux is heading in the right direction, but common practices in Linux application packages interfere with taking the next step. And completely effacing all organization is just going to make those bad programming habits worse.

Saturday, September 13, 2014

Taxing My Patience

I've complained about the FuBAR and the generally and necessarily convoluted nature of individual taxes administered on a national level.

This year, they've gone a bit farther out into looking-glass land. The FuBAR form is now electronic-only. Not only electronic-only, but it requires the Adobe Reader. The instructions can be read with free software PDF viewers, but the actual form you have to fill-out has to be opened by the Adobe Reader, which, at the time of this post, is no longer available for Linux. (Android (ARM), yas. Linux, No, No, Nooooh!) According to the Financial Crimes Enforcement Network (huh?), it only works on Macs and MSWindows boxes. The pdf file I linked above even goes so far as to say that mobile devices are not supported, although, when you go to Adobe's site, you can download an Android version.

Wait. Let me get this straight -- I have to download a PDF file that I have to open with Adobe's proprietary (and bug-ridden) reader, on a Mac or an MSWindows box, read and follow the instructions in that form, and then fill out the form on-line?

Uhm, no. But it's still just as silly. I have to download that form on a Mac or MSWindows box, fill it out on the bug-ridden Adobe Reader, and submit it through my bug-ridden web browser to the Financial Crimes Enforcement Network over the bug-ridden internet. (Who named this agency? How long until the US has its very own Agency of Silly Walks? And where did they learn about electronic document security?)

And somewhere in the "FinCEn" site, there is mention of a digital signature, and the problem of putting two digital signatures on the document when submitted by a married couple, requiring submission of a form to give one spouse the authority to submit for both.

What The Foolishness?

The Constitution was constructed, not so much to protect freedoms or rights, but to prevent this kind of insanity. It is precisely this kind of insanity which allows corrupt officials within a government to commit offenses against the freedoms and rights of individuals with impunity.


Wednesday, August 13, 2014

Is There a Girl on the Beach Waiting for Me?

I was listening to the radio this morning, Asahi Broadcasts Morning Partner (おはようパートナー). (My wife chooses the station and program, I just listen while doing the morning chores.)

Keimoto-san's team played The Beach Boys' "The Girls on the Beach". I was hanging out the laundry. And I heard the lines, "... are all within reach, if you know what to do. ... and one waits there for you."

(Can't quote too much, don't want copyright lawyers trying to enforce intellectual property on me.)

And I think about the shift in attitudes, from when it was a boy's right, as it were, to make a play for a girl, to now, when it seems it's anyone's right to make a play for anyone.

What is this business about making a play for, well, anything? Or anyone? Why does the entertainment industry seem to be so fascinated with making control a commodity?

What could Brian Wilson and company have been thinking, when they penned lyrics that seemed to suggest it was a boy's right to have a girl? What were they selling? And why would a self-respecting woman listen to such lyrics willingly?

I had to dig deep in my memory. Read up a little on Wikipedia about the history of The Beach Boys and about their father and such. Remembered what it was like listening to their tunes on the radio. And about taking my stereo to church to play music for the dances.

Dug out memories of when it seemed like etiquette lessons were primarily about teaching me to assert control. Politely, of course. Memories of wondering whether I could really do such a thing as ask a woman to become, essentially, chattel, for a few minutes for a dance, for a few hours for a date, or especially for a lifetime.


I didn't want to be in control of everything in a relationship. That was too much work, and I was having a hard enough time figuring out how to be in control of myself.

I wasn't interested in structured relationships or activities, too young to see the structure as a framework within which to move, instead of as a set of rules defining everything that had to be done.

And too young to understand that learning how to set structure aside, and when, was the next step after learning etiquette.

Somehow, I learned how to ask for a dance, and then I learned how to ask for a date. Almost. Still not good at asking people to schedule me a piece of their time.

I figured out that the best way to succeed at asking for a dance was to put the question of whether I could get a kiss or not out of my mind. I wanted to dance, and many of the girls at the dances wanted to dance. Neither they nor I really wanted to do anything more, so there was no real need to fuss with the social pressure, ego competition, really, over kissing and making out.

Focus on the dancing and you can get a dance.

Most of the girls I danced with didn't really know what to do on the dance floor, so I usually had to lead. And they liked letting me lead them on the dance floor for a bit. After a few of the more adventurous girls saw that I wasn't going to ask them to go off and engage in ego stroking sessions, more of the girls were willing to dance with me.

Some of the most popular girls seemed a bit disappointed that I didn't want to do the mutual ego-stroking thing. Part of me said, "Wait a minute, what chance did I just miss?" and part said, "That's okay." I wasn't ready for it.

Never really did learn the etiquette, the small-talk, the rules that keep the mutual ego stroking "safe".

When I say safe, I'm not just taking about keeping things from heading towards physical/sexual exploration, but also about keeping the conversation topic away from traps where people hurt each other and themselves. The mind games.

I've sometimes noted that marriage is the archetype of all relationships. When you learn the fair give-and-take of marriage, you can extend that understanding to less intimate associations.

If I do a little meta-substitution with the lyrics, substituting "partner" for "girl", and "world" for "beach", and think beyond the adolescent focus on control for the "within reach" part, the lyrics are more about encouraging young kids to get out and find people to be friends with, to work, study, and play with.

And I remember the innocence of youth (the ironic, but very real innocence of youth), and I remember that I usually read such better meanings in the lyrics back then. I was a kid. I knew better.

I think that's still the case with youth, and it's a good thing.

Monday, August 4, 2014

"Lose Yourself to Dance" == Date with Dojo-san? -- 「ダンスに奪われるまま」 ≡ 道上さんとデート?

My wife regularly listens to a morning talk show called 「おはようパーソナリティー道上洋三です。」 ("O-hayo Pasonaritei Dojo Yozo Desu." or "It's the Morning Personality Dojo Yozo!").
内の嫁は毎日のように朝トークショーの「おはようパーソナリティー道上洋三です」を聞いています。

Sometimes I'd like a little quiet in the morning, but it has been good for my Japanese.
偶には静かな朝を過ごしたいのですが、ボクの日本語力が道上さんに助かるでしょう。


The last couple of weeks, Dojo-san has been running a corner called 「道上さんとデート」("Dojo-san to Deto", or "A Date with Dojo-san").
最近の2週間ぐらい、道上さんは「道上さんとデート」と言うコーナーを行っています。

Some listeners wrote in to say that Pharrell Williams singing the refrain on Daft Punk's "Lose Your Soul to Dance" sounded to them like "Dojo-san to Deto".
リスナーの何人かのメールに、ファレルウィリアムズが歌うダフトパンクの "Lose Yourself to Dance" (「ルーズ・ユアセルフ・トゥ・ダンス」)のリフレインが、「道上さんとデート」に聞こえることを知らせてくれたのです。

And that turned into this corner, where Dojo-san meets up with listeners and their families at places like the Osaka Aquarium, and then talks about it on the radio.
その話からリスナーと家族が大阪海遊館のようなところで道上さんと会う機会ができたようです。後に道上さんがラジオ番組のコーナーにその様子を紹介します。

Neither my wife nor I was were listening when they first explained this, but Dojo-san was kind enough to blog about it.
この話が出たところ、二人ともあまり聞いてなかったのですが、道上さんはブログに載せてくれました。

So, how does "Lose yourself to dance." sound like "Doujou-san to deeto."?
なら、「ルーズ・ユアセルフ・トゥ・ダンス」はどうして「どうじょうさんとデート」に聞こえるでしょう?

The "l" of the "loo" sound in "lose" is a little harder than the soft "d" of the Japanese mora "ru". Moreover, the "l" consonant colors a long "u" vowel towards the long "o" sound. That's where the Japanese ear hears the lengthened "do" mora.
"l" の影響で「ウ」が「オ」に近くなって、「ル」がかたくなって、「ド」に移ると思います。

The final voiced "s" of "lose" combines with the initial "yo" of "your" to produce "zyo" (which happens to be an alternate Latinization of "jo"), and the final "r" disappears. Thus the "jo".
濁った "s" が "yo" にくっ付いて、 "zyo" が発生したら、尾にくる "r"が消えて「ジョ」の「オ」が延びる。

How "se" could sound like "sa", you'll have to ask the French. They know.
「セ」が「サ」になるのは?まあ、フランス人に聞いて。わかると思います。

Final "l"s often sound to Japanese ears like the Japanese nasal mora. And the "f" sandwiched between the "l" and the "t" disappears, without a vowel to sustain it.
尾にくる "l" の発音は日本人の耳によく「ン」に変わるのがあります。そして「ト」の前の "f" が消えるでしょう。

And that's the pair of mora, "san".
それで「さん」ができたと思います。

"To" sounding like "toe"? There is no native lingual fricative "t" sustained by a long "u" sound in Japanese, so that gets mapped to either the "te" or "to" mora with a trailing "u" which disappears.
外人はちょっと不思議に思うかもしれないが、「トゥ」が「ト」に変わるのが日本人ならわかると思います。

Shifting "da" with short "a" to "da" with long "a"? The short "a" is just a little lower in the front of mouth then the short "e", and the long "a" is a diphthong, the short "e" sliding into the short "i" or long "e" sound. It's close.
どうして「ダ」が「デー」に聞こえるでしょう?ここの "da" は「ア」よりも、「ェア」のような発音です。つまり、短「o」ではなく、短「a」の発音です。あの聞き難い「apple」の「a」です。「エ」から行けば、「エー」まで聞こえるらしい。

Why does the nasal "n" disappear? It gets hidden by the lingual fricative, "s". But how on earth does that "s" turn into a "to". Lingual fricative spoken heard as a lingual stop?

Maybe that disappearing nasal helps. Push the tongue a little hard, and the lingual fricative kind of gets stopped.

But I'll note, in addition, that with certain dialects of Japanese, it can be really hard, sometimes, for the foreign ear to hear the difference between "so" and "to".

日本語の方言の中には、外人の耳に「ソ」と「ト」の違いが聞き取れないのがあります。

ということを以って、「ト」の前の短すぎる「ン」が消えるでしょう。

そして、消えた「ン」の所為、舌が硬く着いて「ソ」の雑音が止められて、余計に「ト」に変わります。

And Daft Punk has presented us with a nice small example of the fun stuff that happens at the boundaries between English and Japanese.
要するに、ダフトパンク等が、英語と日本語の境界線付近に出来上がる面白い発生物の一つの小さい例を提供してくれたのです。



Wednesday, July 23, 2014

Is every difference a perversion?

We've been using Disney's Frozen and the song "Let It Go" in some of our English classes at school this last week.

I like to dig into the background of the literature we use, and while I was doing so I noted a bit of momentary controversy. Some of the Christian community have claimed that both the film and the song are promoting homosexuality/bisexuality.

Naturally, many of the homosexual/bisexual community were only too happy to pick up on that and claim the song as a new anthem.

Pardon me for drifting off-topic for a moment, but I remain nonplussed by the use of the word, "gay", as a euphemism for homosexuality/bisexuality. "Gay" was once a corollary to the Japanese word 「派手な」(hade-na), "showy, ostentatious, dramatic, flamboyant". (And I wonder about the similarity between "gay" and 「芸」(gei), "arts/literature/crafts".)

The current use of the word in English presents a conflation. People who are "creative" are supposed to be "liberal" in their attitudes towards sexuality, particularly their own sexual behavior.

Hmm. Historically, much of our "greatest" art and literature has been produced in such an environment. By scare-quoting "greatest", I don't mean to disparage our cultural legacy. The kind of art that crosses cultural borders and endures history does tend to be born in the furnace of internal conflicts. And "liberal" sexual attitudes do tend to lead to internal conflicts. But they are not the only factors.

But there is another kind of "great", and the predominance of creative work is born in many kinds of trials, tribulations, strivings, conflicts, troubles.

There is much that is dramatic that is not at all about "coming out of the closet of sexual repression".

There is much that is romantic that does not involve sexual adventure.

There is more to both life and love than sex.

(Sure, queue somebody famous saying, "There must be, but I don't know what," I suppose. Woody Allen? I don't remember.)

Sure, the classic animal responses to stress are fight, flight, and sex. But sex is only one out of three there. And none of those are the correct general human response. One of the traits of the human animal is supposed to be sometimes reacting to stress by thought, and by behavior guided by rational thought.

Okay, I've ranted about the conflation. Someday I want to rant about the negative impact of that conflation on social and private dialog, and on our relationships and behavior. Today, I just want to say that conflating things with sex is not necessary.

When I first heard "Let It Go", the lyrics bothered me. Too many people I know spend too much of their lives repressing the wrong things, then break out of that repression, but fail to break out of the real self-oppression. But the final line of the song provides he counter-balance. The storm does matter for Elsa after all, and so does the cold. And I don't think the listener will be deaf to the irony in that line.

Put in context of the plot of Frozen, if "Let It Go" were intended to be a metaphor for "coming out" sexually, it is provided with a stiff warning that coming out is not the ultimate solution.

As members of the Disney crew who produced the movie have noted (quoting other artists and authors from pretty much every era), once you publish, the work of art takes a life of its own. People should interpret it according to their own ideas. That's part of the purpose of art.

But I don't think Elsa's differences have to be interpreted as a metaphor for a different sexual orientation. There are many ways people are different from each other, and there are many social influences that work to try to get us to suppress our differences.

And simply suppressing our differences is not good. Quite the opposite. We need to look at our differences, acknowledge them, embrace them, and put them to good use. Those differences are what makes the world go 'round, as the saying goes. And they also are important parts of what makes us as individuals tick.

------------

I will note that I'm a little ambivalent about the ending of Frozen.

Part of me wanted Hans to find out his love was not real by actually kissing Anna. Then he could have been a bit less treacherous, maybe found a more positive way to help set Anna and Elsa up for the act of true love.

I generally like plots to work out so that people can be forgiven of their mistakes.

Then again, in Frozen 2 (Unfrozen? I'm sure the stockholders are going to insist on a sequel.) maybe a plot twist as ex machina as in Frozen can bring Hans back to prove he's not such a bad guy after all. This is Disney, after all.

;-)

Monday, July 21, 2014

Getting some use out of Android

This is going to try to be a positive post.

First, a list of applications I'm using regularly (on the train and at Church, mostly):

  • Jota+ -- text editor -- after learning (erk) more of the "gestures" (like how to let my finger just sit long enough on an icon), I have figured out how to start a selection. Also, an external (hardware) keyboard is sometimes useful.
  • Elecom bluetooth portable keyboard (real hardware) -- I have the old flexible one. Flexible means I have to put it on something flat to use it. Bluetooth means that I really can't use it when the WIFI is active, or when lots of people around me are using WIFI and/or the wireless phone network. Bluetooth stutters and repeats like crazy and does other undesirable things when there's a lot of stuff going on in those frequency ranges.
  • USB keyboard -- A cheap one, for using at home. Nothing special. But the physical keyboard is just more useable than the touch-screen keyboard, especially when I want to use control keys and Japanese input.
  • EMobile portable router -- Without this, I couldn't really use the thing as a portable. However, I'm not fully satisfied with it, and the lack of source code is a serious pain. I'm pretty sure there's a full-fledged GPL violation hiding in there. And the result is that I can't tweak the settings. Using it on the train is a bit hit-and-miss. And at church, sometimes it just won't connect.
  • Book of Mormon, Gospel Library, and several other apps from the Church. I can read the scriptures in English or Japanese. If my Spanish were good enough, I could read them in Spanish, too! Lots of languages. Except the Bible. I have the Bible (King James Version) in English on the tablet, but copyright issues prevent the Church from publishing the Bible in most languages other than English. But if the WIFI connection is good, I can get the tablet to read the scriptures out loud to me, too.
  • Firefox is in the Play Store after all! I also use Google's browser, of course.
  • Google's stuff: map, mail, quickoffice and spreadsheet (way limited), map, earth, youtube.
  • Debian No Root -- finding ways to make it work for me. I can run gcc on it, and vim. Synaptic blows up on me from time to time, but apt-get works okay. gedit wouldn't load by synaptic, but "apt-get install gedit" took two tries and got it. YAY! A real text editor!
  • Terminal IDE -- This helps immensely with making the Android development stuff more accessible for people like me that just have to use C.
My initial impression was pretty negative.

Currently, well there seem to be ways around the stupid artifacts of corporate culture. [Update, August 18th: Not enough.]