When you try to run a program downloaded from this web site, you may
see a warning like "This program is not digitally signed." Code
signature was invented for improving the computer security.
However, it added a new (and evil) purpose now, which is to decimate
individual developers like myself. A code signature used to be
unreasonably expensive. But, now it is not just expensive.
No matter how much money you pay, a code
signature is not issued to an individual programmer. It is
obviously an infringement of freedom of publishing a software.
But, I can do nothing about it. My main job as a programmer is
secure even if one day I cannot publish a software, but what a boring
world would it be?

03/12/2019

Un-Boeing-like Accident?

We don't know if the crash of Ethiopian Airline B-737 Max 8 was caused by the
same cause as Lion Air's crash a while ago. However, even if the causes of
the two accidents are different, the background of the accidents maybe traced
back to the change of the design philosophy of Boeing.

Lion Air's accident
reminded me of an Airbus
300-600R crash at Nagoya airport in 1994. I don't know if you remember,
but the crash was obviously from the design error by Airbus. Airbus
300-600R in go-around mode, mixed control-input from the human-pilot and
auto-pilot together. Auto-pilot controlled the pitch trim, and the
elevator input from the pilot controlled the elevator. On April 26, 1994,
the pilot of Airbus 300-600R accidentally pulled the go-around lever, setting
the airplane into the go-around mode. The pilot wanted to continue
landing, but the auto-pilot pulled the nose up to go around. The pilot
pushed the yoke harder, fully deflecting the elevator to the nose-down position,
while the auto-pilot moved the elevator trim to nose-up position to counter the
elevator. Eventually the elevator trim overpowered the human-pilot.
At that time, the aircraft no longer could lower nose. The aircraft
climbed violently, stalled, and then crashed killing all souls on board.
The obvious cause was that the aircraft could be put in a state that mixed input
from the auto-pilot and the human-pilot together.

On the other hand, Airbus did everything to deny the design error. They
announced right away that the accident was caused by the human error.
Their point was since the human-pilot may make a mistake, the auto-pilot must be
trusted in case of emergency. Therefore the accident was caused by the
human error.

You don't have to be a Ph.D to understand Airbus's logic was absurd. We
can discuss if the input from the human-pilot should be prioritized over the
auto-pilot or vise-versa. Both human-pilot and auto-pilot has some
probability of making a mistake. We need to bet on one of them.
Human cannot make accident absolutely zero. All we can do is to minimize
the probability of an accident. If, as Airbus said, Airbus took a bet on
the auto-pilot, and the human-pilot happened to be right, it was unfortunate,
but not a design error.

Well, let's say Airbus was right that the
auto-pilot should be prioritized. Then, the inputs from the human-pilot
and the auto-pilot must not be mixed. If Airbus wants to trust the
auto-pilot over the human-pilot, input from the human-pilot should be shut off.
Or, if they trust the human-pilot over the auto-pilot, the input from the
auto-pilot must be shut off. In either case, the inputs must not be mixed.
However, Airbus 300-600R mixed them in go-around mode. Therefore, it was
an obvious design error.

To my surprise, Japanese counterpart of NTSB, accepted what Airbus was saying
and concluded that the accident was caused by the human error. Hello??
As a Ph.D in Mechanical Engineering, I think it is obviously caused by the
design error. Airbus should have been held responsible. By the way,
Airbus should have kept Concorde flying instead of developing A380.

I guess someone working for Japanese NTSB got richer. Airbus probably
made a secret change in the control system of Airbus 300-600R. Typically
it is called an SB, or Service Bulletin. No similar accident was reported
after this Nagoya accident.

<-
I've restored Amazon Affiliate Link. I appreciate if you use this link
when you buy something from Amazon.com.

Anyway, the Boeing's reaction to this accident was this: Boeing trusts
the human-pilot over the auto-pilot in case of emergency. Therefore a
similar accident is impossible in Boeing aircrafts.

It was supposed to be.

I had some chances to talk with employees of Boeing before in conferences.
They were saying Boeing likes pilots, and they trust the pilot in case of
emergency. They never employ side-stick because pilots love control yoke
right in front of the pilot seat. Boeing aircrafts disables auto-pilot and
complies with the pilot's input when a strong pressure is applied to the control
yoke. Boeing was always pilot-centered. That's what I heard then.

But, what about Lion Air's accident? The reaction from Boeing was a
copy of the reaction from Airbus after the Nagoya accident. Boeing said
that the solution was to make sure the pilot was informed and trained to deal
with this situation. No, it's not. I wouldn't say it is an design
error. The human-pilot may make an error in case of emergency. It is
true. If the design philosophy trusts the auto-pilot over the human-pilot,
it is a valid philosophy. There is not right or wrong. But, we need
to keep in mind that the computer may make a mistake, too.

I'm a programmer. I know that a programmer makes mistakes because I
make mistakes. I'm not the god. A control program used by the
auto-pilot is written by a human-programmer and may include an error. It
is nothing to surprise if the auto-pilot makes an error. Just like
trusting the human-pilot will never eliminate an airplane crash, neither
trusting the auto-pilot will never eliminate an airplane crash. All we can
do is make an airplane crash less likely to happen.

