カテゴリー: メモ

Androidタブレットの画面表示の課題

ブラウザの課題

ブラウザにはAndroid用Firefoxを使っているのだけれど、デフォルトがスマートフォン表示になっているため、非常に頓珍漢なことになっている。

タブレットの画面エリアでもスマートフォン扱いになっているため、左右センターにちょこっと表示されるYahooや、スマートフォン表示を左右に引き伸ばしたAmazon、文字が引き延ばされて全ての文字が32pxや60pxになってしまっているブログニュースサイトなど。

毎回、メニューから「デスクトップサイト」をonにしているのだが、タブウィンドウごとの設定保存で、タブを閉じるとモバイル表示に戻ってしまうし、タブを閉じていなくても画面最小化しているときにスワップしてメモリリセットされると再表示時にモバイル表示になってしまう。

ドメインごとにデスクトップ表示・モバイル表示など切り替えたいし、いまどきブラウザのUser-Agentで出力をサーバ側で切り替えるのもやめてほしい。

ブックマークの表示も気になっていて、デスクトップのブラウザのようにブックマークをサイドバーに常時表示する設定がほしい。

VivaldiのAndroid版では、サイドバー表示できているので、こういう設定がFirefoxにもほしい。デスクトップのMacでFirefoxをメインにしているので、モバイルだけVivaldiというのもブックマークの共用の都合上、非常に面倒なことになってしまう。

アプリの課題

タブレットといいつつ、巨大画面のスマートフォン扱いになっているため、アプリによっては画面表示に難がある。

特務機関NERV防災では、文字が枠からはみ出ており、特に右上の「編集」ボタンが「編」の一部しか見えていない。

旧Twitter(現𝕏)のアプリでも、真ん中寄せのスマートフォン表示で、タブレットの画面幅を最適に使用できていない。(ところで、投稿ボタンは旧Twitterロゴのカラーの青なんだけれど、これは現𝕏のカラーに変更されないのだろうか)

こういう画面設計、アプリ設計の課題が、Androidタブレットの使い勝手を悪くし、評判を落とし、コスパ最高なのにどうしてもiPadに勝てない原因のひとつになっているのではないだろうか。

DOOGEE T30 Ultra Androidタブレットを買ってみた

いま使っている11inch M1 iPad Proの液晶がへたってきて、端が黄色く変色してきた。これ、よくある液晶の経年劣化の不具合なのだけれど、修理すると数万円はかかってしまう。

一番使う手元で操作する情報端末なので、液晶の見た目が非常に気になってしまうので買い替えを検討していたのだが、直近で発表、発売されたiPad AirとiPad Proがお値段高すぎで、たんなるコンテンツビューワーとして使うには、あまりにもなスペックになってしまったので意気消沈。しかも、モバイル回線がeSIMオンリーになってしまい、それはそれで不便な気がする。

とはいえ、液晶の修理の数万円がかかるなら、ということで、試しにAndroidのタブレット、DOOGEE T30 Ultraを買ってみた。iPad Proの修理代で2台は買えてしまいそう。

届いたので早速セットアップ。Android自体はスマホを使っているので操作や基本的な設定については、特に問題になるようなつまづきはない。重たいゲームはしないので、CPUやメモリについても問題なし。

Webブラウジング、YouTube動画視聴、YouTube Musicでの音楽再生。Kindleでの読書など、ほぼiPadと同様な環境を設定することができた。

液晶はけっこう綺麗。中国人お好みの特有の青色がきつい感じもしたが、色味調整で気にならないレベルまでに調整できた。

設定していて、今まで通りの使い方ができないと気になったのは、iPhoneとSMSを共有していてiPad Pro側でSMSのメッセージを確認することが多かったが、それができなくなったことくらい。

しばらくiPad Proはシャットダウンして、このDOOGEE T30 Ultraで過ごしてみようと思う。特に問題が発生しなかったら、iPad Proのスペックは不要だったということだし、このままAndroidのタブレットで生活できそう。今年のWWDCでの今後のiPadOSの動向次第では、やっぱりiPadということになるかもしれないけれど。

電話着信やデータ通信の不具合を改善も、やっぱり遅いGoogle Pixel7 アップデートの配信

「Pixel 7/8/Fold」でソフト更新、電話着信やデータ通信の不具合を改善

配信されているらしいが、使用している端末ではアップデートが確認できず。やっぱり配信が遅すぎ。こういう大事な修正は、真っ先に配信を全端末に行うべし。

ぜんぜん変わっていない。こういうのは良くないと思う。Googleの対応はクソという感想しかない。Android自体の評価も下がります。

