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]

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.

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.

Thinking about an Ideal Operating System Init System

[JMR20170414: Posted the meat of this in my defining computers blog, here: http://defining-computers.blogspot.com/2017/04/how-proper-init-process-should-work.html.]

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?

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.

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.

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.

"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").
最近の２週間ぐらい、道上さんは「道上さんとデート」と言うコーナーを行っています。

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.
要するに、ダフトパンク等が、英語と日本語の境界線付近に出来上がる面白い発生物の一つの小さい例を提供してくれたのです。

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.

;-)

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.]

Have Android, Will Exhibit Tourette's.

Sudden tendencies to socially unacceptable behavior while riding the train for about a month. I'm sure the people around me were a little put off, although they didn't show it.

Cause?

Acer Iconia A200 and Android.

Android is missing so many pieces it is not funny. If you want a functioning system, you have to load all sorts of apps from Google's play store or whatever that is.

• No way to edit text. (I'm using the free version of Jota+ for now, but it's like a straightjacket compared to, say, gedit.)
• Likewise for getting a good look at your filesystem.  (Yeah, there are free file managers, but the blurbs for all of them make me feel less than comfortable about installing them.)
• Firefox? (Well, there is a free version of Opera, and some browsers I've never heard of if you want an alternate browser.) 
• [Wait! I found it! (I mean, really, how hard was searching the Play Store for "firefox". Sometimes I guess I'm a little braindead when things don't work the way I want them to.)]
• Sylpheed? (Yeah, there are other mail browsers, including a Google gmail app, but I can't find a way to access the paste buffer in the gmail app. 10 MB, and no paste function. I'm not willing to try any of the others at this point.)
• Gnupg? (Supposedly, the functionality for apps is built in with the Google Play app. But I haven't find any way besides the meaningless popularity ratings to decide whether I trust a particular independent dev. And what about the other, more important uses of gnupg?)
• [Okay, searching the Playstore for "gnupg" found this, as well, although I have to do a little research on the Guardian Project first. That chicken-and-egg problem of "trust" is not really solved well by the PlayStore.]
• Libreoffice? (Google has their QuickOffice and their spreadsheet app, but, again, there's important stuff missing. I've plunked around with KingSoft in the docomo store. No. Huh uh. Do not want that. And the rest? Trial versions? Huh?)
• bc? gcc? Good luck with that.

Well, wait. There are two bright spots in the mess, a no-root Debian and a Terminal IDE. Seriously rough edges on both, but access to command-line tools, after a fashion. (I'll have to review them later.)

Why does this mess exist? Really, really simple. When Google put Android together, they made a way for hardware companies to provide lip-service letter-of-the-law appearance of compliance with the GPL, without really complying.

Specifically, don't expect drivers from Acer. In fact, pretty much every manufacturer thumbs their nose at you about drivers. So, no, if you want to install real Debian on the thing, you're on your own, in an intellectual property paucity minefield.

So, I take notes at a conference, using Jota+, thinking I'll paste them into e-mail after. (Editing text in the gmail app is a bit of a UI minefield.) Select, copy, and ... no paste.

[update: Attach an external keyboard, and ctrl-v pastes for me. No promises for your Android device, though. Or mine, next time I try this. Oh, and the external keyboard is a Japanese keyboard, but the layout seen by this Acer is US. Most of the shifted punctuation keys are out of place, and I don't see anywhere to change the keyboard mapping.]

No, if you were sitting beside me today on the train, I was not swearing at the person I was writing the e-mail to. I was swearing at Acer and Google. After several years of pretty reasonable self-control, I guess I've find something that pushes me over the edge again. (And this blog post is part of the stress management routine that results.)

[Update 2: I'm finding ways to use it after all.]

God as an Extraterrestrial

I was talking with one of the teachers I work with after school yesterday, and he asked me what I think of the idea that God is an extra-terrestrial.

I told him that i don't really see any other possibility. Any useful concept of God that I am aware of presupposes a being beyond the confines of this planet, both physically and temporally.

But I'm afraid that wasn't the question he was really asking.

Most of the theories that God was an extraterrestrial tend to involve making "a god" something less than God, because we tend to think of extraterrestrials in the frame of the fantasy literature on the subject of highly advanced, but still limited beings, perhaps mortal.

God is not just highly advanced, and He isn't limited in any sense, definitely not mortal.

So I think I need to explain my thoughts a little further to him:

God dwells in the eternal, immortal realm.

This earth, and the universe of its existence, is just one small part of that realm. We, in our mortal state, can't make much sense trying to talk about the nature of eternity, but we can understand that the influence of God fills this universe of our existence.

Hmm. In that respect, God is very much not extra-terrestrial. He may be watching us from a distance, but he is also watching us right up close.

Note to the Members of the PTA English Class [Updated]

For the time being, I will post the PTA English Class posts on my Random Eikaiwa blog. (But it's not ready yet.)

The first post is up. I'll try to annotate it later.

Thanks, in advance, for your understanding.

Things I Like about the Book of Mormon -モルモン書の気に入ったところ

Sometimes people ask me whether I believe the Book of Mormon to be what it claims to be. (I do.)
時には、モルモン書について、その中に書いてあるとおり、本物だと思っているかどうかを聞かれる場合があります。（そうです。本物と思っています。）

Sometimes they ask me why.
時にはどうしてそう思っているかを聞かれるのです。

There is no single reason. Hey, even my characteristically long blog posts are too short. :) But I can list a few things here that I like about the book.
一つだけの理由を言いあげることが出来ません。それどころか、ボクのブログ投稿が大抵長いにもかかわらず、短すぎるのです。（笑）とにかく、ここでその書物の好きなところの幾つかを取り上げることができます。

** First, if you want a good summary of the gospel of Jesus Christ, the Book of Mormon provides one. For instance, you can find a good definition in 3rd Nephi, chapter 27, particularly starting around verse 13.
＊まずは、イエスキリスト様の福音を簡潔にまとめた成句の幾つか、モルモン書の中に見つかります。その内の一つは、第三ニーファイ書２７章、特に１３節から相応しい定義があります。

Reading this, you can see the even shorter summary Joseph Smith wrote in the Articles of Faith, that we believe

• in Jesus Christ,
• in repentance -- turning our hearts and lives towards God,
• in the covenant of baptism,
• and in the gift of God's Holy Spirit.

この中に、ジョセフ・スミスが信仰個条にもっと短くまとめた定義が見えてきます。詰まり、

• イエスキリストを
• 心をも人生をも神様へ傾ける悔い改めを
• バプテスマの聖約を
• そして、神様の聖なる御霊の賜物を

私たちは信じています。

** Second, most of the book of 3rd Nephi is devoted to the record of Savior's personal visit to a group of his disciples in the Americas, shortly after His resurrection. The visit starts in chapter 11 and essentially continues almost through the end.
＊その二、第三ニーファイ書の大半が救い主ご自分が、復活間もなくアメリカ大陸に住んでいた弟子たちの仲間に訪れたことの記録に充てられています。１１章から大体最後までがその記録が続きます。

If you wonder why Jesus would have visited the Americas, you might recall what He said about "other sheep, not of this fold" in John 10. And if you wonder what made the Americas so special, you will be interested in verse 1 of 3rd Nephi chapter 16.
もし、イエス様がどうしてアメリカ大陸を訪れるのかを不思議に思われるなら、イエス様がヨハネ１０章に「この囲いにいない他の羊」について何を語られたかを思い出して下さい。また、どうしてアメリカ大陸がそんなに特別なのかを疑問に思われているなら、第三ニーファイ１６章一節は気になるでしょう。

** Third, I am a firm believer in the freedom of the soul, and the Book of Mormon confirms this pretty strongly. See, for example, 2nd Nephi chapter 2, where the necessity of law, opposition, and choice is explained, and the relationship between redemption, freedom, and joy is shown.
＊その三、私は人の自由を硬く信じています。モルモン書はその自由をよく説いています。例えば、立法、対立、及び選択の必要性を説いて、贖いと自由と喜びの関係を見せる第二ニーファイ２章をご参考下さい。

These are just a few of my favorite passages from the book, and I think they are worth recommending to pretty much everyone.
ボクの大好きな聖句のなかからのわずかなものです。大体の人に大きな価値があると思います。

Facebook or Basshook?

My wife was interested in a promotion of some sort recently. The promotion requires either facebook or one other social network login to register for.

(What? I have to share my social login stuff with them to join their promo? NO THANKS!)

But I did click the Facebook link.

Did I type in my address? I don't think so. That means the promo must have shared the address I typed in with facebook, without my permission.

So I got a "Just click here to complete your registration." mail.

I did not click.

This is not an "I don't think so." When me wife understood that the promo required facebook or something equally noxious, she said she'd do without the promo.

So, now I suddenly get hundreds of "so-and-so accepted your friend request" and such. I checked the headers and the raw source. These are not spoofs, these are from the facebook servers.

Not sure what to do about it. Even complaining to Facebook requires giving them more information than I gave LinkedIn when I signed up there.

Facebook is poison.