  |
はてなキーワード: IMとは
Photoshopのタイル構造はどのように実装したら良いですか？何か参考になるソースコードなどはありませんか？
Photoshopのタイル構造は、画像を小さな矩形のブロックに分割して、各ブロックを個別に処理することで実現されます。これにより、大きな画像の処理を高速化することができます。
このアルゴリズムを実装するには、以下のような手順が必要になります。
画像を読み込む
処理が完了したら、結果を保存する
以下は、Pythonで実装された簡単なタイル構造のコード例です。この例では、画像を単純にグレースケール化しています。
import numpy as np from PIL import Image # 画像を読み込む im = Image.open("input.jpg") # タイルのサイズを決定する tile_size = 128 # 画像をタイルに分割する tiles = [] width, height = im.size for y in range(0, height, tile_size): for x in range(0, width, tile_size): box = (x, y, x + tile_size, y + tile_size) tile = im.crop(box) tiles.append(tile) # 各タイルを個別に処理する for i, tile in enumerate(tiles): tile = tile.convert("L") tiles[i] = tile # 処理されたタイルを結合して、元の画像を再構築する output = Image.new("L", (width, height)) x = 0 y = 0 for i, tile in enumerate(tiles): output.paste(tile, (x, y)) x += tile_size if x >= width: x = 0 y += tile_size # 結果を保存する output.save("output.jpg")
このコードは、Pillowを使用して、画像の読み込み、タイルの分割、処理されたタイルの結合、結果の保存を行っています。このコードを改良することで、より高度な画像処理アルゴリズムを実装することができます。
回答ありがとうございます。しかし、実際にはこれに拡大縮小、タイルを跨いでのコピー＆ペースト、ペンツールでの描画などが加わります。拡大縮小は画像ピラミッドのようなもの、メモリ以上の巨大な画像を扱えるのはmmapを使っているのではないかと予想しています。これらを一言で回答するのは難しいと思いますが、何かアドバイスをいただけないでしょうか。よろしくお願いいたします。
拡大縮小、タイルを跨いでのコピー＆ペースト、ペンツールでの描画などを実装するためには、より高度なアルゴリズムとテクニックが必要になります。
拡大縮小に関しては、画像ピラミッドを使用することで実現できます。画像ピラミッドは、複数の解像度レベルで同じ画像を表現する方法です。画像ピラミッドを使用することで、拡大縮小のプロセスを簡単かつ高速に行うことができます。OpenCVやPillowなどのライブラリは、画像ピラミッドを構築するための機能を提供しています。
タイルを跨いでのコピー＆ペーストは、オーバーレイ技術を使用することで実現できます。オーバーレイとは、複数の画像を重ね合わせることで、新しい画像を生成する技術です。タイルを跨いでのコピー＆ペーストは、オーバーレイを使用して、複数のタイルを重ね合わせることで実現できます。また、透明度を使用することで、重ね合わせたタイルの一部を透明にすることもできます。
ペンツールでの描画に関しては、画像のピクセル単位での操作が必要になります。これは、OpenCVやPillowなどの画像処理ライブラリを使用して実現できます。画像のピクセル単位での操作には、色の変更、描画、消去などが含まれます。これらの操作を組み合わせることで、複雑な描画機能を実現することができます。
最後に、メモリ以上の巨大な画像を扱うために、mmapを使用することは可能です。mmapを使用することで、ファイルをメモリ上にマップし、ファイルと同じようにアクセスすることができます。これにより、ファイルがメモリに収まらない場合でも、ファイルの一部をメモリにマップし、必要な部分だけを読み書きすることができます。ただし、mmapを使用する場合は、適切なメモリ管理が必要であり、オーバーヘッドが発生する可能性があるため、十分なテストと調整が必要です。
無料版。シングルプレイヤー。Classic Mode。マップは「World」。時間は無制限。
移動してみるとかなり広い都市だな。内陸部っぽい。
ブラジルの大都市って海沿いが多いので、内陸というとサンパウロあたりか？
ちょっと行き詰まったので適当にサンパウロの真ん中を選択して回答。
うーん、ちょっと離れてるな。そんな大都市というわけでもない。アララカラという街だった。
誤差253km。4221ptだった。
ま、まあブラジル基準では250キロなんて近所みたいなもんだから…。
表札？みたいなものに「Indonesia」と書かれているが…表札に国名なんて書くか？
いや別の看板に書かれたURLが「.id」ドメインだな。ほなインドネシアか。
これは「コロナ対策でマスクつけろ」みたいな看板なんかな。インドネシアも大変だな。
どうも山奥の小さな村って感じで、動き回っても情報が増えそうにないのでサクッと回答するか。
とはいえインドネシアも広いからな…ええい、ジャワ島に決め打ちしていく。
おお、かなり近かった。誤差66km。4782pt。奇跡だな。
標識に街のマークっぽいのが見える…小さいけど「ALL-AMERICA CITY」と書いてある？どゆこと？
看板に「Elvis Presley Birthplace」って書いてある。マジか。
ってかエルヴィスの故郷ってどこよ。メンフィスとかじゃなかったっけ。
どうもこのあたりは「Tupelo」という街らしい。
いや、メンフィスの南東でTupeloを見つけた。これで確定できるな。
誤差100m。5000ptだった。
ALL-AMERICA CITYというのはアメリカの都市を表彰する制度で、テュペロは5回くらい受賞しているらしい。
山間の街。低いほうへ向かってみるとやや広い道に出た。
通りすがりのトラックに書かれたURLをチェック。.fiドメイン。フィンランドかな。
わかりやすい標識があった。「292」の道路を西に進むとHELSINKI。
「290」の道路を北に行くとHÄMEENLINNA、南はKIIPULA。
ヘルシンキの周りで首尾よく各地名を見つけたので初期地点を割り出して回答。
誤差は2m。5000ptだった。
道も細くて一車線しかない。とりあえず進むしかないので進んでみる。
だいぶ進んで遠目に町？村？が見える。ここまで看板なし。
めちゃくちゃ牛が飼われてるな。
初標識。「On Sciobairin SKIBBEREEN」「Draighneach DRINAGH」「On Léim LEAP」。
地名は聞き慣れない感じだけどその他の文章は英語なんだよなあ。
ってことはアイルランドあたりか？
と思って地図を眺めてみるといきなり「SKIBBEREEN」を見つけた。ラッキー。
初期地点に目印がなさすぎるので進んだ方向から見当をつけて回答。
誤差900m。4997ptだった。
最近コンピューターサイエンスがプログラマーに必要か否かみたいな話が上がっているが、そもそもコンピューターサイエンスって何だよ。どこまでの範囲をさしてんの？
ググって出てきた情報を整理しただけなので詳しい人、補足・訂正よろしく！
https://www.acm.org/binaries/content/assets/education/cs2013_web_final.pdf
CS2013はACM/IEEE-CSによるカリキュラム標準。
ACM(計算機協会)はコンピュータ分野全般の国際学会、IEEE-CSはIEEE(米国電気電子学会)の中にあるテクニカルソサエティ。
https://www.ipsj.or.jp/12kyoiku/J07/20090407/J07_Report-200902/4/J07-CS_report-20090120.pdf
J07-CSは一般社団法人情報処理学会がCC2001CSをベースにアレンジを加えたカリキュラム標準。今はCS2013を反映したJ17-CSがあるらしいけどその辺は良く分からん。
https://www.ipa.go.jp/files/000024060.pdf
J07ーCSから抜粋。CS2013と比較するとナレッジエリアがあったり無かったり。
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか？(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか？
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの？とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも？
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか？
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね？」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
ある日のことである。以前のブルマーに関する調査に物足りないものを感じていた僕は、なんとはなしに「ドイツ ブルマ」で画像検索した。すると、個人のブログで、戦後の西ドイツを舞台にした「橋」という映画にブルマーが映っているのが紹介されていた。1959年の映画であるが戦時中が舞台なので、これは明確に戦前にもショーツ型ブルマーが使われていたことを示しているようだ。Youtubeにも動画が上がっており22:48頃からブルマーの出てくるシーンが確認できる。
そんなことから、もうちょっとドイツのブルマー事情について調べたくなった。
自分が以前調べたナチスのブルマーとは、ドイツ女子同盟のものだ。
ウィキペディアによれば、ドイツ女子同盟は、もともとナチズムを信奉する少年の有志で構成されていたヒトラーユーゲントの下位組織として発足したものだが、ヒトラー政権の成立から3年後、全ての未成年男子がヒトラーユーゲントに編入されると、これに伴ってドイツ女子同盟も強制参加の団体へと変化した。
設立の理念は、ドイツの将来を担う「良妻賢母」の育成であり、軍人教育は施さなかった。よって、健康な子供を産むためにカリキュラムは家政学ではなく、体育の方に重点が置かれた。つまり、国によって「女らしさ」「母性」「健康」が強制されていたわけである。そのせいか、略称をもじった卑猥なジョークもあったらしい。
さて、そういうわけで、軍服のような制服のみならず体育教育に使う、こちらのように黒い短パンというか提灯ブルマー姿の女性を確認することができる。写真によっては、サイズがあっていないせいか、角度のせいか、ほとんどショーツ型ブルマーのようになっているものもある。
ちなみに、こちらのサイトによれば、ブルマーを卒業すると白いワンピースになったそうである。また、色は黒であると言及されている。
しかし、写真を見る限りでは、冒頭の映画ほどハイレグではない。これは地域によってブルマーの規格に差があったのか、それとも監督の趣味だったのか、よくわからない。1930年代のThe Woman’s League of Health and Beauty（英国の健康増進団体、ヨガも取り入れている）ではhttps://flashbak.com/the-womens-league-of-health-and-beauty-nazis-pilates-and-the-birth-of-the-keep-fit-movement-4580/:title=
ショーツ型ブルマーに似た制服]で運動しているし、https://aurora-ray.blog.ss-blog.jp/2017-09-15=ドイツ女子同盟のフィギュア(オーロラモデル 1/35ミリタリー WWII ドイツ少女同盟 体操着姿 ガレージキットフィギュア ML76)]ではやっぱりショーツ型ブルマーに似ているのだが、詳細はわからない。冒頭で紹介した映画ではのんびりしたシーンであり、ナチス的な全体主義をあまり感じない。もしかしたら、ドイツ女子同盟とは別に、普段からブルマーがそれなりに普及していなことも考えられなくもない。
その後ドイツではブルマーはどうなったか。以前の記事にも書いたように、東欧ではブルマーが採用されていたことを示す写真はちらほら見つかったが、制服として具体的にいつ頃採用されていたかなどの情報は見当たらなかった。そのため、しばらく調査は暗礁に乗り上げていた。
きっかけになったのはDeepLやGoogleの翻訳である。英語のショーツ型ブルマーを意味する語の一つ「gym knickers」をドイツ語にしたところ「Turnhose」という語が出てきた。これで何かがわかるかもしれないと思った。確かにこれは「短パン」を意味する言葉に過ぎない。だが、ドイツ語のウィキペディアには、英語版とは違い、こんなことが書いてあった。
Für Frauen, Mädchen und Jungen (bei Jungen aber nur bis zum Alter von etwa zehn Jahren) gab es etwa zwischen 1960 und 1990 Turnhosen in Slipform, die zwar umgangssprachlich Turnslips genannt, im Katalog aber unter der Bezeichnung Turnhose geführt wurden. Als Material verwendete man anfangs schwarzen Doppelripp und Helanca. Passend dazu gab es auch die Turnhemden.
女性、女の子、男の子の場合（ただし、男の子の場合は約10歳まで）、1960年から1990年の間にパンティーの形のジムショーツがありました。これは通称ジムブリーフと呼ばれていましたが、カタログにはジムショーツとして記載されていました。当初、使用された素材は黒いダブルリブとヘランカでした。それに合うジムシャツもありました。
やっとのことで、具体的な年代を特定できる情報を見つけた。1960年から1990年、確かにドイツではショーツ型のブルマーが採用されていたのだ。
もちろん、出典が明記されていない以上どのくらい正確な情報かはわからない。ショーツ型ブルマー（上ではジムブリーフと訳されている）を意味する「Turnslips」で画像検索してもまったくそれらしいものは該当しない。だが、調査は確実に一歩前進した。
ドイツでブルマーがいつまで採用されていたか、かなり具体的な情報を手にすることができた。しかし、今回のドイツや前回のチェコとは違い、ポーランドやロシアに関する情報はなかなか手に入らない。昔の記事のように確かに写真はある、動画もある。だが、文字情報が乏しいのだ。「ソ連 体操着 歴史」「ソ連 体育 制服」「体操着 1960」などと単語を変えてもなかなか引っかからない。おまけに、ポーランド語でgym knickersを訳して「majtki gimnastyczne」で検索すると、スポーツ用の下着しか出てこない。また、言語によっては体操着に該当する言葉を探しても、レオタードしか出てこないこともある。
プロの陸上選手がブルマ姿になっているものは出てくるが、学校での採用事情については、なぜかデータが少ない。
資料が見つからない理由は恐らく三つある。一つは、ロシア語やポーランド語ではブルマーを何と呼んでいたか、正確な名称がわからないことだ。チェコ語では、幸運なことに「Jednotný cvičební úbor」が「体操用の制服」といった意味で、直訳でもよかったようだが、他の国の言葉ではそうでなさそうだ。
もう一つは、そもそもネットに資料が載っていない可能性だ。国によってネットの普及した時期は異なるが、紙媒体の資料をわざわざネットに乗せる熱意や理由がないことも考えられる。
最後に、これは前述の熱意がないことと重なるが、欧米ではそもそもブルマーに対して関心が薄いのではないか。海外にも服装に対するフェティシズムはあるようだが、何がセクシーと感じるかは国によって全然違う。ブルマーフェチの人は海外では人数が少ないのではないか。
全くの推測だが、ブルマー時代末期には、ブルマーを性的に感じるあまり盗撮する者が後を絶たなかったという。それが原因で、ますますブルマーが性的だという感覚が強まった。となると、日本でブルマーマニアが増えた理由は、個人のカメラやビデオが日本で普及した時期にも理由があるのかもしれない。
ポーランドやロシアでのブルマーについての文字情報が見つかったら掲載する。しかし、いつになるかはわからない。また、東ドイツと西ドイツとでブルマーの普及に違いがあったか。このあたりも資料が乏しいが、見つけたら公開したい。
また、今まではブルマーはほぼ紺色と思い込んでいたが、黒という記録を見つけた。白黒写真の画像しか見つからなかったケースを、再検討する必要がある。
元記事 (Zerohedge)：https://www.zerohedge.com/geopolitical/vaccine-mandates-great-reset
執筆者：Philipp Bagus via The Mises Institute,
ワクチンを受けていない人への圧力が強まる いくつかの国では、ワクチンを接種した人たちが、コヴィドの介入によって奪われた自由を取り戻しつつありますが、ワクチンを接種していない人たちはそれほど恵まれていません。彼らは差別の対象となっています。公共の場へのアクセスや旅行が難しくなっています。一部の国では、職業によってはワクチン接種が義務付けられているところもあります。
しかし、なぜ政府は予防接種キャンペーンをそれほど重要視し、これほどまでに圧力をかけているのでしょうか。また、誰が世界的な予防接種キャンペーンに関心を持っているのでしょうか？
これらの疑問に答えるためには、普及しているワクチン接種に関する物語を分析し、そこから誰が利益を得ているのかを問う必要があります。
その際には、国家、メディア、製薬業界、超国家的機関の間の利害関係の連合を取り上げなければならない。
ワクチン接種キャンペーンには、明らかに経済的な利害関係があります。ワクチン接種の普及によって莫大な利益を得ることができるからです。
コビド19の危機において、政治家は恐怖とヒステリーを組織的に増幅させた。これは偶然ではなく、当然のことなのです。国家は、内外の危険から国民を守るという主張の上にその存在意義を築いているのですから。国家は恐怖の上に成り立っているのである。国家の助けがなければ、国民は飢餓、貧困、事故、戦争、テロ、病気、自然災害、パンデミックに対して無防備になってしまうという物語である。したがって、国家は、起こりうる危険に対する恐怖心を与え、それを解決するふりをして、その過程で権力を拡大することが利益になるのである。比較的最近の例では、9月11日の同時多発テロや第二次イラク戦争の後、テロの脅威に対応するために米国で市民的自由が制限されました。同様に、平時には考えられないほど国家権力を拡大するために、市民の基本的権利を犠牲にして、意図的に恐怖心を煽り、コヴィド-19を特異な殺人ウイルスとして描写することは、政府の利益となった。
コロナ危機が始まったとき、ウイルスの潜在的な危険性についてあまり知られていなかったため、政治家は非対称な報酬に直面した。政治家が危険性を過小評価して対応しなければ、過小評価の責任を問われることになる。選挙も権力も失うことになる。特に、死者の責任を問われることになればなおさらだ。集団埋葬の写真はさておき、危険を過小評価して行動しなかった場合の結果は、政治的に致命的なものとなる。対照的に、危険性を過大評価して断固たる行動をとることは、政治的にはるかに魅力的である。
もしそれが本当に前例のない脅威であれば、政治家はロックダウンなどの厳しい措置をとって称賛されます。そして政治家は、彼らの断固とした行動がなければ、実際に災害が起きていただろうと主張することができる。しかし、その対策が大げさであったことが判明した場合、その対策がもたらす可能性のある悪影響は、集団埋葬の写真のように政治家と直接結びつくものではなく、より間接的で長期的なものであるからです。ロックダウンによる間接的かつ長期的な健康コストには、自殺、うつ病、アルコール依存症、ストレス関連の病気、手術や検診のキャンセルによる早死に、そして一般的な生活水準の低下などがある。しかし、これらのコストは、思い切った介入に直接関連するものではなく、政策のせいにされるものです。これらの結果の多くは、次の選挙の後、あるいはそれ以降に発生し、目に見えません。例えば、生活水準が上がれば、平均寿命がどの程度伸びたかを観察することはできません。また、ロックダウンをきっかけに発症したアルコール依存症やうつ病で6年後に誰かが死んだとしても、ほとんどの人はおそらくロックダウンを行った政治家の責任にはしないでしょうし、もし責任にしたとしても、その政治家はすでに退陣している可能性があります。このように、脅威を過大評価して過剰に反応することは、政治家の利益になるのです。
政治家にとって魅力的なロックダウンなどの厳しい措置を正当化し擁護するためには、恐怖心をあおることが必要である。19年のソ連危機の際、政治家が恐怖とヒステリーを煽り、ロックダウンなどの高度な制限措置を実施したことで、経済や社会構造に与えたダメージは計り知れないものでした。しかし、社会は永遠にロックダウンすることはできません。どこかの時点でロックダウンを解除し、正常な状態に戻さなければならないのです。しかし、殺人ウイルスの脅威に対する恐怖心を煽ると同時に、正常な状態に戻すにはどうすればよいのだろうか。
ワクチン接種キャンペーンにより、国家は大きな危機からの救世主としての役割を果たすことができる。国家は国民のために予防接種を組織し、その予防接種を国民に「無料」で提供するのである。この「予防接種レスキュー」がなく、永久にロックダウンされた状態では、市民の権利を制限することによる経済的・社会的な悪影響があまりにも大きいため、国民の間で恨みが募り続け、最終的には不安が脅かされることになります。だから、遅かれ早かれ、ロックダウンは終わらせなければならない。しかし、国家当局が、それ以上の説明もなくロックダウンや制限を撤回し、「結局、危険はそれほど大きくなかった」「制限は大げさで間違いだった」などとほのめかすようなことがあれば、住民の支持と信頼を大きく失うことになるだろう。したがって、政府の立場からは、最も厳しい規制から脱却するための、面目躍如たる「出口のシナリオ」が必要であり、それを提供するのが予防接種キャンペーンである。
国が提供するワクチン接種によって、国家は大きな脅威の物語を保持し続け、まだロックダウンから抜け出すことができる。それと同時に、ワクチン接種によってある程度正常な状態にしている救世主のように見せかけることもできる。そのためには、できるだけ多くの国民が予防接種を受ける必要がある。なぜなら、国民のほんの一部しか予防接種を受けていなければ、予防接種キャンペーンを開放に向けた必要なステップとして売り込むことができないからである。このように、国民の大部分にワクチンを接種してもらうことが国の利益になるのです。
この戦略が成功すれば、国家は前例を作り、権力を拡大し、さらに市民をより依存させることになる。市民は、国家が自分たちを死の窮地から救ってくれたと信じ、将来的には国家の助けが必要になると考えるだろう。その見返りとして、彼らは自由の一部を永久に手放すことを厭わないだろう。国が主催する毎年の予防接種のブースターが必要であるという発表は、市民の依存心を永続させるだろう。
マスメディアは一線を画し、予防接種のシナリオを積極的に支持している。
国家とマスメディアは密接につながっている。有力メディアによるフレーミングと、国民をターゲットにすることには、長い伝統がある。すでに1928年にエドワード・バーネイズは、その名著『プロパガンダ』の中で、大衆を知的に操作することを提唱していたのである。現代の国家では、マスメディアは、covid-19のような政治的措置に対する大衆の承認を構築するのに役立っている。
マスメディアが国家を支持するのにはいくつかの理由がある。国が直接所有しているメディアもあれば、規制が厳しく、国の免許が必要なメディアもあります。さらに、メディアハウスには国家教育機関の卒業生が常駐している。さらに、特に危機的な状況下では、政府との良好なつながりがメリットとなり、情報へのアクセスが優遇される。また、ネガティブなニュースや危険性を誇張して伝えることで注目を集めることができるため、国家の恐怖物語を伝えようとする姿勢も見られる。
コロナ事件では、ソーシャルメディアで拡散した一方的な報道が批判的な声を封じ込め、恐怖とパニックを引き起こし、国民に大きな心理的ストレスを与えた。しかし、メディアにとって魅力的なのはネガティブなニュースだけではなく、国家が国民を大きな危機から救い出すという物語もよく売れる。このように、ワクチン接種という物語は、マスメディアの思惑通りに動いているのです。
国民国家、メディア、製薬会社に加えて、超国家的組織もまた、世界の人口が確実にワクチンを接種されることに関心を持っている。
超国家的な組織は、世界的な予防接種キャンペーンが重要な役割を果たすようなアジェンダを積極的に追求している。これらの組織には、世界経済フォーラム（WEF）、国際連合（UN）、EU、国際通貨基金（IMF）、世界保健機関（WHO）などがあり、これらの組織は相互に密接に関係しています。
これらの組織の中には、目標として「偉大なるリセット」や「偉大なる変革」を掲げているところもあります。パンデミックや気候保護、ジェンダー、移民、金融システムなどの分野で、これらの組織は世界中のすべての人々の利益のために協調した答えを見つけようとしています。これらの組織は、責任の共有とグローバルな連帯を強調しています。ワクチン接種、気候変動、金融や移民の流れを中央で管理することは、新しい世界秩序の特徴でもあります。例えば、WEFの2019年の年次総会のテーマは「グローバリゼーション4.0」でした。Shaping a New Global Architecture in the Age of the Fourth Industrial Revolution" でした。また、超国家的な計画の例として、国連の "Global Compact for Migration "があります。国レベルでは、ドイツ地球変動諮問委員会のWelt im Wandel - Gesellschaftsvertrag für eine Große Transformation (World in transition: Social contract for a great transformation)政策文書に見られるように、こうした過激なアイデアが支持されています。
Raymond Unger（2021, pp.84-89）は、この超国家的計画の推進を、アントニオ・グラムシやハーバート・マルクーゼが想定した文化戦争の一環として捉えている。意見や怒りをグローバルに管理することが、特に気候変動やコロナの分野における恐怖やホラーのシーンと結びついて、新しい社会主義の世界秩序を確立する。実際、WHO、IMF、国連は元共産主義者が率いている。WEFは、製薬会社や大手ハイテク企業などのグローバル企業が出資しています。WEFは、国連の「2030アジェンダ」にも大きく出資しています。WHOもまた、製薬会社やビル＆メリンダ・ゲイツ財団から多額の資金提供を受けており、世界的なワクチン接種キャンペーンを先導しています。コビド19危機の際にも、製薬業界はWHOに影響力を行使した。また、IMFはWHOの勧告に従う場合にのみ国家を支援している。
これらの超国家的組織は、コビド19の危機を自分たちのアジェンダを進める機会と考えている。国連の政策文書「Shared Responsibility, Global Solidarity: 国連の政策文書『Shared Responsibility, Global Solidarity: Responding to the Socio-economic Impacts of COVID-19』は、covid-19を現代社会の転換点と捉えている。この機会をとらえ、世界的に協調して行動することを意図しています。大手ハイテク企業は、このようなアジェンダを支持しています。彼らはWEFのメンバーでもあり、マスメディアと同じように、自分たちのプラットフォーム（Twitter、YouTube、Facebook）で、covid-19に関連する不愉快な情報を検閲している。特にYouTubeでは、予防接種に批判的な動画はすぐに削除されています。
IMFのクリスタリナ・ゲオルギエヴァ理事の基調講演のタイトル「From Great Lockdown to Great Transformation」も、超国家的組織がコロナ危機を自分たちのアジェンダのために利用したいと考えていることを強調しています。WEFの創設者であるクラウス・シュワブは、コヴィド-19の危機は、"経済・社会システムの新しい基盤を築く "ための「貴重な機会」であると主張している。COVID-19: Thierry Malleretとの共著である『COVID-19: The Great Reset』の中で、シュワブは決定的な瞬間について語り、新しい世界が出現すると主張している。シュワブ氏によれば、今こそ資本主義の根本的な改革が必要であるという。
したがって、世界的に調整された予防接種プログラムは、偉大なリセットのための超国家的戦略の構成要素と解釈することができる。
世界的な予防接種の構造が確立され、それがその後の世界的な予防接種キャンペーンに利用されるのである。グレート・リセットを提唱する人たちの視点から見ると、世界的な構造と組織の必要性が強調されています。これらの組織は、「気候変動」に効果的に対処し、グレート・リセットを推進するなど、他の世界的な目的のために使用することができます。要するに、国家、メディア、製薬業界、超国家的組織が密接に絡み合っており、予防接種というストーリーに共通の関心を持っているのです。
当エントリはある程度の情報技術リテラシーが必須であり、一部の情報はPC初心者および初級者に推奨できるものではない。
しかしPC初心者および初級者はシステムを壊す、大事なデータを失うなどの手痛い失敗をして成長するのもまた事実であり、もしもプログラミングなどに興味のあるPC初心者および初級者がこの情報を活用する場合はシステムを壊す、大事なデータを失うことを覚悟して実行するように。
チュートリアルに指示通りに進めれば大きな問題はほぼ発生しません。
Chrome OSは初期状態のデフォルトで「ノーマルモード」と呼ばれる一般ユーザーモードですが開発者向けに「デベロッパーモード」が用意されています。
ノーマルモードはChrome OSの様々な制限があり、デベロッパーモードによって制限の解除が可能です。
しかしノーマルモードからデベロッパーモードへ移行するとPowerwash(初期化)されてしまい、システムやユーザー領域へ追加された情報はすべて削除されます。
もしデベロッパーモードが必要な場合はデベロッパーモードの詳細を調べ、現在の情報は削除されてしまうことを念頭に実行しましょう。
ちなみにProject CrostiniのLinuxレイヤーへDebianリポジトリからパッケージを導入するなどにはデベロッパーモードは必要ありませんので多くの場合はノーマルモードのままの運用で十分でしょう。
Android OSアプリやChrome OSアプリを開発したい場合は最初からデベロッパーモードにしたほうが後悔が少ないです。
Chrome OSでは一部のキーがほかのOSでは見慣れないものが並んでいます。
迷いがちなので一番最初に覚えるべきキーボードショートカットは「Ctrl+Alt+?」です。
「Ctrl+Alt+?」でいつでもキーボードショートカットを確認できることだけは覚えておきましょう。
多くのChrome OSデバイスはGoogle Play Storeへ対応しており、Google Play Store経由でAndroid OSアプリ導入が可能です。
しかしながらGoogle Play Storeへ公開されているAndroid OSアプリが必ずしもChrome OSへ最適化しているのか？と言えばそうではなく、Android OSアプリの開発環境であるAndroid StudioがデフォルトでChrome OSでの実行を許可していることもあり開発者が意図せずChrome OSへインストールできてしまうことが大半です。
したがってChrome OSへ導入するAndoirdアプリの動作へ何らかの不具合があったとしても脊髄反射で酷評せず、やんわりと丁寧に博愛精神をもってChrome OSではこうだとアプリ開発者へ情報共有することをオススメします。
多くのAndroidスマートフォンやタブレットはARMアーキテクチャーと呼ばれるものを採用していますが、現在のChrome OSデバイスは高性能な製品になるほどx86(x86_64)アーキテクチャーを採用している傾向があります。
本来コンピューターアプリケーションというものはアーキテクチャーが異なると実行起動動作が不可能ですが、Android OSアプリは異なるアーキテクチャー間でもアプリの実行起動動作が極力可能となるように互換性をだいたい確保しています。
しかしながら例えばARMアーキテクチャー向けのAndoird OSアプリをx86アーキテクチャーなデバイスで実行するとアプリ動作のパフォーマンスが著しく落ることが多いです。
これは高度なグラフィックス機能を必要とするゲームなどで顕著に現れる傾向にあり、Chrome OSでは期待したほどAndroid OSアプリが軽快に動かない可能性を理解しておく必要があるのです。
コロナ禍によって多くのChrome OSデバイスを販売することが出来ましたが、それによってChrome OSデバイス間の性能差が問題視される機会も増えました。
具体的には「インターネット上でChrome OSでの動作報告がなされているAndroidアプリが自身のChrome OSデバイスではインストールできない」といった報告です。
これは一部のAndroidアプリ開発者がデバイス性能によってインストールの許可不許可を決めているために起こることで解決方法は基本的にありませんので諦めましょう。
これから導入するAndroidアプリのためにChrome OSを購入する際は価格につられて低性能すぎるデバイスを購入してしまうと失敗する確率が高まりますので注意が必要です。
ただし、Googleが提供するアプリなどは基本的にそのようなことは無いようです。
設定から「Linux（ベータ版）」で「オンにする」とLinuxのインストールが開始されます。
現在のChrome OS v90ではLinuxレイヤーを実現するProject CrostiniではデフォルトでGPUによる支援機能を実行できません。
Chrome Webブラウザを起動し、URL欄へ「chrome:flags」と入力しアクセスして「Crostini GPU Support」を「Enabled」とし再起動してください。
この変更で動作に不具合を確認した際は設定を元に戻してください。
LinuxにもGoogle Play Storeのような簡単にLinuxアプリを導入できる環境が存在します。
GUIパッケージマネージャーを導入する場合は「ターミナル」を起動し下記を実行してください。
sudo apt install synaptic gnome-software
Chrome OSとLinuxレイヤーではパッケージの導入先がデフォルトで海外のサーバーになっており少々遅いです。
日本国内のサーバーへ変更することで速度を改善できる可能性があります。その際は「ターミナル」を起動し下記を実行してください。
現在のChrome OS v90ではChrome OSとLinuxレイヤーを実現するProject Crostiniで日本語入力を共有できず、キーボード入力しても英字しか印字されません。
日本語入力をするには別途に日本語インプットメソッドと日本語フォントが必要です。
日本語インプットメソッドと日本語フォントを導入する場合は「ターミナル」を起動し下記を実行してください。
Linuxへ詳しい方はfcitx5のほうが何かと問題が少ないでしょう。
しかし一部のfcitx5向けパッケージがDebian公式リポジトリに存在しない可能性があるのでご注意ください。
KVMやLXC、Dockerなどの仮想環境を幾度か試しましたが、仮想環境を構築したProject CrostiniのLinuxレイヤーを再起動するなどによってProject CrostiniのLinuxレイヤーシステムへ致命的な破壊が起きることがあるのを何度か確認しています。
Project CrostiniのLinuxレイヤー自体が仮想環境のため、Chrome OSのシステムが破壊されるわけではないですが業務利用時にLinuxレイヤーシステムの破壊が起きてしまうと困ってしまうので仮想環境構築は推奨できません。
仮想環境によって開発環境の統一を計っている現場では開発デバイスとしてChrome OSデバイスは利用しないほうが良いでしょう。
ただし、Chrome OSデバイスは実質的にAndroid OSデバイス、タッチスクリーンデバイス、キーボード付きデバイス、タブレットデバイス、ノートPCデバイス、コンバーチブルデバイス(いわゆる2in1)、マルチタスクデバイス、ウィンドウ可変デバイス、タッチスタイラスペン付きデバイスとして機能する可能性を秘めていますので実機デバッグ用デバイスとしては非常に価値があります。
昨今はアスペクト比が16:9でないどころかリアルタイムに可変してしまうデバイスが物凄く増えていますのでスマートデバイス向けアプリを開発する現場ではデバッグ用として1台持っていても全く損しないデバイスかと思われます。
さらに言えばティーン層はGIGAスクール構想によりChrome OSでプログラミング学習をしているわけですからティーン層取り込みのためのUI開発にも使えるのではないかと考えます。
Linuxフリークでもそうでも無い人でもLinuxへ多少の知見があればエントリのタイトルが目に入った時の声はたった1つだろう。
「は？」
これは良くも悪くもLinuxのデスクトップOSとしての評価を如実に表している声だ。
不便・不安定・不親切、おおよその一般ユーザには全く推奨できず、不具合の解消はLinuxユーザ自身の問題解決力が問われる。
しかしそんなLinuxは不気味なほど一部のパワーユーザからは絶大な支持を得る。
Chrome OS上のLinuxはProject Crostiniと呼ばれるプロジェクトの成果によりChrome OS上でLinuxの動作が可能となってきたが、これまでBeta版扱いだった。
正直に言って誰しもがChrome OS上で動作するLinuxは永遠にBeta版であろうと考えていたと思う。
結局は好きものなLinuxフリークのために用意してくれていたお遊びであって、GoogleとしてはProject Crostiniを本気で活用する気なんて無いのだと知った気になっていた。
なに、そもそもChrome OSもAndroidもLinuxベースOSだ。Linuxの上でLinuxを動かしているに過ぎないし、Googleはすでに我々へLinuxデバイスを多くリリースしてくれているではないか。高望みはいけないのだと諦めていた。
しかし違った！違ったのだ！GoogleはProject Crostiniへ本気だった！
ついに、ついに、ついに！家電量販店でLinuxデバイスがいつ行っても買える時代がやってきた！
Androidのように自身がLinuxディストリビューションであることを一般ユーザのために隠しているOSとは意味合いが全く違う。
むしろAndroid StudioをインストールしてAndroidアプリを開発するOSだ。足りないパッケージをAPTからインストールするLinuxディストリビューションとしてのOSなのだ。
あぁ何とでも言えば良い！
Chrome OSのLinuxレイヤーはChrome OS側のIMと連携できなくてLinuxレイヤーは独自にFcitxなどのIMを導入する必要があるって？
んなもん知っとるわ！それがどうしたぁ！！！
仮想環境であるLinuxレイヤーへKVMなどを導入しLinuxレイヤーを重ねて構築すると不安定になり全てのLinuxレイヤーが致命的に壊れることがあるって？
もうそんなことは何度も繰り返してんだよ！壊す前提で実験しとるわい！！！
バカにされたって罵られたってChrome OSのLinuxが正式版になったんだよ！！！
ありがとうLinuxフリーク！ありがとうお前ら！ありがとうGoogle！ありがとうドザー！ありがとうマカー！
#COCOAボランティアデバッグ に尽力されている皆様に深い敬意を表します。
併せて、 OSS コミュニティへの悪影響を残している関係行政機関・各社担当者を強く軽蔑します。
project dead? · Issue #773 · Covid-19Radar/Covid19Radar · GitHub
(注) これはアプリケーション固有の問題ではない( Apple-Google API の問題)が、前項の問題点と併せることで脅威となりうるので便宜的に示しておきます
※一部で報じられている「保健所から COCOA への陽性情報の登録に必要な処理番号が即日発行されない」などの問題もありますが、ここでは省略します
※以下はあくまでシミュレーションであり、 COCOA の悪用を助長する意図はありません
細かい説明や具体的な表現は控えましたが、この攻撃を仮に受けたとして致命傷に近いダメージを受ける事業者は少なくないと思います。
事業所単位で COCOA の導入を推奨している管理者は直ちに見直すことを推奨します。
本日より COCOA の導入を促すテレビCMが放映されているようです。（ #検察庁法改正案に抗議します で一躍有名になったきゃりーぱみゅぱみゅ氏などが出演されているようです）
一方で COCOA アプリケーションのリリースは 2020年7月13日 にリリースされた v1.1.2 を最後にアップデートが途絶えており、不具合ととれる多数の事象は解決されず、上記に挙げたような問題点が払拭されることも残念ながら当面は無さそうです。
世間では高ぶる正義感からか COCOA の導入を声高らかに勧めたり、従業員やビジネスパートナーに導入を強いている管理者も現れているようです。
このエントリを通じて、そのような方々へ抵抗出来る材料が提供できれば幸いです。
冒頭のように COCOA の原型であるとされる Covid-19Radar/Covid19Radar プロジェクトも OSS にあるまじき「放置状態」が続いています。
これが GitHub を買収した企業に所属する人間の所作ですか？
IT/ICT や OSS を通じて昨今の COVID-19 感染拡大を発端とする諸問題を解決する動きは支持したいですが、このような杜撰なサービス運営により IT/ICT や OSS に対する世間の期待を悪化させることを強く憂慮しています。
Allowed countries
AE - United Arab Emirates
AL - Albania
BE - Belgium
BG - Bulgaria
BI - Burundi
BM - Bermuda
BN - Brunei Darussalam
BO - Bolivia (Plurinational State of)
BZ - Belize
CD - Congo (Democratic Republic of the)
CH - Switzerland
CK - Cook Islands
CN - China
CO - Colombia
CR - Costa Rica
CY - Cyprus
CZ - Czech Republic
DE - Germany
DO - Dominican Republic
EE - Estonia
EG - Egypt
FI - Finland
FK - Falkland Islands (Malvinas)
FM - Micronesia (Federated States of)
GB - United Kingdom of Great Britain and Northern Ireland
GG - Guernsey
GH - Ghana
GN - Guinea
GS - South Georgia and the South Sandwich Islands
HK - Hong Kong
HM - Heard Island and McDonald Islands
HT - Haiti
HU - Hungary
IN - India
IO - British Indian Ocean Territory
IR - Iran (Islamic Republic of)
JE - Jersey
JO - Jordan
KE - Kenya
KI - Kiribati
KW - Kuwait
KZ - Kazakhstan
LA - Lao People's Democratic Republic
LB - Lebanon
LI - Liechtenstein
LK - Sri Lanka
LR - Liberia
LU - Luxembourg
LY - Libya
ME - Montenegro
NO - Norway
NU - Niue
OM - Oman
PE - Peru
PL - Poland
PM - Saint Pierre and Miquelon
QA - Qatar
RE - Réunion
RS - Serbia
RU - Russian Federation
RW - Rwanda
SC - Seychelles
SH - Saint Helena, Ascension and Tristan da Cunha
SK - Slovakia
SO - Somalia
SZ - Swaziland
TF - French Southern Territories
TJ - Tajikistan
TL - Timor-Leste
TN - Tunisia
TO - Tonga
TR - Turkey
TZ - Tanzania, United Republic of
UG - Uganda
UM - United States Minor Outlying Islands
US - United States of America
UY - Uruguay
UZ - Uzbekistan
VC - Saint Vincent and the Grenadines
VE - Venezuela (Bolivarian Republic of)
VI - United States Virgin Islands
VU - Vanuatu
YE - Yemen
ZA - South Africa
ZM - Zambia
ZW - Zimbabwe
優待席を用意してもらってて、満員だから座れないなんてことは起こりえないように努力したのに
満員で座れなかった私頑張ってるとか意味不明なアピールに使われたから
いやいやあんた優待席用意したんだから座れましたよね？って事実を指摘しただけじゃねーのか？
そしたらグレタ側の反論が、列車を突っ切って移動しようとしたから座れなかったとかいう反論でしょ？
俺からすれば、グレタ側の言い訳がひど過ぎると思うんだが？以下原文な。俺の理解は間違っているか？
グレタ：
Traveling on overcrowded trains through Germany. And I’m finally on my way home!
Liebe #Greta, danke, dass Du uns Eisenbahner im Kampf gegen den Klimawandel unterstützt! Wir haben uns gefreut, dass Du am Samstag mit uns im ICE 74 unterwegs warst. Und das mit 100 Prozent Ökostrom. 1/2
Noch schöner wäre es gewesen, wenn Du zusätzlich auch berichtet hättest, wie freundlich und kompetent Du von unserem Team an Deinem Sitzplatz in der Ersten Klasse betreut worden bist. #Greta 2/2
グレタ：
Our train from Basel was taken out of traffic. So we sat on the floor on 2 different trains. After Göttingen I got a seat.This is no problem of course and I never said it was. Overcrowded trains is a great sign because it means the demand for train travel is high!