Androidの端末を使用しているのは、仕事で表示確認の実機調査用のため。仕事で不要になったら、もう必要ないくらい。

メインはiPhone使ってます。iPhoneで、こういう重要なバグ修正の配信が遅れることはないので、安心してメイン端末として使えます。

追記:
どうもSIMが刺さっていると、遅延するらしい。SIMを抜いてWifi接続にて、設定でアップデートメニューを選択すると、更新ができた! こういうの良くないですよ。感じ悪い。

Google Pixel7 アップデートの配信が遅い

2023/12のアップデートが発表され、配布が始まったとニュースになっていますが、自分のPixel7では、2023/11が最新と言い続けています。

アップデートはローリングリリースということで順次配布となっており、順番が来るまで配信されないようですが、多くのセキュリティの問題が出ており、こういうのは迅速に適用すべき内容であると思いますが、こういうのが順次配信ということで置いてきぼりにされているのがPixelの問題だと思います(しかもいつ配信されるのかがわからないまま放置される)。

他メーカーの他機種のAndroidと比べて、きちんと毎月のアップデートが配信されるのは評価できますが、こういうローリングリリースはやめていただきたい。

AppleのiPhoneのiOSは、アップデートのリリース発表とともに配布がされていつでも適用可能になっていますが、どうしてAndroidはこういったリリース対応ができないのでしょうか。これだけでもAndroidをメイン端末にするのを忌避してしまいます。

2023/12/13追記
12/07リリースの更新が12/13にようやく配信されたので、適用。約1週間、時間かかりすぎ。リリース時点で詳細発表されているため、セキュリティ問題でインシデント起きてもおかしくないですね。こういうのはAndroidのOS更新だけでなくGoogle Playのアプリ更新でも起きていて、アプリの作者が「更新配信しました」と言っていてもGoogle Playにアクセスすると更新されていないことが多々あります(GoogleをログアウトしてGoogle PlayのサイトにWEBアクセスすると更新されているバージョン配布されているが、そのままWEBログインすると更新前の記述になっている)。こういうの良くないです。

サーバOS更新

このWEBサーバは、いままでCentOS7のVPSを使用していたのだけれど、そろそろ重い腰をあげてOSを更新。というかサーバごと入れ替え。

新しいサーバはUbuntu 22.04のVPS。別の環境への引っ越しで、クリティカルな部分はないもののあれこれめんどうだった。

先の見えないCentOS。またCentOSでのメジャーアップグレードも規定の方法がないのでサーバごと入れ替える必要があり、今回はディストリビューションをUbuntuに変更した。OSは使い勝手のよいFreeBSDでもいいかな、と思ったけれど、サーバ用OSとしてメジャーなLinuxに慣れておくことも重要なためUbuntuを選択。

環境の大きな違いは、CentOS7ではremiのレポジトリを入れてPHP8.2をインストールしていたのだけれど、Ubuntuでは標準でインストールできるPHP8.1にしていることくらい。これも大きな問題ではなく、そのままアプリケーションは移行できた。

きちんと新サーバが動作しているので、旧サーバは月末までに解約しよう。

macOS Sonoma 14.0 に対応したESET Cyber Security Proを入手する

もうすぐ、maoOS Sonoma 14.0がリリースされるが、それに対応したESET Cybet Securityについては、日本でのサポートを行なっているキヤノンマーケティングジャパンでは、現時点ではまだ「未対応」とされている。

実は、すでに対応バージョンが存在する。macOS Sonoma 14.0に対応したESET Cyber Security Proはこちらからダウンロードできる。
https://www.eset.com/int/home/cyber-security-pro/download/

日本語版はリストには存在しないがEnglish – United Statesを選んで、「DOWNLOAD」のボタンのリンクをコピー
https://download.eset.com/com/eset/apps/home/ess/mac/latest/eset_cybersecurity_pro_en.dmg
末尾の_enを_jp _ ja に変更すると日本語版が手に入る。
https://download.eset.com/com/eset/apps/home/ess/mac/latest/eset_cybersecurity_pro_jp.dmg
https://download.eset.com/com/eset/apps/home/ess/mac/latest/eset_cybersecurity_pro_ja.dmg

正式な日本語サポート対応版ではないので、ご利用はご自身の判断でどうぞ。不安な場合は、キヤノンITソリューションズのサポートが「対応」と言うまで待ちましょう。

追記2023/09/26
依然としてApple Siliconにネイティブ対応していないようだ。Intelアーキテクチャのみのパッケージング。そろそろネイティブ対応してほしい。