Which philosophy do I like? Obviously I would trust the human-pilot.
A human-pilot can better adapt to an unknown flight condition.
But, if the auto-pilot steps on the programming error, it cannot correct itself.
Well, we can theoretically make it wireless-updatable. But, do you want to
start updating the control software of an airplane while flying? "The
flight-control computer needs reboot. It would take 10 minutes to
restart." Would you click "Yes" to this? Machine learning? It
does good, if the flight condition is an interpolation of the known training
conditions, but it may go berserk if it happens to be an extrapolation.

So, I liked the Boeing's pilot-centered design.

In Lion Air's crash, the human-pilot tried to pull the nose up while the
auto-pilot was trying to dive. The auto-pilot was thinking the aircraft
was about to stall. The pilot was trying to prevent the aircraft to dive
into the ocean. From the aircraft point of view, it had no idea who was
right. In the aircraft-accident history, there were numerous cases that
the human-pilot ended up pulling the nose up too high and stalled and crashed.
The aircraft trusted the auto-pilot. And, the auto-pilot happened to be
wrong this time. It was unlucky.

Again, it is not a design error. Both the human-pilot and the auto-pilot
can make a mistake. Who to trust depends on the design philosophy.
If the design philosophy trusts the auto-pilot over the human-pilot, it is a
choice, not an error. I don't like it though.

If Boeing trusted the human-pilot like it did before, Lion Air's accident
could have been averted. If current Boeing trusts the auto-pilot over the
human-pilot, it is not an error, but I feel it is unfortunate.

03/03/2019

Trying to release a YSFLIGHT Demo for Android, but...

I have succeeded in running YSFLIGHT kernel on Android several months ago.
Alghouth it is not playable yet, I thought to release a demo-only version.

Since I have a new laptop now, I installed the latest version Android Studio.
As expected it could not build from a project set up by an earlier version.
Evidently, Google doesn't even running a unit-test of building a project from
earlier-version Android Studio. That's the way grad students write
programs. (No unit tests)

This is exactly the major problem of Android development system. It
changes. It changes way too often. Now many developers seems to be
thinking frequent update is a good thing. It is a huge mistake, as huge as
a red-giant about to explode into a supernova. If a software is coming
close to its goal, it gets stable and has less-frequent updates. If
something needs to update frequently, it is an indication that the thing is bad.
It needs update because it is disgusting. From my observation, Android
Studio is a crap.

It's not just Android Studio. Too many too often updates. I want
to shout "DON'T UPDATE!!!!" Seriously I want developers to take time to
make a secure and robust code that needs fewer updates. Current trend of
releasing pre-mature and updating later attitude is toxic. The current
trend of software development is quite deplorable. That's not what I
learned. People may call me outdated. But, if releasing a crap
pre-mature software is the trend, I proudly stay outdated.

Fix for this problem was easy. I entered the exact error message, and
Google took me to the solution. I wish Google didn't create this problem
for the first place.

But, the program was running extremely slow, most likely because I compiled
in the debug mode. I changed the configuration to release mode and tried
to test on the emulator, then I was told I needed to sign the code. The
APK file was indeed named as something-release-unsigned.apk.

Argh! Code signature again! The main purpose of this
code-signature thing used to be for good cause, but now is to decimate
individual developers in the name of security. It's evil. I followed
an instruction to make my developer signature which presumably won't be accepted
by the Play Store. But, it's ok. My plan is to upload my APK here.
I have no business with Play Store.

But, Android Studio keeps trying to run something-release-unsigned.apk and
keeps complaining that the APK is not signed. Android Studio could not see
somthing-release.apk which d**n Android Studio has just built by itself seconds
ago. I force-deleted the something-release-unsigned.apk, but Android
Studio only complains file not found.

The time is up for the day. I reverted all the changes except the fix
for the new version Android Studio. Will try again.

Last year I bought a vintage game program called Plazma Line from
www.suruga-ya.jp. I also
ordered a Sanyo Cassette Data Recorder called MR33DR from Yahoo auction.
According to the description the data recorder spins, but the seller
could not confirm if it worked or not. Majority of the defective
data recorder has some mechanical problems. If it spins, I thought
it should be in good shape. The data recorder crossed the pacific
ocean using the service from buyee.jp.

However, the data recorder
didn't play sound. It spins. But no sound from the speaker and the
phone jack. My problem became suddenly challenging then. But somehow
I wrote a program that applies filters to the audio recording from a
conventional audio cassette player and restored Plazma Line successfully.

Repairing my data recorder has been in my to-do list, but I have been postponing
mainly because I didn't have a skill set to do so. Now, after making some
serial connection adapters for FM-7, I thought maybe now I can do it. So I
tried. (Read more)

02/15/2019

Heard Airbus stopped building Airbus 380. They should have modernized
Concorde and kept them flying instead, or at least kept Concorde flying :-P