ちなみに、Sonomaに対応していないESET Cyber Security Proのまま、OSのアップデートをすると、このあたりの情報ではネットワークが死ぬらしいので注意。

追記2023/09/27
さくっとSonomaに更新。ESET Cyber Security Proもきちんと動作しているようです。

2023/09/29更新
キヤノンITソリューションズより、macOS Sonoma 14.x への対応についてにて対応バージョンが公開されました。対応版はV6.11.414.0とのことで、上記の先行してのインストールしたバージョンと同じものです。

Amazonを騙るspamメールが届いた

というようなフッターのついたspamメールが届いた。

Amazon Japanは合同会社だし、フッターに(C) Sumitomo Mitsui Cardとはどういうことだ。

Amazonの利用規約に書かれている正式な会社名、連絡先はこちらです。

一部のファイルが利用できなかったため、バックアップの作成が完了しませんでした。Macのロックを解除するとバックアップの作成が再開されます。

MacのTimeMachineで、初期化したHDDを接続後、初回のバックアップにて「一部のファイルが利用できなかったため、バックアップの作成が完了しませんでした。Macのロックを解除するとバックアップの作成が再開されます。」というエラーでバックアップに失敗。

Macを再起動して、再度初期化したHDDを、あらためて繋いで初回バックアップを試みても、エラー再現。何が起きているのかさっぱりわからない状況。

そもそも、新規にTimeMachineでバックアップを取るのは、このところ、1ヶ月〜2ヶ月程度のバックアップ期間で、なぜか古いバップアップが認識されなくなって、でもディスクは使用したままという謎な挙動になってしまい、ディスクの容量不足になってしまうため。これはこれで、TimeMachineの挙動としてはおかしいが、HDDを初期化して繋ぎ直して、新規バップアップをとれば、いままではなんとか復活していたのだが、本日ばかりはちょっと、トラブル。

初回のバックアップでエラーが出る、MacのハードやOSはこんな感じ。

エラーの状態からバックアップを再度行うと、1回目のバックアップとして完了。HDDを見るとinterruptedの失敗のディレクトリが残っている状態。そのあとで1回目の成功のディレクトリができている。

これ、どういう状況なんでしょうか。これで1回目のバックアップは正しく取れているのでしょうか。リストアしていないので、成否がわかりません。

2023/09/22追記

本日、またディスク容量とバックアップ履歴がおかしくなる事象が発生し(ディスクを直接見ると8/27からのディレクトリがあるのにTimeMachine管理画面では09/20からのデータしか見えず、それ以前のデータはアクセス不能で削除もできない状態)、またHDDをフォーマットして繋ぎなおし、バックアップ指定した。今度はエラーなく初回バックアップに成功した。

どうもディスク容量と履歴がおかしくなるのは、このところの何回かの事例発生から想像するに、古いバックアップが1日ごとになっている状態で、ディスクをぎりぎりまで使って次のバックアップの際に、1日単位のバックアップを消さないといけないときに発生するのではないかな。macOS 13 Venturaに更新してから発生しているので、OSのバグの予感。もう直ぐ、macOS 14がリリースされるが、修正されているだろうか。


2024/12/27追記

いまだこのページへのアクセス多いのですが、当方の環境においてはmacOS 14にアップグレード後は、一度もこの症状でていません。macOS 15 Sequoiaにアップグレードもしていますが、現時点では発生していません。正常にバックアップができているようです。発生していた当時のOSのバグの可能性が高いということでしょう。

なお、https://qiita.com/eguchi2017/items/56abcc1c7bd6e6992862 も参照ください。アクセス権の設定によっては正常にバックアップされないこともあるようです。

Windowsのプロセスを強制的にkillするには、wmicコマンドのdeleteオプションを使う

taskkillコマンドを使う

taskkill /f /im explorer.exe

taskkillではアクセス拒否されてしまい、killできないこともある。管理者権限で指定しているのだから、killできないとおかしいのだが。

これでも言うことを聞かない場合は、こちらを試す。

wmic process where "name='explorer.exe'" delete

これなら、確実にプロセスをkillできるようだ。

wslでsystemdを起動する方法

wslを起動してから、

$ sudo vi /etc/wsl.conf

でエディタを起動して、以下を記述する。

[boot]
systemd=true

これで、次回のwslの起動から、systemdが自動起動してinitの処理を行うようになる。ただし、initの処理が走るためにwslの高速な起動が、もっさり起動になってしまうのが、玉に瑕。