I reluctantly tried to upgrade my Ubuntu 14 in my virtual machine to Ubuntu
16, ending up destroying the desktop. No icon, no menu, no Terminal opens
with Ctrl+Alt+T. Utterly broken. I am not that familiar with Linux
that I can log in single-user mode and correct settings. I can choose to
revert back to back-up Ubuntu 14, or otherwise only option looks to be clean
re-installation, absolute waste of time. I end up going through absolutely
unproductive and unpleasant waste of time regular basis.

Linux is still extremely brittle. It never gets solid. If a major
update breaks the settings so easily, I want Linux developers stop major
updates. I want security updates, but I don't want major updates.
Does anyone want a new version of an operating system? I don't know anyone
looking forward to a new version operating system. A new version, from
time to time, makes perfectly healthy hardware unusable by making changes to the
device-driver model that I never asked for. Kills good programs by making
unnecessary changes in the kernel. When there is major hardware updates, I
understand it is inevitable. But, did we have one in the recent years?
I am not aware of any. For the past many years, the same thing has been
just getting faster. No major changes in the hardware. Major upgrade
of an operating system is always a nuisance to me. If they keep doing what
customers don't want, nobody will use their product eventually.

Thank you for your patience! YSFLIGHT Ver 20181124 is ready for
download! Major changes are as follows.

- Shadow mapping in OpenGL 2.x version.- Particle rendering for clouds
and smokes.- Particle rendering support in OpenGL 1.1 and Direct3D9
executables.- Added Air-Racing mode. Quite primitive, but it at least
measures time to pass all check points for you.- Massively and automatically
tested add-ons. I hope the ones stopped working now works again.- Stopped
using Windows installer. I am tired of it.- SRF models in .FLD file. Older
preliminary implementation was checking bounding-box collision, but it now check
polygon-by-polygon collision.- Separated ILS view and Tower view (I think I
made it back to same as previous versions.)

When you try to run YSFLIGHT, you may be seeing a security warning from your
operating system stating that the executable binary is not code-signed.
The purpose of he code signature is to confirm that the program is written by a
known person and not altered by a malicious hand. The purpose itself is
very correct.

Information security is extremely important. There is no question about
that. We hear security breaches, stolen information, identity thiefts, and
all sorts of crimes. Many of those incidents originate from a malicious
program. Of course, the responsibility is primarily on a person who wrote
such a malicious program. Such a programmers should be locked for
life without parole.

But unfortunately there are even more cowardly groups of people. There
are some companies called certificate authorities who are responsible for
issuing digital certificates including code-signing certificates. Those
companies are taking advantage of the security problems and cowardly trying to
decimate individual free-software programmers.

Code-signing certificate used to be too expensive for individuals. Most
of them used to cost like $500 per year. Not just one-time payment every
year you have to pay. I wanted to get one for my projects. Yeah, it
is not impossible to pay $500 per year, but I couldn't justify to do it for my
free-software projects. This time one of the long-time YSFLIGHT users
raised a concern about the security warning. So, I did shop around again.
I then found $179 per year certificate from COMODO. I paid for it, only to
hear that they no longer issue a certificate for individual developers.

I looked into other major certificate authorities, too. None of them
issues a code-signing certificate to individuals any more. They apparently
are united and are trying to destroy individual developers. It is not just
unaffordable. It is now impossible for an individual developer to get a
certificate. It is not right. I don't understand how it is allowed.
The certificate authorities are intentionally trying to decimate individual
programmers like myself.

Therefore, it is not what I like, but I am not able to sign my programs
available from YSFLIGHT.COM. I just release my programs without signature.
I can do nothing about it. Probably those cowards will win.
Individual free-software developers will eventually extinct. All I can do
is to tell what's going on on this web site.

1/6/2019

Still no words from Vector.co.jp. For the meanwhile, folks outside
Japan can download YS FLIGHT 20181124 version from download.com already.

I had to cancel flight so many times due to bad weather. I hope we
have more flyable days this year.

I flew a local flight from Beaver. I haven't practiced maneuvers for
a while, so I thought to practice some this time. After flying steep turns
a few times, I noticed another airplane came into the proximity and started
practicing maneuvers. I think he was doing Power-On Stalls. I picked
a large gap of the clouds and climbed through it.

If you are an owner of a classic Fujitsu PC, FM TOWNS, and if you are
trying to put your hard-disk emulator such as SCSI2SD internal,
WAAAAAAIT!!!

Do you have an adapter to be inserted between your SCSI2SD and FM TOWNS'
internal SCSI connector? Aren't you trying to directly connect your
SCSI2SD to the internal SCSI connector because it is a rectangular 50-pin
connector just like a standard SCSI connector?

DON'T DIRECTLY CONNECT YOUR SCSI DEVICE TO
THIS CONNECTOR!! MOST LIKELY YOU FRY YOUR DEVICE OR FM TOWNS OR BOTH!!

You need to insert an adapter between the FM TOWNS' internal SCSI connector
and the SCSI device.